HTML and CSS Reference
In-Depth Information
Adding Inheritance
In the past, most game engines used the idea of object inheritance ubiquitously. For example, animated sprites
are built up from moving sprites that are built up from Base Objects. Part of this inheritance hierarchy deve-
loped because of the static nature of languages such as C++, which lend themselves to using inherited classes
and virtual functions to treat different types of objects uniformly.
Using Inheritance in Game Engines
As game engines grew in size, people realized that a static hierarchy of classes quickly became unwieldy. Even
though you might want some shallow hierarchy in your classes for where objects share the same base function-
ality, artificially creating a single deep hierarchy doesn't usually make sense.
Take the example of a shooter game with a number of different weapons the player can pick up. Say you
have the following three weapons:
• A crowbar, which can be used only to hit people and doesn't have ammunition
• A pistol, which can be used as a projectile weapon or can be used to hit people as a mêlée weapon and
has a limited amount of ammunition for shooting
• A grenade, which can be used only as a projectile weapon but also has a ranged damage effect
Even in this simple case, coming up with a single hierarchy that allows for code reuse, while at the same time
preventing weapons from being burdened with functionality they don't need, is difficult. You might be tempted
to create the following set of base classes:
Weapon
MeleeWeapon
RangedWeapon
AreaDamageWeapon
Although this isn't perfect—a grenade, for example, would subclass
AreaDamageWeapon
but would need
to override any mêlée weapon functionality and disable it—at first glance it at least seems like a workable base.
Adding new types of weapons, however, quickly becomes clunky and redundant. Imagine how to handle a rifle
with an attached grenade launcher, which would be a weapon with ranged, mêlée, and area damage. Something
such as a landmine that is set somewhere and causes area damage when stepped on (much like a mêlée weapon)
would also be a challenge. When you start jumping through hoops to make a class hierarchy work correctly, it
becomes clear it's time to move on to something else.
That something else is known as the
component/entity model
. The idea is that you don't define a linear
class hierarchy to build up to your wanted level of functionality; rather, you define a number of loosely coupled
components that know nothing about each other and just go about their own business. For example, in the case
of the weapons defined previously, you could define separate components for Melee Attacks, Ranged Attacks,
and Area Damage Attacks and bind the triggering of those components to the different firing inputs. (For ex-
ample, when the weapon is equipped and fire1 is pressed, do a mêlée attack; when fire2 is pressed do a ranged
attack.)
The only downside to components is that there tends to be a lot of them, and adding a long string of compon-
ents on object creation and dealing with not knowing what base level of functionality all objects support can be
challenging. Components also tend to be self-contained, which means that when you do want them to interact,
you have additional problems.
