Zool: Taking It to the N Dimension - The Game Maker's Companion: Game Development - page 55

PARENTING

If all this use of parenting still seems confusing, then try to remember that there are two different
effects of giving an object a parent in Game Maker:
1. The child object inherits all the events and actions of its parent (unless it has identical events,

in which case the child's events override those of its parent).

2. All collisions events with the parent object (for example, obj_solid ) are now also triggered

by collisions with the child object (for example, obj_platform ).

An Alien State
You probably won't be surprised to learn that we're going to make use of state objects again in
this game. When we made Fishpod, we had a very clear rule: every different behavior and/or
appearance had its own state object to handle it. Now this may work fine with simple games like
the Fishpod example, but it is not always practical when things get more complex. For a start, we
already know Zool will have seven different appearances for movement alone, and we'll need to
add several more later for attack moves. If we apply the same rule about appearances, then that
could mean ten or more different state objects for Zool. There would be many common behaviors
between these different appearances, producing a lot of duplicated or subtly different versions of
the same actions (for example, look back at the platform collision events for obj_pod_jumping and
obj_pod_falling in the Fishpod game). Our events will contain a lot more actions than the ones
in Fishpod and duplicated actions can be dangerous if they need to be modified: it's easy to
introduce errors by forgetting to change all of them.
Now we could use Parents as a way of reducing duplicated code and sharing common
behaviors between state objects. Making one object a parent of another allows it to inherit all of
its events and actions or override those events with its own when differences are required.
However, complex inheritance hierarchies can quickly become difficult to follow, so too many
parents and use of inheritance could be just as problematic as too many state objects.
The bad news is that there are no hard and fast rules about how much you should use such
mechanisms as state machines or inheritance in programming, and you have to develop a gut
instinct for it. However, you should always bear in mind that they are designed to make your life
easier—not as some kind of programming philosophy. It is never right to use parents, state
objects, or any other programming mechanism just “because you can.” You should always
consider whether it actually makes your life easier or harder as a result!
To this end, we have tried to group our states together into a smaller number of state objects
that include common behaviors. There will be eight moving-related states in all (one for each
appearance and two for climbing) grouped into four different state objects. We will simply store
the current state in a variable, and manage this state variable from within the events and actions
of the four state objects . Combined with a small amount of parenting to cope with behaviors
common to all states, we believe this will provide an effective and manageable result:
• obj_zool —The parent object for all Zool state objects. This will handle any behaviors

that are common to Zool in all states.

obj_zool_land —This state object will handle all states and behaviors relating to
moving on land: standing , walking , and skidding .

•

obj_zool_air —This state object will handle all states and behaviors relating to
moving in the air: jumping and falling .

•