This game was called “Game3″ just because this is the 3rd XNA project I’ve opened on this computer, and that was the default name.
I’ve put in somewhere between 500-900 hours into this project (schoolwork being mixed in there makes it hard to estimate), and I think that I’ve been very productive in that time. The project is now 8300 lines of code, in about 187 class files.
So, why didn’t I finish in time for DBP? Here are some of the mistakes I made:
- Overambitious project goals.
- Picked wrong light rendering design for the design of this game.
- Underestimated the complexity of implementing some design ideas, such as the terrain, and the lighting set up.
- Focused too much on building clean, pretty code, instead of hacking together a finished game.
- Spent too much time building the game engine, and too little time building the actual game logic.
- Spent two weeks building my own physics engine from scratch, instead of using an existing engine.
Here’s a composite of a few screenshots of my Git commit history:
I tried to choose a game concept that was as simple as possible, while still maintaining some of the key elements from my 100+ page outline of a much more complex game.
That said, I was still far too ambitious for a 3 month project. I think that any 3D game that can be competitive with a 2D game is going to take a lot of extra time to polish well. For example, I didn’t realize how much time triplanar normal mapping would take to get right. It’s simple in theory, but getting the slope angles just right, getting the transitions between texturing planes just right, mapping the normal maps onto the correct plane, etc, etc, all took a lot of extra time.
Before deciding to do this project in first person 3D, I read that many people avoid indie 3D games because creating the artwork takes so much longer (or they can’t do it themselves). As one example, it took me about 45 minutes to create the doll enemy model (pretty quick, no?). I figured, well, I can create a 3D model of an enemy in ~45 minutes, so 3D artwork is not a big deal — I’ll just go make the next Halo now!
In reality, the artwork is no big deal. It’s really everything but the artwork that makes 3D much more work than 2D, especially from a first person perspective. When I say “artwork” I mean 3D models, textures, texture mapping, animations.
In a first person perspective, you can see thousands of meters into the distance, but also if the player looks straight down at the ground, since only a 1-2 meters are viewable, we expect to see a great deal of detail. Managing detail at close and far distances well is an order of magnitude harder than managing detail in a 2D game. In a 2D game, or even in a 3D game with a relatively fixed camera perspective (e.g. Starcraft or Diablo), you know how much geometry can be viewable in the worst case, and there’s much less detail scaling needed.
As an example of detail scaling, getting terrain detail to scale well in this game was done over the course of many weeks. Indeed, it’s still not perfect. If you’ve tried your hand at realtime 3D drawing, then you’ve probably done a terrain. However, you may not have encountered the mess of fading textures and specular/normal/emmissive maps between detail levels. I used geometry instancing for the distant chunks, which meant no lights in the distance in my lighting model. Things like this added up quickly.
I thought a bit about what the title of this post should be. A reference to Duke Nukem Forever felt appropriate at first, until I realized that it’s probably not fair to compare my 3 months of development to 14 years of off-and-on DNF development. Hell, even if I am writing DNF-level vaporware, at least Duke Nukem Forever is finally being released, right?