I was talking to a colleague yesterday. He was putting together a library of 3D sprite-type routines for games. He was at odds with another colleague about how to proceed once the library was complete. One wanted to take the Roger Corman approach and write a dozen games with it. The other wanted to write a single large-scope game. Interestingly, they are putting off making what would appear to be a very important design decision, because they were still trying to get the underlying library just right. I think this underscores the importance of working with a robust library of code --sometimes the quality of the library is even more important than the vision of the game itself!
Of course, the need for mature and robust libraries is more important if you plan to write several games with it. Even if you plan to only write one game with your library, it's still important to make it robust, generic, and bug-free. If your base library is good, you probably will end up using it again in one way or another.
After all, there wouldn't be a Y2K problem if throwing away old code was the norm :)
Use mature code libraries for as much stuff as possible.
By "mature", I mean something that's been around a while and is fairly debugged, whether it's written by you or it's written by a third party. The stuff my games are built upon are about 50/50. About half of it is an old German cross-platform class library. The rest of it is a bunch of game-specific stuff that I wrote on top of it over the past few years. By putting as much stuff as possible in a library, you get a lot of reuse. With the reuse, you will eventually end up with nicely bug-free apps that you can make quickly.
A couple of days ago, I ran some metrics on my code. Here're the numbers I got. . .
My library (not the German class library, just the game-specific stuff) = 5104 lines of code
My Longest game (Backgammon) = 1661 lines of code
My Shortest game (ChessCards) = 392 lines of code
Average game = 871 lines of code
Putting this in Roger Corman terms, if ChessCards was a 90 minute movie, 83 minutes of it would be stock footage. If you think that getting 392 lines of code working and debugged is pretty easy, you're right.
Find or write a mature library that's got the bugs fixed, and stick with it!
Comment your code as you write it!
You certainly don't have to make your code-weight 50% comments, as is common in college assembly courses, but it is important that you comment the tough spots and interesting bits. Much as you won't want to, you will have to revisit your code later during the coding or debugging process. If you're smart and you comment the trouble spots well, your life will be made much easier later. When I'm in the process of writing something really hairy (like a recursive search routine or a loop several levels deep), I like to pseudocode the whole thing in comments first like this. . .
// loop through every enemy
// first, check to see if a player's bullet has hit the enemy
// if the enemy is hit, remove him from the list
// otherwise, see if he has a bullet available and can see the tank
// if he can, fire the bullet
// check to see if the enemy is at an intersection
// if so, turn or go straight
// finally, update the enemy's position
// and move to the next enemy
Then, write the code to perform each step under the comment. For example, the code above is pseudocode for the loop in Think Tank in which all the enemies update themselves. It took about 150 lines of code to actually do all of the stuff mentioned. If I just wrote the enemy-update loop top-to-bottom without a plan, it probably would've been more code and time to do it.
Comments not only provide a way to see what you were doing later, they can be used as a planning aid for getting stuff done. They don't increase the ultimate size of the compiled code, so take the time to write 'em as you're coding.
