Robert Walter

Programming languages are like musicians. The broader the audience they are addressing, the more popular they can become, even if they are not the best at what they do. While it takes a lot more than a mainstream orientation to stay on top of the charts, it is always a plus to address the wants of the many.

But there is a place for the specialized, too. Just as alternative artists pervade the history of music, domain-specific languages (DSLs) have enjoyed a long tradition in software engineering (a good overview is given in Deursen et al., 2000¹). While early versions of this kind of programming language like FORTRAN, Lisp, and COBOL evolved over the years to fulfill more generic purposes (thus staying famous), others like SQL, regular expressions, and make became evergreens within their technical domains. Despite their success, however, the concept of engineering and the potential of using DSLs have been relegated to the “academics and theory” shelf for a long time (a good reference on DSL development patterns is given in Mernik et al., 2005²). Only recently, a growing interest in software design philosophies like user-centered and domain-driven design, as well as the coming of age of model-driven development methodologies and language workbenches, has led to a new popularity for these elegant tools.

Now, without stressing the music analogy any further, let’s take a look at two questions.

1. Why should game developers care about DSLs?
2. How can game developers make use of DSLs?

Naturally, I need to cover some basics first, but I cannot dive too deep into the details of language-oriented programming (LOP) in this chapter. Therefore, those who are new to the field of programming languages and how they work might consider reading the cited literature first.

What Are DSLs?

Object-oriented programming expert Martin Fowler only recently defined the term “domain-specific language” in a very handy way (Fowler, 2010³), so let’s use his definition in order to discuss the characteristics of DSLs:

The purpose of a DSL is to let users write computer instructions in a “natural” way. I knowingly choose the generic term “user” in this context, since DSLs are first and foremost languages designed for domains, not specific user groups. Although domain experts should be involved in the creation of a DSL to make use of their domain knowledge, they do not have to be users of the language. In game development, however, there is a huge potential in empowering designers using DSLs, as you will see later.

Unlike general-purpose languages (GPLs) like C++ and Java, DSLs provide only a limited vocabulary and almost no control structures. Instead, they offer powerful, domain-specific semantics. In short, a DSL features exactly the elements necessary to describe its application field formally (read “completely”) and precisely, which makes it easier to learn, even if less expressive, than a GPL. DSLs abstract by making the relevant details of a domain explicit, while omitting the distracting ones. This approach allows developers to address problems right where they occur: in the problem space, instead of manually mapping them to a generic solution space.

Like GPLs, DSLs feature a formal syntax. Thus, a domain-specific program (DSP, a program written in a DSL) can be processed automatically with an interpreter or a generator, for example.

What Does a DSL Look Like?

Bearing the game development process in mind, you can think of a sample language that is tailored to the “interactive dialog” domain. Listing 13-1 shows a language definition using four regular expression rules.

Listing 13-1. Simple Language Definition for Branching Dialog

dialog ::= dialogLine dialogLine+ ;
dialogLine := character action ':' STRING ('or' dialogLine)?;
character := ID ;
action := 'asks' | 'says' | 'answers' ;

The first rule defines a dialog as a dialogLine followed by at least one or an arbitrary number of additional dialogLine elements (specified through the + symbol). A dialogLine features a character that has to be an identifier (ID), followed by an action that is either the keyword asks, says, or answers. A colon and a STRING (the actual content of the dialog line) follow. The rule for the dialogLine uses optional recursion (the ? symbol indicates optionality) to allow nesting dialog lines. A program written in the language above might look like the one in Listing 13-2. Although the language design in this example is certainly far from perfect, it should give a basic idea of what DSLs can look like.

Listing 13-2. Simple DSP Example for Branching Dialog

Robert asks: “So, what do you think of this so far?”
Reader answers: “It looks just great!”
    or
Reader answers: “Not so sure if that might work, but I'll give it a try.”

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⁴).

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⁵). 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.”

return inventoryItems
        .Where(item => item.IsSelected)
        .OrderByDescending(item => item.Value);

Instead of throwing something at a closed openable door, say “Or you could just use the handle like anyone else, of course.”

Why Should You Even Care?

As mentioned before, domain-specific languages raise the level of abstraction, which allows you to address problems right where they occur. But what does this mean for game development? Game development combines the artistic challenges of multimedia production with the engineering challenges of IT. Experts from many different disciplines (game design, art, programming, acting, music, and so on) join forces to create and deliver a product. Thereby, the transition from game design to a playable game is arguably the most crucial step to take within a production process.

Game design documents (GDDs) are the common tool used to bridge the gap between design and implementation. However, just as in classic software engineering, document-based development approaches of this kind present several problems. They rely heavily on game designers’ ability to communicate their ideas in a comprehensible way, and to understand problems occurring during implementation that call for design changes. These changes must be thoroughly integrated into the GDD. At the same time, development teams must be able to interpret the design document correctly and translate it into code, never missing revisions or ad hoc changes.

