Design of the Times

This summer, Game Developer magazine shipped its last issue, yet another casualty of the journalism’s transition to digital. Since 2008, I had been writing a bi- or tri-monthly design column entitled Design of the Times, so the end of the magazine marks the end of that column as well. My blog earned me the initial opportunity; I posted about “8 Things Not To Do” as a game designer, which attracted the attention of editor-in-chief Brandon Sheffield, who was looking for a new design columnist who would focus more on the details and mechanics of game design. I didn’t feel equipped to produce 1,600 words every month, so I contacted my favorite game design blogger, Damion Schubert, to see if he would alternate months with me. (Damion gets credit for the name, by the way.) Eventually, we added a third columnist, Jason VandenBerghe, who probably wishes he had gotten a few more columns in before the end.

I enjoyed having a gig that forced me to put my thoughts down on paper on a set schedule. As random ideas floated through my head, I would saves the most interesting ones in a Google doc (which I may as well make public now), so that I would have a big backlog of column topics. After picking one, I would ruminate on it for a month or so until I had enough material for a full column, which is much more preparation than a typical blog post receives. I also tried to write columns that felt as much like journalism as they did like opinions, which meant doing research, quoting sources, and interviewing developers. For example, I talked to Days of Wonder CEO Eric Hautemont for my column on digital board games. Ultimately, I wanted to get out of my own head as much as possible.

My column essentially killed this blog as my writing energy focused on producing one piece of high quality every other month. Fortunately, Brandon agreed to let me repost my column online, so that my blog did not entirely disappear. (Damion’s blog, in fact, did die and only returned after the magazine disappeared.) I, too, am now returning to blogging although I am curious how relevant blogs are in the age of Twitter and Tumblr, not to mention Polygon and Gamasutra. (My post on stories and games garnered only two comments here but got 88 on Gamasutra.) I am not sure if I have the discipline to produce long-form pieces as with my old column, but I don’t think short-form posts have much value anymore. Fortunately, my career is undergoing an enormous transition, so I am at least going to have a lot to discuss.

In sum, I produced 25 columns, totaling about 40,000 words, which is almost as long as a standard size non-fiction book. My earlier columns focused mostly on very concrete, nuts-and-bolts topics and can be read almost like chapters in a game design textbook:

I also spent three separate columns struggling with the emergence of the free-to-play model as I saw it as the dominant design challenge of our time – indeed, in 2008, I predicted that the ultimate result of free-to-play would be “that the line between game business and game design has blurred.”

An important turning point came with a two-part series entitled “Theme is Not Meaning” on how a game’s theme and mechanics are related and how they can easily undermine each other if a designer is not careful. The article was well-received and eventually became a highly-rated GDC lecture. I transitioned to higher-level topics that were less easy to categorize. I wrote back-to-back columns entitled “Start Making Sense” and “Stop Making Sense.” I talked about how players inevitably ruin games for themselves in “Water Finds a Crack.” I wrote that “To be a game designer is to be wrong” in “Taking Feedback.” I asked (but didn’t answer) the question “Should Games Have Stories?” I finished my run with a column on “When Choice is Bad.”

I want to thank my editors, Brandon Sheffield and Patrick Miller, for trusting me with the column over its five year run. Looking back, I see much that I could have done better – I still can’t write a concluding paragraph to save my life, and I also wrote my share of filler columns when pressed for time. I’d like to thank the readers for taking the time to engage with my work, and I hope they continue to follow my current thoughts and projects here at my blog.

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.

What Microsoft Should Have Done

The biggest story of the upcoming console generation is that Microsoft has, within a month of the initial Xbox One announcement, already bowed to pressure and reversed its attempt to cripple the importance of physical discs. The Internet is currently doing a victory lap.

The transition from physical to digital was sure to be rocky, but the start to this console generation is now a lost opportunity for the industry. Physical discs are bad for everyone (except for retailers, of course). They are bad for developers, who lose the long tail of revenue once Gamestop undercuts them with used copies. They are bad for consumers, who end up paying artificially inflated prices for new games because of the inefficiencies of selling a digital product as a physical good. Physical discs are expensive, inconvenient, wasteful, and – most importantly – allow the entrenched and reactionary interests of retail to control gaming.

The answer, however, is not to implement a slate of arbitrary and restrictive rules that push the consumer away from physical discs. The answer is to make digital games so attractive that players will abandon physical discs on their own. (One might call this the Steam strategy.) Microsoft could have avoided this whole fiasco by maintaining the old disc-based ecosystem while softly undermining it with three moves that create an alternate digital future.

1. Cap the price of all digital games at $40

I argued that converting players from retail to digital required a price drop back in 2008. Besides the fact that both the publisher and the developer get more revenue from a $40 digital sale than from a $60 retail sale, the price cut strongly incentivizes players to buy the digital copy instead of the physical one, which is what Microsoft wants most anyway. The different price tiers make logical sense as well – a $60 disc costs more because it can be loaned out or resold while the digital version has the restriction of being tied to the original owner. Valve has maintained the $60 price point for new AAA PC games, but they have put in 10 years of hard work earning the trust of the community (not to mention that the $60 price is mainly an anchor point to make the discounted price more attractive). Microsoft does not have the same well of goodwill to draw upon, so they need to make a bold statement about the benefit of a digital game, which should start with a lower price.

2. Heavily discount older titles

Developers selling games on Steam always report that their highest-revenue days come during Steam Sales, better even than the first days after release when the game is still at full price. The power of the sale really has to be seen to be believed (here is an example from the indie game Dustforce.) Many developers were concerned about what these heavy discounts would do to their overall revenue, until they saw the actual results. Steam Sales generate extra revenue by appealing to a segment of the audience that might not normally buy the game – someone who is only willing to pay $5 but has either the patience to wait for a sale or the urge to buy before time runs out. Indeed, one of the hidden benefits of Steam is how many games are bought and then never actually installed; the community is full of collectors. Ultimately, heavily discounted digital games are the best weapon against used games, which at least still carry some stigma of being a secondhand item; buying a “new” digital copy at a bargain price is much more compelling.

3. Purchase persistence and backwards compatibility

