Game Development Reference
In-Depth Information
Reference Model
There are two kinds of ephemeral artifacts that have to be created in the second layer of the language engineering
workflow. The intention is to find exemplary instances of the front end (reference models) and the back end
(reference output) of the toolset. The reference artifacts should iteratively be developed to enrich and specify the DSL
requirements more precisely. In the end, they should include instances for all domain elements in order to cover the
domain exemplarily as well as consider language engineering principles (see Table
13-1
).
A reference model is a sample program written in the planned language. The central issue is to think of a
representation that covers as many of the DSL requirements as possible. Thereby, the reference model serves as a
communication platform between domain experts and language engineers in order to combine and manifest their
expertise in the language design. In other words, the reference model is the vehicle to map the DSL requirements
(layer 1 of the workflow) to the concrete syntax of the language (which will be defined in layer 3). Again, the language
engineer should moderate the creation of the reference model, always keeping the tooling of the language in mind.
This is where the game designer (as a domain expert) might benefit even more from the language creation process.
The task of finding a textual or graphical formal representation that separates a game concept or design from its
technical realization in a multi-expert group implicitly leads to a reconsideration of existing design ideas and can
validate and render them more precisely and even enhance them. Let's see how Tobey and David are proceeding.
Using pen and paper, David and Tobey start to create reference models for their weapon description language
based upon the first DSL requirements.
David: I think I understand what reference models are meant for, but how are we going to approach this?
Tobey: Let's start with the weapon type language. How would you like to define weapon types if we were to be
completely free? Go ahead, how would you define the weapon type Halberd, for example?
David: Well, maybe just like this:
Halberd is a new weapon type.
Tobey: Very good. Now, is it a one-handed or two-handed weapon type? How fast is it? What is its range?
David: This would be a slow, two-handed weapon type of long range.
Halberd is a new, slow, long-range, two-handed weapon type.
Tobey: I like your language design, since it's extremely readable and explicit. It already contains all the
information necessary to define a Halberd. However, it is somewhat verbose, so I would suggest simplifying it a little.
Since this is a definition language, I would argue in favor of making this fact explicit in the language, introducing a
keyword Define.
Define Halberd as a new, slow, long-range, two-handed weapon type.
Tobey: Since it's a definition, we can leave out the term “new.” What's more, we are going to define weapon types
here, so maybe we can also leave out the term “weapon,” if you like, to make it handier:
Define Halberd as a slow, long-range, two-handed type.
After some more corrections and discussion, minding some of the language engineering principles of Table
13-1
,
they create the following reference model. As you can see, the term
type
is defined to be optional, minding the Flexibility
principle.
Define type Halberd: slow, long-range, two-handed.
Define Axe: medium, mid-range, one-handed.
Define type Dagger: fast, short-range, one-handed.
