I talk about the theory of game design a lot and I’ve been doing some fairly rapid iteration on a Wizard’s Academy scenario recently so I thought that it might be a nice time to work through how that process has gone to give some sort of illustration of what happens when theory meets practice.
So during the Kickstarter I made all sorts of rash promises about adding four new scenarios to the game so now I have the task of very rapidly designing and testing them so that I can keep my word without adversely influencing the shipping deadlines. In some ways this is a forgiving task, the core gameplay is well tested and functions very well and internal balance is not tremendously important as it’s beneficial to have some scenarios be easier while other are more difficult. However it’s also important to avoid “dead scenarios” that nobody will ever want to play and the new scenarios each need to be sufficiently different to the existing ones in some fundamental way, such that their inclusion is a genuine bonus rather than just a way to make a heavier rulebook.
For most of the new scenarios was thinking back through all of the playtesting for moments that amused or interested players, but that didn’t occur very often. The scenario currently named “Unstable Academy” is a fusion of two of these: Players enjoy room switching / rotating mechanics and players enjoy it when there’s a lot of ice on the floor and they need to do clever things to get to where they’re going – but no current scenario focuses on either of these aspects.
Strictly the scenario started as “What if room swapping / rotating was much more common?” which quickly lead through “What is the objective of such a scenario?” and into “What have players enjoyed doing?” which got me to a sketch outline of the scenario:
The academy is coming apart and the seams and rooms are blinking into and out of reality. A master of dimension could right this mess in a single spell, but these are apprentices, they figure that the best way to freeze everything in place is to literally freeze everything in place – binding the rooms together with ice.
Previous experience makes it possible to throw the nuts and bolts together relatively quickly. Most scenarios do well defaulting to slightly more botches than spells. It’s good to categorise the glyphs as 1-3/4-5/6/7 and have each set unlock on response to a problem being solved. Disaster cards should start with activates, wildmagics and a couple of level 1s and progress 00/11/22/33/44/dead. All of this and more has been shown to work in previous testing and while each scenario tends to break at least one of these rules, it’s always for a good reason and they generally prove to be a good starting point for any development.
After that nailing down the special rules that’d make the scenario work became important. Special rules are the hardest part of scenario design, done well they give a scenario its flavour and let it truly stand apart. However they also increase complexity and may interact with existing spells, rooms, characters or disasters in unexpected ways. Ideally they should be kept to the absolute minimum necessary to get the job done: In this case one rule to make the rooms move around a lot, a rule to make it possible to bind them with ice and a rule to add more glyphs as the group got closer to victory.
Games thrive on interesting choices, so any room swapping should be to some extent a result of the players choices. The core game already makes spatial relations important so all that’s necessary is to make the players choices somehow swap rooms, but also to encourage them to do something other than execute a perfectly optimal series of swaps. The rule “Whenever a player moves their room swaps with the room outside of the academy” covers these design principles perfectly, its deterministic and the players can work out the impact that their movement will have on the academy turns in advance, but the need to move towards certain areas conflicts with the need to game moves to provide an ideal room layout. I also wanted the rooms to rotate, but player choice would be too powerful there, so a second rule was added making a room rotate ninety degrees clockwise whenever it’s activated, as rooms are activated frequently this should provide plenty of spin, but players can see activations a turn in advance so can still plan around them.
A binding rule is much simpler: Once a room has an ice token in it, it cannot be moved or rotated in any way. This needed two additions. The first was “a room inside the academy” to stop the group icing the room outside of the academy and consequently stopping all switches in a single move. The second was the caveat “…except by the mana crystal”. It’s a general design principle that it’s more fun to let players have a last ditch “all or nothing” chance than to slowly but inevitably lose over a long period in which they aren’t meaningfully altering the outcome of the game. Wizard’s Academy implements this via the mana crystal which lets players spend a limited “run out and you lose” resource to solve most types of problems that can come up – including rooms being rotated to block off vital areas. “Once a room inside the academy has ice in it then it cannot be moved or rotated except by the mana crystal.” is still a fairly short and sweet rule, but covers the edge cases too.
Adding glyphs simply requires a look at what success is. There are 17 rooms total, but only 16 are inside the academy. The mana crystal uses mana to blow up ice if it’s ever frozen or surrounded by ice, so the theoretically maximum number of ice counters before that happens is 11-14 depending on how many entrances it has. Since the group win if they achieve the objective for even a fraction of a second one more than this is possible since they’d win after placing it but before resolving the fact that placing it kills them all. So 12 should be achievable in any layout. That divides nicely by three, allowing new glyphs to be added when 3, 6 and 12 rooms are frozen.
Finally required spells and disasters need to be stated, generally it’s a good idea to keep these to a minimum, since as fewer things are fixed a larger number of permutations are possible giving the scenario more variety. However if a particular draw would make the game ludicrously hard to stupidly trivial it’s worth stacking the deck so that it doesn’t happen. There are three potential dangers for this scenario:
No spells that create ice appear in the spell grid. (Game is likely unwinnable)
Fire appears in the initial deck. (Fire is therefore present before meaningful fire fighting options – fire melts ice so an early big fire ruins the game.)
Water appears in the initial deck. (Water is therefore present with plenty of time to spread, ice freezes water on contact so might auto-win the game.)
With that in mind a level one spell that creates ice is fixed into the first slot and the initial level one disasters are fixed at “troll” and “imp” (The only two level ones beside water and fire). So how did it playtest?
Well the first game was greatly loved by the players, an unanticipated yet pleasing aspect to the scenario is that trolls and imps are affected by ice so a lot of joy was had in trying to construct imp slides, by which imps tried to chase glyphs but ended up slipping into the mouth of a waiting troll and being devoured.
The “activate rotates room” rule was a disaster and was quickly erased from the game. It created a lot of downtime in which players were manipulating cardboard rather than playing the game and didn’t add nearly enough in terms of tactical considerations to be worth the overhead. The “movement swaps rooms” rule worked much better and was generally lots of fun – but had a bizaare effect on turn one: The first player moves out of the room, throwing everyone else outside of the academy and trapping them there with nothing to do until the first players turn comes around again. That’s no fun, so an extra setup rule was added to start the players in random rooms rather than all starting in the same room. Throwing companions into the abyss is still a consideration, but that becomes an “interesting decision” rather than a “the game forced me to do it”.
If all games followed the pattern of the first playtest the scenario would work with modifications, the group explored the spell grid and locked a few spells at every level before ultimately completing the objective a turn or two before they’d lose in a nailbiting finish. The problem was that over the course of the game they essentially “solved” the scenario and would win trivially in every subsequent play: The dominant play was to make a staff of freezing so that they could freeze rooms without expending glyphs and then cease all attempts to progress through the spell grid. As this sort of exploration is a big part of the game and the errors it creates a part of the challenge, such a strategy would be both devastatingly effective and deathly boring. Something must be done!
A new version was cooked up with a significant change: Now when a multiple of three rooms is frozen and a new glyph revealed the freezing spell gets shuffled into the newly revealed spell level, invalidating any staff of it and obliging the players to find it again. Combined with the other minor changes (random start locations and no rotating rooms) surely the scenario will work cleanly.
Testing the new version showed that it utterly and completely crushed a group, despite the presence of several experienced players. At the peak of their power they froze three rooms, but by the end of the game only a single ice token remained. They still had fun and it’s nice that people enjoy losing the game, but I think that it’s best for there to at least be a chance of success.
The first factor that hurt them was just bad luck, for the level 1 disasters they drew “fire” and another copy of “fire”. One of their level 2 disasters was “inferno”. The game generated so much fire that it became impossible for them to freeze most of the board.
The second was that the objective is just too damn hard. Some scenarios require the players to seek out a specific spell at each level and then cast it, Guardians, Demon Binding and (to a lesser extent) Botchy Snatchers all follow this pattern. Often the first casting achieves the objective, but if it doesn’t the second usually does. Making it so that three castings are required – more if any ice has melted – simply made the objective unachievable within the time limit.
This provides a pesky problem. The edge case disaster draw is an easy fix, it could be ignored (Giving more variety at the cost of a small % of games being extremely difficult) or the level 1 draws could be fixed (Guaranteeing one fire and one water so that the things that interact with ice are present, but at least exist in reasonable quantities) however the ‘time limit’ is much harder.
The first playtest demonstrated that one of the core ideas (lots of ice!) was fun and generated some great game when it came off. Reducing the requirements to 2-4-6-8 ice rather than 3-6-9-12 would make the game winnable, but at a cost to the ‘core fun’ of the scenario.
It may be possible to solve the problem by taking a step back. Forcing a search for the freeze spell made the scenario unwinnable, but it’s necessary to make searching through the spells rewarding enough to encourage interesting behaviour. Perhaps a different mechanism could be used towards the same end? What if after a new glyph is unlocked the spell is temporarily disabled until progress has been made at the next spell level? The first group demonstrated the victory is possible with binding a couple of spells at each level, if an extensive search of half (on average) of the effects is not required.
So I’ll modify the scenario in that way and give it a whirl later this week!
I hope that gives some sort of insight into how I apply the game design principles that I talk about on this blog in practice. I’ve talked about the role of a core decision in introducing game design to newbies, have touched on meaningful decisions in a bunch of posts and have highlighted the value of solving two problems with one stroke but it all becomes a bit messy in practice. I think that these fundamentals gave me a nice starting point for this scenario, but ultimately all design comes down to playtesting and iteration until you’re sure about something. For a game I’d do a *lot* more testing than I’m putting into the bonus scenarios, but I hope that breaking down this smaller challenge contextualises some of the other things I’ve had to say about design. I’m sure everyone does it differently, if you’re inspired it’d be great to see write ups of how you folks tackle specific challenges 🙂