I will never buy an Android phone or tablet. Why? The reason is that, now that I am on my third iPhone and second iPad, I have a lot of apps attached to my Apple ID, the majority of which are games. If I switched to Android, I would have to buy all those games all over again. Instead, when I upgrade between Apple devices, all my games are waiting for me. Much of it will never be downloaded again, but the option still exists. I haven’t gone heavily into iTunes for either music or movies, and that would tie me even closer to the Apple ecosystem. Neither the Playstation or the Xbox works this way; migrating to the PS4 or the Xbox One means starting a new digital games collection from scratch. Ostensibly, this migration of games between generations is not possible because the consoles are not backwards compatible; put another way, Microsoft and Sony both made the strategic decision not to spend the money to support this feature. In fact, the companies are missing a huge opportunity to help players tie themselves to their own closed ecosystems. If digital purchases from a Live account persisted forwards across every version of the Xbox, how less likely would a player be to switch over to the Playstation? Most importantly, purchase persistence gives players one more reason to buy a game digitally as it will be forever included with the account.

Combined, these three changes would destroy the traditional retail market. The $40 price would make digital games cheaper at release; the ongoing heavy sales would undercut the used games market; and persistence would make digital games easier to maintain across multiple devices. Microsoft needs to make buying games digitally a better deal for the consumer than buying them physically. The trick is to allow both physical and digital to co-exist and then let the consumers catch up with the obvious benefits of the latter. Allow the retail market to wither and die by evolving past it rather than attacking it directly and needlessly.

GD Column 24: Should Games Have Stories?

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

Stories and games have always had an uneasy marriage. From the beginning, designers have written stories into their games, giving the player a fixed beginning, a narrative path to follow, and a preset ending. At the same time, many players flocked to games because of their lack of narrative structure; a game experience is a chance to create a story, not to submit oneself to a designer’s unpublished novel.

At the root of this problem is an almost theological dilemma – can a game designer tell a story if the player’s choices actually matter? If the most important element of a game is its interactivity, then every static plot point a designer crams into the experience takes away from the centrality of the player. Put another way, if a game has a spoiler, is it really still a game?

To be clear, with the exception of a few abstract game like Tetris, almost all games benefit from story elements – an interesting setting, a distinctive tone, memorable characters, engaging dialogue, dramatic conflict, and so on. The best games have characters and settings that rival those of any other media – consider GLaDOS from Portal or Rapture from BioShock.

However, the actual narrative of a game – meaning the series of events which determines the plot – is the hardest element to reconcile with the essential interactivity of games. For this reason, narrative cannot be handled as it is with books or movies, in which the story is the core element that everything else must support.

Consider how Sid Meier added story elements to Pirates!, a game set in a period dripping with narrative possibilities. Instead of creating a single swashbuckling tale, with fixed plot points and a preset ending, he filled the game with the bits and pieces of a traditional pirate story. Depending on his choices, the player can rescue a long-lost sister, duel an evil Spaniard, survive a treasonous mutiny, discover buried treasure, escape from prison, and woo the governor’s daughter. Upon retirement, the game displays the notable events of the pirate’s life, chronicling the ebbs and flows of fortune. While the plot of a single playthrough would suffer in comparison to that of an authored work, the events have a special meaning for its intimate audience of one.

However, not every game is well-suited to become a dynamic story generator; some themes and mechanics are best handled against a mostly fixed backdrop. A hero needs an evil wizard to slay; a soldier needs an enemy to fight; and a plumber needs a princess to rescue. The solution is to use a light touch, to suggest rather than to dictate, to let go of the very idea of plot. Let the player explore the world and then assemble the final story in her own head.

“The Rolling Stones confirmed that lyrics are most evocative when just short of indecipherable.” – Paul Evans, The Rolling Stone Album Guide

Indeed, the role of narrative in games is more akin to the role of lyrics in music. A song’s words give the piece its context, its mood, and its setting while still leaving a suggestive gap for the listener’s imagination. Indeed, recordings often have lyrics that are inaudible, leaving the meaning intentionally obtuse. Would a writer ever do the same with the text of a novel? Further, listeners often enjoy songs in a foreign language. How many readers pick up a book in a different tongue? The exact meaning of a lyric is not its primary role; great songs leave room – often, a great deal of room – for the listener. So too must a game’s narrative leave room for the player.

Consider LIMBO, the puzzle platformer noted for its atmosphere, with its monochromatic tone and minimalist audio. The game’s story revolves around a very primal quest – a boy’s search for his missing sister – and raises more questions than it answers. Why is the boy looking for her in a dark, mysterious forest? Why is he chased by a monstrous spider? Who are the kids trying to attack him? Although LIMBO is completely linear, the lack of a traditional narrative – with a plot and dialogue and answers – means the story must be written by the player.

Another example is Atom Zombie Smasher, the micro-RTS about a patchwork military trying to stop a zombie apocalypse in the fictional South American city of Nuevos Aires. The game is peppered with gonzo vignettes (“Esposito scores the winning goal. Minutes later, he’s eaten alive.”), showing how the citizens handle the onslaught. The epilogue is a masterpiece of bizarro narrative, with scenes of a cyborg El Presidente and AK-47 fruit trees backed by President Eisenhower’s famous “military-industrial complex” speech.

Most importantly, Atom Zombie Smasher creates an evocative world without a traditional, canned narrative; the vignettes, in fact, are delivered at random during the campaign, letting the player’s imagination fill in the gaps. Brendon Chung, the game’s designer, points out that ”piecing information together is fun and knowing the work trusts and respects you is satisfying.” The effect is perhaps a bit too jarring for a mainstream audience, but the result is that Atom Zombie Smasher feels so much more open and alive than any pre-digested corridor shooter or bloated, dialogue-heavy RPG. A fixed plot is the enemy of player engagement.

“The function of prayer is not to influence God, but rather to change the nature of the one who prays.” – Soren Kierkegaard

One of the most tantalizing aspects of mixing video games and narrative is the possibility of interactive fiction, in which the player gets to make the big decisions in an otherwise traditional story. So far, this potential is unrealized as the player’s choices are usually limited to selecting between a few preset branches. Although there may be more than one ending, as long as the outcomes are finite, interactivity only promises a difference in degree, not in kind.

