GD Column 25: When Choice is Bad

The following was published in the May 2013 issue of Game Developer magazine…

Nothing defines video games more than the importance of player choice. Interactivity is what separates games from static arts like film and literature, and when critics accuse a digital experience like Dear Esther of being “not really a game,” it is usually from a lack of meaningful player choice.

However, because choice is held up as such an ideal among game designers – armed with phrases like “enabling player agency” and “abdicating authorship” – the downside of choice is often ignored during development, hiding in a designer’s blind spot. In fact, every time a designer adds more choice to a game, a tradeoff is being made.

The game gains a degree of player engagement as a result of the new option but at the cost of something else. These costs can commonly be group together as either too much time, too much complexity, or too much repetition – all of which can far outweigh the positive qualities of the extra choice.

Too Much Time

If games can be reduced to a simple equation, a possible equivalence would be (total fun) = (meaningful decisions) / (time played). In other words, for two games with similar levels of player choice, the one which takes less actual time to play will be more fun. Of course, usually the comparison will not be so obvious; a new feature will add a meaningful decision, but is it worth the extra time added to the play session?

As an example, Dice Wars and Risk are similar games of territorial conquest which answer this question differently. In both games, players attack each other by rolling dice, and the victors are rewarded with extra armies at the start of their next turn. In Risk, the player decides where to place these armies, which can be a meaningful decision depending on the current situation. In Dice Wars, however, the armies are placed randomly by the game, and the result is a much faster game.

Which design is right? While the answer is subjective, the relevant question to ask is whether the combat decisions become more meaningful if the player takes the time arrange her new armies – or, as is likely, how much more meaningful they become. After all, the player can pursue a more intentional strategy in Risk, but is that aspect worth the not insignificant extra time taken by the army placement phase?

The answer may depend on the audience (Dice Wars is a casual Flash game while Risk is a traditional board game), but the designers should understand the ramifications of their decisions. Sometimes, army placement in Risk can be a rote decision, and sometimes, reacting to an unexpected arrangement in Dice Wars can lead to a new, more dynamic type of fun. Ultimately, the aspects of Risk which lengthen the play session must justify the time they cost to the audience.

Too Much Complexity

Besides its cost in time, each choice presented to the player also carries a cognitive load in added complexity that must be weighed in the balance. More options mean more indecision; deciding between researching five different technologies feels much different than choosing between fifty. Players worry not just about what they are choosing but also about what they are not choosing, and the more options they decline, the more reason there is to worry.

Each type of game has a sweet spot for the number of options that keep play manageable, enough to be an interesting decision but not too many to overwhelm the player. Blizzard RTS’s have maintained a constant number of units per race for decades; StarCraft, Warcraft 3, and StarCraft 2 all averaged 12 units per faction. For the third game, the designers explicitly stated that they removed old units to make room for new ones.

Indeed, RTS games as a genre are under assault from their more popular upstart progeny, the MOBA genre, best exemplified by League of Legends and Dota 2. The original MOBA was a Warcraft 3 mod entitled Defense of the Ancients, which played out like an RTS except that the player only controlled a single hero instead of an entire army.

This twist broadened the potential audience by radically reducing the complexity and, thus, the cognitive demands placed on the player. Instead of needing to manage a vast collection of mines and barracks and peons and soldiers, as in a typical RTS, the player only needed to worry about a single character. Consider the UI simplifications made possible by allowing the camera to lock onto the player’s hero instead of roaming freely across the map, which forced the player to make stressful decisions about managing his attention.

Of course, this change did take away many of the meaningful choices found in an RTS. Players no longer decide where to place buildings or what technologies to research or what units to train or even where to send them; all these choices were either abstracted away or managed by the game instead. Again, the relevant question is whether these lost decisions were worth the massive amount of complexity they added to a typical RTS.

The success of MOBA’s demonstrate that although players enjoy the thrill and spectacle of the large-scale real-time battles pioneered by RTS games, they do not necessarily enjoy the intense demands of trying to control every aspect of the game. Designer Cliff Harris discussed a similar point for his successful alt-RTS Gratuitous Space Battles, which does not allow the player any control of units during combat: “GSB does not pretend you can control 300 starships in a complex battle. It admits you can’t, and thus doesn’t make it an option. Some people hate it. Over 100,000 enjoyed it enough to buy it, so I can’t be the only person with this point of view.“

Too Much Repetition

