Game Development Reference
In-Depth Information
Using proper generators, dialog written in the language of Listing 13-1 can be transformed into different formats.
For example, you could create several scripts sorted by characters for the audio recordings, the necessary XML format
for the story engine, and a graphical representation such as a dialog tree displaying the dialog's structure. The dialog
script becomes the central entity for dialog writing (it is code, after all!). Whenever dialog needs to be changed, the
writer changes the DSP and distributes the new version by recompiling the program. This type of centralization
represents but one way that DSLs can significantly help to preserve consistency throughout the development process,
utilizing the “DRY” principle (“Don't Repeat Yourself,” Hunts and Thomas, 1999
4
).
Now, for everyone who might feel the need for a third, more “renegade” reader answer in Listing 13-2, like, “Don't
bother me with DSLs. Everyone knows that they are impractical due to the fact that one always needs to build a complete
infrastructure for them, like a parser, an editor, and an analyzer, which still would not be comparable to a common IDE,”
please make do with the second reader answer in Listing 13-2 for now. I'll come back to this issue in a second.
A Categorization of DSLs
There exist different “kinds” of DSLs. A DSL can either be internal or external (Fowler, 2010
5
). This differentiation
is useful since internal and external DSLs are not only different in the way they are created and used, they are also
usually applied in different contexts, as you will explore in a second. A less rigorous way to categorize DSLs is to
consider their technical orientation. Eventually, both ways of categorization should help you to get a better “grip” on
the term “DSL.”
Internal DSLs
An internal DSL is embedded in a GPL using a limited set of the features of the GPL. Internal DSLs are bound to the
grammar of their host language and thus do not need a distinct toolset to be processed. This, of course, constrains the
flexibility of syntax design. A good example of an internal DSL is incorporated within the .NET Framework component
LINQ. It provides a natural language-like API that utilizes the access to data collections.
A common way of defining an internal DSL is through chained methods. Listing 13-3 illustrates the Method
Chaining pattern (compare Fowler, 2010; there are more patterns described to define internal DSLs—take a look at
Fowler's book) available in LINQ. The given statement returns a list of selected inventory items in descending order
according to their value. Note that this is plain C# code.
Listing 13-3.
Example of the Method Chaining Pattern Used in LINQ
return inventoryItems
.Where(item => item.IsSelected)
.OrderByDescending(item => item.Value);
Internal DSLs exploit the advantages of language-like programming interfaces, making code more
comprehensible and consequently easier to maintain. In game development, I consider internal DSLs a useful tool to
simplify development processes, since many domain experts (visual artists, sound engineers, etc.) do have a technical
background and thus, even if they are not intending to use internal DSLs to develop game logic by themselves, are able
to understand corresponding programs. This capability introduces interesting possibilities in terms of communication,
cooperation, and agile development techniques like pair programming.
4
Hunts, Andrew, and David Thomas. The Pragmatic Programmer. Amsterdam: Addison-Wesley Longman, 1999.
5
Fowler, Martin. Domain-Specific Languages. Amsterdam: Addison-Wesley Longman, 2010.
