A Study in Transparency

GDC is around the corner and, for the first time since 2010, I’m going to be giving an actual talk instead of just doing a panel. As followers of this blog know, I am a big fan of tabletop games and am very interested in how they overlap with digital games. My talk will be about why transparency defines board games and how that matters to video game developers. (Here is a link to my slides, which are still under construction.) Furthermore, I was on The Game Design Round Table recently talking about transparency in game design, as seen in both physical and digital games.

Here is the info on my talk. Hope to see many of you in San Francisco!

A Study in Transparency: How Board Games Matter

Soren Johnson, Founder, Mohawk Games
Location: Room 3007, West Hall
Date: Thursday, March 20
Time: 2:30pm-3:30pm
What defines a board game? If a video game is described as being “like a board game,” what does that mean exactly? Judging by the recent success of video games inspired by mobile ports of tabletop games, the defining trait of board games is not, in fact, their actual physical components. Instead, the key factor is the transparency necessitated by the physical design. This transparency fosters many positive traits, including deep engagement, player comfort and meaningful choice. This talk will go into extensive detail on how transparency works for successful tabletop games and what lessons apply to the design of digital games.

PRACTICE 2013: The Art of Strategy

I was on a panel (with Keith Burgun of 100 Rogues and Brad Muir of Massive Chalice) on strategy games at PRACTICE 2013, which is NYU’s annual game design conference. My talk (the first 15 minutes) was on the value of transparency and how that trait defines what we think of as “board games.” Keith’s and Brad’s talk were quite interesting, and we were also joined by Frank Lantz for a wide-ranging discussion afterwards. (Here’s a link to my slides.)

As part of the conference, I also did a short Q&A with Bruce Lan, one of the students from the NYU Game Center:

Q. Since I’m a reader of Designer Notes, and I’ve been writing my gaming blog for several years in order to share readings and establish a habit of writing down thoughts on game design, I’m curious about what motivated you to start your own blog?

A. I started my blog out of a desire to express my ideas about game design, not all of which I could put into practice with my games. I wanted to have a voice in the game industry, and the best way to have one is to just start speaking. As I’m not a particularly talented public speaker, blogging was the best way for me to communicate. I’ve often had a hard time keeping up a regular post schedule, but I was determined to never let the blog just die. Eventually, the posts add up, and the blog develops a footprint online. I was also lucky that my blog attracted the attention of Brandon Sheffield, then editor of Game Developer Magazine, who offered me their design column, which fortunately forced me to write 1500 words on a specific topic every other month. Reposting these columns kept my blog alive for a number of years, and – now that the magazine is gone – I need to develop a new posting style that fits my current career.

Q. What differences did you find the most interesting or challenging between designing for turn-based strategy (Civilization) and real-time strategy (Spore)?

A. Turn-based games excel at focusing the player on specific key decisions and making the ramifications of these decisions clear to the player. Further, because the game progresses in discrete steps, the player can project a series of events easily in her head. (If I discover Animal Husbandry in 3 turns, then my worker needs to reach Paris by then to build the Pasture to increase the rate that city is building the Pyramids, and so on.) Indeed, it is almost difficult to make a turn-based game that is NOT strategic because the format creates opportunities for interesting decisions so well. The problem with turn-based games is that they are tedious. Certain optimal strategies become rote and repetitive in time (such as optimizing a city’s growth and production each turn). Furthermore, because the game demands the player to keep making decisions, turn-based games can slow down to a crawl near the end as the player has more and more units to move each turn. Real-time games solve this problem by allowing key decisions to slip by the player, forcing him instead to make key decisions about how to spend his attention. Moreover, real-time games are easier to balance because the game’s pace is constant for everyone. Neither format is superior, of course, but the choice has a major impact on the gameplay aesthetic.

Q. The production processes and design issues for AAA games are so different from developing small games. How did you shift from developing games like Civilization 4 to mobile and social games? Do you think it’s possible for you in the future to step into the indie game scene?

A. I moved away from AAA development because the enormous budgets kill innovation as publishers are primarily concerned with predictable returns on their investment. Further, maintaining a distinct design vision become incredibly difficult as team size balloons into the hundreds. I have actually just started an independent game studio dedicated to building innovative core strategy games (check us out at mohawkgames.com). We are determined to stay small so that we have the flexibility to make games that are original while still delivering the gameplay depth of a major title like Civilization 4.

Plants vs. Zombies 2: Between Scylla and Charybdis

The following two articles form an interesting diptych on Plants vs. Zombies 2:

In other words, the first author believes that the game is ruined by microtransactions while the second author believes that EA didn’t do nearly enough because it was “afraid to upset players.” Did EA ruin PvZ2 by going free-to-play? Or did it simply not go far enough? These two pieces seem to emerge from parallel dimensions.

