Or, “Teaching a Confusing Game Mechanic to the Uninitiated Through Subversive Design”
This is the story of how Harry Potter: Hogwarts Battle came to be. Sort of. I was the lead designer for a collaborative deck building game engine built by Forrest-Pruzan Creative. That engine was later licensed by USAopoly, who then in turn combined it with the Harry Potter license to make a really awesome deck building game. What you’re about to read is an account of the design processes that got us to the point where USAopoly decided put our engine to use.
Around the spring of 2013 I had an idea for a collaborative deck building game that I pitched to my bosses at Forrest-Pruzan. I described it as a backbone that we could apply a license to and show to a publishing partner (other than USAopoly) that we knew published lots of licensed mass-market games. That it would eventually become Harry Potter: Hogwarts Battle wasn’t even a blip on our radar.
What I did know from the start was that I wanted to build a system that would ease non-gamers (or at least the kind of consumer that buys a handful of games a year through mass-market retailers) into the deck building genre. Deck building hadn’t been done with much success in mass-market to that point — and generally speaking still hasn’t — so I knew I had to distill the genre down to something that could be taught in about two pages of rules. It would also need a strong theme with characters players would immediately recognize. Those characters had to have intuitive connections to the cards they lived on.
We didn’t go with Harry Potter. That came later, once USAopoly licensed the game structure from us. We began with another well-known set of family-friendly characters that occupied an enormous world that gave us fertile ground for expansions. I won’t spell out exactly what the property was, since we didn’t ultimately partner with them, but if you want to guess, you’re welcome to. There was little doubt that the theme would catch peoples’ eyes when they were wandering through the game aisle at Target, Walmart, or Toys ’R’ Us, but whether those consumers would understand what a deck building game was from the box was another question entirely.
Something to always remember about games that sell at mass-market: consumers are far less likely to buy a game if they don’t immediately understand what the components do, even if they love the theme. To a complete layman, deck building games look and sound like collectable card games, and collectable card games are generally considered to be a much bigger investment in products, time, and mental energy than most people want to jump into. Games purchased at mass retail are predominantly impulse buys, and a product that confuses or intimidates that impulse buyer doesn’t help itself much in the sales column.
All of this meant that even with the universally loved theme we were building our concept prototype with, there was a trap sitting in between us and the consumer. If a customer didn’t understand right away what it was — or at least what we wanted them to believe it was — they’d walk right past it. We needed to take the deck building game and make it look, at a glance, like something anyone with absolutely zero understanding of deck builders would still see as a “typical” board game.
You do that by giving whatever game you’re making, regardless of genre or category, the trappings of mass-market family strategy board games.
It needed a board.
To your grandmother or neighbor or gym teacher who’s only ever played Monopoly, Scrabble, and Yahtzee before (apologies to gamer grandmas, neighbors, and gym teachers), games have these specific things. Boards, dice, and movers are, in one combination or another, in (unscientifically calculated) roughly 98% of the games you’ll find on mass-market shelves.
Boards and dice and movers aren’t generally necessities in deck building games, but we weren’t designing a deck builder for a crowd that already knew what they were looking at. We had to hide something that was likely new and foreign inside a facade they were comfortable with. So we made this.
There’s not a whole lot of revolutionary design in creating a play mat that shows the setup for a card game, but it checks off the “has a board” box when grandma looks at the back of the package. After we determined that the board was an aid for setting up the game, we saw that we could also use it as a scoring track; something else that mass-market game consumers are familiar with. Most other deck builders counted Victory Points at the end of the game, but the majority of the board games this audience was familiar with had transparent scoring that tracked turn-by-turn. We steered into that.
The idea was that as the team of heroes played the game, the villains they fought against were slowly marching up their side of the track in the center of the board towards the crown. You and your partners scored points and climbed up your own side of the track by defeating villains. Whomever got to the crown at the top first won.
This covered the board and the movers, though the latter was eventually dropped from the final Harry Potter build. Now we had to figure out how to make dice relevant to the game. Once again, I’m going to stop short of laying out the full mechanics of the die integration. My initial build didn’t make it into the finished Harry Potter: Hogwarts Battle game that USAopoly published, so I’ll keep that under wraps for now. Instead, I’ll offer you a sidebar that’s probably more interesting than the initial design itself.
In early 2016, the Forrest-Pruzan team had a meeting with the USAopoly product team that was working on Harry Potter: Hogwarts Battle. USAopoly had secured the rights to the Harry Potter license, and had brought along a rough (but surprisingly polished) prototype of the game that they had built. Late in the meeting, one of the USAopoly designers pointed to the dice, which even at that point looked a lot like the House Dice that appear in the game now. “We’re not entirely sure that we like these though,” he said. “I don’t know for certain if the game needs them. Was there a reason you included dice in the initial build?”
“Honestly?”, I asked. “It’s because if someone who doesn’t know what a deck building game is turns over the box, they’ll see dice and say ‘oh, I know what dice are, this must be a game’ and put it in the cart. Seeing dice makes people think they know how to play it right away.”
The USAopoly group laughed, entirely amused at how subversive the real function of the dice was. Later that year at GenCon, one of their designers told me that this revelation led them to look a little deeper at how wide they thought the audience might be. Thinking of the game as something that would likely be the first foray into deckbuilders for many consumers led them to breaking the game into seven sub-games, starting with a super-simplified “intro game” and progressively ramping up the mechanics and challenges as the sub-games went on.
USAopoly did use dice in the game, though not the way I’d planned. I think their execution was done really nicely within the game, and at the end of the day, my whole reason to use them at all was literally just to have them on the box. Harry Potter: Hogwarts Battle stayed true to that, and stepped it up in its execution.
Now we had our board, our movers, and our dice, all there to disguise a deck building card game as a standard-issue “roll and move” game. The next step was to start baking in things that would help new players get started once they’d bought the game.
Thinking back to the first time I ever played Dominion, I knew there were a few places I could see new players having trouble. First, there was the idea that you’d have a fresh set of cards every turn. Second, I knew it would feel foreign that you didn’t draw your cards at the start of the turn, but instead at the end, when you couldn’t use them. I also wanted as many aides as I could fit in that would help players set up and put away the game. Lastly, and this may have been the biggest challenge, the tracking of resources in deck builders can be brutal for someone who’s never even heard of a deck builder before, let alone played one.
The turn flow issues were simple to solve (or at least alleviate). I knew right away that I was going to give every player a basic player board to use as a cheat sheet. “Put your deck here.” “Discard your cards here.” “If you need to draw a card but there are none left, shuffle your discard pile and put it back where your deck was.” It’s hardly something worth taking any credit for as design innovations go.
Next, resource tracking. I wanted a game where players could gradually chip away at villains, so that meant having a physical counter of some kind that could be placed on villain cards on the board. Working backwards, that meant that rather than just counting up damage that could be dealt with cards in your hand and checking them against a villain’s threshold, I could just have players gather tokens on their player board before allocating them to villains. This also gave me a simple currency system for buying new cards from the board; play your cards, get tokens, spend tokens to buy stuff or fight bad guys. At the end of your turn, unspent tokens went away.
Using tokens, I realized, also gave me a way to make collaboration matter. Since I had a physical accounting device, I could have effects where resources could be given, taken, or carried over from one turn to another. Card effects could go beyond giving you resources for your current turn, and could branch out into ways to set your teammates up for theirs. It was something I’d never seen executed quite this way before, and it felt incredibly intuitive as a way to encourage players to work together and help each other navigate through their first few games. From that point on, the cards were all mechanically designed with this kind of teamwork in mind.
Setup in deck builders can be a little daunting to newcomers. There are typically dozens if not hundreds of cards to sort through and keep properly arranged. In order to simplify this process as much as possible, I built several visual cues into the prototype. (This is my background as a graphic designer showing through.)
The players’ starting decks would have obvious, color-coded faces. This meant that players could pick the starting cards out from the full hero cards deck very quickly, and that there was no counting of different kinds of cards when assembling starting decks. Each player had three “attack” and seven “money” cards, but unlike in other deck builders where setup included counting out three-and-seven for each player before the game, here you just handed the red player all the red cards.
Once the starting decks were sorted out, the only cards left to sort were the purchasable hero cards and the villain cards. Keeping these visually distinct was easy; the card backs for heroes had a light color and the word “HERO”, and the villain cards were dark and said “VILLAIN”. Additionally, the layout for the card fronts were very distinct; hero cards always used a “portrait” orientation, the way most playing cards are viewed on a table or in hand. The villains were set up using a “landscape” orientation, leaving no room for confusion.
Lastly, I used some mechanical shortcuts to make setup faster and easier. There would be no “always available” step-up resource cards like in most other deck builders. This once again reduced sorting when setting up and putting away the game. I also decided early on that the hero and villain decks, respectively, would be entirely random. This meant that setup was a simple as shuffling the deck and placing it on the board. No sorting of card stacks needed at all.
It went over like gangbusters in playtests, especially with folks who’d never seen other deck building games before. Together, the whole package was one constructed with them in mind. I’d built a game engine and prototype that had all the trappings and touchstones of a “traditional” board game, while maintaining — and building on — the depth and comparative novelty of a deck building game, and it flowed intuitively.
While the game design goals and the prototype construction decisions were all my own, I owe gratitude to several other FPC team members and contractors who gave feedback and helped build parts and mechanics. It was an early-stage concept pitch meeting with Andy Forrest, Alan Pruzan, and Jay Wheatley that made it clear to me that introducing an advanced game structure to a mass-market audience would require disguising it as a more basic game model. Our contractor Dan Emmons pushed for more clarity in how players needed to win as a team rather than as individuals with a common goal. Eric Duffy ground through days of editing art files, painting tokens, and cutting hundreds cards for the prototypes. All of us, plus the entire in-house staff at FPC played through dozens of games to see where we had to add, dial in, or abandon various mechanics.
I also have to give enormous credit to Andrew Wolf, Kami Mandell, and so many others at USAopoly who paired our prototype with the Harry Potter license and kept designing the game towards that property. They did an amazing job of turning our engine into a finely-tuned performance automobile.
Thank you to all of you!
*Ludum Videtur: Loosely translated, it’s Latin for “appears like a game”.