SandCat — Update 3

This is the third update for SandCat, the game ruleset development language.

SandCat is a game description language which allows designers to ignore software development and focus entirely on game design.

Changes 0.0.4

Here is a list of changes and additions.

  • I made the first steps toward a reusable centralized runner. I reorganized the code and remove everything that wasn’t needed for the runner. There was a lot of testing code, such as some opengl rendering libraries, which are not needed, so they were removed.
  • I created SandCat_Runner which compiles into a dll and exposes some methods to load in game rules and query them. This is intended to be the central and only required library for playing SandCat rules files on any platform.
  • I created SandCat_Unity, which is a unity plugin that links to SandCat_Runner, allowing a game designer to load and play SandCat rules within Unity.
  • I created a few various Unity utility classes to facilitate quick iteration. Such as mapping SandCat game state values to sprites or colors. These allow designers to more easily organize how their game is displayed and interacted with.
  • Added error checking to SandCat_Runner. Now it reports syntax and runtime errors instead of crashing. A huge improvement.
  • Actions and methods can have multiple does-if statements now. This allows for more flexibility.
  • Added a language feature to generate random numbers within a range. More powerful methods of generating random numbers might be necessary, but this is a good first step, and sufficient enough for the majority of games.


I recreated the game Topsoil for this update. Topsoil is a small puzzle game which released a few weeks back. You can see real the game here. Definitely watch the trailer if you want to understand the game.

Here are the SandCat rules for Topsoil.

And here is a gif of the game being played in Unity. The UI and interactivity is handled by Unity, but the game mechanics themselves are all described in the rules above. The visuals you see below are simply a fancy reorganization of the game state, while all changes in game state are handled by the rules.


The problems here are obvious. Yes it works, but many behaviors are repeated multiple times. The core issue here is the grid. The language does not have the tools necessary to adequately handle the grid and because a lot of strategy games rely on grids, this is a big problem. I think two new language features are needed to solve these issues.

  • Line expansion. 
    This line — Cell1, Cell2, Cell3 : [Plant(0), Color(0)]. 
    is equivalent to — Cell[1..3] : [Plant(0), Color(0)]. 
    I think this feature has many uses even outside of grids, so it’s something I had planned on doing regardless.
  • Array Structures.
    I’m much less confident this is a good idea, but I think it’s fundamentally required because designers need to be able to index into a structure. Without arrays designers are forced to manually iterate through unorganized objects. For example, in the Topsoil test game I’m forced to iterate through the cells multiple times — the logic could be drastically simplified if I could index directly into the grid structure.

I want each new feature to have many uses. I’m consciously trying to avoid the trap of creating a very specific feature which only solves very specific situations. I don’t think these two features fall into that trap, but with each new language feature I feel that I’m getting closer to that sort of problem. With this in mind, I plan to add the line expansion feature first, then recreate Topsoil using the feature. From there I’ll reassess and decide if array structures are still required. I imagine they will be, considering how many games fundamentally rely on grids and spatial relations to function.

That’s all for this update! Thanks for reading.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.