Indeed, the two writers are from very different worlds. Faraday is the founder of Pocket Tactics, the premier mobile strategy game blog. As it caters to core gamers, free-to-play is generally considered a dirty word there. Katkoff, in contrast, was a Product Manager for Supercell’s cash-cow free-to-play strategy MMO Clash of Clans, a game notorious for attracting whales willing to drop thousands of dollars on the game.

For Katkoff, PvZ2 represents great unfulfilled potential as a free-to-play game because EA did not aggressively tempt players enough to spend. For one thing, the game is not hard enough to force players to buy boosters:

Sadly PvZ2 is ridiculously easy. It takes absolutely no effort to pass levels, making the game unchallenging and boring. . . . PvZ2 offers boosters for real currency, which enable players to clear levels with some consumable super powers. But to create the demand for these boosters players need to have those moments where they’re just about to clear a level and realize that they’ll lose without the help of a booster. Lack of challenge results in low demand for boosters, which causes stagnant revenue.

Furthermore, the game lacks the gates that typically restrict players in free-to-play environments, which then creates demand for various unlocks and powers:

PvZ2 has no restriction mechanics and thus no core loop. An ideal core loop for the game would have been similar to the one in Candy Crush Saga, where sessions are restricted with energy mechanics. I’d argue that energy-based core loops would have increased monetization of the game by creating consistent demand for energy and increasing demand for power ups – when level restarts have a cost, not failing a level becomes valuable.

EA created plenty of ways to spend money – plant unlocks, special powers, extra plant food, and so on – but the game is not engineered to push players to spend. Hence, the game quickly dropped out of the top 20 in the Top Grossing list for iOS games and now hovers around number 50, which Katkoff considers a failure for a game with such high promotion and anticipation.

In contrast, the game simply disgusts Faraday; the experience is ruined because commerce becomes a constant and unwelcome guest, poisoning the atmosphere and taking the focus away from pleasing the player:

Plants vs. Zombies 2 is designed to be fun, of course, but it’s very obviously designed to be just fun enough that the frustration of playing it will force you to open up your wallet to buy an early unlock of a plant for $5, or spend $6 to see a new part of the game world. It’s crass. It’s gauche.

After praising the charm and originality of the original, Faraday declares that “the biggest mistake EA and PopCap could have made with Plants vs Zombies 2 would have been to make it a slow, grindy treadmill.” Unfortunately, to extend the gameplay and create room for an in-game store, EA did just that:

After the first eleven levels, PvZ2 grabs the treadmill’s speed control and slams it all the way back. Once you’ve finished the 11th level in Egypt and seen everything that that game world has to offer, Plants vs Zombies 2 informs you that to progress to the next world, you have to go play all of the levels over (and over) again, gaining stars to unlock the pirates. Or you can just pay six bucks.

In some ways, the two authors seem to differ factually (the star system Faraday describes does sound a bit like the type of core loop, with built-in gates restricting the player, that Katkoff recommends). Nonetheless, that both Faraday and Katkoff view PvZ2 as a failure is damning for EA; if they couldn’t please either the free-to-play money guy or the original fan of the series, then who were they trying to please? Perhaps the ugly lesson here is that if a company decides to risk losing its core audience, then it might as well go all the way and make sure it gets the money.

EA is caught between the Scylla of core gamers and the Charybdis of whales. Core gamers care about what they play, and for decades, they made EA a very wealthy company. Unfortunately, whales are going to make other companies even wealthier. They turned Supercell into a $3 billion company from just two free-to-play games, which now generate over $2.5 million per day at an insane 75% profit margin. By comparison, EA had an anemic 2.5% profit margin last year, and they made a lot more than two games. As a public company, how can EA ignore whales and compete with companies like Supercell which cater to them? The answer is that they can’t, and Popcap won’t be making games like the original Plants vs. Zombies anymore.

PRACTICE

I am going to be speaking at the upcoming PRACTICE: Game Design in Detail conference, which is being held November 15-17 at the NYU Game Center. I am joining a panel, entitled “The Art of Strategy Games,” with Keith Burgun (of 100 Rogues) and Brad Muir (of Massive Chalice). Here’s the description:

Strategy games occupy a special place in the hierarchy of game design as the clearest expression of the ideal of “interesting decisions”. In this panel, three designers working in the strategy realm discuss their approaches, discuss the specific challenges of designing strategy games and talk about the creative possibilities and future directions of the genre.

I’m really looking forward to hearing the rest of the talks (from interesting folks like Rob Daviau, Sean Vanaman, and Jake Rodkin) and meeting everyone at the conference. Hope to see you there!

Spore: My View of the Elephant

