Game Development Reference
In-Depth Information
Note that the class diagram in Figure
13-6
is not the created reference output but gives an overview of the
classes that need to be generated for the corresponding reference model. The reference model would be an actual
implementation of at least one of the classes in the target language, such as C++.
Figure 13-6.
Class diagram illustrating the classes that need to be generated
Language Definition
The language definition and the processing rules are directly derived from the reference artifacts. The language
engineers have to identify syntax rules and static semantics based on the reference models for the language. The
creation of the generators and/or interpreters should not be performed at the very end, but iteratively with the
language definition, since some requirements of the processing might influence the language implementation.
Furthermore, depending on the technology used to create the language toolset, small adaptations—in comparison
to the reference model—are inevitable in language design. However, the language engineers should always confer
with the domain experts in order to find an adequate solution in case of changes. In order to make external DSLs
really applicable, IDE support is necessary. Language workbenches support the creation of smart editors, which, for
example, feature syntax highlighting, text completion, and syntax analysis by default.
Just like in GPLs, the abstract syntax is the structural description of a DSL. In its representation as an abstract
syntax tree (AST), a DSP can be processed by a parser. The user, however, writes DSPs using a concrete syntax,
featuring keywords in a distinct notation. A concrete syntax thereby always conforms to an abstract syntax. Hence, it is
possible to create several concrete syntax definitions for the same abstract syntax, for example, a visual and a textual
representation for different use cases.
Given the reference artifacts from the last section, Tobey and David are now able to derive the grammar for
their languages as well as create the processing rules and tools for the interpreters and generators they need. To
illustrate how the grammar can be derived from the reference models, you use the Xtext grammar language to create
the weapon type definition language. Considering the reference model again, you can derive that weapon types are
defined by a sequence of single weapon type definitions:
Define type Halberd: slow, long-range, two-handed.
Define Axe: medium, mid-range, one-handed.
Define type Dagger: fast, short-range, one-handed.
