The things we have done so far are enough for our first game. Do not expect a top selling game though. For the time being we will concentrate on more basic elements of a game.
Since we are developing a game that covers all the aspects, or most of them, of a real world game we should start organizing our work. This means we should try to find some basic rules that will help us be consistent so that the game can be extended as we develop more skills in the future and as the customer's demands push us to a direction. It is well known that a program costs more to maintain and extend than to develop at first place. So it is a good idea to apply good practices from the very beginning.
The game we will create is a simple driving game. A small car we can drive in a city of four buildings. From the player's point of view the game means nothing, but from the programmer's point of view it is a chance to apply everything developed so far in the tutorials. We have some simple physics in the movement of the car, collision detection as the car moves, realistic behavior in the speed and acceleration of the car and reading the keyboard.
This being the first full game I want to show you how demanding it is to develop a game. In future installations I will try to show you the artistic challenges and difficulties of a game. Game development mixes a lot of different areas of creation: graphics, 3D modeling, animation, user interface design and programming.
The game is a two dimensional driving game. You are driving a small car around the streets of a small town consisting of four buildings. You turn the wheel to the right with the 'M' key, left with the 'N' key and you bring straight ahead with the 'J' key. Acceleration is by pressing 'A' and braking with 'Z' key. When the car hits a wall it turns red. You can reset the game and start again with the 'R' key.
The code is split in many files depending on what it does. This way we can easily add functionality and improve it by the time.
The entry point to our game is in the 'driving_game.cpp' file. Then we have the 'clf_timer.cpp' which contains the time mechanism. It is a good practice to follow some naming conventions in the file names. It will help you find the right file when you need it. For this reason I use the 'clf_' pattern in the beginning of the core functionality files. Next comes the 'geometry.cpp' file. In this file we have the basic geometry classes and functions. In 'clf_objects.cpp' we have the game objects and their class hierarchy. Here we also have the collision detection code. Finally we have the 'clf_random.cpp' which contains the random number generator.
The geometric entities we need right now are the 'point', the 'rectangle' and the 'polygon'. They are great candidates for classes, and as such they are implemented. These classes carry the 2D description within their name and they do not have a third coordinate. In the same file we implement the intersection and collision tests.
The entities of our game are in the objects file. There we implement the base object class which exposes the interface of an object, as well as the specialized objects like the buildings and the car. To marshal all the objects we have a manager object that takes care of time, user input and collision checks.
This tool is going to be part of our library. We do not need it for the moment but we include it in the project anyway.
This is one of the fundamental parts of a game. Correct time keeping makes the game feel realistic and behave the same regardless of the processing power of the computer.
In 'driving_game.cpp' you will find the main application code. It is derived from the simple application sample. In this file we create all the objects of the game and then we let the object manager take care of the user-game communication.