A few weeks ago and with little fanfare, Spore turned five-years-old. The game was announced at GDC 2005 during Will Wright’s annual mind-blowing speech on whatever floats through his head. The initial concept – of a game in which the player evolves a species from cellular development to galactic dominion – generated an immense amount of hype, which the game struggled to fulfill upon its 2008 release. Spore received middling reviews from the gaming press, who found the gameplay weak and unfocused, and harsh criticism from the scientific press, who felt tricked by the promise of a game built from real science.

For myself, the time is now right to put down my own thoughts on Spore’s development – my memories of the project are still fresh, yet enough time has passed to ensure that criticism doesn’t impact active teams. I joined Spore in May 2007 for what ended up as the final 15 months of the project; however, the team started the game in 2000, which meant that I saw just 20% of the complete story.

Thus, my view of the game’s development is inevitably incomplete – bringing to mind the parable of the blind men and the elephant – and needs to be viewed from that perspective. I would welcome – indeed, encourage – other members of the Spore team to speak up on their own experiences with the project, especially if their perspectives differ from my own. Nonetheless, here are four lessons from my time with Spore.

1 – Don’t be afraid to challenge the initial vision

Ultimately, Spore was about two big ideas – powers of ten and procedural content. The first idea refers to the classic short film by American designers Charles and Ray Eames, which zooms in, by powers of ten, on a man and a woman until reaching quarks and then zooms out to the entire universe. This film inspired Will to create a game with similar radical shifts in scale, jumping from a cell to a creature, then to a tribe, then to a civilization, and finally to a space-faring empire.

The other idea – procedural content – was that all content in the game (such as creatures, vehicles, and buildings) could be represented with just a few kilobytes of data – which was, in Will’s words, “the DNA template of a creature while the game, like a womb, builds the ‘phenotypes‘ of the animal, which represent a few megabytes of texturing, animation, etc.” From this seed grew the powerful editors (which enabled some subversive creativity), procedural animation (which could truly handle anything), and content pollination (which shared the community’s best works).

When Will started developing the game, the core idea was powers of ten, reflected in the game’s original title, SimEverything, which promised a game at every zoom level. While prototyping that game, procedural content emerged as a way to fill the player’s universe, and that concept kept growing and expanding until it wasn’t clear anymore which concept was Spore’s big idea. A game can have two big ideas, of course, but the problem was that only one of these ideas was any good.

Spore’s biggest issue was that the play at each stage was fairly shallow because the team was making five games at once. (At one point, Will described each of the game’s five stages as light versions of classics – cell is like Pac-Man, creature is Diablo, tribe is Populous, civilization is Civilization, and space is Masters of Orion.) However, making five different games at once is a bad idea; making one good game is usually hard enough.

Each of the five stages had different controls, different interfaces, different nouns, different verbs, different goals, and so on. Some effort was made, of course, to share ideas and elements across stages; however, the compromises involved often watered down what was supposed to make each stage distinct in the first place. For example, each stage required a friendly means of engaging with other entities; in the creature stage, this mechanic became dancing for other creatures to make friends while, in the civilization stage, this mechanic translated into attacking other cities with music instead of bullets. Neither mechanic was the best idea for its own individual stage, and the justification was high-level consistency. Thus, the powers of ten idea put the team in a state of perpetual compromise where every major decision had to be considered according to its effect across all five stages.

On the other hand, procedural content was a genuinely interesting and fertile idea – one which was novel for the time, appropriate for a game about evolution, and rich with gameplay possibilities. The tragedy of Spore is that the team never re-evaluated its first big idea in comparison to its second one. Indeed, one of the problems with traditional, siloed game development is that initial assumptions are rarely challenged as the game is never exposed to the oxygen of actual player feedback.

Focus is an important asset for a team; if the game’s scope could have been reduced to just the biological stages (cell and creature), the team could have focused on fully exploring the intersection of procedural content and evolutionary gameplay. In the later, social stages, the editors served a mostly cosmetic role anyway, which pushed them to the background. Unfortunately, the best thing about powers of ten was that it sounded like a great idea, generating a huge amount of hype and press, so the die was cast at the 2005 reveal. What makes players buy a game, however, is often not the same thing as what actually makes them play it.

2 – Gameplay must support the theme

I have written before on the importance of a game’s theme matching its actual gameplay, and that the mechanics can easily subvert the intended meaning of a game, regardless of the designer’s stated goals. Indeed, I wrote about how this dissonance affected Spore:

The reception of Spore, a game sold with an evolutionary theme, provides a recent example. In the October 2008 issue of Science magazine, John Bohannon wrote the following about how the game delivered on the theme’s promise:

I’ve been playing Spore with a team of scientists, grading the game on each of its scientific themes. When it comes to biology, and particularly evolution, Spore failed miserably. According to the scientists, the problem isn’t just that Spore dumbs down the science or gets a few things wrong – it’s meant to be a game, after all – but rather, it gets most of biology badly, needlessly, and often bizarrely wrong.

