Game Development Reference
In-Depth Information
What Are DSLs?
Object-oriented programming expert Martin Fowler only recently defined the term “domain-specific language” in a
very handy way (Fowler, 2010
3
), so let's use his definition in order to discuss the characteristics of DSLs:
A DSL is a computer programming language of limited expressiveness focused on a particular
domain.
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.”
3
Fowler, Martin. Domain-Specific Languages. Amsterdam: Addison-Wesley Longman, 2010.
