SandCat — Update 4

Welcome to the fourth update for SandCat, the game rules prototyping language. This update assumes you are familiar with SandCat, so read the introduction post here if you’re not.

It has been a while since the last update, so a lot has happened.

Changes in v0.0.4

  • Cleaned the syntax. Made everything more consistent. Removed characters that weren’t necessary, and made commands more consistent. Syntax now generally follows the pattern of Name = Type. So,
ChickenHealth = 0.
CowHealth = 0.
AddHealth = Event using Health 
does Health = Health + 1 if Health < 5.
GiveChickenHealth = PlayerAction does AddHealth(ChickenHealth).
GiveCowHealth = PlayerAction does AddHealth(CowHealth).
  • Added arrays which work like this,
Chickens = [5]{Health = 0, Mana = 0}.
ChickenCastSpell = Event using Chicken 
does Chicken'Mana = Chicken'Mana - 1 if Chicken'Mana - 1 > 0.
ChickenOneCastSpell = PlayerAction 
does ChickenCastSpell(Chickens[0]).
ChickenTwoCastSpell = PlayerAction 
does ChickenCastSpell(Chickens[1]).
  • Randoms in arrays evaluate for each index, instead of only once for all of the indecies. This is a small change that just make random generation much easier.
  • Built and launched the SandCat website, which you can see here. Eventually I hope the website will grow to something more, but for now I mostly wanted a place to post the games that I create with SandCat. Which brings me to the next point.
  • The SandCat library can now run on the web. So Unity webgl builds, or any web builds of any kind, are now possible. This is huge because it means designers can easily distribute their prototypes online for quick feedback.


Yahtz is another small test game I wrote. You can play the game here. I spent maybe an hour writing the general design on paper and then moved to SandCat to code the prototype. A few issues came up which needed to be fixed so I wasn’t able to complete the design.

Here are the issues.

  1. The language still doesn’t reduce duplication very well. You can see this problem in Yahtz. The behavior to move the characters is partially duplicated for each character. Ideally a designer should be able to specify how characters move, then all characters move that way. I have a few different ideas for ways to fix this. One solution is to add a simple type system so designers can specify how types behave with each other. Another possible solution is to allow designers to specify how arrays interact with each other. However each of these have their own issues. This isn’t an easy problem to fix and so I don’t have any definite or planned solutions yet.
  2. The language needs better iteration tools. The language relies mostly on recursion, and a more typical for-loop is possible, but both are a quite annoying to use. I’d like a better solution, but I don’t have any proposals yet.
  3. I intended the game to have enemies, which when killed would drop coins. But currently it would be quite difficult to add or remove entities. I think this can be easily fixed by adding Count, Add, and RemoveAt commands to arrays. I chose this solution because its minimally invasive.
Coins = [2]{X = 0, Y = 2}.
Coins'Add 1.
Coins[Coins'Length]'X = 5.
Coins'RemoveAt 0.

This update feels lacking in concrete solutions. I’m not 100% sure how to solve these problems yet, but I still wanted to put out an update. These problems are big and difficult, but the toolset is moving along. It’s getting closer to a workable solution — allowing designers to quickly specify, test, and iterate on their designs.

Like what you read? Give Ryan Rothweiler a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.