Why Runes?

Wed, August 19, 2020
The three reasons why Rune-based coding is the right fit for CodeSpells.

In the last post, I showed a spell written in a Rune-based programming language.

It's the same spell being cast in this video: when it lands, it raises () the terrain by placing a small () sphere. You can see it in action here:

Now, I've met approximately five billion coders in my day, so I know some of the questions they'll ask: What if I want a cube, not a sphere? What if I want a sphere with radius X, not just a "small" sphere? What if I want the Runes to look different? What if I want to define a variable; can I customize how its rune looks? What if I want the sphere to be made of ice? Etc.

And then, there's the favorite question of good coders: Why? Why runes?

Well: I'm glad you asked.

The artistic reason: Code should "feel" magical

Fundamentally CodeSpells Authored Works are works of art. They're supposed to immerse you in the fantasy of being a wizard.

I don't know about you, but programing Java or Python takes me right out of the fantasy. It would be like Tolkien saying, And then Legolas checked his watch. It was time for battle. Blockly breaks the illusion for me too -- to a (slightly) lesser degree.

But runes?

I can clearly imagine wizards using runes to harness magic and bend it to their will. In Ursula K. Le Guin's Earthsea cycle, wizards have to know the "true name" of something in order to gain power over it. In my CodeSpells Authored Works, encountering a Rune is equivalent to learning something's true name. You can now use the Rune to write spells you couldn't before.

The gamification reason: Code should integrate with gameplay

Many CodeSpells Authored Works will be games (or at least they'll employ some form of gamification).

In old versions of CodeSpells, after spending months developing the in-game coding experience, my collaborators and I have always struggled with the game design aspect of the project: What, ultimately, will the player do... aside from coding?

We never had a satisfactory answer. Everything we came up with felt "bolted on", designed after-the-fact, and artificial.

But with Runes? They make the perfect collectable. The more you collect, the more powerful your spells. Suddenly coming up with "game loops" (as the fancy people call them) becomes easy. Here's one recipe:

(build your own game loop)
  • The player will use spells to do X so they can collect more Runes.
  • Runes will let players write better spells, so they can do more X.

Just fill in X.

It doesn't make game design easy. But it certainly makes it easier.

I hope the CodeSpells Canon will be full of works about collecting knowledge of cool languages for crafting spells I've never seen before. Make a work like that, and you can bet I'll play it.

The modding reason: I want modding and spellcrafting to be friends.

I define modding as: writing code outside of a CodeSpells Authored Work -- either to change the work or to create a new one. I define spellcrafting as writing code inside an CodeSpells Authored Work -- for the purposes of altering the world around you.

Note: Unlike spellcrafting, it's okay for modding to break the fourth wall and not "feel magical." In theory, any language would be adequate -- even Cobol or Fortran.

That said, I want there to be a clear pathway for players to become modders. This is both for their own sake and because CodeSpells is a community. Communities grow when the people within them grow.

Runes allow me to make spellcrafting and modding so similar that they are really just slightly different syntaxes for the same semantics.

I suppose you could make a Rune version of any modern programming language. You just have to do two things: 1) say what the syntactic (glue-like) bits should look like as Runes (parentheses, curly braces, square brackets, commas, angle brackets, etc.), and 2) say what the semantic (meaningful) bits in your language should look like as Runes (ifs, ands, ors, keywords like class and for, API functions names, user-defined variables, etc.).

Luckily the language I'm using to build the CodeSpells Authoring Tools (and therefore the one that mods can be written in out-of-the-box) is a descendent of Lisp. So for me, there's less work making Runes for all the boring glue-like bits and a lot more time for the fun meaning-carrying bits. And more importantly, for players, there will be none of this nonsense: "Congratulations, you killed the Possessed Wizard with a fireball. You've unlocked... a Comma Rune and a Curly Brace Rune!"

Lame. Breaks the fourth wall. It's like Tolkien saying: News of Legolas's prowess in battle reached Sauron by way of Tik Tok. The orcs were ordered to post mean comments.

Note: In my CodeSpells Authored Works I'll be giving wizards knowledge of the boring Parentheses Runes for free. (They are simply Runes for grouping other Runes.) So whenever players collect a new kind of Rune, it'll always be something they can actually get excited about, a "true name," something with real semantic meaning -- not something syntactically lame, like a square bracket or a semi-colon.

(programming language musings)

I wonder if John McCarthy in 1958 realized that his hyper-minimal syntax would one day be the perfect fit for wizard coding games in the year 2020.

What's next?

My next post will talk more about what Runes and Rune-based coding will be like and how the CodeSpells Authoring Tools will help authors create their own Rune-based languages.

- Stephen R. Foster

P.S. Please consider supporting us on Patreon. We can't do this without you!