The Storm Programming Language

One of my goals with Wisp is to give players the ability to easily generate their own content without leaving the game. From maps, to campaigns, and custom scenarios. The editors to support this player generated content should allow you to go beyond simple map building and into the realm of custom gameplay through scripting. With this in mind, I created Storm a scripting language for the strategy game Wisp. My other motivation was that creating Storm would help me get experience in language implementation and design.

Since, I've discussed my language with some of you I thought I'd post a demo so you could try it out first hand and describe my work in more detail. Storm is a not an object oriented language, but it does let you create .Net objects and invoke/access their members. Its design was inspired by Clojure, Boo, Arc, Go, and JavaScript. Storm is an s-expression based language, so it has a Lisp like syntax. It currently has the following features:

• Integer and floating point numbers, with a full set of math operators
• Booleans, with a full set of relational operators
• looping and conditional expressions, with support for iterators
• Literal syntax and built-ins for arrays and hashtables
• Generic .Net object integration (use this for other data structures and foreign code)
• Functions and variables with lexical scoping
• A module system with public and private functions and variables (case based visibility)
• Foreign modules, expose arbitrary .Net objects and functions as Storm modules
• Configurable execution time limits (an infinite loop will not freeze the game)
• Configurable stack limits (infinite recursion will not crash the game)
• Sandboxing, limit API access and run multiple interpreters
• Optional dynamic scopes, for things like mapping a single module to multiple game objects
• Chain operator, (-> obj foo (bar baz)) becomes (bar (foo obj) baz) think "obj.foo.bar(baz)"

Storm currently does not have macros, closures, generators/coroutines, or exceptions. Not much work is left to add macro and closure support, but I stopped work on Storm before getting them in, they will come later. I'm leaning against adding exception support. Generators are more work as rewriting them as state machines is not trivial, but it is something I would like to include at some point. I haven't done any optimization, but performance seems adequate for my needs. The implementation uses a hand written recursive descent lexer and parser and an AST based interpreter.

If your curious the best way to learn more about the language is to look at the Doc module in the demo then try code in the Scratch module. I've included a description of the grammar and sample code for all features. The Game module shows how you could use Storm's dynamic scopes to support a MonoBehaviour like scripting interface (it drives the cube in the demo).

While this demo exposes Storm as a low level scripting language that you can use to create your own Unity like MonoBehaviour scripts, this is not how I expect to use the language in Wisp. Players will probably never see any Storm code or be able to type in scripts. Instead players will work at a higher level of abstraction with GUIs that in the back end generate Storm code. Think of Storm as executable XML or JSON format that can be serialized and stored in a central database of user content.

On other fronts, pun intended ;), I've begun work on the AI behaviour engine and I recently completed the networking engine with resynchronization support. The main technical components of Wisp are coming together nicely and I'm looking forward to doing more game play specific implementation work.