Game Development Reference
In-Depth Information
actly what the differences are. As the data becomes more complicated, the number
of fields begins to grow, and it becomes increasingly dicult to manage all of the
information.
Second, if the model for goblins needs to be updated, a designer has to update
each individual asset. This busy work can be time consuming and bug prone if
every instance is not found and swiftly remedied.
Conversely, with object-oriented data, repeated information is removed. By
adding a concept of parent data, more semantic information is added. Here, via in-
heriting from the base goblin data, it is made explicit that the red and blue goblins
are types of goblins:
<object name="Goblin"
HitPoints="50"
Model="goblin.model"
Alligance="Enemy"
Weapon="Axe"/>
<object name="Blue Goblin"
Base="Goblin"
Color="Blue"
Weakness="Red"/>
<object name="Red Goblin"
Base="Goblin"
Color="Red"
Weakness="Blue"/>
<object name="Red Goblin King"
Base="Red Goblin"
Hitpoints="100"
Model="goblinking.model"/>
This data is more concise, and more importantly readable. The extra noise of
resetting individual weapon characteristics is gone. If all of the goblins had too
many hit points, a designer would be able to update the hit points in the base data
to update all different types of goblins.
14.2.2 Implementation
Much like class inheritance, data inheritance can occur completely at build time.
The existence of inheritance is only a tool for adding more semantic information
for the user. During the build, the inheritance hierarchy can be removed. For each
piece of data that has a base object defined, a tool can walk the fields of that object.
If a field is set in the base data but not set in the child data, this build tool can
copy the value to the child data. After this conversion tool has been run over all
of the data files, the end result will have all of the inheritance hierarchy removed
from the files, leaving no need to modify the runtime (see the following code):
