Game Development Reference
In-Depth Information
The arrows show inheritance, so
RenderableActor
inherits from
Actor
. On the
surface, this looks okay. You can instantiate an object from anywhere in this tree to
provide the functionality you want. If you just need a boulder to fall on the player, it
can be a
PhysicsActor
object. If you want a new type of pickup, you just write a
new subclass and instantiate that. It
'
s perfect, right?
Nope, it
s not perfect by any stretch of the imagination. If you recall my advice from
Chapter 3,
'
looking at this diagram should
raise a red flag. I spoke about keeping class hierarchies nice and flat, which this fails
at completely. Why does it matter?
Let
“
Coding Tidbits and Style That Saved Me,
”
s say you build the previous system for your first-person shooter game. It would
probably work just fine for a while. Now let
'
s say the designer comes up to you and
asks you to make a new kind of pickup, a mana pickup that has an animation. You
can
'
t derive from
Pickup
since it doesn
'
t include any of the animation code, and you
can
'
'
t derive from
AnimatingActor
since that doesn
'
t include any of the functional-
ity needed for pickups.
One option would be to derive from both classes via multiple inheritance, but that
would be disastrous. You would have to use a virtual base class to avoid the dreaded
diamond of death, as shown in Figure 6.2.
Figure 6.2
The diamond of death.
The problem with the diamond of death is that it
'
s not clear what happens when
members are inherited from the base class. Let
'
s say you have the following declara-
tion for the previous diagram:
class BaseClass
{
protected:
