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.
 
Search WWH ::




Custom Search