Postmortem
While Zulu Hour was not my first game, it was my first fully-featured game. Fully- featured, as in, ready for prime time. It works like a player would expect it to. This is not to say it is a good game (though I think it is). Fully-featured is the difference between Deus Ex and Starcraft Ghost. I’m sure somewhere, in some archived repository, there is a playable demo of DNF, but it just isn’t “finished”. It might have a memory leak, it might require a console command to start a level, or it might crash if the player tries to save his/her progress. It doesn’t matter how good Starcraft Ghost would have been; if it’s never released then what good is it? Well, I’ve found even if you think your game is 80% complete, you may very well have 80% to go. The leap from playable to releasable is huge.
Making this game was always supposed to be a learning experience, and it was nothing if not that. I learned so much it’s difficult to decide where to begin, so I’ll start from the beginning. Unless you’re James Silva, and have insane talents both artistically and technically, you need to get a team. Actually, I should elaborate on “artistic”: unless you are familiar with, and good at, creating game art, get a team. I’ve had some modeling experience, but the day I got my first asset from Karl, it was painfully obvious my game art should never see the light of day. However, the fact that I started out making my own assets was a huge advantage, and is one of the most important pieces of advice I can give: get a prototype of your game working before you start looking for an artist. The reasons for this are numerous. First, it shows potential teammates that you are serious about making (read: finishing) the game. Second, it gives a feel for the game. Is it slow and grinding or frenetic? A good artist will pick up on the style of the game and make the art fit. And third, it gives you a head-start on the code. Having art sitting around waiting to be used is not a good thing. The artist is more likely to get bored, and the programmer could quickly become overwhelmed with all the assets that need to be used.
Another lesson learned: get a good art pipeline. If your artists can’t get their assets into the game by themselves, you’ve got a problem. And don’t blame it on the artists. You’re a programmer; you make software that is supposed to make people’s jobs easier. So, do it for your artists! If they can easily tweak their art and see instant results, you’ll get infinitely cooler and prettier results. Also, along these same lines, fast prototyping can be huge. For us, Karl is good with Flash, so he made quick mockups of his ideas so I could replicate them in our engine. Explosions, pop-up messages, etc. were ridiculously easy for me, because I was merely making my effects look like his.
Of course, I learned copious amounts of technical things over the course of this project, but most of them you can learn at Riemers or the XNA website. However, some you won’t. For one, and I may get some nasty comments about this, I somewhat disagree with Shawn Hargreaves’, “don’t optimize until you have to.” Whenever possible and feasible, optimize in-line. If I use foreach loops and new strings everywhere when I’m developing, the last thing I will want to do is replace them later. I might tell myself, “it’s just for now” but I’d be lying. In my opinion it will be just as readable, and you won’t need to do regression testing. Now, I realize Shawn was probably advising against running NProf everyday and accounting for every drop in framerate, and I agree. You can easily start worrying too much about performance and try to figure out why it was just cut in half – even though you’re still getting 150 fps. However, if you wait until you’re at 5 fps, you’re going to give yourself migraines trying to boost your performance. Perhaps you’ll find a much faster way to render dynamic vertex buffers in the beginning and use it throughout your game.
I’m going to try to restrain my gag reflex and end on somewhat of a cliché: beware of scope creep. If the words MMO, FPS, or RTS are in your plan, seriously reconsider. I’m not saying it’s impossible, but I’ve learned it is so much better to release a breakout clone than just a tech demo of an elf running around with a dagger. For your first couple games, just release something that works and is fun. You’ll learn a lot, have a finished product you can show off, and you’ll be much more likely to have energy for another. This being said, don’t be afraid of tiny creeps here and there – it could turn out to be your game’s secret sauce. Your teammates and friends will undoubtedly have suggestions for your game. Use your judgment, but I think a good rule of thumb is if you can’t make a prototype of the idea in a week or less, it’s probably too big. I made the basic chase scene for Zulu Hour in about half a week. It was instantly fun, and added a very unique aspect to the game.
I have realized this turned out way more preachy than I intended. These are simply lessons learned from our first released game, and they may or not apply to other projects. Overall, I had a great time making Zulu Hour, and I hope people get some fun out of playing it.