Optimize for Everything

If you are a game programmer, you probably have an instinctive desire to optimize your code so that it will run fast.

Or you might want to optimize it so that it takes up less space in memory. Often, though, the key to getting code to run fast is to use more memory, and the key to compressing your memory usage is to bog the code down.

This trade off between speed and space is well known to every code-monkey out there. But consider that there are other factors you should optimize for as well.

The Joy of Dirty Coding

I've been making games since I was a teenager, but for several years I was stuck in a rut. I just couldn't finish anything. Then I bought a book: Building XNA 2.0 Games by James Silva. (Sadly, not an affiliate link. Amazon won't pay people in my home state for pimping out our favorite books.)

The book shocked me to my core. Why? Because in many cases, Silva's code was worse than mine. Messier.

I, mind you, am entirely self-taught. I, mind you, am disdainful towards industry standards despite the fact that I haven't properly learned how to use them, what they are for, and why they have become the standard.

Silva is none of these things. He's well-trained and he was working with one of Microsoft's dark archons when he wrote the book.

Silva was simply optimizing for something else: finishing a game. He was making his code as clean and nice as he could while still putting only the amount of effort into it that he could sustain through the completion of the game.

Jon Blow in a speech I can't find right now calls this optimizing for years of your life. His example was code for (I think) Doom where a straight, linear search was used to find assets rather than a hash table. When he saw the code, he thought "that's not optimal. A hash table would be much faster."

Ah, but would the extra time taken to code a hash table have prevented the game from being released?

The Joy of Clean Coding

You also have to optimize for maintenance and teamwork. So there's an argument for the good coding practices that I just hinted you should discard. In fact, just as obsessing over clean coding can keep you from finishing the game, obsessing over dirty coding can trip you up too. Almost nothing you write for your game will be one-and-done. The cleaner it is, the easier it will be to fix when you inevitably have to go back and add this or that bit of functionality.

If you're working on a team, it's also wise to optimize for not getting axe-murdered by grumpy teammates. A lot of times, in this space, you will see me write "Hey, here's this neat thing I do:" followed by a, "warning: this is not vetted for passing your programming classes or certifications or for keeping a job." I can get away with dodgy practices as a lone wolf. But being a lone wolf also severely limits the scope of what I can accomplish. Legend of Zelda: Breath of the Gameboy is pushing my capabilities to the limit. Grand Theft Skyrim is, and will likely always be, far, far out of my reach.

If you want to make those giant, epic games, you need a team. If you want a team, you have to optimize for teamwork.

Cross the Finish Line

So there's another optimization balance: cleanliness and teamwork versus just getting it done. Presumably, as you improve as a coder, you'll get better at finishing things and making the code cleaner and easier to work with at the same time. As you make games, though, you always want to seek that balance point. Do you need to push on? Do you need to tidy up a bit? It's a call you have to make.

This is one reason indie game developers ought to start with Space Invaders rather than Grand Theft Skyrim. The bigger your game is, the cleaner your code needs to be. The cleaner a newbie makes his code, the farther off the finish line gets.

And the one thing a one-man team must optimize for above all is crossing the finish line.

At the same time, if you aren't making a game that you want to bring into existence, you are killing your motivation to work, which is again, sub-optimal. This is why I work in XNA/Monogame instead of Unity even though Unity would probably be faster and certainly be more convenient. The Unity finish line is closer, but whenever I step onto that track, I stop moving.

After reading Silva's book, I forced myself to let the cruft and terribleness build up in my code and just forge on. As a result, I released a passable space invaders clone into the XBox 360 indie market where before I would have given up before I was finished.

My next game will be better. But I can say "my next game" because I've already finished a game. This wouldn't have happened if I hadn't optimized for crossing the finish line.