As the cost of production rises, developers cannot risk creating sections of a game without guaranteeing that the player will experience them. Thus, regardless of player choice, the interactive storyline must synchronize at key points. The plot of Knights of the Old Republic exemplifies this problem. The player can pursue a good or evil path, but both paths lead to the same place; the villain Darth Malak must be defeated, either to stop him (the good path) or to usurp him (the evil path). Even with completely divergent ethical paths, no outcome is possibly without Malak’s death.

These static plotlines lead to a jarring disconnect for many players, who might spend tens of hours playing an RPG but have no lasting memory of the story because it has nothing to do with the player’s own interests or choices. Ultimately, people write stories to share what it means to be human. What does that goal mean in the context of games? The core element of most stories is the choices made by the characters; the core of games is the choices made by the players. Thus, what makes games meaningful must be the choices made by the players themselves. Can a game ever tell a specific story and still preserve the importance of player choice?

The action RPG Bastion successfully tackles this dilemma. The game tells the story of a mysterious “Calamity” that shattered the world into pieces. As the player progresses, he learns of why the weapon which caused the disaster was created and what went wrong when it was triggered. At the game’s conclusion, the player must choose between either reversing time to possibly prevent the Calamity or to evacuate the survivors to a safer place and a new start.

What is most interesting about this decision is what happens next – which is that almost nothing happens. The game simply ends, with only a single image reflecting the player’s choice. The designers do not pretend that they are giving the player actual agency with this decision. Instead, the choice becomes almost meditative, a simple reflection of the player’s own nature. Would you undo your greatest mistake, or would you move forward as a new person?

In Bastion, the player learns about herself through the act of making a choice, not from seeing what some designer thinks should be the result. In The Walking Dead, the designers emphasize player choice by providing feedback on how one’s choices compare with those of other players. These results similarly illuminate the player’s own personality by showing which of his decisions go with or go against society at large.

Games that focus purely on the designer’s plot choices ignore that the most important part of a game is the player. Putting a story, regardless of its power or depth, inside a game is actually a crutch, an easy way out that stunts the advancement of our form. Games must leave room for the player, not just within the rules and the mechanics and the systems, but within the story as well.

GD Column 23: How to Become a Game Designer

The following was published in the Nov 2012 issue of Game Developer magazine…

People enter the games industry for many different reasons. For some talented artists, programmers, and musicians, a games job is a great way to employ their talents in a vibrant and creative field. Others simply enjoy being involved with one of their own hobbies and personal passions. However, for many, there can be only one reason to join the industry – to become an official Game Designer.

The simplest way to become a designer, of course, is simply to start making games. More powerful tools and distribution channel exist now than ever before to help individual developers create great games. Andreas Illiger made Tiny Wings. Brendon Chung made Atom Zombie Smasher. Vic Davis made Armageddon Empires. Jonathan Mak made Everyday Shooter. No one needs permission to become a game designer.

Nonetheless, not everyone has the resources, or simply the guts, to go it alone. Unfortunately, for established companies, starting game design jobs are nearly mythical; the job simply requires too much experience, and the competition is too fierce. Most game companies are already full of developers who want to be designers, so most new recruits are hired because they possess a specific skill, such as code or art.

One needs to earn the position of game designer, and one earns that position on the job. If a developer is positioned correctly to do design work, opportunities will present themselves. I earned my first design position by being ready when the Civilization 3 team lost its design and programming staff to the founding of Big Huge Games.

The team lacked a pure gameplay programmer, and our company president, Jeff Briggs, was filling in as lead designer. I was never officially titled as a designer, but I accepted every design task that was available. By the end of the project, my contributions were clear, and Jeff shared his design credit with me.

Thus, the big question for a working game developer is how to position oneself to take advantage of the opportunities that emerge to work as a designer. Here are a few suggestions that might help.

1. Learn to Program

Games are a very broad category, often encompassing multiple art forms at once (words, music, visuals). Some games have strong story elements. Some are almost pure abstractions. However, the one aspect they all share is that they are all based on algorithms. Code is the language of games, and knowing how to code will qualify one for a great variety of roles.

Perhaps someone needs to script enemy behavior? Does the team need a scenario editor but no one has time to build it? Maybe the game needs more random map scripts? Does a senior designer have an idea for a new game but needs a programmer to prototype it? All of these tasks could grow into more established game design roles, but only a programmer can undertake them.

2. Work on the UI or AI

There are two areas of game development that are not strictly thought of as “game design” but actually are – user interface and artificial intelligence. Because artificial intelligence,  which controls the behavior of non-human agents in the game world, is so inseparable from gameplay, working on AI is impossible without daily interaction with the designers. If an AI coder does a consistently good job and keeps asking for extra responsibility, game design is the obvious next step.

This path is even more clear for interface work, which is on the very forefront of the user’s experience. Game mechanics are useless if they cannot be communicated to the player, and UI is the most important tool for solving that problem. Thus, interface design is game design. The best part of the “interface track” to game design is that very few game developers want to work on the interface. Senior artists and programmers often view interface work as only suitable for junior developers. Use this prejudice to one’s advantage and volunteer for the job; game companies are always looking for capable developers excited to work on interface design.

3. Volunteer for DLC

Another nice path to game design is downloadable content. The stakes are inevitably lower for these smaller releases, and a game’s official designers are usually too burned out from the final push to even want to think about the DLC. Thus, DLC is a great opportunities for aspiring designers to step forward and demonstrate their ambition and potential. Companies want to see their employees grow into the role as hiring new designers is a huge gamble; DLC provides a great, low-risk opportunity to train them internally.

Working on the design for an expansion also has a huge benefit for the aspiring designer. Namely, one avoids the challenge of creating fun from a blank slate, which can trigger crippling pressure for a new designer. Instead, one can simply continue iterating on the core design, applying lessons learned from the game now being in the hands of thousands of players. Most games have plenty of low-hanging fruit that only becomes obvious after release; focus on these improvements, and the players will respond positively.

4. Focus on Feeback

Game design is part talent and part skill. Noah Falstein once postulated that a disproportionate number of designers are INTJ on the Myers-Briggs scale (meaning Introverted, iNtuitive, Thinking, and Judging), which suggests that some personalities are better suited to game design than others. However, talent will never be enough; one should actively develop one’s design skills, and there is only one true way to do that – implementing a design and then listening to user feedback. My own design education didn’t really begin until the day Civilization 3 was released when many of my assumptions about how the game played were proven completely false.

