Week one of making our Magical Spell Masters prototype saw us coming to abrupt terms with flaws in the concept. The central mechanic was predicated on a player being able to spell any word, and the cleverness was in figuring out which words were the right ones. In practice this is difficult, and it certainly isn’t very fun.
So we quickly pivoted to something more like a deck builder: you accumulate particular magic words during your run (‘fire’, ‘tempest’, ‘inferno’, etc.) and these are the ones you’re trying to locate in your grid of tiles. You can still spell anything (according to the English word list we’re using on the back end) but these words will do trivial amounts of physical damage. You might be able to prod an enemy over the line if they have a few HP, but fundamentally you want to be using magic words in your deck.
To this end, most of my work this week was diving deep into the world of event systems. Unity canvas elements of course require the event system by default. Configuring buttons with behaviours in the inspector is just creating an event trigger.
Taking part in team stand-ups and talking about how I’m working on an event system can feel a bit like I’m telling people: “I’m working on something that sounds clever and important but is really just an excuse not to do the many other important things in my backlog.” If I were working on a prototype for a physics-based platformer (which I am) then that would probably be true.
But for something with even the smallest degree of mechanical complexity such as Magical Spell Masters, it’s absolutely necessary. And since the whole feel of the game depends upon tweens and animated canvas elements, it’s something I needed to work on sooner rather than later.
Of course, I don’t have experience building such a thing. On a large project, it’d almost certainly need some sort of authoring tool, or at least a friendly interface within the Unity inspector. (I believe PlayMaker can handle stuff like this too, but where’s the fun in that?) In our case, I’ve just made a singleton events system class where I’m chucking all my game events. It’s working well enough so far, but I can see it becoming an issue as it balloons in size. I’m already at my mental limit in terms of comprehending how everything fits together—how one event leads to another and another, variables being handed from one game object to the next.
Knowing where to put my listeners is sometimes a challenge. Without relying on manager classes (a habit I’m gradually breaking out of), I sometimes feel a bit like my program is a messy baton relay. Take the base letter tile clicking event, for example. When a user clicks on a letter tile, that instance of the tile tells the drop zone it’s been clicked and passes along a char so that a new tile instance (with the same letter) can be spawned in the drop zone. It also passes along a list index so that the original, clicked tile knows when its ‘partner’ in the drop zone has been clicked so it can re-enable itself.
Or there’s the tile melee attack. The drop zone listens for the ‘CastSpell’ event so that it can send its tiles at the enemy. The tiles generate a ‘TilesHitEnemy’ event when they reach their target, and the enemy listens for this event so that it can play an animation. The enemy’s health bar also listens for this event and subtracts hit points when each tile hits.
It makes sense when I write it here, and it does work. I like how dynamic it all feels, how fun it is to click play in the game view and see everything talk to each other and just work as planned. But it also feels precarious— like a bizarre creation in The Incredible Machine—that’s held together with nothing more substantial than my vague intentions. Trusting instances of game objects to hand over their precious data moments before politely destroying themselves feels like sending nuclear launch codes via carrier pigeon.
I’m sure there’s a better, more robust and logical way to structure event systems. There are probably many ways, and it’s in my interest to learn about them. For now though, it’s the glue that’s turning this prototype into a playable game and I’m enjoying building it.
Not too much to report from the art front. We’re not trying to fill these prototypes with tonnes of final art assets. I have a title card for our pitch video and some rigged book enemy models:
And that’s it for today. Week three is when the prototype is meant to be done. The actual outcome of this process is a pitch video, so there’s going to be a lot of smoke-and-mirrors work from here.