The source of this dissonance is that, even though it was sold as such, Spore is not really a game about evolution. Spore is actually a game about creativity – the reason to play the game was to behold the wonder of other players’ imaginations as they used (and misused) the editors to create objects not imagined by the game’s designers – from musical instruments to fantastical creatures to dramatic scenes.

Spore didn’t need to be marketed or sold as a game about evolution, but since it was, players’ expectations had to be anticipated. Although one might not be surprised that the game was a disappointment to actual scientists, the crucial decision to limit the impact of the editor on gameplay ensured that players would not be able to experience the fantasy of evolution – that the editor would enable the creation of an infinite number of unique creatures, with behavior and performance dependent on player choice.

Of course, the editor enables an infinite number of visually distinct creatures, but the gameplay effects of the creature parts are unfortunately quite discrete. The feet components each carry with them a canned set of attributes – for example, Stubbtoe gives “Sprint 2,” “Dance 1,” and “Speed 2” – regardless of the position of the foot, the length of the attached limb, or the shape of the body. Thus, the attributes of each creature is simply a summation of all the named body parts, and although the procedural animation guarantees that a many-limbed creature will walk convincingly, the player’s creativity in designing the creature’s shape has no impact on actual gameplay.

This disconnect stand in sharp contrast to the cell stage, which does deliver an editor with consequence. The exact position of each Proboscis, Flagella, and Cilia matters as the player-designed cell swims along, chomping prey while avoiding predators. Thus, the cell editor delivers actual gameplay that the creature editor does not, a key expectation for players.

How did the creature editor lose its bite? Obviously, the 3D world of the creature stage posed a greater challenge than the 2D world of the cell stage, but reducing the game’s scope to just the biological stages could have helped considerably. However, the root issue was a philosophical debate about the role of the editor in the game. Should the editor enable unparalleled aesthetic customization, at the expense of gameplay consequence, or should the game mechanics support every choice made by the player, even if that meant limiting the flexibility of the editor? Should Spore be an interactive art museum or a customizable video game?

The question is akin to asking if Spore is a game or a toy, which is, in fact, one question that got asked a lot during the game’s development, often without a clear answer. For players able to put imagination before gameplay, Spore is a magical experience; indeed, the game is at its best when played by ten-year-olds. However, for core gamers expecting a game about evolution (or, perhaps more accurately, a God-game about intelligent design), Spore fell short.

3 – The only prototype which matters is the game

One distinctive element of Spore’s development was a focus on prototypes to test out design ideas quickly and efficiently. Chris Hecker and Chaim Gingold gave a very well-received talk at GDC 2006 on this topic; they demonstrated one important prototype which proved that the creature editor could work, that editing a creature in 3D by pulling, prodding, and stretching various body parts was fun.

Generally speaking, prototyping is a great idea; the process saves time and money, focuses the developers on tangible problems, and suggests ideas that would never emerge from a design document. However, unless a prototype is meant to answer a very specific and relevant question – such as whether the creature editor will feel right – an over-abundance of prototypes can lead to a false sense of progression. 100 compelling yet limited prototypes are less likely to lead to a great game than a single playable one.

The team eventually posted fourteen prototypes for players to try out, and what is notable about the selection is how few of them had a meaningful impact on the final game. I do remember Gonzaga/SPUG being used by the creature team, but much of the game’s core design was still up in the air when I joined, with most of the old prototypes long forgotten. (The civilization stage, for example, was just a tech demo of a spherical world.) A game must be greater than the sum of its parts, and the gameplay systems can only be understood when they exist within one complete experience, regardless of the shortcomings of the current technology.

Sid describes this process as “finding the fun” as he is pulling and prodding his prototype into a playable game; however, he is working on a single prototype, which will eventually morph into the final game. For Civilization 4, I built the game on top of a cancelled RTS project, which allowed us to have a playable game working, using 2D billboards for art, within months. Jon Shafer prototyped Civilization 5 within the Civ4 codebase, only switching over to the new graphics engine when it was ready. Visitors to Blizzard are regularly shocked by how their games appear to be shippable years before release, which is how they balance the demands of AAA production with the importance of iterative game design. These fully playable “prototypes” signal the beginning of the most crucial part of game development – when the designers can change the game rapidly based on feedback from actual playthroughs, not disparate, standalone experiments.

Spore was not fully playable until, at best, the final year of the project. Shipping the game earlier was never an option, and shipping the game latter was politically and emotionally impossible because of the time and resources already invested in the preproduction process, which did not result in a playable game. Of course, many successful games are not fully playable until months before release, but they tend to be part of established genres or franchises; the fun was already found in previous versions, and the team simply needs to improve the core gameplay without ruining anything. Having an unplayable game until shortly before shipping is not ideal, of course, but some projects have very demanding time constraints.

