Redundant Code Is the Enemy

This will be a pretty short-ish bare-bones post as I up to my neck in cleaning up my code, double checking everything whilst trying to put more stuff in I’ve set myself a few short term deadlines and goals in order to focus my efforts in the near future. Coming up this Saturday (only 4 more days!) I am doing a testing session at a friend’s house (no one lives near me). So far I have 8 victims/volunteers, which hopefully should grow as the day approaches.

While I have had a singleplayer test/practice mode in the game for sometime the game is designed around people playing against people. It’s hard to emulate how a normal person reacts in simple code and some randomised elements don’t effect the AI at all. While I’m not saying it’s not possible, it’s just not feasible because I am not an expert in AI. I know this sounds rather vague and roundabout but hopefully when you do get your hands on the game you will understand what I mean.

So far I am on track despite having to restructure large parts of my scripts. When I started making a prototype build for Readapt I only had two player support and about a half-dozen random modifiers. I also had a specific scripts unhelpfully called “Player” and “Player_2” one for each player, which contained code responsible for movement, weapons, abilities and movement. Suffice to say when you have four players, each with their own unique and massive script troubleshooting code and implementing new content is a pain.

In the last day and a half I have managed to generalise the player script, so each player refers to the same script. This means if code is bad it should show up on all players, instead of being specific to one player. I also divided the player script into smaller scripts, the original player script still contains all code relating to movement, score overlay, hp overlay and collision detection. However, weapon and abilities have their own scripts which again are scripted to work on all 4 players.

So what does this all mean and why did I bother? There is like 30% less code, less redundancy and scripts are better organised. This will mean less time scrolling around in code and actually coding. It means that I only need to implement things once and test them once, instead of four times. Why didn’t I do this from the start you may ask? It had occurred to me earlier when I was prototyping, except my skills in C# and in Unity were even more rudimentary than they are now and were simply not up to the task. I am still learning as I do everything more or less for the first time. At times things can be a bit daunting but I enjoy the process of learning which I find pleasantly addictive.

That’s it for now, I recorded another podcast episode last Sunday and I’ll blog again when it’s up. I’ll probably post about the upcoming testing session afterwards too. I aim to implement the feedback and more content in the following week and if all goes well I’ll put a public build out. I hope the game holds up, doesn’t crash, bug out or catch on fire.

Wish me luck!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s