Vast: The Mysterious Manor | Development Diary - Gray Areas: The Making of the Enchanter

Designer/Developer Diary, Vast -

Vast: The Mysterious Manor | Development Diary - Gray Areas: The Making of the Enchanter

Despite its dense, interactive design, Vast: The Crystal Caverns scales very well across its player counts. Still, for my money, the game thrives at three or four players. At three players, each role can easily understand the capabilities of the other roles. This transparency makes for tighter, meaner games. At four players, the delicious emergent alliances have enough space to twist the players into all sorts of strange configurations.

This dynamic doesn't really change in the five player game, but I don't find myself usually wanting to play V:TCC with its full compliment. I think the fault lies with the Thief. I wasn't around when the Thief was being designed, but I think it's pretty obvious why the role doesn't jump off the page the way the others do. In terms of design, I think the Thief is well-made, with a tight action economy and some very interesting and subtle tools for interacting with the other players. But, because it was the last role designed for V:TCC, Patrick and his crew had to be careful not to undo all of the hard work they had put into the game. The Thief therefore treads lightly within a game system that is otherwise characterized by so much drama and color. When it comes to playing the role, it sometimes feel like you're in a separate game, milling about snatching the occasional victory condition here or there, hopeful to somehow outpace the rest of the players. And it works, but it isn't half as inspiring as the rest of the game.

From its earliest drafts, Patrick wanted the Enchanter to be different. The simplicity of the Thief's mechanics were an effort to make him easier to understand so that in games with lots of players folks could get a handle on the potential of all of the other players. But, this simplicity could easily backfire, making the Thief seem a little...unfinished. Of course, anyone who's seen any part of Patrick's rigorous playtesting practices knows that assumption is unfounded. For this reason, Patrick initially wanted the Enchanter to be a lot more mechanically interesting, with a deeper array of tactical and strategic options.

To this end, Patrick cycled through a range of options of what to do with the Enchanter. But, no matter how elegant and sophisticated its system was, it never quite got traction in our playtests. Every once in awhile an iteration would make a big splash, but it would so dramatically upset the rest of the game that it took a lot of the excitement out of the game.

In one iteration the Enchanter could give players different tokens which would either be buffs, debuffs, or tokens that would enable the Enchanter to adjust their position. This system had some promise but the debuffs were extremely frustrating to deal with. With the right debuffs placed on the right players, the Enchanter could slow the game to a crawl. This was supposed to encourage players to attack the Enchanter (releasing them from their debuffs), but the onus to attack the enchanter was yet another action penalty. So, no matter how weakened you found yourself, the last thing you wanted to do was to waste one of your few remaining actions swatting the Enchanter!

With each iteration the Enchanter seemed to get more baroque. But, no matter how clever the systems Patrick built around the Enchanter were, the core formula still didn't work. We were at a loss about what could/should be done with the role. Patrick was stuck, and, after a frustrating playtest, he turned the role over to the studio at large.

Working as a team, the first thing we did was re-frame the question around the Enchanter. The question about mechanisms and role complexity was a red herring. What did the game really need the Enchanter to do? Was he trying to speed up the game or slow it down? Should he impact the core system lightly, like the Thief, or completely change the game? As developer, my impulse was that the Enchanter needed to speed up the game. This was a 5th or 4th player role, so speeding up the game by a turn was a good thing. And, unlike the Thief, I wanted the role to totally upset the game. If players were in a game with the Enchanter, they should feel like their strategic assumptions were under attack.

With general parameters in place, we tore apart the role. My tenancy as a designer is to start with systems and incentives. The mechanics will take care of themselves. Even working as a developer, I try to maintain this ethos. So, as everyone rushed in with their ideas about the Enchanter, I tried to guide the conversation away from mechanical solutions. It wasn't enough for the Enchanter to be a dexterity game or deck-builder. If we weren't thinking about game holistically we were wasting our time.

Miniature sculpt of the Enchanter from Vast: The Crystal Caverns
In that conversation a new Enchanter emerged that radically transformed Vast: TMM. The basic concept was simple. The Enchanter would only offer buffs to the players. Powerful buffs. Some would grant extra card draws or treasures, others would be as strong as offering players a bonus turn. Previous iterations of the Enchanter had done similar things, but there had been a fundamental problem to those earlier iterations. The currency by which players “bought” those buffs only ever mattered to the Enchanter. This made the interaction feel a little flat. We needed the currency to matter for everyone. This led to the creation of the curse system.

Here's how it works. Each turn the Enchanter reveals an enchantment card. It's almost always a good thing, sometimes a very good thing that every player dearly wants. Players then on the count of three reveal a (blind) bid from one to five, using fingers their hands to indicate their bids. The high bid takes the enchantment (ties decided by the Enchanter, of course).

But, what are the players paying? Well, the winning players must draw an amount of curses from a bag equal to their winning bid. Most curses are blank, and do nothing but stack up in front of a player. But, 25% of them are Dire Curses. These matter, a lot.

When a player attempts to take the action which will win the game, the whole table must reveal all of their curses which are usually hidden. If the player taking the game-winning action has the most or is tied for the most Dire Curses, the winning action cannot be taken. They are stuck—made mighty by the Enchanter's magic, they are now bound to him.

Players can free themselves from these binds by running after and hitting the enchanter (each hit returns a dire curse to the bag). In practice, this means that while the enchanter's enchantments speed up the game by a few turns, it also adds a wonderful “over-time” period to the game where players have to settle old debts. Because the number of Dire Curses in the Enchanter's curse bag is so low, ties are quite common and so often more than one player is prevented from winning. So, before the Spider can escape the Manor, he's got to hunt the Enchanter first. Though the inability to instantly win the game is technically a “debuff,” because the Spider's mechanics are boosted by purchasing the Enchanter's enchantments, the challenge to free yourself of his curse before winning feels like a surprise boss fight.

For the Enchanter's part, the game is won by emptying the curse bag of all of its Dire Curses. They've got a few ways to manage “curse flow” but mostly they must encourage players to bid highly on enchantments and then to avoid being slapped around by the other players.

Mechanically, the role was quite easy to build. It was obvious the auction needed to be a blind-bid because it would allow players to communicate fuzzy information about how many Dire Curses they had already obtained. With this injection of curses into the game as a foundation, the Enchanter's other upgrades were built do adjust curse-flow, increasing the ways that the Enchanter could subtly change the course of play. As it so happens, there is a bit of a deck building element as well. The Enchanter starts with only two enchantments, which are shuffled and drawn from each turn to determine which enchantment is cast. But, as an upgrade, additional enchantments can be added to the draw stack, allowing the Enchanter to offer more enchantments per turn or draft enchantments specifically for certain game situations. For all of its mechanical simplicity, the role dramatically changes the arc of the game. There's a lot more uncertainty in the design and the five player TMM game is zany in a way that I think is very well suited to the theme.

no caption
Our Prototype Board for the Enchanter. Nick will make it pretty later.

 

 

- Cole Wehrle

 

Find the original post and discussion on Board Game Geek!


Back to Blog