Spore was given an eternity of development time, and – more importantly – was new, new, new, new, new. No game had ever been made like it, with such immense scope and without a familiar template, so the project had an immense amount of risk, which only grew greater as more and more money was spent without a fully playable prototype. Creating such a prototype for a project with as much technical innovation as Spore would have been no small feat (much of the procedural animation, for example, was not finished until the final stretch), but no other method exists to make a fun game from scratch.

4 – Team cohesion beats team quality

Of one thing I am quite certain, the Spore team was the most incredible collection of game developers I have ever seen. Their creativity, their leadership, their diversity, and their raw intellectual firepower was inspiring. Starting at the top, the game was led by Will Wright, a legendary designer, and Lucy Bradshaw, an admired veteran executive producer. Key members of the team have gone on to make notable contributions to the industry: Chris Hecker is the designer/programmer behind SpyParty; Alex Hutchinson was the Creative Director of Assassin’s Creed III; Jordan Maynard is the Creative Director of the iOS MOBA Solstice Arena; Brian Sharp is a Lead Engineer at Bungie; Caryl Shaw was an Executive Producer at ngmoco; Ocean Quigley, Stone Librande, and Andrew Wilmott were (respectively) the Creative Director, Lead Designer, Lead Architect on the new SimCity. Beyond that, companies like Valve, Double Fine, and Riot are full of Spore alumni.

The Spore team was an incredible collection of talent. It’s an old chestnut that the key to a successful project is an exceptional team, but a team cannot be measured by adding up the qualities of each individual member. Instead, a team should be measured by its cohesion – how well the members are able to align their goals, priorities, and talents. Unfortunately, the Spore team was chronically fractured, divided into factions which had completely different priorities for the project. One well-known divide was the cute-vs-science debate; the ‘cute’ team wanted a playful, emotionally engaging experience while the ‘science’ team wanted an accurate representation of how the universe worked. I joined the team after a tenuous compromise was struck, which attempted to combine cute mechanics with a scientific theme.

However, I witnessed a new divide among the team which was less well-known; as more core game developers (such as myself) were recruited to help finish the game, a cultural gap emerged between the newer ‘gameplay’ team and the older ‘Sim’ team. The former group (which went on to spearhead Darkspore) was primarily concerned with how Spore played as a game. Were the mechanics engaging? Did the player’s choices matter? Was the game replayable? In contrast, the ‘Sim’ team carried the traditional Maxis DNA and was more comfortable with Spore as a toy box. Could the players express themselves? Was sharing one’s creations with other players meaningful? Did the game spark the imagination?

These cultural divides ruined Spore’s chances to be a focused, cohesive experience. Spore could have worked either as a cute game or as a scientific one. It could have been a series of interesting decisions or the best set of magic crayons ever devised. Games design works best at the extremes, delivering a distinctive experience to a specific audience; making a game for everybody is the same thing as making a game for nobody. Moreover, there are thousands of ways to make a game about cosmic evolution or world history or modern combat or human relationships or even something as concrete as baseball; the trick is to pick the one that best matches the strength and passion of the team.

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.

The Road to Zynga

So, I’ve got a new job, which was revealed publicly in an interview at GamesIndustry International. I’ve actually been at Zynga for nine months now, so most of my games industry friends (and regular friends, for that matter) had known about it for quite awhile, making this move one of those “worst-kept secret” things. Surprisingly, the news stayed out the press, with the exception of an off-hand reference at Gamasutra during my first week of work! The turn of events which got me to Zynga is somewhat head-spinning, especially since I am now back in Maryland, working with Brian Reynolds, Tim Train, and a bunch of other former Big Huge Games people. I can’t helped be a little bemused because I was originally hired in 2000 to replace Brian & co. to finish (or, more accurately, to restart) the development of Civilization 3 after the mass exodus to BHG. Indeed, at the time, emotions were still a little raw at Firaxis, so my initial, second-hand impression of them was perhaps not ideal! Over the years, I got to know Tim and Brian in person, and I could always tell that their design culture would be a great fit for me if the opportunity ever arose. I didn’t always expect that opportunity to come at Zynga, but so far, so good. I’ll have a lot more to say on that topic once I can actually talk about my current project!

Here are some relevant bits from the interview:

Q: You’re the latest in a string of former EA employees to join Zynga. What do you think this says about EA and what does it say about Zynga?

