On these pages we will analyse various types of games and discuss possible approaches.

- Snooker - These pages discuss the various types of collision in a snooker/pool game.
- Car racing game - These pages discuss modeling the suspension of cars.

### Common Features

Here are some things which may be similar in these types of games.

The game may consist of a number of objects each made up of polygons (often triangles). The vertices of each triangle are stored in the coordinate system of the object you are building. We can move the object around by transforming all its verticies.

In order to prevent the object from getting distorted by repeated transorms (each of which may have small rounding errors) we tend to keep the verticies in there original form and generate the current position from this at each frame using a transform matrix to represent its position and orientation.

If we assume you are modelling, say an aircraft, then choose a local coordinate system for the aircraft, say x along the fuselage, y along the wing or whatever. Then encode all the vertices for that object in that coordinate system directly. Then to rotate that object multiply each vertex(vector) by the rotation matrix to give the transformed vertex(vector). This rotates the whole object around its origin. You can then offset the aircraft to be where you want on the screen by adding a fixed vector to each vertex (or equivalently by using a 4x4 matrix).

It is best to avoid Euler angles if possible. Sometimes there are angles implied in the situation itself, for example in the case of an aircraft, the control surfaces imply rotation around certain axis. In this case we need to convert the angle information to matrix form as soon as possible. I guess the thing to keep in mind is that, when combining rotations, order is important. So if you want yaw then roll then pitch then yaw you will need a different matrix than if you want yaw then pitch then roll, these angles are relative to the aircraft not the ground.

## Car Racing Game