A game is not an inert set of algorithms; it is a shared experience existing somewhere between the designers and the players. Unless a game is constantly exposed to a neutral audience, its design is only theory. Games should have as much pre-release public testing as possible; the designer’s skills will only grow stronger with each successive exposure. Aspiring designers must find some way to experience this feedback loop. Releasing a simple mobile game or a mod to a popular game and then learning from the public feedback is much more valuable than working on some mammoth project which is unlikely to ever gain an audience before release. Even creating a simple board game can improve one’s skills as long as the designer can find a testing group for feedback.

5. Be Humble

Personal humility is a key attribute for success in today’s game industry. A designer must accept that a majority of his ideas are not going to work. Indeed, the game designer’s job is not to follow one’s muse or ego, but to choose a vision and let the team lead the way. Designers need to be humble listeners, not persuasive orators. If a designer ever finds herself arguing why a playable game mechanic is fun to a skeptical audience, then the game might be in big trouble. Designers still need to be assertive and confident – or else no one will ever take them seriously – but humility gives the clarity to see things as they are, not how one wishes them to be.

For aspiring designers, of course, this rule counts double. Coming across as arrogant or too certain of one’s ideas is a sure way to appear unready for the job. Having a great idea that no one takes seriously can be immensely frustrating, but the key is to maintain the right attitude. If one’s idea get implemented, don’t think of that idea as having won but as being tested. The real work begins once the idea is playable, and then it belongs to everyone. All game teams have more ideas than they will ever be able to implement, so developers should all ensure that the best ideas are pursued, regardless of their origin. Indeed, the origin of an idea is usually forgotten; what is remembered is who put in the hours to get it right.

Who Should Be a Designer?

Finally, all aspiring game designers should answer these simple questions: Have you ever made a video game? A scenario or a mod? A board or card game?

If you answered no to all of these, then you should ask yourself if you really are meant to be a game designer. Painters start drawing when they are young. Musicians learn to play instruments in grade school. Writers start to write. Actors act. Directors direct. Young game designers make games. If it’s a passion – and it has to be a passion to succeed – then designing games is something that you absolutely have to do, not just want to do. A true game designer cannot be stopped from creating games.

Designing games is not the same thing as playing them. The set of people who enjoy making games is much, much smaller than the group of people who enjoy playing them. Designing a game can mean years and years perfecting a single concept and demands the strength to learn from all the criticism which will be heaped upon the design. Ultimately, the mark of a true game designer is that, given free time on some random weekend, that person will sneak in a few hours of what he or she enjoys most – making a new game.

Choosing the Soundtrack for Civ 4

Kyle Roderick, a master’s student in music at Texas Christian University, recently contacted me with some questions about the soundtrack to Civ 4. I am sharing my answers here for anyone else who might be curious about how it was created.

Q. Why was preexisting music chosen to underscore the game? Why not have a wholly original score?

By choosing preexisting music, we were able to include pieces of the highest quality which also gave a historical flavor for relatively low cost. Creating our own score would have been expensive, required a lot more work, and would likely be much shorter in time. (We had almost no practical limit on how many historical pieces we could include.) Most importantly, Civilization games are improved by real bits of history, even if incidental, such as relevant historical quotations, the names of great people, accurate wonder visuals, and so on. Music was one more tool for us. However, we did write music for certain key parts of the game, such as the classical age, which has no preserved musical pieces. Also, we did commission a piece from composer Christopher Tin (my college roommate, by the way) for the intro screen, which became “Baba Yetu” and actually won a Grammy award, the first ever for a video game!

Q: Why this music? How did you go about choosing the pieces which would underscore the various game periods?

I selected the music based on my own collection of classical music. I spent a few months listening through as many works as I could while listing ones which might work well. I then added them to the game to see how they matched the experience of playing Civ. I discovered that many of my top pieces worked poorly because they had too much dynamic range – a great climax might work well in a concert hall, but it can be a little disorientating as background music during a turn-based strategy game. Thus, much of the soundtrack is built from dance music (such as Brahm’s Hungarian and Dvorak’s Slavonic Dances) or middle movements of larger concertos or symphonies (such as the 2nd movement of Beethoven’s 5th Symphony). One climactic piece I did leave in, regardless of how it broke the mood, was the final movement of Bach’s Double Concerto simply because I love that piece so much.

Q: Much of the music which accompanies the Medieval game period is from the real-world Renaissance, and the Renaissance game period is underscored by Beethoven, Bach, and Mozart. Could you comment on these perceived discrepancies?

Unfortunately, the best pieces (and especially my personal knowledge of them) are not distributed evenly across history, so I had to fudge the dates a bit. Design is a series of trade-offs, and – in this case – sacrificing historical accuracy for the highest quality of music made sense. Giving Bach, Mozart, and Beethoven their own era meant they get plenty of time to shine while still leaving room for the great Romantic composers. I was also unsure of what to include from the actual Medieval period, so this shift strengthened the whole experience.

Q: The modern era is represented solely by American minimalist composer John Adams. Why only Adams, were other composers considered?

The repertoire from modern period is much more varied than that of any other era’s, which meant that finding a consistent style and tone would be difficult. Furthermore, the chaotic structure and casual dissonance of much of modern music would be a difficult match for the mainstream audience of Civ. John Adams is a singular composer from this era; even though he is as well-schooled in minimalism as Glass or Reich, he composes with the heart of a Romantic. His works have a certain movement and thrust to them which makes them a better fit for the less experienced ears of the average player. By using only Adams, I was able to maintain stylistic consistency for the era while also finding a palatable way to stay true to the stylistic innovations of the periods.

I would like add that I will always be grateful to whoever at 2K Games actually approved by request to include so much John Adams. The price was not low, and it was certainly an idiosyncratic choice. I was somewhat expecting them to balk at it, and I’m glad they supported me. (I have similar feelings for them approving the Velvet Underground’s “Rock and Roll” as the background piece for the Rock and Roll wonder; so many other cheaper (or more expensive) paths could have given that moment a very cliched tone.)

