Domain Specific Language (DSL) and AI

The time has come for me to write another blog. This blog will be talking about the presentation that we say in class called “Flirting with the dark side” and had to do with Doman Specific Language (DSL). If you want to download the slides from the presentation you can get them here. All right topic confirmed… words incoming.

Domain Specific Language (DSL):

DSL or Domain Specific Language is a language that is specialized to solve particular application problems. These problems all have some sort of class or type in common. Another way to put it is a language that is great at solving a specific class of problems. DSL is designer friendly as the code is and the language is higher level language and does not need to be handled by a programmer. This means that designers can code something like AI without the assistance of multiple programmers for implementation. DSL is like a declarative file format as you normally state things happen. You do not have to worry about managing the memory and everything else that the programmer does, instead all you have to do is state how things are. DSL files could be thought of as a smart file that has a list of declarations.  So what does DSL look like? This is the example for DSL code used in the presentation.

if $Aim -> is of class Huge Ship

      if $distance > 3500 AND $distance < 20000

       if [THIS] -> fire missile $Missile on $Aim

        $Missilesfired.strength = $Missilesfired.strength + $Damage

        [THIS] -> set fire missile time difference to 16 ms

        $defend = random value from $Value.def2.min to $Value.def2.max - 1

        [THIS] -> interrupt with script '!plugin.fightcommand.defmove' and

          prio $Prio: arg1=$defend arg2=$Aim arg3=null arg4=null

        gosub Defensive.Definitions

      end

   end

end

Using DSL for AI and High Level Languages:

DSL is great for AI as it makes it easier to implement when the implementation is near the domain of the problem. DSL is also a higher level language so it does not come with the same concerns as lower level languages. There is no need to manage memory or how the code will work together. When you eliminate the lower level concerns then the language before more designer and artist friendly. Not everyone on team wants to worry about the lower level concerns. Designers and artist can work easier knowing that there will not be any issues while working with lower level code. AI is usually done by solving a limited set of problems with a small set of well-known solutions. With fewer issues in the implementation, the more AI issues can be solved.

DSL Making Your Own Language and Compliers:

As stated before DSL is a higher level language and comes with its own benefits. You can avoid memory management, complex syntax, and complicated undefined behaviors. This makes it so that more people can work with the language and does not need a programmer to implement it. So how would you implement DSL? For one thing you don’t have to make your own language. Creating compilers, interpreters, virtual machines, garbage collectors, and parsers are all too complicated. Instead we can use pre-existing languages like XML, JSON, and plain text documents. This implementation is easier for artist and designers to grasp and work effectively.

Guidelines for creating a DSL:

To create a DSL you want to take the logic that is coded into your engine by the programmer’s and use it outside of the engine in a simpler context. Take all of your logic code from the core game engine and use it outside of the engine. This is also called scripting. You can use DSL and scripts to run the pick and choose the logic code that you are going to use at any point in time. This makes it easy for designers to use the tools that are in the core game engine and use them in a versatile way. To make your DSL you must know what you are aiming to solve and solve just that problem. Making system for one purpose only make you code nice, neat and organized. When code is clean it is easier to understand, go thought and most importantly debug. One phrase that stuck with me from the presentation is “Minimal Syntax, Maximum Power”. As a programmer myself I like the complex syntax of c++ or java and had a hard time getting used to languages like python with minimal syntax. The less syntax the more powerful the code is. I have not thought about that before but I am stating to understand what this statement means. The more syntax there is the more you feel constricted to the style but with less syntax you get more freedom and that can make code more powerful.

Some closing tips:

I liked the statement “Keep low level logic in low level code”. There is no point in scripting code game engine mechanics in something like lua or squirrel as they are not fit to handle the logic. But you can use something that I like to call “designer logic” with higher level code. Gameplay and how the designer thinks are great for higher level code as it has the capability to handle it and make is easier on the implementer. One last closing tip that I took away from this is that you can create and deploy multiple DSL it does not have to be just one. A DSL should handle a specific problem and that is it. Making code cleaner is always the best.