Three Lessons Learned

So I think I mentioned in my last post (two months ago?) that some buddies and I were working on a tower defense game that we hoped to demo at an upcoming conference in September. As you may have noticed, September has almost come and gone but I haven't posted any stellar updates detailing the success of our demo at said conference.

Part of this is due to an unavoidable stall in development progress, which brings me to my first lesson learned. When I realized the ever-increasing scope of the game I would soon be writing, I should have pulled in more developers. As it is, I am currently the only programmer among a group of two 3D artists, two concept artists, and one musician. Although there is a certain amount of pride in being able to take full ownership of the (increasingly large) code base, there is also much to be said for having a fellow to bounce ideas off of and having someone to share the load when you're not available.

Another thing that's bitten us in the development of our game is not understanding core requirements in the beginning. We think we have a great idea for a game and started prototyping the basics right away. For a simple tower defense game, you have enemies moving from one end of the screen to the other, and that's what we created initially as a 2D game. Once we had this basic prototype, we realized that it was pretty darn difficult to make projectiles with faux-depth in a 2D isometric view look right. So we had to make the leap to the third dimension, which involved converting our 2D sprites into 3D rigged/animated/textured models. We started creating 3D animated models right away before adding concept artists to the team; so the models had to be recreated. But once we had our concepts, we needed to make specific decisions regarding Art Style - the overall game appearance - and this required new models yet again. As a programmer I occasionally overlook these finer details; I mean, if all the characters on screen are moving to their correct destinations... it looks good! But the second lesson I've learned is that Art Style is something that should be seriously considered early on in a game's development.

Performance is also a major consideration for our game. Although we want to have the best-looking game we can build, we also want it to be playable for as many people as possible, so limiting it to the highest-end graphics cards didn't seem right. And given the fact that I was developing the game on a laptop with only 32MB of dedicated video memory at the time, I had a big problem creating a game I wouldn't be able to play! So we took a step back and realized that our 3000-polygon models probably weren't going to cut the mustard. But even with reduced-poly models, we wanted to do some fun stuff in our game like using outlines on our toon-lit models, particle effects, etc. And some of these special effects are expensive operations that quickly drop frame rate and can cause the game to lag. So as our designer likes to say it, the final lesson for today is to "prototype everything." Although he doesn't really mean to prototype everything. What should really be prototyped is all of the core systems of a game that could be rendered/executing together at the busiest point of the game's interaction: music, sound effects, lighting, particle effects, blur effects, and so on. And provide a way to instantly, with the push of a button, drop a hundred or more models on the screen to simulate the game at its most computationally-intensive point to see how it will perform in the worst-case scenario. Doing this type of prototyping early on can help identify where you need to save polygons or cut features that could prevent your intended audience from playing your game.

The cool thing about my team is that we're all learning as we go, and sometimes part of that involves looking back and saying "You know, we could have..." So I hope this helps as you start your next project.