Game Objects in a Structure - Learning C# by Programming Games - page 199

this game object might consist of many other game objects, such as a door, stairs,
windows, and a kitchen (which itself, in turn, consists of different game objects).
In the case of puzzle games, the grid that represents the playing field could also be
considered a game object that consists of a grid of other game objects. Given these
different types of game objects and the relations between them, we could say that
game objects generally form part of a hierarchy . This hierarchy can be completely
flat, as was the case in our first example game Painter , but the complete Jewel Jam
game explained in the following chapters has quite a complicated hierarchy of game
objects.
Many games use such a hierarchy of game objects. Especially in 3D games,
such a hierarchy is very important because of the complexity of three dimensional
environments. Objects in 3D games will normally not be represented by sprites, but
by one or more 3D models. The advantage of a hierarchy is that these objects can
be grouped together, so that if you pick up a vase that contains a scroll with magic
writings on it, the scroll moves along with the vase. Such hierarchies of games are
also called scene graphs since they present the scene (the environment) as a graph-
like structure.
In the Painter game, our basic type of game object was represented by the
ThreeColorGameObject class. It is clear that not all game objects will have three pos-
sible colors, a current position and a current velocity. Until now, this is how we have
represented game objects, simply because it was sufficient for the basic examples
that we were using. If we want to develop bigger, more complicated games, we have
to let go of the basic premise that a game object is a three colored sprite. But then,
what is a game object? In a sense, a game object can be anything we want. So we
could define the following class to represent a game object:
class GameObject
{
}
Okay, this is maybe going a bit too far. For now, let us assume that any game ob-
ject has a position and a velocity, but how the game object appears (if it appears)
is something that we do not yet want to say anything about. So if we want to de-
fine a generic GameObject class, it will in any case have the following two member
variables:
protected Vector2 position, velocity;
Note that we used the protected keyword to make sure that classes inheriting from
GameObject have direct access to these two member variables. If we want to have a
game object that is represented by a sprite, we can inherit from this base class and
add the necessary member variables.
We also add the main game loop methods: HandleInput , Update , and Draw . Since
we do not know yet how the game object should handle input, and how it should be
drawn on the screen, we leave these two methods empty. In the Update method, just
like we did in the ThreeColorGameObject class, we update the current position of the
game object according to its velocity and the elapsed time.