A: The shift we’re seeing with industry talent moving towards social and mobile games illustrates the challenges of the old model. That model demands selling a $60 box product, which requires exceptionally high production values to sway the consumer. Of course, AAA production means development costs measured in the tens (or perhaps hundreds) of millions of dollars, which then requires a game to sell at least several million copies at the $60 price to be worth developing. This business model can work, but the margins are not great, and they keep getting worse as development costs increase and retail sales soften. One of the bizarre paradoxes of this system is that some mid-tier games cost too little for traditional games companies to fund because the company needs to put all of its organizational weight behind a few key titles.

Mobile and social gaming suddenly became very attractive for game designers because they circumvent this problem entirely. As these games require a fraction of the cost of AAA games, radical new ideas can be tried out fairly easily and with little institutional pressure. Further, feedback is much easier to gather from the Web or connected smartphones, and teams can continually course-correct with regular updates. The old system of expensive, multi-year development, cut off from the oxygen of player feedback, suddenly became much less appealing.

Q: Given your experiences in the past on Civ IV and Spore, how well does what you’ve learned on traditional games apply to the social space and Zynga’s approach?

A: Fun still happens inside the player’s head, and that doesn’t change from platform to platform. What does change is that certain design possibilities are unlocked with each new technology, such as zero account overhead, assumed persistence, guaranteed connectivity, pre-made friends lists, built-in viral channels, universal access, and ever-improving game engines. These features let us explore areas of design that were previously unavailable. Indeed I feel like my work right now is a direct continuation of what I have done in the past, and I am simply using my twelve years of experience as a strategy game developer to take advantage of these new possibilities.

Q: Are you coding, or designing, or some of both?

A: I am doing the code and the design for the project, just as I did with Civ IV. I like working this way because I can spend less time explaining how I want a feature to function and more time watching how it works out in practice. I am using a somewhat unusual technology solution (GWT/PlayN) that enables me to write a HTML5 game in one language, including client and server, which means I have no duplicate, error-prone code and a very consistent style. Of course, doing code and design could make me a major bottleneck as the project grows larger, but one of the advantages of strategy games is that – because they are rules-driven instead of content-driven – a small amount of code can create a large amount of gameplay. Thus, extra engineering resources will be dedicated to features that work in parallel to the core game – scalability, UI, matchmaking, metrics, modding, and so on.

Q: Can you give us any hints at all about what your game project at Zynga entails?

A: I’m afraid that it’s too early to reveal much about what I’m currently working on, especially since a lot could change between now and our release date. However, I can say that I am working on a game that would not be a shocking departure from my development history, but one that is multiplayer-focused, free-to-play, persistent, and playable in the browser. Most importantly, the game is one that actually ends, with real winners and real losers. That’s a big departure for Zynga, but it’s a necessary element for many types of strategy games. Decisions matter in vastly different ways once games have an actual victory condition. Put another way, a bit of a level race does exist in persistent MMOs like World of Warcraft, but ultimately the race is just with yourself. No one else really cares how much time you put into your dwarf cleric. On the other hand, it’s a powerful feeling when you beat someone to a wonder in Civ IV.

Q: Do you see social games becoming more like familiar PC or console games in terms of mechanics?

A: After a couple years the term “social gaming” came to mean different things to different people, and many traditional game developers simply use the term to describe “games on Facebook that we don’t like.” On the other hand, some of the biggest hits (Words with Friends, Bejeweled Blitz, Draw Something) are not really thought of primarily as “social games” but simply as great games that take advantage of the possibilities of social gaming – guaranteed connectivity, account persistence, meaningful friends lists, etc. Therefore, the best-case scenario for social gaming is for the term itself to disappear as all games become more social, even ones that are traditionally thought of as primarily single-player. For example, consider how friend-based leaderboards drive the experience in console games like Trials Evolution or Burnout Paradise.

Ultimately, gameplay is determined by the input and output of the devices we use, which enables and encourages certain types of play, and there are currently three important formats – the consoles (defined as gamepad, high-def TV, couch-based), the PC (keyboard, mouse, monitor, desk-based), and mobile (small screen, touch-based, omnipresent). Consoles will continue to dominate avatar-based games as controllers are built to “pilot” characters or vehicles. PCs are the natural home for more complex games because of their precise input and “lean-in” environment. Mobile is perfect for asynchronous gaming, and the touch-based user interface creates entirely new types of games just like the Wii did with motion-based controls. The best games will take advantage of the unique power of their formats, which is why we shouldn’t necessarily expect Facebook games to suddenly become Halo.

Q: What’s your take on the impact of social and mobile games on the traditional console business model?

A: What’s interesting about the games business right now is that we have four different business models operating at once. For console games, retail still dominates with increasing revenues from microtransactions. On the PC side retail is dead, but traditional, single-purchase games still thrive on Steam. Furthermore, free-to-play games from CityVille to League of Legends can succeed purely via microtransactions. On mobile devices, the app store dominates with the big money coming from in-app purchases. Over time, these four models will almost certainly merge into one consistent system. We have already seen plenty of convergence; Steam made a big push to support microtransactions and free-to-play games while in-app purchases were an important later addition to Apple’s App Store. The big question is the next generation of consoles. The benefits of fully embracing an app store model are obvious, but there are many entrenched interests and historical relationships slowing down that transition.

