The art of game development refactoring

Every thing that starts with “The art of…” sounds so cool doesn’t it? Can’t say I’m a real master at what I’m about to write. This “vision” appeared before my eyes when I made a question about game loop performance techniques in the Portuguese game development community. Out of many answers, one had this pearl of wisdom:

Make it work, make it nice, make it fast!

And I’ll be damned if this simple sentence didn’t influence me since that day… not so long ago.

How I handled my code before…

To put it in simple terms: my code was written to be as close to the end form from start. I coded all the possible performance tricks immediately, wrote reusable code asap and my refactoring was usually very short. This made all well planned projects to be coded in very short terms.

I always had one major problem though: every time the project needed one or more deeper changes I had to recode a lot and, naturally with the same degree of “end code” vision. This means that I used to pre-plan too much and that my code changes were not that agile. More than often this meant that the game was slave to the code and not to the design and this is usually a game killer.

After that sentence, all was different…

Make it work

First objective of every line of code: making it work, no matter what. Is it slow? Is it ugly? Often yes! Does it work? YES! And this is a good thing. Code that works as soon as possible offers you the possibility of being able to access if you need changes or not sooner. This is very important in game development, especially short development like with flash based games.

You will go through all the same design issues, but you’ll do it sooner, you can adapt sooner. That’s the whole point of agile development: you can make changes without compromising features changes or feature additions.

It is very important that you don’t do anything stupid, like having duplicated code. Be fast, don’t be sloppy. It’s OK if you are not paying attention to a lot of details and you are writing in the easiest possible form, but it is not OK if you are copy/pasting code and this is just an example.

Is it has intended? Is everyone happy with the current form?

If yes, refactoring is in order…

Make it nice

If everything is according to plan, you can, you should and you will (I command thee) refactor your code to make it nice. I’m very fashion victim code wise. I like my variables of the same context to have the same length for instance, but it is more than enough if you comment your code, cut the loose ends and have your code ready for you to forget about it. That’s right, move it away from your brain, you’ll need the room for the next iteration. If it is well documented and easy to read, you can return to it anytime.

Here’s a good cliche: Hold in your brain only the things you can’t have written down.

Make it fast

Well… now it’s the tricky part. Your code is probably not the fastest thing in the world, why? Well, you made what you were supposed make, you probably added changes to it, you commented it and made it nice and tidy, but maybe you have some stuff there that could use a little help. Actually I’m pretty sure you do. This is due mostly to the fact that making it work as fast as you can usually doesn’t mean you made it as fast as it can work. Wow… am I on a cliche thing or what?

Every piece of software needs its own set of performance tweaking. It can be anything really.

A world of performance tweaking stuff has been written, maybe I should add mine also one of these days, but there are things that are pretty common.

Heavy calculations come to mind… it’s quite common to use really heavy math operations on a per frame basis instead of pre-calculating this kind of stuff. If you have dozens of objects calculating sines and cosines, making divisions, calculating distances and so on, you will have a lot of performance tweaking ready to be made.

Object creation is a major issue with Actionscript also. A lot of the code snippets I find have new objects created inside some methods that are supposed to be called most if not all frames.

Another common issue is that a part of your code is bottle necking the rest, often causing frame drops. Identify what causes the bottleneck, then either run it from time to time, use a maximum iterations value or segment it in your game loop.

I guess I should just write some optimization articles soon or I can be here forever…

See you all soon,
Vlad