Q: Saint-Saëns and Rimsky-Korsakov together are an interesting case. They feature one track each in the Industrial game period, both selections from larger works: the “Allegretto con moto” from Saint-Saëns’s Cello Concerto in A minor, and “The Young Prince and the Young Princess” from Rimsky-Korsakov’s symphonic suite Sheherazade. Why were these two tracks included? Were other composers considered for singular inclusion?

I played the cello from early childhood through college, so I have always been partial to pieces which feature that instrument. Furthermore, the Saint-Saen Concerto was probably most difficult piece I ever learned, so I wanted include something from it, and the middle movement made the most sense. I probably toyed with including something from his 2nd Piano or 3rd Violin Concerto, but the former is a bit too explosive and the latter is a bit too apocalyptic. As for the Rimsky-Korsakov, I wanted to add something from Sheherazade because it would provide just a dash of exotic (or, at least, exotic-sounding) music. “The Young Prince and the Young Princess” is a long, slow dance, so it was the best choice to maintain the game’s flow.

Q: Another interesting case is that of the inclusion of John Sheppard’s Media vita. Sheppard is a relatively obscure composer in that his significance is usually overshadowed by Thomas Tallis, whose works are not represented in the game. Is there some reason behind the inclusion of this track?

My knowledge of music from the Renaissance is quite poor, so I enlisted the help of my cousin Erik Anderson, who is a cello professor at Minot State University, and his wife Dianna, who is an accomplished pianist. They created a list of pieces and composers I should consider. As a result, I bought a bunch of music from this period, and the Sheppard piece stuck out to me because of its austere beauty and consistency with the period. I am actually surprised when I look back that I didn’t include any Tallis; I guess they just didn’t stand out to me for some reason.

Q: The recording of “Christian Zeal and Activity” was edited to exclude the sermon. Was this your decision? How do you feel about this significant alteration?

That old recording is an essential part of “Christian Zeal and Activity” (used to great effect by Scorsese in Shutter Island), but spoken dialogue would seriously damage the flow of a Civ game, so I had no choice. Indeed, I edited most of the Adams pieces to take out some of their more climactic or dissonant moments; “Harmonielehre” is missing its shattering opening, for example. Taking these bits out was disappointing, as I didn’t want to damage the structural integrity of the work, but also one of the many steps made to make Civilization 4 fit together as a whole, without any single element demanding the user’s attention over all the others.

Q: If you could go back and change something about the soundtrack to Civilization IV, what would you change? Why?

I am quite proud of how the soundtrack turned out; I often get compliments on it, and I certainly never would have dreamed that “Baba Yetu” would win a Grammy. Of course, I wish my musical knowledge would have been deeper and wider so that I could have built a more varied selection; I definitely leaned pretty heavily on Bach, Beethoven, Dvorak, and Adams. However, if I was to design another Civ game, it would be extremely difficult to go through the process over again and force myself to pick new pieces; I do view the soundtrack of Civ 4 as a piece of myself that sits inside the game, an enthusiastic jumble of my passions and my happenstances.

GD Column 22: When Digital Meets Physical

The following was published in the Aug 2012 issue of Game Developer magazine…

If video games and board games are cousins, then they are starting to behave like they belong to the European aristocracy. The two formats are intermixing such that the artificial line separating the two is blurring, with many digital games now built to resemble board games. Consider the recent mobile games Cabals or Hero Academy; both contain the trappings of board games – including turn-based play, a shuffled deck of game pieces, a visible board divided into tiles, and transparent rules with no hidden modifiers – even though these games only exist in digital form.

Other, more mainstream video games are including select board game elements, such as the collectible card mechanic in Rage. The designers assume that the audience is familiar with board game conventions, so that including cards or dice can be just as useful as any other video game convention in helping players feel comfortable with the design.

Meanwhile, the collision of digital and physical gaming is changing the latter as well. More specifically, the iPad is revolutionizing the board game industry as digital translations of physical games are finally viable. The iPad’s features – a large, high-resolution screen, a touch-based interface, and (perhaps most importantly) a robust infrastructure for selling digital apps – are the perfect combination for digital board games. Eric Hautemont, the founder and CEO of the board game publisher Days of Wonder, expressed his enthusiasm for the device:

The beauty of the iPad is that you could forget about it. Meaning that when you put an iPad between two players, the screen is so well done that you almost forget there are electronics behind that. When you sit down to play Small World on the iPad, you stop thinking about it as an iPad game and just think of it as Small World. In the future, the question of whether something is a “board game” or an “iPad app” or whatever it will be in the future becomes a meaningless question.

Days of Wonder’s business experienced a significant bump from mobile. Since the release of Ticket to Ride Pocket on the iPhone, the boxed version of the game began selling more copies, by a sustained increase of 70 percent. Meanwhile, the iPad version is consistently a top-100 app, selling for a healthy $6.99. (One sign of the healthy iOS market for board games is how well they have maintained a high price point in a sea of 99-cent games; Catan and Samurai both sell for $4.99 while Carcassonne still costs a whopping $9.99 two years after release!) Indeed, since release, the digital versions of Ticket to Ride have outsold the physical one by 3-to-1, which raise the question of whether Days of Wonder is a board game company or a video game company.

Transparent Games

The success of digital board games means that they can no longer be excluded from discussions of video game design. However, as board games become increasingly digital, how do they still retain the traits of a board game? Can a board game still be defined as simply one with physical components? What about the aforementioned Cabals or Hero Academy, which exist only in digital form? What about the iOS game Assassin’s Creed Recollections, a real-time variant of Magic: The Gathering, which could not exist without a computer to handle the real-time interaction?

If the physical components are not necessary, then what is the essence of a board game? Why do some games fall into this category and other games do not? Perhaps what defines board games is not their physical elements but their absolute transparency, a philosophy that all a game’s rules should be visible.

This realization has important implications; if transparency is the thread that connects all board games, then transparency must be a major reason why people enjoy playing board games at all. Accordingly, transparency is then one possible source of fun in all games, and designers should understand the role it plays in their own designs.

For example, the Civilization series is essentially a giant board game that could only be played with a computer to handle all the calculations and record-keeping. The majority of game mechanics are clearly transparent to the player, from how much food a city produces each turn to how much time is needed to discover the next technology.

