So you’ve tracked down every computer genius you can find, managed to get fifty million dollars in funding, and come up with the perfect computer game, one that will make you millions upon millions of dollars. We’re talking about
Now, let’s be honest, it can’t be THAT hard to write a computer game, can it? Well, you do need to plan out how it’s going to be structured… and you need to make sure it’s not hackable… and it needs to be as efficient as possible… Let’s face it, writing the code is at least as difficult as coming up with the design documents.
In the last installment I briefly mentioned a Game Design Document. There’s also a Technical Design Document, which contains all the technical specs of the game. This is where you write down the skeleton of the engines and how they interact, the requirements you need to meet or exceed, the specs of the server if you’re running an online game, and an entire host of other statistics.
This document could very well end up being over three hundred pages, but it will save you much time in the long run for the obvious reason: it’s all organized for easy reference. I’ll probably have a later column dedicated to this document, but I haven’t thought that far ahead yet.
There are a few requirements for the code that aren’t as obvious as they should be. In fact, they’re often completely overlooked, which causes much chaos and mayhem in the long run. Here are what I feel are the most important aspects to your game code, or indeed to any computer code at all.
From here it gets pretty geek-oriented; you have been warned.
First of all, and most importantly, make sure everything is well commented. I was working Quality Assurance at a small company for six months, and their biggest project was several thousand lines of uncommented code. When the lead programmer for that project moved on, it took two weeks for the next coder to figure out what anything did.
Commenting code is absolutely essential, no matter what the coders tell you. Most programmers, myself included, don’t like to comment code. After all, why should they comment code they’ll probably be the only people to ever see? It must be commented because the odds are they won’t be the only people who need to know what it does, and an hour commenting will save a week decoding when that happens.
Not only should you comment code, but you should actively plan for the possibility of coders moving on. The easy way to do this is to make sure all pieces of code are understood by at least two people. This way, if person A gets hit by a truck or two, person B can step right in to replace them. Then, if person B gets struck by lightning a bunch of times, the comments will help person C learn what the code does, while he actively dodges unstable staircases.
Don’t worry about leaving the comments in the final compiled version of the code. The compiler will ignore the comments and just skip right over them, leaving the compiled code indistinguishable from code that didn’t have comments in it. If your programmers don’t know this, they’re probably the wrong programmers for your game.
Next, it’s important to make sure your code is simple. If five lines of code will get the job done, don’t use fifty. Shorter code is easier to comment, and harder to hack undetectably. I’ve personally seen code that was ten times as long as it needed to be, and the programmer had no clue it could be shortened as much as it could.
Your code should also be a little bit modular wherever possible. If you can group many lines of similar code in to one set of code, it should be done. Wherever code can be reused, make sure it happens. Just keep it well commented, so future coders will know what they’re looking at and where things go.
Make sure all code exists in at least two places. If the server spontaneously combusts, you need to have backup copies of everything so you can restore it all quickly, or else you’ll find yourselves very unamused.
Similarly, make sure all coders store a copy of all their code on the main server, so the company has a copy of it all. This isn’t as intuitive as you might think, as we’ve had coders actually refuse to put their code on the company system. Both ends of this idea must be enforced.
Finally, the code should be easily extendable. If the game does really well, you want the ability to create an expansion for it, right? That’s much easier to do if you design your code to hold that capability down the line. Otherwise you might need to rewrite large portions of the game, and who wants to do that?
So those are the basics of code creation, and the last of the four essential building blocks of game design.
[B]Disclaimer:[/B] Behind the Veil was written by Chris Marks and hosted by Diabloii.net. The opinions expressed in these columns are those of the author, and not necessarily those of Diii.net.]]> Related to this article