Game Development Reference
In-Depth Information
The vector F is now exactly perpendicular to N and is situated on the plane created by N and F'. It is better
than F' in that it is tangential to the smooth surface represented by the mesh. Vector R is perpendicular to
F and N and, after normalization to the length of 1, is identical to the R vector mentioned earlier.
Last, but not least, for the transformation, calculating the coordinates Q, to which the bike model is going
to be moved. Q should be a constant distance above the surface, so we take a short offset in the direction
of N above point P. Since the axis origin of the bike model is in its center, without this offset in the direction
of N, the bike would appear half above and half below the grid. To create the illusion that the bike rides on
the surface, the offset needs to be equal to about half the height of the bike model.
The vectors N, F, and R and point Q are not only for the coordinate transformation; they are also the basis
for all the display items that pertain to the bikes. The following are a few other uses:
Animation
: The bike is animated to move along the direction of the F vector as time progresses.
Player control
: When the bike is instructed to turn, its direction is changed to either R for right or
to (-R) for left. That direction then becomes the forward direction.
Wall generation
: The height of the wall is constructed perpendicular to the surface using N. R is
used to create the thickness of the wall.
Explosion model
: When the bike hits a wall, the explosion animation is positioned perpendicular
to F and centered at point P.
Camera positioning
: More on this in the following section.
Camera positioning
A common difficulty in 3D game design is where and how to position the camera so that everything the
player needs to see is clearly visible. The approach I implemented in CycleBlob is extremely simple and
seems to work well most of the time.
I wanted the game world to feel like it's a small planet floating in space, so the basic idea of a top
view camera was there from the beginning. To achieve the final look, several other details needed to be
worked out.
Camera relation to the bike
: As the bike turns, should the camera be rotated with it? Or should it
remain more or less in constant orientation relative to the grid? With a camera that “sticks”
relative to the bike, the bike is always seen driving toward the top of the screen and the world
looks like it's spinning in front of it. One can imagine a long, invisible rod sticking out of the back
of the bike and holding the camera that films it from above. With such a camera, the most natural
control system is one that turns the bike either left or right from its current heading using the left
and right arrow keys. The main downside I found to such a camera is that it is easy to lose
orientation and miss an upcoming turn in order to avoid hitting a wall. This is the main reason that
in the final implementation I chose to keep the camera constant to the grid and to control the bike
using the Up, Down, Left, and Right keys for constant directions. When the user hits the Up key,
the bike turns to the direction that corresponds to the top of the screen. When the user hits Left,
the bike turns to the left of the screen, and so on.
