Blizzard Entertainment’s Hearthstone is the market-leader in digital collectible card games. In addition to a considerable casual user base, the game is also a popular esports title with several small online tournaments played around the world every day and multiple global live tournaments taking place every month. According to Esports earnings data, the prize money awarded in Hearthstone tournaments is the seventh-largest amongst all esports games.

Despite all of this, the three-and-a-half-year-old game has no in-client competitive play support whatsoever. The developers have expressed interest in adding such support, but according to their latest statements, they are planning a full in-client tournament experience with no estimated completion date.

This seems to contradict all modern software development methodologies. We have agile sprints with new functionality delivered each sprint. We have minimum viable product (MVP) methodologies that identify the essential features and start by delivering those and expanding later. Yet, the development of Hearthstone does not seem to follow such methodologies.

What if it did?

Identify the pain: it’s all about user experience

When selecting features for development for an existing product, we have the luxury of already having actual users who use the product for their own purposes. Therefore, we can start gathering data on what are the most crucial weaknesses in the user experience straight away.

Therefore, let’s examine what an online tournament experience looks like at the moment.

The tournaments are run on third-party websites that are used to generate the competition bracket, whether it is in single-elimination, double-elimination, or perhaps Swiss format. Players register their account ID on these websites, and when they are prompted to play the game, they can contact their opponent in-game based on this ID.

However, there is still a hurdle to climb before the match can start. Hearthstone matches are typically played with multiple decks, most commonly in Conquest format where the player needs to win a game with each of their decks to win the match. The standard competitive format is a best-of-five Conquest with one ban: each player nominates four decks without knowledge of their opponent’s lineup, after which they each ban one of their opponent’s decks without knowledge of their opponent’s ban. All of this is currently managed on third-party websites: players manually enter their lineups and perform the bans.

However, there is no connection between the website and the game client. Therefore, once in-game, it is standard practice to require both players to upload a screenshot of their deck selection screen to confirm that the decks they have told they have on the website are the decks they also have in the game. As only class information is relayed over the website and not all deck details, a common way to attempt to cheat is to prepare different variants of the same class and then select one that is most tuned to defeat whatever classes the opponent has: the shared screenshots are used to verify that each player has only one deck prepared for each class.

The screenshots are shared from the friendly challenge deck selection screen, where the players can only select the deck they want to play with. Regular tournament rules prohibit the players from leaving this screen for any reason after the match begins, as if they do, they may edit their decks in an attempt to cheat.

Once the match begins, it is up to the players to ensure that decks are queued according to rules: in Conquest format, once a deck has been used to win a game, it cannot be selected again, and in Last Hero Standing, a deck that wins has to be selected for the next game as well. Mistakes, accidental or intentional, in queueing decks are a regular source of complaints to tournament administrators.

Another source of issues is disconnection during games. As there are no replays and no way to pause or continue a game, it is often difficult to determine what the result of a game that ended in a disconnect should be. Usually a screenshot showing unavoidably game-winning position can prove that a win should be awarded to one of the players, but short of that the game is usually replayed from the start.

Another issue during games is in-game communication from other players or observation by other players. These are often prohibited by the rules, but players need to manually change their in-game status to prevent messages and observation of their games.

Finally, as there are no replays or match history, players are usually required to manually take screenshots of the games they win: failure to do so has occasionally resulted in the losing player contesting the result and getting a regame because the winner has been unable to prove that the game was actually played.

So, what kind of things could the game client do for the players?

Ability to challenge to a tournament game instead of a regular friendly game
Muting all communications with other players and preventing observation unless both players agree (confirmation dialog)
Ability to select the tournament decks and disable all other decks
Ability to select ban or no ban format and perform the bans
Ability to set the match format: Conquest, Last Hero Standing, or free selection
Ability to set the match length: Best-of-one, best-of-three, up to best-of-17 (all nine classes) or free length
Ability to return to an incomplete challenge with the same decks, at least the latest challenge
Automatically saved game replays that can be used to prove results and continue a game after a disconnect (or at least automatic game-end screenshots to prove results)

Prioritize for rapid delivery

Software development nowadays is expected to deliver fully functional software in small increments over a short period of time. With the pain points identified, the tournament functionality can be divided into multiple sprints and actual, helpful functionality can be delivered from sprint one.

Phase one: Tournament challenges

Starting with the low-hanging fruits, it would be possible to implement a tournament challenge:

Set the number of decks used by each player
Select your decks
Ban or no ban, optionally ban one of your opponent’s decks
Optionally mute all communications with other players, prevent observation unless the other player also agrees to it (confirmation dialog)
Ability to return to your latest tournament challenge with the same decks
Automatically saved screenshots of game results

While this basic package would not enforce any specific tournament format or solve disconnect issues, it would achieve multiple important goals:

Prevents cheating by enforcing deck and ban selections within the game client
Prevents outside observation (ability to allow it if both players agree is important for broadcasted matches) and communication
Allows for restarting the client as players could safely return to the same decks they had
Automatically saves proof of game results

This tournament challenge is the MVP of competitive play support! Not a full in-game bracket, not format selection, just plain and simple answers to the real pain points players are experiencing in online cups every single day.

Phase two: Tournament format support

For the next phase, it would be possible to add more specific format support: still retaining free selection as an option, but also enable proper selections to be enforced in-game:

Select the tournament match length: Best-of-one, best-of-three, up to best-of-17 (all nine classes) or free length (the number of decks to be selected depending on this choice)
Select the tournament format: Conquest, Last Hero Standing, or free (decks available for selection appropriately, no possibility to queue the wrong deck)
Ability to return to a specific state of the match upon approval of both players: as there is no disconnect-proofing at this point, we need the ability to declare a disconnected game (or indeed any game) as won by either player or as a regame

These options would fine-tune the tournament challenge:

Makes it easier to keep track of the match score
Makes it easier to queue the right deck
Enables disconnect handling within this framework even though disconnected games cannot be continued

Phase three: Disconnect-proofing

The next step would again be a bit more work than the previous two: actually enabling a game interrupted by a disconnect to be continued from a replay.

As there is currently no replay feature whatsoever, I would expect this to be a major undertaking. The key point is that it would be possible to deliver significant quality-of-life improvements to players way before this challenge needs to be tackled.

Phase four: In-game tournaments

This seems to be the main thing in the mind of the Hearthstone development team when it comes to tournament modes, but in an agile development framework, it is the last one to tackle.

There are already loads of third-party websites that can generate tournament brackets – they are not used for Hearthstone alone, but also for a large number of other games. Many have also added Hearthstone-specific support for deck selection and banning, but they would not need to do that if those aspects were supported in-game.

Therefore, the least urgent aspect of tournament support is actual bracket generation and solving questions such as synchronous or asynchronous tournaments. The team can come up with awesome things for these, but first, it is the basic tournament support and user experience that needs to be addressed.

Conclusions

With simple identification of issues and prioritizing them based on urgency and development effort to ensure a steady stream of deliverables, all of the issues can be solved effectively and also with a clear outward appearance of progress.

This has been a sample analysis of a particular issue, but the same principles apply everywhere:

Identify the pain
Prioritize, proceed from the clear and straightforward to the unclear and fuzzy
Deliver fully functional parts, start with the minimum viable product (MVP)
Maintain the momentum: deliver and make the customers feel that you are delivering