It is hard to guarantee consistency throughout a project, especially with larger teams. On a project management level, agile development approaches like Scrum (Schwaber, 1995, Keith, 2010) have been introduced successfully in the last years to address these issues and to compensate for the missing scalability. Utilizing frequent communication (“daily scrums”) and short iteration cycles (“sprints”), an empowerment of the development teams as well as a process supervising role (“scrum master”) have brought significant benefits to different AAA productions, like Double Fine’s Brütal Legend,⁷  Valve’s Left 4 Dead 2,⁸  and Turn 10’s Forza Motorsport 3.⁹  Still, there is a gaping lack of consistency on the tool level that strengthens the transition from design to implementation, and that is where DSLs fit in.

In the realm of academia, there are different approaches that try to devise generic, formal languages that allow the description of game design per se. Because they need to be able to cover the design of Skyrim as well as Angry Birds, however, their concrete syntax often lacks accessibility and expressiveness, making them inapplicable in practice.

It seems to be a more flexible and hence a more pragmatic approach to allow and utilize both the creation and the application of specific modeling languages that meet the demands of a given game project directly. This way, toolsmiths and developers can facilitate long-established and a “for them approved” terminology as well as an appropriate level of technical orientation and abstraction in the language design. DSLs enable exactly this, and generally, can be an integral tool to support the following:

• The implementation of games in a faster, more precise, and more natural way.
• The communication of game design by creating and using semantically meaningful and at the same time formal models.
• In the case of external DSLs, the integration of high-level content into a game by automated interpretation or (text) generation.

Hence, the main potential of DSLs in game development is to empower non-programmers like game designers and writers. Still, DSLs can be a useful tool for programmers too, not least by fostering interdisciplinary collaboration among the different domain expert groups, but also by writing code on a higher level of abstraction. This approach leads to faster iteration times, a higher consistency throughout the development process, and eventually to higher product quality.

In the following section, you will look at a language engineering workflow that demonstrates how DSLs can be defined and how this process can accompany and enhance game design.

How to Use DSLs

The categorization of DSLs has shown that their application can be manifold. That is also true in the context of game development. However, instead of a tedious discussion about which application fields might be more or less appropriate for them, you will work through a language engineering workflow. The workflow is intended to let you, as a toolsmith, create languages for your game projects, since you know best which tools fit into your development process. The workflow is therefore knowingly independent from the type of DSL you want to create and the tools you want to use to create your language infrastructure. For illustration purposes, you will consider the creation of a weapon definition language to highlight the steps of the workflow and underline how the language creation process itself can be used in the context of designing aspects of a game. Naturally the example is simplified due to the limited space a book chapter provides.

Halberd is a new weapon type.

Halberd is a new, slow, long-range, two-handed weapon type.

Define Halberd as a new, slow, long-range, two-handed weapon type.

Define Halberd as a slow, long-range, two-handed type.

Define type Halberd: slow, long-range, two-handed.
Define Axe: medium, mid-range, one-handed.
Define type Dagger: fast, short-range, one-handed.

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>
     <Weapon id="Splitter">
          <Type>Axe</Type>
          <Attack>16</Attack>
          <MaxDurability>23</MaxDurability>
          <DurabilityBehavior>
               <Day value="0.1" probability ="30" />
               <Stroke value="0.2" probability ="50" />
          </DurabilityBehavior>
     </Weapon>
     ...
</Weapons>

Define type Halberd: slow, long-range, two-handed.
Define Axe: medium, mid-range, one-handed.
Define type Dagger: fast, short-range, one-handed.

Model: typeDefinitions+=TypeDefinition* ;

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.

________________

¹van Deursen, Arie, Paul Klint, and Joost Visser. “Domain-specific languages: an annotated bibliography.” SIGPLAN Not. 35 (2000): 26–36.

²Mernik, Marjan, Jan Heering, and Anthony M. Sloane. “When and how to develop domain-specific languages.” ACM Comut. Surv. Ser. 4. 37 (2005): 316–344.

³Fowler, Martin. Domain-Specific Languages. Amsterdam: Addison-Wesley Longman, 2010.

⁴Hunts, Andrew, and David Thomas. The Pragmatic Programmer. Amsterdam: Addison-Wesley Longman, 1999.

⁵Fowler, Martin. Domain-Specific Languages. Amsterdam: Addison-Wesley Longman, 2010.

⁶Kleppe, Anneke. Software Language Engineering: Creating Domain-Specific Languages Using Metamodels. Amsterdam: Addison-Wesley Longman, 2008.

⁷Gamasutra. “Postmortem: Behind The Scenes Of Brutal Legend.” www.gamasutra.com/view/news/25799/Postmortem_Behind_The_Scenes_Of_Brutal_Legend.php#.UJAn-Gcdx_A.

⁸Nutt, Christian. “Q&A: Valve’s Swift On Left 4 Dead 2’s Production, AI Boost.” Gamasutra. www.gamasutra.com/view/news/25701/QA_Valves_Swift_On_Left_4_Dead_2s_Production_AI_Boost.php#.UJAod2cdx_A.

⁹Graft, Kris. “Racing Evolution: Forza 3 And The Changing Driving Sim.” Gamasutra. www.gamasutra.com/view/feature/4144/racing_evolution_forza_3%25%20_and_the_.php.