Choosing the Game

While many of the more advanced features of 3D programming haven't been discussed yet, there has been enough basic ground covered to write a simple 3D game. You will use the knowledge gained thus far, plus add a few new things.

Before we actually begin writing a game, it would be a good idea to come up with a plan. We will need to know the type of game we will be writing, the basic features it will hold, and so on. Given the limited set of topics we've covered this far, we obviously can't create something overly complex.

Instead, a simple game will be written. One of the first demo games for MS-DOS was called "Donkey," in which the user controlled a car, and the goal was to avoid the donkeys in the road. Sounds simple enough; this chapter will make a 3D version, without the donkeys. We'll call this game "Dodger."

Before we begin actually writing some code, though, we need to spend a little bit of time planning and designing our game. What will we need for the game, and what do we want to do while playing it? Well, obviously, we'll need a car class to control our vehicle. Then it might be a good idea to have a class to control the obstacles we will be trying to avoid. Plus, we'll need our main game engine class that will do all of the rendering, and keep it all together.

If you were attempting to create a commercial game that you wanted to be published and sold in stores, you would spend a lot of time coming up with a game proposal. Game proposals are in-depth documents that detail the vast majority of the game concepts and features. Given that the scope of this book is intended to cover the actual development work, and not necessarily the steps that you would need to take in order to get it published, this exercise will be skipped.

Another recommended document that is normally required before development work starts is the technical specification (spec for short). This includes a mildly detailed list of all the classes, plus the methods and properties the classes will implement. It may also contain UML diagrams that show the relationships between the objects. The goal of the spec is to sit down and really think about the design of your application before you start writing any code. Again, since the focus of this book is on the code, the spec for this project will be omitted as well. I would recommend that you always spend some time coming up with a spec before writing any code.