Designing a DSL

November 24th, 2007

While it’s true that a DSL has many advantages, it’s also true that designing a DSL is very difficult. One should have full knowledge of the target domain and idealize a language that could represent accurately all the required concepts. In this article I’ll present a language based on the DSL that we currently use at Orion’s Belt.

Our language is just a XML idiom for a web based combat and management game. The language was built with the following considerations:

  1. We need a DSL to describe the game rules
  2. The DSL simply changes an object state
  3. We specify with the DSL how the object state is changed

Let’s imagine that we want to write code for a facility that generates energy. It could be something like this:

<Resource Name="PowerPlanet" InitialState="ToBuild" Type="Building">
   <!– Build the facility –>
   <RuleSet State=”ToBuild” Next=”InProduction”>
      <!– check cost –>
      <ResourceNeeded Name=”Money” Quantity=”100″ />
      <ResourceNeeded Name=”Wood” Quantity=”200″ />
      <ResourceAvailable Name=”Labor” Quantity=”1000″ />
      <Start Duration=”10″ />
   </RuleSet>
   <!– Check if the facility is complete –>
   <Ruleset State=”InProduction” Next=”Ready”>
      <IsCompleted />
   </RuleSet>
   <!– Ready to produce, what does it do per turn= –>
   <RuleSet State=”Ready”>
      <Add Resource=”Energy” Quantity=”100″ />
      <Add Resource=”Polution” Quantity=”50″ />
      <Remove Resource=”Money” Quantity=”10″ />
   </RuleSet>
</Resouce>

This is not a complex language - in fact, it’s quite simplistic. But with this little code we specified almost everything that the engine needs to know on how to handle PowerPlants. And we accomplished that by writing functionalities instead of writing how they should be implemented.

Related Posts

One Response to “Designing a DSL”

  1. Vlad Says:

    I really enjoyed this post. I finally understood how this can work on a game like OB.

    This leads to a load of questions and options, but it’s an all around good way of implementing designer side decisions without any actual logic coding.