The Specification

With much of the busywork out of the way, you can start working on one of the most important sections of the gamethe specification. I cannot stress enough the need for you to spend time thinking about the problems you need to solve before you write a single line of code. Virtually every budding game developer I know has started the first game by jumping in and writing some code. You'll only be making more work for yourself later when you realize your quick working solution doesn't quite work the way you intended.

So for this game, what problems need to be solved? Look at the diagram shown in Figure 2.1 earlier. Obviously you will need some type of game engine that will be the brains of the operation. You will need a player object, a rendering device, and a way to maintain the level information. A common way to display development specifications is with UML (unified modeling language). You will find a Visio UML document in the media folder on the included CD, and also in Figure 2.5.

Figure 2.5. A simple UML diagram of the game objects.

If you're familiar with UML, the figure probably looks familiar enough. If you're not, perhaps you should understand what the point of this document is. First, it breaks down the problem into the logical components that will make up the game. In this case, those objects are the main game engine, the player, the level, the list of blocks, and each individual block. The public properties and methods for each object are listed within that object's box, so you can have a quick overview of the size and scope of each of the objects themselves.

Fancy diagrams aside, what really needs to be done for the game? You will obviously need to have a central area where everything is controlled. In this case, it will be the game engine. If you notice in the UML, the game engine will also maintain the graphics rendering device and code as well (which is implied through the InitializeGraphics method). The major things the game engine needs to know are:

• The player object

• The current level

• Is the game over?

• If so, has the player won the level?

• If so, has the player won the game?

The game engine will also need to store other information, such as the rendering device, plus maintain the game's objects, but these will occur in private methods and are not shown in the UML from Figure 2.5. The next object is the player, which is actually quite simple. The only information needed for the player is the position it's currently in, and the capability to render itself in the scene. In our game engine, the player is really more of an abstract concept than a development object. The object here is mainly used to control how the player is shown visually.

Everything else in the game engine comes from the levels object. In reality, this object is quite simple as well, because it just maintains a few other objects, notably the blocks collection. Each block maintains all of the information needed to control itself within the level, including the list of possible colors, and whether the colors will roll over.

With the basic specification out of the way, it's time to start coding. You can rest assured that most likely the specification will change slightly between now and the completion of the game, but this gives you a perfect opportunity to start writing some code.