Creative process of a procedural spell crafting system

When I was a kid and played D&D (actually I still play D&D once in a while, but that kid part is no longer true), I’d always play as a Wizard - or some other spellcaster. I always thought spell casting was appealing: instead of brute strength, you get to use the power of your intellect/mind/wisdom/etc and use that to vanquish formidable opponents.

The only problem with role-playing such characters is that you don’t actually need to use your intellect to cast spells. Table top games and video games instead offer pre-engineered spells (granted, that sometimes allow customization). This was the starting point of an (overly) ambitious project that I started in 2014: Mages of Mystralia.

Screenshot of the game in its current state

The guys on the dev team and myself were all amazed with what Magicka had achieved: although lacking the “intellect” aspect I longed for, the game delivered a truly believable experience of playing a spellcaster in battle: a constant effort to concentrate on recalling sequences - sometimes messing up and producing unforeseen, undesirable synergies with the environment or with previously cast spells.

Our approach was to exploit another aspect of spell casting: creating spells. Not recalling memorized spells. Not experimenting randomly. Designing! And because we’re hardcore believers of the saying “easy to learn, hard to master”, we had to make designing spells a simple, elegant procedure in the context of cleverly designed levels. We decided to make an action-adventure game where the player’s steps in understanding a procedural spell system would be properly paced; where intricate environmental puzzles and growingly difficult combat encounters drive the players to seek new spell components required for new spell designs.
 

Development Process

We started off with the simplest programming tool we knew, Virtools. That software was exactly that: easy to learn, hard to master. It could achieve almost anything without a single line of actual code.

Virtools' scripting

The first iterations of our spell crafting system were based on Virtool’s “flow” of procedures: the spell’s sequence could be controlled and data was transmitted from node to node to achieve specific results. This way, the player could decide how a spell would evolve over time or react to different triggers. In this system, we only had to “hardcode” the elements (fire, water, earth, etc). Everything else was scripted. We stubbornly clung to the ideal that the player should be able to recreate any spell that he saw in other games or in movies.

Unsurprisingly, it was way too complex for the design direction we had agreed on, so our next iteration was the exact opposite. Any and all management of the spell’s sequence was removed and we instead "hardcoded" sequences that seemed to fit best with the behaviors that the player used on the spell. For example, adding the "movement" behavior to a spell immediately implied that the player would create a projectile. Each behavior was a rune on the page and players could stack as many as they wanted by connecting them to the main “node” in the center. It was very limited, but based on our playtests, it was far more accessible and enjoyable. Because we had to deliver demos to potential partners, the system stayed like this for a while and we immediately started working on level designs to support it.

Our spell crafting system in the summer of 2015

We thought our system would provide an extraordinary opportunity for us to develop a unique lore: we would be able to actually show the inner workings of magic. What Robert Jordan and Ed Greenwood tried to describe with words in literature, we would describe with nodes and connectors. We wanted our system to almost feel like programming, without showing lines of code, variables or any numeric values at all. Because every spell we made tended to look like spider webs of nodes, we came to use the stars and constellations as a theme for our magic system’s narrative context. We contacted Ed Greenwood (because, why not) to help us develop that lore. With his help, we slowly started weaving a consistent game world around our less-than-ideal spell system.

The response from distributors and partners was underwhelming. The game's visuals were still work in progress and the spell system itself could not sell the game. And to tell you the truth, we were not thrilled either. We were bitter about the fact that the spell crafting system was almost dumbed down to a customization system.

To make things worse, more spell crafting games began appearing that year. Lichdom: Battlemage was one that was very much in line with the experience of Magicka (with more customization). Then Codespells, a game that cleverly teaches basic programming to kids, was announced. The impressive procedural system of Codespells became a very solid reference for “programming-based” spell behaviors and made us realize that we absolutely needed to reinstate at least some of the more advanced mechanics that we previously had (now that I look back on it, I’m grateful we did remove them at first). Visually, our system looked comprehensive and the constellation-inspired glyphs really did the job well. We felt that this elegance was key to making the game completely accessible. So our next iteration needed to preserve that while providing a solid alternative to other spell crafting games. And time was running short; some dungeons were almost finished, already.

In the following weeks, we reset the whole system and UI. This time, we opted for a new paradigm: templates. They were really only archetypes to help us define the basic sequence: immediate spells (instantaneous effect), projectile spells (existing for a while or until they hit a collider), and conjuration spells (existing for a fixed period of time, no matter what). Players could create very different spells from these templates by choosing from a variety of behaviors (for example, "explode on contact", "move", "boomrang"). A secondary rune, called Augment, could then modify parameters of behaviors they were attached to. We agreed to sacrifice the more unusual spell types ("channelled" or "sustained" spells - those didn't feel right in-game anyways) but created a defensive spell category (self) to allow at least a basic "shield" mechanic. This category ended-up having a lot of hard-coded combinations. We didn't like it, but it was the only considerable compromise we had to make with this new iteration. This is the version we showed at Pax East in early 2016, so we were able to collect data from a larger sample this time.

Our spell crafting system in early 2016

Closing the loop

As the game’s production progressed and more content was added, we were slowly getting to the point of no return. Soon, it would be too late to change the spell crafting system. Our valued marketing/business guy Dan Adelman was putting pressure for us to deliver a new graphic overhaul of the spell crafting menu and we knew we could only afford to do that with a final, bulletproof design.

And then, while fooling around in Transistor, it struck me: nested spells! It was not exactly that in Transistor, but the idea of re-positioning behaviors differently in a sequence made me realize that we already had the basis for that: our templates. If a fireball was to hit a wall and create an AoE explosion, that would in fact be a projectile spell (fireball) that then creates an instantaneous spell effect (the explosion). So we added four different triggers, used much like behaviors. The player simply connects a trigger rune to the spell and when he does, he can select a previously saved spell that will be cast when the appropriate event is triggered (onHit, onEnd, onTimer, onCast).

This rendered many of our existing runes redundant. For example, “explode on contact” was removed. In a few weeks, we went from 20 different behavior runes to a mere 11, but the resulting system still felt 10 times as deep as before.

Current state of the spell crafting system

Now more than ever in my career I understand the weight of a truly iterative design process. In my previous roles in large productions, we never had the time to do it properly and I thought that it would change by having my own studio and team, but budgets and deadlines are what they are. Because of this, we could perhaps not do as many wishlist features as I hoped, but I believe this is only a small price to pay to obtain a more solid core feature. 

All in all however, what I’m most proud of is the overall consistency and flow of the player experience through the game. We recently achieved an important production milestone where we can play the game from beginning to end and feel what it’s like to learn each rune one by one. We were aiming for a 10 hours long action-adventure, but from the results of our most recent playtests, time spent experimenting with the spell crafting system increased the play-through time to 15 and in some cases well beyond that. And we’re not quite done adding content yet, because we plan to ship across all platforms in Q2 2017.

Perhaps in a future post, I’ll go into details of more precise issues and challenges that we faced, notably the (somewhat) procedural spell FX system. Thanks for reading this!

---

A little bit of shameless advertisement now: if you want to learn more about Mages of Mystralia or if you can spend a minute to support us on social media, please look us up on google/facebook/twitter/etc. This would help us a lot!