Game Development Reference
In-Depth Information
Conclusion
Domain-specific languages are a powerful tool to abstract the core of a problem from technical or unrelated
constraints. For game development, they offer different possibilities to be usefully applied. They can bridge the gap
between game design and its implementation by empowering game designers and writers to formally describe parts
of a game, meaning to program it. The creation process alone can help to validate, refine, and enhance existing game
designs, making the process itself a tool to find precise game design descriptions. Using generators or interpreters,
the formal structure of DSLs enables all kinds of possibilities for processing domain-specific programs. Generators
might be used to transform a DSP automatically into another, usually more specific format, like C++ code or XML
files to free programmers from tedious and error-prone tasks. DSPs might as well be interpreted directly to simulate
and evaluate modeled behavior, like playing through an interactive dialog, or to derive additional information from a
DSP in real-time, like the in-game item statistics shown in this example. Last, but not least, internal DSLs can be used
to make programming interfaces more comprehensible to non-programmers, opening up new possibilities for pair
programming, something that, unfortunately, could not be handled in more detail in this chapter.
The language creation process itself can be used to communicate and reconsider a game's design iteratively, as
has been shown by the example in this chapter. Game designers can incorporate design rules into the DSL, making
the design independent from concrete implementations—an especially important consideration for multiplatform
games and/or game series. Once defined, game designs (using a formal language) can be distributed to different
platforms with proper generators. Design changes need only be implemented once and can be distributed
automatically to all platforms. At the same time, programmers can integrate their domain knowledge into (code)
generators so that boilerplate programming tasks are performed automatically with a constant level of quality.
Yet DSLs are no silver bullet for game development. It must still be proven whether the proposed application
fields work in practice. A major downside of external DSLs is that one needs to create a corresponding toolset in
order to make use of a language. Hence, it is always necessary to consider whether the investment of creating such
a tool actually pays off in the intermediate and long term. However, given the state of the art of modern language
workbenches that support the implementation of DSLs nowadays, and the fact that there is quite regularly the need to
create specific tools in the context of new game projects, it seems only reasonable to consider creating and using DSLs
more frequently in the future.