App stores, in general, are very interesting simply because they make it possible to actually charge players for small-scale games. For example, there is no reason why I shouldn’t be able to buy Ascension for $4.99 to play in my browser, but the tradition simply does not exist to “buy” web pages. On the other hand, the Apple App Store combines frictionless purchasing, flexible pricing, automated submissions, and an enormous audience to create a market for games which didn’t exist previously. At some point, the importance of the browser (with open standards and cross-device support) needs to combine with the ease of the app store (with a standardized purchasing model), to hopefully create an even better system.

Q: Do you think the kind of hardcore PC player that you targeted with Civ IV will want to play your next game at Zynga, or do you have to change your design philosophy to cater to a new, more casual audience?

A: I expect Civ fans will absolutely be interested in my current project at Zynga; in fact, I anticipate them to be among the first wave of players to try out the game. As with Civ IV, I will be trying to make the game as simple as possible to keep it accessible for any kind of player. Remember that Civ itself is no typical strategy game and has an audience which is an order of magnitude larger than any other turn-based strategy game. The reason is that the series is infused with “Sid’s design parsimony” (to borrow a phrase from Chris Crawford), refusing to pile on more and more rules and mechanics in the name of realism. I hope to carry this tradition forward to make a game for every gamer.

Dragon Age Legends: Guilds Explained

My current game, Dragon Age Legends, was released last month. I wrote the following post as designer notes on the upcoming guild system.

One of the design goals of Dragon Age Legends is to have meaningful social mechanics. Many social game are social only in the sense that they use the player’s social graph to help spread the game virally through her network – by encouraging the player to invite her friends as neighbors to grow her farm, for example, or trading items with one another through the gifting system to finish a building. While these mechanics help grow a social game’s visibility, they don’t necessarily make the actual experience of playing the game more fun.

Our core social feature in Legends is borrowing friends’ characters to fight alongside one’s own character in combat. As one’s friends level up their own characters, they make the game more fun by providing new skills and stronger characters to use. Unlike most RPGs, players of Legends will be able to try out the entire skill tree depending on how their friends upgrade their characters. Borrowing a friend’s character also provides that friend with a small gold bonus, which creates some interesting dynamics – encouraging players to have the most appealing characters (to earn more gold) while also giving veterans a charitable reason to bring along low-level friends they want to help.

However, a genuinely meaningful social mechanic can create its own share of problems. Facebook friends are not necessarily one’s actual friends. Players often announce their names and character details in various forums, hoping to find “fake friends” to fill out their list. Doing so creates three advantages. First, the more friends the player has, the more opportunities for his character to be borrowed and thus earn friend gold for the player. Second, high-level friends make combat far easier because of their high stats and upgraded skills.

Finally, a surplus of friends allows the player to bypass the rest time restriction. Borrowed characters enter a rest state after combat finishes for a certain period of time (often for a few hours, depending on the level and damage sustained). This rest period exists so that players will not be able to reuse a single friend’s character over and over again (and, thus, feel no incentive to invite other friends into the game). However, if a player has a huge list of fake friends playing the game, perhaps numbering in the hundreds, this mechanic becomes irrelevant as there will always be a ready supply of fully rested characters.

These three advantages can greatly distort the balance of the game. In particular, if a player has a huge list of high-level friends, which is not difficult if one looks in the right places, the combat becomes trivially easy. High-level characters can wade through most monsters easily, which prevent us from finding an ideal difficulty level. We could boost the strength of all monsters across the board to compensate for endless high-level friends, but that change would ruin the game for the average player who only uses her real friends. Besides, we want the player to experience the power of a high-level friend mowing down waves upon waves of darkspawn from time to time, just not in every battle.

To fix this issue, we are creating a new system – Guilds. A Guild is a select group of 16 friends who are playing Legends. The player can only borrow characters for combat from this group of 16. The composition of a Guild can be changed at any time (as long as the character being removed is not currently resting), so a player is not restricted to whichever friends are first added to the Guild. Also, a new castle room – the Great Hall – will allow players to expand their Guilds.

Guild membership is one-way; I might have my friend Ethan in my Guild, but Ethan does not need to have me in his Guild. However, if we are both in each other’s Guilds, we receive a bonus of a shorter rest time when using each other’s characters. This feature creates some interesting social pressure, forcing players to choose between using their friends with the best characters and using their actual best friends.