The final way that too much player choice can negatively affect the game experience is perhaps a bit surprising, but games with too much freedom can suffer from becoming repetitive. A typical example is when a game presents the player with an extensive but ultimately static menu of choices session after session; players often develop a set of favorite choices and get stuck in that small corner of the game space.

Sometimes, a fixed set of options can work if the player needs to react to a variety of environments; the random maps in a Civilization game can prod the player down different parts of the technology tree. However, almost all games could probably benefit from reducing some player choice to increase overall variety.

Consider Atom Zombie Smasher, a game in which players use up to three special weapons (such as snipers or mortars or blockades) to help rescue civilians from a city overrun by zombies. However, these three weapons are randomly chosen before each mission from a set of eight, which means the player reacts as much to the current selection of weapons as to the city layout or zombie behavior. Instead of relying on a particular favorite combination, the player must learn to make unusual combinations work, which means the gameplay is constantly shifting.

Similarly, in FTL, the crew members and weapons and upgrades available change from game to game, depending on what the randomly generated shops provide. Thus, the game is not about discovering and perfecting a single strategy but about finding the best path based on the tools available. Put simply, the variety of gameplay in Atom Zombie Smasher and FTL emerges because the designers limited player choice.

At the opposite end of the spectrum, games with hefty customization systems usually devolve into a few ideal choices, robbing the flexible systems of their relevance. In Alpha Centauri, players used the Unit Workshop to create units with different values and abilities. However, the most effective combinations soon became obvious, marginalizing this feature.

Thus, giving the player too much control – with too many options and too much agency – can reduce a game’s replayability. Indeed, would Diablo be more or less fun if players couldn’t actually choose their skills? The game would certainly feel different as the loss of intentional progression would turn off many veterans, but the new variety might attract others looking for a more dynamic experience. Randomly distributed skills might force players to explore sections of the tree they would have never experienced otherwise. The important fact is that this loss of meaningful player choice would not necessarily hurt the game.

Ultimately, game design is a series of tradeoffs, and designers should recognize that choice itself is just one more factor that must be balanced with everything else. Even though player control is core to the power of games, it does not necessarily trump all the other factors, such as brevity, elegance, and variety.

Dragon Age Legends Post-Mortem

I wrote the following post-mortem on Dragon Age Legends during the summer of 2011, a few months after release. Because the game was still live at the time, the piece was never published. However, as the game has now been offline for over a year, and most of the development team has moved on from EA, I feel comfortable posting my thoughts from that time period.

My thinking today is different from back then. I have largely soured on the potential of free-to-play gaming as it almost inevitably leads to an unhealthy addiction to whales – customers willing to pay thousands of dollars for various items and perks. Legends never attracted the whales necessary to sustain itself, which is perhaps for the best anyway as I’m not sure how I feel ethically about players spending that much money on my games. (Having said that, I also feel one of Legends main problems was that we priced some items, such as energy, far too high.)

I do still believe in the potential of asynchronous gaming, especially for limited-scale, turn-based games (like Hero Academy or Ascension) or for long-term, real-time games (like Neptune’s Pride or Civ4’s PitBoss mode). With Legends, however, the asynchronous format screwed up an otherwise solid gameplay loop – the energy system artificially limited game flow and tying the game’s mechanics to real-world time made balancing for every type of player a nightmare.

These novel formats – appointment mechanics, friend recruitment, limited session lengths – seemed interesting at the time, but I now believe what should have been obvious – that a game’s format should enable and support the game experience, not limit and complicate it. Looking at the core gameplay systems now, I can’t help wonder how the game would play if remade with a dynamic XCOM-style campaign, with each turn-based battle moving the game clock forward, which would then determine how fast the characters heal and consumables are crafted. The game loop would still work and all the energy gate, friend list, and free-to-play complications could just be dropped. Maybe someday…

Our primary goal with Dragon Age Legends was to create a “social game for gamers.” This social RPG combined the interesting decisions and difficult trade-offs found in traditional games with the innovations of the social game world. In fact, the game is split into two halves – a turn-based tactical combat system similar to Japanese RPGs like Final Fantasy and a persistent, appointment-based castle-building game inspired by asynchronous Facebook games like FrontierVille.

What Went Right

1. Core Design Loop

We designed our core game loop specifically to match the Facebook format, with players jumping into the game for short play sessions throughout the day. The character’s core stats (health and mana) do not regenerate naturally as they do in most RPGs. (Health does replenish but only outside of combat and only in real-time – one heart per hour.) Thus, if players want to restore their health and mana between battles, they need to rely heavily on their consumable items – health and mana potions, injury kits, and mana salves.