One area not so transparent was the combat system, still a black box to the player, leading to fears that a tank could lose to a spearman under the wrong circumstances. Civ 4 took steps to fix this problem by providing players with the exact probability of success for each possible battle. Civ 5 went even further, with a detailed graphical widget to show the estimated damage.


The combat systems of these games were still opaque to the average player (the hard-core, of course, reverse engineered the formulas). However, these features still honored the ideal of transparency by making the results of combat clear; the designers understood that transparency was an important virtue for the series, and the changes were well received by the fans.

When Digital Beats Physical

One of the most exciting aspects of the digital-physical merger is that some board games are greatly improved in the transition to a video game. First, digital board games require no set-up time or record-keeping, which means that games can be played much faster and in new environments; suddenly, Memoir ‘44 can be played in a coffee shop without scaring away the other customers.

Being able to play a digital board game tens, or even hundreds, of times transforms the experience. A heavy, card-driven historical simulation game like 1960 will probably be played only a handful of times in person, but the Web version allows finishing a game in an hour. The brevity and frequency of games lowers the pain of a loss, which means players can experiment with new strategies without fearing they are blowing their one chance to play the game that month.

However, one challenge of such frequent play is that imbalances are found much quicker than ever before. A Few Acres of Snow, Martin Wallace’s 2011 wargame on the French-Indian War, gained some notoriety for needing a quick patch to deal with a dominant strategy for the English known as the Halifax Hammer. This strategy emerged so soon after release because the game was playable for free on the Web; water found a crack that much sooner.

Another advantage of digital board games is asynchronous play. One of the challenges of board gaming is finding a way to get people together for long, uninterrupted blocks of time. Asynchronous play circumvents this issue by letting people run games at their own pace; the program simply waits for the next player to make her move.

One iOS game, Ascension, owes much of its success to getting this format right. The game was a competent variant to the seminal deck-builder Dominion, but Ascension met its greatest success when it hit the App Store. The developers focused on asynchronous play as not some unusual game mode but as a core feature of the game, enabling players to easily manage multiple concurrent games. Not every board game is ideal for asynchronous play (each turn needs to feature a significant number of decisions), but ones that are should find new life on mobile devices.

Analytical Fun

Whether played asynchronously or in single-player, digital translations can eliminate the waiting time associated with meaty board games. A certain type of Eurogame with little randomness and no hidden information, typified by Caylus and Puerto Rico, is painful to play with optimizers, who are unafraid to slow the game down to a crawl to ensure they make just the right decision. However, the negative experience of waiting for a slow player can often lead to the mistaken impression that optimization itself is not fun.

Optimization while under social pressure to finish faster may not be fun, but finding just the right move to handle a tricky situation is exactly why these types of games are so rewarding. Analysis paralysis, after all, is also known as intense engagement in single-player games! The problem with playing in person is not wanting to slow down the game while also fearing that rushing will lead to the wrong move.

Both asynchronous and single-player versions of board games solve this problem by giving the player all the time he needs to perfect his plan. Indeed, Puerto Rico comes alive on the iPad, shining as a tight, elegant game that can move at a comfortable speed when a single person gets to make all the decisions. Indeed, the popularity of cooperative board games in recent years, such as Pandemic and Ghost Stories, suggests a healthy market for solitaire video games with a board game soul.

This revelation underscores the value of decoupling the physical characteristics of board games from their defining feature – absolute transparency. The lesson for all designers is that transparency can be a virtue in almost any genre or format. Consider the natural tile-matching patterns in Triple Town, or the predictable enemy behaviors in Plants vs. Zombies, or the simple physical elements in Cut the Rope. These games don’t appear to be board games, but they all share the virtue of transparency.

GD Column 21: More Than Zero

The following was published in the April 2012 issue of Game Developer magazine…

A zero-sum game is one in which the gains of any one player are balanced out by the losses of all the other players, such as winning a pot of chips after a hand of poker. Using strict game theory terminology, many competitive games are not actually zero-sum. Scoring a field goal in football, for example, does not take three points away from the other team.

However, more loosely speaking, the phrase “zero-sum mechanics” can mean that hurting one’s opponent is as equally valuable as helping oneself. In a typical RTS like StarCraft, a rush strategy, which aims to destroy the enemy’s economy as soon as possible, is just as viable as a boom strategy, which focuses on building up one’s own economy. If one can quickly wipe out the enemy’s first units, it’s irrelevant what level of development one’s own troops ever reach.

Thus, whenever a game rewards the player equally for hindering the enemy as for strengthening herself, the game has a zero-sum mechanic. Most team sports (basketball, soccer, football, etc.) share this characteristic; the defense, which prevents the opposition from scoring, is just as important as the offense, which does the scoring.

Competitive games are firmly rooted in this soil. Fighting games balance protecting one’s own health with taking away the health of the opponent. Strategy games encourage countering an enemy’s plans as well as perfecting one’s own. Shooters combine killing as many enemies as possible while also fulfilling some parallel goal, such as capturing a flag or checkpoint.

Zero-sum mechanics, in fact, seem to be the default choice when designing competitive games. However, their ubiquity masks the many, many problems with this type of gameplay. Indeed, zero-sum mechanics are, at best, a necessary evil and, at worst, a wrongheaded approach to game design that turns away many potential players.

The Zero Problem

The problem with zero-sum mechanics is that they require a negative experience for someone – watching a devastating combo annihilate one’s character in Street Fighter, watching one’s buildings crumble in Age of Empires, dying and respawning over and over again in Team Fortress. One player’s pleasure results from another player’s pain.

In fact, competitive games do not require that another player must suffer. A game’s rules determine the frequency and intensity of player interaction; ultimately, the designer decides how players will interact with each other during play. Indeed, competitive games are even possible without players being able to affect one another at all – consider parallel sports like golf or bowling, for example, or online games with asynchronous leaderboards like Bejewelled Blitz or Burnout Paradise.

The most important distinction is whether a player can lose their current progress or if they can only lose the ability to continue progressing. In the former case, the game mechanics have a zero-sum feel as losing one’s progress is usually a painful experience and often a sure route to a loss. In contrast, one of the defining traits of the Eurogame movement (epitomized by games like Ticket to Ride and Settlers of Catan) is eschewing such direct, zero-sum player conflict in favor of limited, indirect interaction which will not destroy a player’s progress.

