# Domain-specific languages for scripting [closed]

As most of you know, embedded interpreters for languages like Lua and Python are widely used for scripting game logic, but I haven't seen much information on people going with domain-specific languages for their scripts, e.g. building a little logic scripting 'dialect' on top of the language used for the rest of the game, using macros or fluent programming or whatnot.

So my questions are as follows:

• What examples of such DSLs have you seen in real-world games?
• What problems were run into?
• Would you recommend this route for other game developers, and in what circumstances?
• Do you see this becoming more common as game development moves toward more metaprogramming-friendly languages, e.g. Boo?
• To answer the real-world DSL usage question Battlefield 1942 used them. Although a lot of mods popped up; from a programmers (my) perspective it was horrible and I lost interest very quickly. – Jonathan Dickinson Jan 23 '12 at 10:45

I've used a domain-specific markup language for game data. It was a pain. I spent days designing it, and then every week or two I needed to tweak it to add more features. At one point I realized I needed to automatically generate some of my game data, and I ended up writing a small program to parse input files in the markup language, massage them, and output different files also in the markup language.

I honestly have no idea what I was thinking. The entire thing would have been simpler, more efficient, less bugprone, and far far less time-consuming if I'd just used Lua.

If you're working on such a restricted system that you can't start up a Lua environment, then perhaps you should use a DSL, but be prepared for agony. Otherwise I firmly believe you should just use Lua. Lua was originally designed as a simple data markup language and is still extremely conducive to using as such, and when (not if) you realize you need something more complicated, you've already got it. All of my current game development is done in Lua and I've never been more efficient or less bugprone.

I cannot recommend against DSLs strongly enough.

• Er, why not? Have you just used Lisp, it would have been a much more pleasurable experience I think. :) Starcraft II has the scripting language Galaxy which indeed is a domain specific language targeted at non-tech guys/gals. – jacmoe Aug 9 '10 at 9:28
• Lisp wouldn't be a DSL any more than Lua or Python. It would be a fully formed language that someone else has spent a long time designing, time that you can avoid spending yourself. – coderanger Aug 9 '10 at 17:18

I haven't seen much information on people going with domain-specific languages for their scripts, e.g. building a little logic scripting 'dialect' on top of the language used for the rest of the game, using macros or fluent programming or whatnot.

Scripting languages tend to be an expensive proposition in games. Even Lua, which is quite fast, is still very much slower than native code. Game teams are typically only willing to take that hit because it buys them two very big benefits in return:

1. The ability to change scripts without having to recompile and reload the game.
2. The ability for non-programmers to write scripts.

DSLs don't give you that, unfortunately.

• I'd argue that 2) is a red herring. For any sufficently interesting script, a non-progammer will need more handholding or debugging help with it than is worth it. There are good programmer-designers out there who don't need help, but you can't slap Lua For Dummies on the desk of a regular level designer and expect them to churn out fun. – tenpn Jul 16 '10 at 8:41
• I agree. I don't think #2 works out well in practice, but I have seen that used as an ostensible reason for integrating a scripting language. – munificent Jul 16 '10 at 15:24
• There are plenty of people with good game ideas who can write Lua scripts but I'd never trust near malloc/sprintf/any place they had to pick a data structure/etc. That's really what #2 means - "The ability for bad programmers to cause minimal damage and still get work done." – user744 Aug 9 '10 at 9:37
• They might not cause memory leaks with a script, but a bad programmer can still write buggy, unmaintainable and slow code. Bad programmers shouldn't be allowed near your game. Hire designers with proven scripting experience and you'll be ok. – tenpn Feb 7 '11 at 17:15

I find it curious that your question limits itself to internal DSLs, since I'd rather advocate the use of an external DSL in order to get the ability to load scripts at runtime and especially to allow non-devs to write game logic in the DSL.

For instance, my current project is using a (for now) simple external DSL to specify part of the game logic that allows game designers to make balance tests mostly without dev intervention.

Of course you'll need to write a parser; to that end, I think the most recommended tool is ANTLR which targets quite a few languages. On my project though we went the parser combinator route with jParsec (our backend is Java, there are variants in other languages) which is quite nice for its close relationship with BNF but perhaps less well documented.

But only if you have a use for it.

No need to create a DSL if you are just going to use it yourself - internally.

Galaxy is the scripting language which the Startcraft II editor is using. It's a prime example of a domain specific language.

It targets game designers rather than programmers:

Timer - Start Raise Lava Timer as a One Shot timer that will expire in 20.0 Game Time seconds
Variable - Set Raise Lava Timer = (Last started timer)
Timer - Create a timer window for (Last started timer), with the title "Lava will raise in: ", using Remaining time (initially Visible)
Variable - Set Lava Timer Window = (Last created timer window)
Timer - Show (Last created timer window) for (All players)
Variable - Set Lava Death? = false


Sample Tutorial

Lisp is the perfect language to use to create domain specific languages, but there's other options, of course. Like Boo.

That way your designers/modders don't have to learn programming, even if it's just Lua, it's still programming.

Edit: Let me add that a DSL can be implemented in a scripting language - it's not synonymous with not using a scripting language. Especially if you are using Lisp or similar, since it lends itself extremely well to create domain specific languages.

Internal dsls are just syntactical sugar on a good API. The API is what is most important. After you have a good API making a dsl is trivial, and not that important.

Arguably UnrealScript is a DSL. It seems to get the job done, although I think it's possible to make game scripting languages even more 'domain specific' than that. I would recommend making a DSL if there is something specific to the domain that will benefit from language changes - I have a few ideas in this area but nothing fully formed currently.

Do you see this becoming more common as game development moves toward more metaprogramming-friendly languages, e.g. Boo?

I don't think that one fairly new engine supporting a language is evidence of game development moving in a given direction, however. It's early days yet.

If what you really need is a general purpose programming language then rolling your own is almost certainly a mistake. If your language seems to need variables, expression evaluation, loops, conditionals, classes, functions and the like then best stick to a known language like Lua, Lisp, Python, JavaScript, etc. [Unreal have abandoned theirs.]

But if what you need is mostly about defining data; is perhaps declarative rather than imperative; perhaps defines states and rules (like GDL); and does not need most of what a GP language does well, then consider a DSL.

But beware: creating languages and compilers can be very hard and prior experience is a big help. I would recommend a PEG parser (itself a DSL) based on an EBNF grammar (another DSL), and if that's too big an ask, then better not to try.