These consumables are the fuel that powers players though combat. What makes Legends unique compared with traditional RPGs is that the player is actually in control of the supply of consumables as the player can create them in the castle with timed appointments. (For example, the castle’s apothecary can create two health potions in 30 minutes.) If a player begins running low on a certain item, she can always invest extra time at the castle to rebuild her supply.

The two halves of the game – the castle and the combat – create a self-sustaining economic loop. Gold earned from fighting battles and completing quests can be invested in expanding the castle and upgrading its rooms. Accordingly, the castle creates the potions, salves, and bombs that the player needs to defeat the increasingly difficult monsters encountered over the course of the game.

Hence, the combat and the castle provide context for each other, motivating the player to keep fighting and to keep building. This loop gave the team a clear central vision for the game, to pair the meaningful decisions of a turn-based RPG with the compelling persistence of a castle-building game. The system proved a good fit for Facebook, in which players might dip in at any time to fight a couple battles or just to craft a few more potions.

2. Meaningful Social Hook

We also wanted our game to have a meaningful social hook – a reason to be on Facebook instead of just being on the Web, like the game’s predecessor, Dragon Age Journeys. Simply put, friends should make the game more fun.

Further, we were not impressed with how many Facebook games implemented social features, often forcing players to pay a “friend tax” by, for example, asking 10 friends to help finish a building. These features help social games spread virally, but they often feel artificial and even abusive of the player’s social network.

Instead, friends should be a part of the core gameplay, so that players will naturally want to invite their friends to join. As a party-based RPG meant to be played a few minutes at a time in a browser, we had an opportunity to address this problem with a new format – the asynchronous MMO. Although players develop a single character, they recruit their friends’ characters asynchronously to help complete the party in combat.

The details of this feature led to some interesting social dynamics. A recruited hero receives a gold bonus that the hero’s owner can pick up the next time he logs on. As players tend to recruit higher-level and better-equipped heroes, their owners have a strong incentive to keep improving their characters, so that they will earn more friend gold.

Recruited heroes enter a rest state after each use, from a few hours to most of a day, depending on how much damage they withstand in combat. Thus, deciding which friend to use and for.which battle is a strategic choice as one’s most powerful friends can only be used a few times each day. In other words, friends become an important, but limited, resource.

This system led to much interesting discussion between our players about how friends should develop their heroes and even whether one friend was using another friend’s character reciprocally enough. In other words, the social interactions between players had become meaningful. As a nice side benefit, Legends differentiated itself from other RPGs because players were regularly exposed to the entire skill tree via their friends’ characters.

3. An Actual Closed Beta

The term “Beta” has lost some meaning over the years as almost every Web-based game exists in a state of perpetual Beta. FarmVille, for example, didn’t remove the Beta tag until April of 2011, 22 months after the initial release and well after falling from its peak of 83 million monthly active users in March 2010 to today’s 43 million.

Many Facebook games are developed iteratively in public, starting from a minimal initial version with many missing features. This approach has many benefits as teams get immediate feedback about what is working and what isn’t – a big improvement from the multi-year silos of traditional game development. However, there are disadvantages to a continuous public development process; early design decisions can become permanent as backing away from them might upset the current community.

We took a different approach as we started our public development with a Closed Beta from January 2011 to our release in mid-March. Just like a traditional MMO, we encouraged players to sign-up for the Beta online and then periodically sent out keys to grow our player base, letting in over 50,000 players.

During this period, we conducted a database wipe every two weeks, both for the sake of lowering our engineering overhead as well as helping to focus attention on the early game by funneling players through it repeatedly. Because our players understood that their characters and castles were not permanent, we were able to experiment and make rapid changes in ways not possible during an Open Beta.

For example, during the Closed Beta, we added a strict inventory cap, removed Always Critical Hit items, slowed the leveling curve, rebuilt the first five maps, and reworked the skills system multiple times. Although these changes were not always popular, any negative impact was lessened by the known lack of persistence.

In fact, we even began charging real money for our premium currency (Crowns) during the Closed Beta, mostly to make sure the system worked. Surprisingly, players began spending large sums of money, even with the knowledge that their characters would soon be erased. We quickly developed a system to return all spent Crowns to players after each database wipe to give spenders more confidence in their purchases. This simple change was worth the effort as the information we gained was invaluable to our monetization strategy.

What Went Wrong

1. Client/Server Synchronization

