Stuck Scripting overhaul

Early on in the development of Slide (before Iridescence had come to be), I added support for small script files to allow levels to contain more complicated puzzles without running into false positives that caused the reset button to show up while the level was still perfectly solvable. I was using C# at the time, and options for proper scripting languages on the .NET platform are shamefully limited, so I rolled my own.

Here’s a sample of what it looked like:

The use-case for stuck scripts is extremely specific, so the language itself didn’t need too many bells and whistles. All I needed to do at any time was compare the number of game objects of a given color, and check if pawns had a valid path to their targets. The snippet above basically translates like so:

The puzzle is unsolvable if any of these are true:

there are more red pawns than blue
there are more green pawns than blue
there are more blue pawns than green, unless all blue pawns can reach a target
there are more blue pawns than red, unless all blue pawns can reach a target

Needless to say, it’s as ugly as it is functional, and adding new features proved difficult. The inflexibility of the original design meant for some truly impressive hijinks as I tried to implement more complex behaviors with only the original syntax.

Today I stripped the whole system out and replaced it with a new one. Since I’m using Haxe for this remake, I was able to take advantage of hscript, a subset of Haxe that allows for runtime interpretation. Now, the script above looks like this:

Much better.

The original scripting system was designed as a black box, with a minimal number of inputs and outputs. By keeping the interface consistent between implementations, I was able to completely change the underlying code without changing any other aspect of the program. It’s nice to be able to change something so integral to the gameplay without worrying about side effects.

2 thoughts on “Stuck Scripting overhaul

  1. Brian

    “I was using C# at the time, and options for proper scripting languages on the .NET platform are shamefully limited”

    When was this? Have you tried or do you have anything against Lua (LuaInterface) or Python (IronPython)? Both have been available with C# for a long time now, and are typically the go to scripting languages. Just wondering why you made this decision. :)

    1. Jake Albano

      I think it was actually the mono compatibility that was giving me problems. IronRuby and IronPython both have dodgy Mono support, and when I was working on the original project I intended to port it to Mac and Linux. LuaInterface hadn’t been updated in a while, and NLua didn’t exist yet.

      So I guess it was a little more complicated than I made it sound. :)


Leave a Reply

Your email address will not be published. Required fields are marked *