A Domain Specific Language (DSL) is essentially a mini language which is
designed to solve specific set of problems. In other words, with language like
C++, the programmer can do almost anything they desire but with a DSL they can
only do a finite list of similar tasks designed to solve one specific problem.
Example of what a DSL may look like. Source: GDC 2011 |
This is an example of a DSL. This is just XML but the
attribute names in the nodes all relate to a specific task, in this excerpt the
DSL is describing a cutscene. We can see the name of the cutscene, start
position, duration etc. Very simple, you can then simply parse this XML into
your program and depending on the attribute names, treat the data correctly.
I have unknowingly actually created domain specific languages
in all three of my years at UOITGameDev. Every year they’ve gotten better, this
is because I always learn from the mistakes of the previous year.
Evolution of DSLs Over the Years
DSL used in first year project, Roboy |
Look at this…trash. It kills me to say this but this is just
awful. Back in first year this was my greatest accomplishment as a programmer.
I created a level editor which allowed the user to place blocks where each block has a unique identifier (the first integer) and the X, Y position of the block
(the second two integers, respectively). I say this is awful because, if I did
not tell you what these numbers meant, you’d have no idea what they
represented. Heck, I’m surprised I remember what these numbers mean.
First year level editor. You choose a block type, and place it on the grid. |
In second year, we also made a level editor and this time
our DSL has evolved quite a bit.
DSL in A Case of the Mondays, second year GDW game |
As you can see above, instead of integers, we went with a
straight up human readable format. This is better in my opnion because it
allows everyone to be able to infer what these values mean.
Second year level editor. Horrible time sink. Limited functionality. But it got the job done. |
Finally, the latest and greatest (so far): Roboy in the
Hood. From our past experiences we knew that making level editors are huge time
sinks, with minimal return. Going into this year we knew we wanted to use Maya
as our editor, this would give us the ability to not only place objects but use
Maya to bake in lighting effects and generate cube maps. Our DSL this year
looks like this:
DSL used in Roboy in da Hood. |
We have switched to an XML format this year. The data in
this XML is used to construct the scene. Similarly to the previous years, we
have to ability to output positions and rotations but this year we’ve added the
ability to export materials and scripts. Below is a list of the current elements
in our DSL. In the left hand column, you see the short hand notation used in Maya and on the right you see their respective meanings.
o, t, l, p
|
Object, trigger, Light, path. First character of model name in Maya
to ID what a block of data is
|
-s, -d
|
Static, dynamic. Tag to denote if object is static or dynamic. Can
only be used if data has object identifier.
|
mat, script, anim
|
Material, script, animation. Denotes which material, script or animation
set a block of data should use. A block of data may have none, all or any
combination of these components.
|
Since we used Maya as our level editor, we made it so the
designer had to give the models specific names; these names are used by the
exporter to generate nodes in the XML document. The XML document is then used
by the importer to reconstruct the asset in game.
Application of our DSL in Maya. |
In the image above, our block of data is named:
o_truck_mattruck_scriptIceCream_d
This translates to: Object with a
truck model, using a material named truck, with a script named IceCream that is
a dynamic rigid body. Our importer and exporter has its own domain specific
language which is used to help us identify data.
Translation of short hand notation used in Maya to DSL used by importer. |
Now that you’ve seen some examples of domain specific
languages, hopefully you see the usefulness in them. Imagine having to type out
or export out a straight up C++ file containing the object placments in a game.
Furthermore, by using DSLs, we are making the project more accessible to
non-programmers.
In all of my samples, I described setting up scenes, but why stop there? You can make a DSL to actually define gameplay elements for example:
Imagine making a script using these simple keywords. It wraps up all the calls to the low level functions into simple to use commands. This is beneficial because it allows non-programmers to write scripts and it also prevents people from messing up the low level functions that the game depends on.