We devoted the first few months of the project to rapidly prototyping the combat system. which went quickly because we reused code, art, and animation from EA2D’s previous Flash-based RPG, Dragon Age Journeys. This period of quick-and-dirty development led to important innovations, such as the accessible, icon-based health/mana system and the extra combat step for consumable use.

However, Journeys is a more straightforward game that runs entirely in the player’s browser, unlike Legends, which requires a client-server architecture. When building the prototype, we ignored this difference for the sake of development speed, which cost us in the long run. Because of concerns over player cheating, we couldn’t just allow the client to handle the combat, and because of lag issues, we couldn’t let the server handle it. Thus, the combat calculations needed to run in parallel on both the server and the client, which meant we had to ensure that the two sets of algorithms were identical.

When the time came to turn on the servers for real testing, the client kept falling out of sync with the server because we had no real solution for guaranteeing the calculations would be in lockstep. For a time, we considered some technical solutions that would allow us to write the code in one language which could be run (or recompiled to run) in both places, possibilities which included the Google Web Toolkit, the haXe language, and running Javascript on the server.

In the end, we adopted the simple, but painful, solution of using manual brute force to ensure that every combat function was written identically in both Java and ActionScript. This process cost months of time for our lead gameplay programmer, during which time design and testing was essentially paused because the combat system no longer worked. This ugly solution blew a gaping hole in our schedule as little design or testing could be done.

2. Brittle Quest System

One big advantage of developing games on the Web is that they can be constantly updated – multiple times a day, if necessary. Bugs get fixed faster, and no gatekeeper stands between the developer and the player, slowing down the delivery of content. This rapid pace, however, does have its downsides, one of which is the challenge of keeping the persistent data of hundreds of thousands of characters in a playable state after every update.

Unfortunately, our quest system commonly dropped a small, but significant, number of players into a broken state after game updates. The problem was that the system did not fail gracefully. If a player was in the middle of a certain event that got changed, renamed, or even removed during an update, she may suddenly have no way to finish her current quest.

This problem was compounded by the strict linearity of the map and quest design. Maps were often a linear series of nodes that were paired with a linear set of quests that a player could only progress through in a certain, set order. If these nodes or quests were modified in any way, then players in an intermediate state could easily fall off the quest chain, with no hope of recovery. They might play through the rest of the game without ever seeing another quest!

As these issues began appearing, our engineers scoured the database, looking for characters with broken quest states, and then manually repaired the data. Eventually, we developed a tool to assist with this labor-intensive process as well as safeguards within the code to automatically fix stuck characters, if possible. Nonetheless, we lost significant engineering time during a key part of the project. The lesson learned is to design game content and systems that are flexible enough to fail gracefully when change inevitably occurs.

3. A Fear of Social

Our goal was to make a social game for gamers, many of whom express grave reservations about the tactics used by typical Facebook games to spread virally, by spamming friends with requests and notifications to pull them into the game. We put our greatest effort into making an engaging RPG and only developed social features that treated our players’ social capital with respect.

Thus, although we developed what we believed to be a fun, core MMO that fit the asynchronous format of the Web, our game was light on the viral loops found in most social games. Although Legends attracted a committed audience eager for new features and more content, our viral factor was very low; our players were neither inviting their friends into the game nor convincing lapsed veterans to return.

The majority of our team, including all of our designers, had never made a social game before, which meant that we were simply not familiar enough with the social hooks and viral features Facebook provided us. The list of standard features that we did not have at launch speaks to our naivety about what makes social games work and spread:

  • No use of Facebook’s notification/request channel
  • No rewards for clicking on another player’s wall posts
  • No collaborative tasks or reasons to ask friends for help
  • No gifting between players (even of actual loot items, as is common in MMOs)
  • No daily bonus for returning to the game

Further, we lacked many of the tools common to social game developers, such as A/B testing and a metrics viewer customized for our game. Instead, we had to rely on our own intuition and feedback drifting in from our community, which meant that we were never quite sure why our basic numbers (DAUs, MAUs, ARPU, K-factor, etc.) were either going up or going down. Ultimately, we were not developing a game that played to the strengths of its platform.

When the game was taken offline in June 2012, the team released a free standalone version that dropped the energy system and allowed people to either start from scratch or import their online characters. The game balance is not quite right as the Legends was not built to be played in long, offline sessions. For example, friend cooldowns were removed but not replaced by anything else, so the player can simply recruit the best allies for every battle, which was supposed to be a core gameplay decision. Further, the crafting system is still in real-time, which goes far too slow if the game is not played in bursts. Still, the game is at least available, which is better than many other Web games which just vanish into the ether.