Domain Specific Languages: Concept and Implementations in all 3 #UOITGameDev Projects

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.