Scripting and DSLs

Scripting and DSLs

    

    We recently watched a GDC video put on by developers from Moonshot Games about Scripting and DSLs (Domain Specific Languages).  Immediately, I was interested, since this year our GDW group is using the Squirrel scripting language for our gameplay logic.  Damian first started off by talking about how some programmers are against scripting and deem it as "lazy", when it is actually quite the opposite.  Scripting is a very powerful tool, and incredibly useful, especially when you are using it for gameplay logic.  I have experience with scripting and always found it to make things much more fluid, organizes things better, and allows you to code gameplay much faster.  This is due to not having to hardcode everything, but rather build the underlying engine, and then "exposing" this classes/functions so that you can then call them within script.  Now understandably, certain things are best done in hardcode (like the engine), but I believe it is much more efficient for gameplay to be done in script.

    He then went on to talk about Component and Systems Soup.  Component soup is basically when you have many different components for your game like physics and animations being used within your game.  They are usually done in both hardcode and script, and can create quite a mess.  

    System soup is similar to component soup, but is on the systems level.  These subsystems can have this component soup within them, and then be called by script or hardcode, which creates an even larger soup.  This makes it even messier.

    He then went on to how a typical code workflow looks.  The engineer designs the the framework within hardcode.  It is then handed off to the designer who implements it within script and designs the game and gameplay, and makes it work.  It then goes back to the engineer who focuses on making it fast and efficient.  Finally it then goes back to the designer to make sure that the code still does what it was originally intended to do.  These last 3 steps can be cyclical, going through several iterations before it is finally done.

    Then, another programmer started to talk about DSLs (Domain Specific Languages).  DSLs are languages which are strong at solving a specific set or class of problems.  Some DSLs are SQL, XSLT, Verilog, and Python.  These range from specific to generic in terms of their degrees of specificity in terms of specialization.  There are 3 principles which pertain to our application of DSLs: 

Principle #1- Code cleanliness and the effects of mapping the code directly to the problem space

Principle #2- Elimination of bugs which are caused by irrelevant concern or problems which do not directly apply to what we are trying to solve

Principle #3- Removing excess overheard; increasing productivity by eliminating details that do not pertain to solving the problem.

    He then moved on to how syntax for DSLs would look.  As you can tell, the key is the minimization of expressions, and straightforward, clean syntax.  Something that really got me interested was the line of:

Bad:   player.health -= weapon.get_damage();

Good:   damage player with weapon

Using syntax like this makes it incredibly easy to understand and write code for what you want to happen.  This form of syntax I think is incredibly powerful, and would allow people who can't code, to be able to have some input within the design process (on the programming side).

    He then ended it off with the benefits DSLs have on the entire team.  This goes to show you that when used correctly, DSLs can be an incredibly powerful tool, and help out when doing any sort of programming within games or software.

    In conclusion, this was probably one of my favourite GDC videos that we watched thus far.  It divulged a ton of information on scripting and DSL languages, which is something I am quite intrigued by, being a strong scripting proponent myself.