Game Development Reference
In-Depth Information
up vector is its right-hand side. When the bike moves towards the top of the screen, the up vector
is its forward direction. With each turn the player makes in the game, this vector is updated.
Taking the camera up vector to always be only the forward direction of the bike would have
resulted in a camera that sticks to the bike rather than to the grid.
The
glLookAt()
matrix is the first matrix that is pushed to the model-view stack when drawing the scene.
This is closely followed by the rendering of the grid model (more on this later in this chapter).
Due to its simplicity, the camera positioning in CycleBlob is not perfect and has been the source of much
of the user feedback I've received. A few notable disadvantages include:
The inability to see around sharp corners. Since the camera is positioned directly above the bike,
it is difficult to predict what lies beyond a sharp edge of the grid. This is especially notable in the
tetrahedron grid in the third level.
The obstruction of the view by the grid itself. If the grid contains tunnels or concave regions, the
view of the player can get obstructed by the grid itself. This is the case, for instance, in the torus
grid in the eighth level (also in the custom-level screen).
These two problems are the result of the same principle that allows for the simplicity of the camera system:
that the eye and center coordinates are derived from the geometry of the grid without taking other factors,
like visibility, into consideration.
The ultimate solution to both problems would be to define an optimal viewpoint above the surface for every
vertex of the grid mesh, instead of relying on the normal, and to linearly interpolate the camera position
between these optimal points. To see around sharp edges for instance, the camera point could be set to
advance a little further ahead of the edge to provide a better view of what's beyond it. To have the bike
visible even as it enters the torus hole, the camera can delay at a safe distance, where the bike and its
surroundings are still visible, and then to pass quickly through the hole.
Defining the optimal viewpoints for every vertex would require a considerable amount of manual labor.
Another option is to code a rule set that can define these points automatically, but that would also require a
comparable amount of work and involve considerable complexity.
An option for camera positioning that I have yet to discuss is that of a “first person” perspective. With a
first-person camera, the player sees the game through the eyes of the rider of the bike. He sees the grid
directly underneath him and the obstacles directly in front of him. The original
TRON
film contains a few
cuts rendered from exactly this perspective.
In an early version of the game, I performed a few experiments with this viewpoint and it turned out to be
extremely confusing and disorienting. The game was practically unplayable since it was difficult to know
where on the grid the bike stood; where the enemies were in relation; and how far the bike was from an
upcoming wall. This has an interesting implication on the realism of the scenes that the movie portrays.
A similar option, which may be more playable, is a middle ground between the first-person view and the
top view. The camera is situated slightly above and behind the bike so that its surroundings are still visible
and distance estimation is easier than in pure, first-person view. This option may be implemented for user
selection in a future version of the game.
