I'm an engineering manager at Braintree. I write about politics, psychology, and software.
Recent blog posts:
19 June 2016
Hearthstone, the online card game by Blizzard, is well known for its exciting gameplay and huge community. I’d hold it up as a real triumph of game design; it’s well balanced, fast and fun. Beyond individual card design, though, Hearthstone stands out thanks to some subtle but powerful decisions the developers made about how the core of the game works. In this blog post, I’ll examine one such core decision – players may only make choices on their turn – and ponder the effects of this invariant as if the game were a software program (which, come to think of it, it is).
Hearthstone is often compared to Magic: The Gathering, and for good reason. Many of aspects of the games are identical: each player is represented as a hero with a certain amount of life; players gain resources (mana) over time, which they can use to play increasingly powerful cards; and the game is won by reducing the opposing hero to 0 or fewer life.
However, Hearthstone’s mechanics are much more restrictive (and simpler) than Magic’s. To pick one example, turns in Magic go through a number of explicit phases in which players make decisions: untap, upkeep, draw, main, combat, etc. Hearthstone implicitly still has phases, but players only make decisions in the “main” phase. The other phases of the turn are restricted and processed automatically by the game – I’ve never seen explicit names for them.
Magic is played face-to-face and involves a lot of decision-making even during opponents turns. Players may decide how their creatures will block enemy attacks, whether or not to counter enemy spells, which cards to discard, etc. Hearthstone has none of these mechanics: the player’s hands are effectively off the keyboard during enemy turns. When a mechanic might require active decision-making during opposing turns, Hearthstone often uses random effects instead. I’ll go into detail on this point in a moment.
From a game design perspective, this is very clever. It takes full advantage of the fact that Hearthstone runs on a computer and can easily generate random numbers. It also makes play on mobile devices much easier. Decisions like this are what make Hearthstone its own game and not just Magic on computers. (Yes, I just described Hearthstone’s use of RNG as a competitive advantage. I’m sure Reynad and Kripp will be thrilled.)
Hearthstone largely revolves around minion combat: each player summons monsters from the Warcraft universe to fight for them and eventually to beat up the opposing hero and win the game. To understand the impact the interactivity rules have on minion combat, consider two common abilities minions in Hearthstone have: battlecries and deathrattles.
A battlecry is an effect that triggers when a minion is played from a players hand. Because they’re explicitly triggered by a player, battlecries can (and frequently do) include targetted effects. The Fire Elemental below is an example of a minion with a powerful targetted battlecry.
A deathrattle, on the other hand, is an effect that triggers when a minion is killed. Minions can be killed more or less at any time, so deathrattles cannot include targetted effects. If the developers want to include a damage dealing ability like Fire Elemental’s as a deathrattle, the rules of the game force them to remove the element of player choice from the effect. The usual way to accomplish this is to make the damage randomly targetted, such as in the case of the Huge Toad card below.
But here’s a wrinkle: some minions have deathrattles that summon other minions. The Haunted Creeper below has a deathrattle that summons Spectral Spiders for its owner. Are those minions allowed to have battlecries? If so, How do their effects get targeted?
Blizzard could have solved this problem by requiring that deathrattles that summon minions only summon minions that don’t have battlecries. Or, they could have divided battlecries into two groups: those that need player involvement and those that don’t, and only allowed deathrattles to summon un-involved battlecries. These moves might have worked, but they introduce more and more categories of things into the game, which increases the game’s overall complexity and make it harder to introduce new mechanics.
The route Blizzard took instead was to distinguish between a player playing a minion from their hand, which triggers battlecries, and summoning a minion via a deathrattle or other effect, which does not. This keeps the interaction between the two types of abilities to a minimum and enables cards like Deathlord, below, which has a deathrattle that summons random minions.
I like to think of this decision in terms of code that might have implemented it or a type system that might have expressed it. In my ideal world, the game would be encoded in a software system powerful enough to tell us when our game rules are potentially in conflict, like when deathrattle effects summon battlecry minions.
Think about if you did it with a type system. Imagine Blizzard had chosen to categorize battlecries and restrict what kinds of minions could be summoned from deathrattles. We might have had types like
NonTargettedBattleCryMinion, etc. Functions in the deathrattle code would have to care about the difference between all these different flavors of minions. Right away, this would be a smell to me that the rules of our game are too complicated. What if we added new mechanics – would they also have to distinguish between these types of minions? Would they have to care about different types of deathrattles as well?
People think that software design is about constructing a taxonomy, often with a type system: is this a different thing than that? Are these things subtypes of this third thing, or are better thought of as components of each other? Is this a “has-a” relationship or an “is-a”? It turns out that taxonomy really isn’t where you want to be spending your time; if you’re fighting the battle here, you’ve already lost the war. When you get bogged down in these questions, step back and ask yourself: how can we make it such that the system does not care about these differences? If nothing cares about the taxonomy, there is no penalty to getting it wrong.
To put it more concretely, Hearthstone today definitely still has different types of minions, but from the perspective of the deathrattle and battlecry mechanics, those distinctions don’t matter. That was an even better move than turn 1 Tunnel Trogg, turn 2 Totem Golem.comments powered by Disqus