For example, in worker placement Eurogames, such as Agricola and Caylus, players take turns choosing exclusive abilities; the competition emerges from players jockeying for position to determine who gets to grab the best jobs first. If a player knows his opponent needs food, choosing the food job for himself can seriously damage this opponent’s fortunes. However, this tactic is qualitatively different from actually destroying an enemy’s farms and killing his villagers in Age of Empires.

In the former case, the setback may only be temporary; in the latter, the player suffers a heavy emotional loss and has little chance of recovery. In fact, a player who spends too much time trying to disrupt his opponents in a game like Agricola can often dig his own hole as each precious action has significant opportunity costs. In contrast, damaging an opponent early in an RTS has little downside; wiping out another player’s economy can actually buy valuable time to grow one’s own much larger.

Balancing a RTS game to not reward destroying another player’s economic base as soon as possible is extremely hard. Indeed, RTS games suffer heavily from a dominance of zero-sum mechanics, which encourage the rush. Many players adopt “no-rushing” house rules to manually rebalance the gameplay away from destructive raids and towards building up for the endgame.

Further, many RTS games end with a whimper instead of a bang because the end goal is usually wiping out the enemy’s forces, which means that the outcome is obvious halfway through the match. In Ticket to Ride, during which players race to complete routes before running out of pieces, the dramatic tension is a consistently rising slope. In contrast, the dramatic tension of StarCraft is an arc which rises and then falls, and – unfortunately – the downward side of this arc is simply a sequence of painful events for the loser.

However, zero-sum mechanics need not be endemic to the RTS genre. Consider economic games, like the Anno series or Railroad Tycoon or even M.U.L.E., in which the primary goal is the acquisition of wealth; because the players are in a race to see who grows the fastest, the games need not encourage – or even allow – players to attack one another.

Alternate competitive mechanics are possible in military RTS games as well. Warcraft 3 introduced the creep – neutral characters who occupy the central area of skirmish maps and who players race to kill for the rewards and experience points. Perhaps a new RTS could take this mechanic a step further and make the game focus solely on killing creeps?

Removing the Negatives

Many competitive games solve the zero-sum problem by severely limiting interaction, so that players can only affect each other under certain circumstances. In Mario Kart, for example, racers can only shoot one another after picking up limited-use shells from certain locations; even then, players will only get the most powerful shells if they are trailing in the race. Even in a cutthroat RTS, a player can only attack after first building a barracks, then training troops, and finally moving them into position.

Thus, limiting player interaction is a powerful tool for minimizing negative emotions from zero-sum play. Games with similar themes and rules can dramatically change their feel depending on what sort of interaction is allowed. For example, Travian and Empires & Allies are similar asynchronous strategy games played over months of real-time about developing a military and then attacking one’s enemies. However, an important difference separates these two games with what happens when players invade each other’s cities.

In Travian, attacks are strictly zero-sum; resources captured by the attacker are taken from the defender’s stockpile. In Empires & Allies, however, combat is actually positive-sum; the resources captured by the attacker are conjured from nothing. Furthermore, while units which die in Travian are removed from the game, defending units in Empires always stay alive, even after a defeat.

Empires quietly belies players’ expectations for combat – that a victory requires a defeat – and this design choices pays off by making the game more accessible and less emotionally draining. In contrast, Travian uses the traditional approach that one player’s gain requires another player’s loss; accordingly, this design choice creates a nasty world full of brutish players with short tempers.

Many designers instinctively assume that conflict must be zero-sum, but this prejudice may be keeping their games from reaching a larger audience. The emotions players experience during a game are real enough, so a mechanic that requires at least some players to suffer should be used carefully.

Adding the Positives

Sometimes, alternate solutions are blindingly simple. In the board game 7 Wonders, players compete along multiple axises – earning victory points for science, civics, buildings, wealth, and military. The default way to implement military in such a game would be to allow players who invest in an army to attack other players’ units, buildings, or resources. 7 Wonders, however, employs a very different approach.

The game is split into three epochs, and at the end of each epoch, players with the largest armies receive positive points while the other players receive negative points. Furthermore, the total point distribution is actually positive-sum, so that losing combat does not hurt a player as much as winning combat helps. Thus, the military strategy does not drown out all the others and is appropriately balanced; a strong military cannot prevent an opponent from winning with strong technology because military victories do not require the loser to forfeit her progress.

Indeed, the spirit of positive-sum gameplay can benefit other aspects of game design. Puzzle Quest, for example, avoids a manual save system by ensuring every combat is positive-sum; players can never lose an item during combat and will always gain at least a little gold and experience from each battle. Thus, a player is always better off after combat, whether a win or a loss, so the game can constantly auto-save into a single slot. This feature, which would be hardcore if paired with a traditional zero-sum design, instead removes the need for a load/save system, which can be a barrier to entry for new players, thereby expanding the game’s potential reach.

Ultimately, zero-sum mechanics are still a powerful tool for game designers as they can unlock primal emotions. Sometimes, allowing players to destroy each other is exactly what a game needs. However, not all conflict need be zero-sum, especially since that design choice has significant disadvantages. Losers need not suffer so that winners can triumph.

GD Column 20: The Coming Storm

The following was published in the Feb 2012 issue of Game Developer magazine…

Ever since OnLive’s dramatic public unveiling at GDC 2009, the games industry has been watching and wondering about cloud gaming, at times skeptically, at times hopefully. The technology holds the potential to revolutionize the business, perhaps forever destroying the triangle that connects consumers with hardware manufacturers and software retailers.

Some of the immediate benefits are obvious. Instant, time-limited demos would allow every developer to showcase their games on-demand with no extra work. Frictionless per-day, or even per-hour, rentals would bypass Blockbuster and other rental chains, ensuring that more money goes directly to the people who actually make the games. Similarly, virtual ownership handicaps GameStop’s ability to resell a single disc multiple times, again making sure money flows directly from the consumer to the developer. Further, if a publisher commits fully to the cloud – with no offline version available – piracy would be virtually impossible

