Game Development Reference
In-Depth Information
For defining weapons, they run through a similar process, finally coming up with the reference model shown in
Listing 13-5.
Listing 13-5.
A Reference Model for Defining Weapons
Define Splitter as Axe:
attack = 16
durability = 23
< by stroke: 0.1, 30%
< by day: 0.2, 50%
Define weapon Needle as Dagger:
attack = 7
durability = 20
< by day: 0.2, 10%
< by stroke: 0.1, 80%
Define Toothpick as Halberd:
attack = 38
durability = 44
< by day: 0.3, 20%
< by stroke: 0.2, 30%
Weapons are defined by a name and refer to an available weapon type. Similar to the term
type
in the first
reference model,
weapon
is declared optional here. After a colon, the weapon properties need to be defined. The
attack
property is determined by a positive number, while
durability
is defined by a maximum value as well as
two additional value pairs. Each
durability
decrease is introduced by a lower than symbol. The first pair indicates
how much the
durability
decreases per stroke with a distinct probability, the second pair respectively how much
the
durability
decreases per in-game day, also by a distinct probability. It is up to the designer to decide which
decrement behavior is defined first (again, minding the Flexibility principle!).
Reference Output
In general, DSPs can be processed in two different ways. It is possible either to execute a DSP directly with a dedicated
interpreter or to process it with a generator, for example, to generate code or configuration files. In the case of
generation, the reference output has to represent the desired generated artifacts corresponding to the reference
models. The relation between the reference models and the reference output is vital to identifying the processing
rules later on. In case of interpretation, the reference output has to mirror the desired results and actions the reference
model is intended to evoke. This could be a storyboard displaying how the interpretation of a dialog defined in a
DSP should be displayed later on screen. The reference output has to be defined for every target platform and every
reference model. That way, the language engineers can derive the processing rules necessary to fill the gap between
both abstraction layers. Actually, the gap correlates to the applied degree of abstraction in the DSL. In other words, the
processing rules have to add the target platform-relevant details that are omitted by the degree of abstraction of the
corresponding DSL. Let's look at the example at FGS again to illustrate this.
For weapon type and weapon description languages at FGS, there are different outputs desired:
•
A media list for the art department
•
Statistics about the defined weapon types and weapons for the designers
•
Configuration files that utilize the weapon types and weapons for the game engine.
You are not going to look at how the different outputs for the DSPs are created from a technical side, but you will
examine how the requirements for the processing rules can be identified and refined working with the corresponding
domain experts.