From a design perspective, the greatest benefit of Guilds is tuning as we can now balance the game for a single target – a player who has 16 friends, with a mixture of low- and high-level characters. Because rest time is proportional to a character’s level, players might not want to fill their Guild with only high-level character who would often be unavailable.

Ultimately, the player should be making interesting decisions during all parts of the game, including when deciding which friends to use for combat. Perhaps a certain battle looks fairly easy, so a player might want to use a couple low-level friends or maybe to even try it solo. Perhaps a looming boss battle makes the player hesitant to waste his highest-level friend on a normal encounter. With infinite high-level friends, these dynamics disappear, to the detriment of the gameplay.

Moreover, we want players to be interacting as much as possible with their real friends, as these are the most important social bonds tying the player to the game. Guilds encourage this behavior via the reciprocal membership bonus to rest times as well as the simple ability to build a subset of friends most relevant to the player. Guilds are a small but important step towards creating meaningful and balanced social mechanics within Dragon Age Legends.

Dragon Age Legends: Economy Explained

My current game, Dragon Age Legends, was released this week. I wrote the following post as designer notes on the economy system.

Many successful Facebook games are persistent management games. In FarmVille, the player plants and grows a prosperous farm. In Millionaire City, the player designs and constructs a bustling city. These games give players a certain number of resources to spend on development and then reward their smart moves with more money to invest, creating a positive feedback loop. The money players earn enables them to buy more things that will earn them even more money for more things and so on.

While this mechanic forms the solid underpinning of most management games, it creates two problems for long-term, persistent play. First, as the gameplay is stretched over months (instead of a few hours in the case of non-persistent games like SimCity), the amount of interaction required for each visit is quite small – place a building here, drop a road down there, etc. Therefore, most social games add UI busywork to fill up the player’s time – plowing, seeding, and harvesting every plot for farming games or clicking on each energy, food, and wood icon that appears in FrontierVille. In actual time spent, these often mindless activities comprise the bulk of each play session.

Second, these games often lack a sense of purpose outside of simply growing the player’s ability to continue growing. If the only reason to earn more money is to invest in items that will earn more money, the game eventually loses players not interested in pursuing purely aesthetic goals. At some point, maintaining a city begins to feel more like clearing the weeds or doing the laundry than playing a game.

The turn-based combat of Legends solves both problems at once. The tactical battles occupy the majority of the player’s time within the game, and they are clearly not mindless click-fests, challenging the player and rewarding smart moves. Furthermore, the battles give the persistent castle an actual purpose; expanding the castle is not an end in and of itself. Instead, the output of the castle is consumables the player can use in combat: health potions, mana salves, shard bombs, and so on.

Indeed, the way consumable are handled in Legends is meant to improve on their use in traditional RPGs as well. Traditionally with these type of games, hoarding is quite common as the player is uncertain what is around the corner – what if she uses too many potions and will not be able to tackle the later game as the difficulty increases? Turn-based RPGs suffer even more as the player is usually choosing between a repeatable skill and a consumable item, which means that the power of the latter has to greatly outweigh that of the former to be worth the permanent loss of the item.

Legends solves this problem with a few simple changes. First, consumable use does not end a character’s turn; instead, it is an optional step. The character can either shoot an arrow or drink a potion and shoot an arrow. Thus, by passing up the use of a consumable, the player is forfeiting an opportunity and needs only to weigh the effect of the item versus its permanent loss.

Second, the game’s core stats, health and mana, do not regenerate as they do in most RPGs. Health does replenish but only outside of combat and only in real time – one point of damage per hour. As for mana, characters receive only one or two free points at the start of combat, enough to use a couple skills per battle. Thus, if players want to restore their health and mana, they need to rely heavily on their consumable items – health and mana potions, injury kits, and mana salves. As long as battles are balanced correctly, consumables become the fuel that players use to power though DAL’s combat.

However, Legends also differs from traditional RPGs because the player is actually in control of the supply of consumables, via the castle. The core of a player’s castle are the workshops – the apothecary (for crafting potions), the infirmary (for salves), and the alchemy lab (for bombs) – which can create consumables over certain timed increments. For example, the player can place a worker in the apothecary to create 2 health potions in 30 minutes of real time. Giving players this control frees them from the anxiety of depleting their limited supply of items. With Legends, players can always invest time and gold into their castle to start rebuilding their supply.

Indeed, 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 into expanding the castle and upgrading its rooms. Accordingly, maintaining the castle and tasking workers to create items provides the potions, salves, and bombs the player needs to defeat the increasingly difficult monsters encountered over the course of the game.

Thus, the two parts of the game fit together and buttress each other. A well-supplied character will lose less battles, earning more gold that can be invested in the castle. A well-maintained castle will create more consumables for the the player to use in combat, increasing the odds of success. The combat and the castle provide context for each other, motivating the player to keep fighting and to keep building.