As for the consumer, cloud gaming enables cutting-edge graphics on any connected device, with no installing or patching ever. Although the system requires a constant Internet connection, more and more games – even single-player ones – are demanding a connection anyway. Indeed, cloud gaming can handle Internet stutters better than local gaming; in Diablo III, a dropped connection sends the player back to a checkpoint screen while OnLive returns the player to the exact frame she last encountered.

Most importantly for consumers, cloud gaming should change the economics of pricing. By removing the traditional retail middlemen, not to mention secondary drags on the system like rental and used-game sales, a developer could easily make as much money selling a game for $30 via the cloud as they could selling it for $60 via a traditional retailer. The industry could finally approach a mainstream price point, with games priced comparably to movies, books, and music – instead of the $60 price point (for a $300 console) which is absurdly out of reach of the average consumer.

Indeed, the economics could change for developers too. If entirely new business models emerge, with consumers paying for a game daily, weekly, or monthly – or perhaps with a single subscription to all available games (a la Netflix)  – the design incentives change. Cloud gaming could reward developers for depth of gameplay over ornate, scripted sequences; infinitely replayable dynamic games like Left4Dead or StarCraft might suddenly be more profitable than hand-crafted semi-movies like Call of Duty or Uncharted.

Rethinking Consoles

Cloud gaming also has important implications for the next generation of consoles. The ability to run games from the cloud gives the console makers a profitable alternative to both the rental market and the retail middlemen, all within their own closed systems. As a bonus, they could even sell inexpensive “cloud-only” versions of their next-gen console, without optical drives or hard disks.

Going down this path, however, raises the thorny question of whether consoles are even necessary at all. OnLive is already selling a “MicroConsole” that provides a current-gen console experience via the cloud; there is no reason similar technology can’t be included by default in new TVs, or even in any cable box or satellite receiver. What defines a console, after all? The three necessary elements are the controller, the screen, and the couch. Soon, anyone with those three things and an Internet connection to the cloud will be seconds away from any game.

Indeed, because cloud servers already dwarf current-gen consoles in horsepower, they can bring a next-gen experience to consumers today, by default. The cloud promises a “perpetual” virtual console that get updated regularly as new, faster servers come online. Publishers should be receptive as a perpetual console promises to end the boom-bust cycle they experience with each new generation.

Indeed, this year in the current generation’s lifecycle should be when publishers are making record profits. Instead, many are fighting just to stay in business; the next wave of forced upgrades could wipe them out. Anything that could prevent the gap years when consumers are forced to migrate between consoles would be a welcome change.

Thus, for the console makers, cloud gaming’s promise is mercurial – it could break them free from the parasitic drag of traditional retail but it could also destroy them by making the hardware itself irrelevant. The best defense against the latter is an active and direct relationship with the consumer, not tied to any one machine.

On this front, Microsoft, with its comprehensive Live service, is far ahead of Sony and Nintendo – many gamers would be hesitant to leave behind their gamerscores, achievements, friends lists, and downloadable games for another ecosytem. However, a radical step could cement this bond.

Because a thin video-based client can run on almost anything, any one of the console manufacturers could start the next generation tomorrow by simply buying OnLive or Gaikai and embedding it in the next system update. Next, they could sell cloud-only versions of the current-gen consoles for almost nothing ($100? $50?), which could revolutionize the market and inoculate the company from the coming shift. Some are predicting the next generation of consoles will be the last one, but it may not even be necessary at all.

Rethinking Games

However, cloud gaming’s potential is much, much greater than changing the economics of the industry; in fact, it could revolutionized the very way games are made. For starters, the cloud could solve the number one problem that plagues most teams – a lack of feedback from real players during the early stages of development when radical change is still possible. Most game project grow slowly from fast and nimble speed boats to hulking battleships which can only change course at great effort and cost.

Using cloud technologies, a team could expose its game to fans as soon as it is playable, with almost no technological hurdles or security concerns. All players need is a browser and, if necessary, a password. Releasing games early for feedback and buzz is nothing new for indie developers (indeed, doing so is their major competitive advantage); nonetheless, for major publishers, the idea is fraught with potential risk, of leaked games and bad press.

However, as the game’s code and assets would exist only on the cloud’s servers, nothing could be leaked. As for pre-release buzz, the greatest danger, of course, is of simply releasing a bad game, and the surest way to do so is to isolate a development team from the oxygen of real players. Further, the cloud’s inherent flexibility creates myriad ways to target players for testing: 24-hour passes, geo-locked sessions, early press versions, pack-in codes, and so on.

Further, the cloud promises more from these early test than some simple metrics or private forum comments. Because the output of a cloud server is a video feed, developers would have access to a recording of every minute ever played of their game. Wonder how players are handling a certain tricky boss? The designer can simply watch saved videos of many different players tackling the encounter.

Still, the greatest change cloud gaming could bring is the end of client/server architecture. Many online games have thin clients, with the “real” calculations being done on the server, largely to prevent rampant cheating. (As Raph Koster famously put it, “The client is in the hands of the enemy.”) With cloud gaming, the client is so thin that it might be inappropriate to even call it a client; it’s simply a video player that takes input.

The upside of this system is that developers would no longer need to waste resources developing a traditional game client, plugging its security holes, worrying about peer-to-peer connectivity, and optimizing what minimal, yet necessary, set of data needs to be sent to the client. In other words, making a game multi-player would now be essentially trivial.

Writing multi-player games is a formidable challenge – keeping game state in-sync between servers and clients in a safe, fair, and accurate manner is no small feat. With cloud gaming, these issues evaporate because there are no clients anymore. Developers simply write one version of the game, run it on a single machine, and update it based on user actions – which is how single-player games are made.

Taking advantage of this feature would require some courage as the developer would need to go all-in on cloud technology. Developing an online game with no client means that the game could only be played via the cloud. There are many benefits to being cloud-only – no piracy, for one – but the greatest benefit might be not even needing a network programmer.

Perhaps the group which has the most to gain from this new model would be small, independent developers, for whom the idea of building an indie MMO seems laughable given their tiny resources. One can’t help wonder what Mojang could do with a cloud-based version of Minecraft, seamlessly updated, playable from any device or browser, that connects every world end-to-end. So far, the big question for cloud gaming is when will it be feasible, but ultimately, the more important question is what will it enable.