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

One of the most lauded features of Dragon Age: Origins was its tactical combat system, which encouraged players to plan ahead and make interesting choices during battle. Indeed, although the system ran in real-time, the player could set a number of triggers that paused combat, to give time for deciding which skills to use and against which enemies. This feature allowed some to play Origins as almost a turn-based game that emphasized smart tactics over fast reflexes.

The Dragon Age Journeys Flash game built in parallel with Origins brought elements of the franchise to an actual turn-based game, in which battles played out on a hex-based grid. For the new Dragon Age Legends Facebook game, we built on top of what worked within the Journeys system (which itself was based on Daniel Stradwick’s Monsters’ Den Flash RPG).

For example, we borrowed the interleaved turn queues from Journeys, which means that the heroes and monsters take turns one at a time instead of fighting together as alternating groups, as is common in many group-based RPGs. Giving the player knowledge of which exact characters will move next creates some interesting tactical decisions. A monster who will attack sooner might be a better target than one who is a greater threat overall. Skills which disable or freeze enemies can be used intelligently to keep the most dangerous monsters at bay.

However, we simplified other mechanics from Journeys. Instead of using a hex-based grid, we adopted a simpler layout familiar to fans of Japanese RPG series like Final Fantasy in which the heroes and monsters line up on opposite sides of the screen is static slots. We built a 2 X 3 grid for each side, with front and back columns so that characters in the back column are protected from melee attacks by characters in the front column. This arrangement allows players to plan ahead by attacking a specific monster in the front line that, when dead, would expose a weak but dangerous blood mage in the back.

Another big change involved how we handled health and mana, the two most common stats from RPGs. Instead of using a bar-based system, in which a character might have 45 of 80 health points, we adopted a more chunky icon-based system. A character’s health is represented simply by 4 hearts, which are measured in halves, identical to the health system from the Zelda games. Mana is represented by single icons and as most skills cost just one mana, the number of icons a character has is shorthand for how many skills she can use.

This simplification had a number of advantages. First, the system had much greater clarity than opaque health and mana bars. These bars generally have the same size on the interface for the sake of consistency, which unfortunately obscures their true values. Although one character might have 20 hit points while another has 200, their health bars look the same on the game screen. In fact, most modern RPGs have superimposed text on top of health bars to give the actual values to avoid any confusion. With the iconic hearts, Legends avoids this problem as the graphics do not obscure any game data – what you see is what you get.

However, the most important reason to adopt the icon system is that it gives players a very tangible understanding of the consequences of their actions; the interface tells the exact effect of every possible action. For example, mousing over the “Power Strike” skill button next to a Hurlock shows that the action will take one-and-a-half hearts away from the monster while draining one mana from the player’s character. Mousing over a health potion shows that two hearts will be restored to the character. Mousing over a shock bomb shows that one heart will be taken away from all enemies. This transparency enables the player to plan ahead and make smart moves.

One reason so many RPGs go with a bar-based system is that hits points need to scale up over the course of a game, ranging from 10 hit points for starting monsters to over 1000 for bosses. With icons, Legends can never support hit point values that scale so high because the interface can only show so many hearts. Instead, the underlying character stats – attack, defense, agility, and luck – provide the scaling we need as players progress through the game.

Damage is calculated by creating a simple ratio between the attacker’s attack and the defender’s defense values. As this ratio increases to 2:1, 3:1, and higher, the damage value in hearts goes up. However, if the ratio remains constant, so does the damage. Thus, characters battling with 10 attack and 8 defense do the same amount of damage as characters battling with 50 attack and 40 defense, which means that the relative value of hearts stays the same. Similarly, agility and luck determine the odds of glancing blows and critical hits, by comparing the attacker’s luck with the defender’s agility.

As for mana, most skills cost just one point, with a few costing two and a handful costing more. The skills are all upgradeable up to ten levels (similar to the Japanese RPG Etrian Odyssey), which means that their power increases over the course of the game. However, their costs do not, so that players can expect to use the same number of skills per battle through all phases of the game. The costs can remain fixed because the better skills are simply an extension of the character’s growing power as he levels up.

Thus, the game’s simple and discrete health and mana values are maintainable across the game’s various levels. The players quickly gain an intuitive sense for how the game works (“shard bombs do one-and-a-half hearts of damage”) without having to memorize formulas or manage large, crooked numbers. Being able to think in small increments – a point here, a couple of points there – allows the player to fit a whole battle into her head at once, making combat a fun, tangible experience instead of a chaotic, stressful one.

GDC 2011 start on Monday, and I am even more excited than normal this year because I helped program the conference. The GDC Advisory Board invited me to join them last summer, and it’s been very interesting watching how the sausage gets made. I’m looking forward to seeing which ideas and sessions work out and which ones don’t. (If you don’t like that the “fuzzy” sessions – the rant, the microtalks, and the challenge – are scheduled during lunch, you can blame me!) It’s been an honor to be part of the process – I am as much a GDC junkie as ever.

I’m taking part in one talk this year, a panel on strategy gaming, for which I hand-picked the members. Hope to see you there!

Strategy Games: The Next Move

SPEAKER/S: Tom Chick (Quarter to Three), Ian Fischer (Robot Entertainment), Soren Johnson (EA2D), Dustin Browder (Blizzard Entertainment) and Jon Shafer (Stardock)

DAY / TIME / LOCATION: Friday 11:00-12:00 Room 134, North Hall
TRACK / FORMAT: Game Design / Panel

DESCRIPTION: Strategy games have one of the longest traditions within the industry, including two of last year’s biggest games, STARCRAFT II AND CIVILIZATION V. In what direction is the genre heading? What are some of most important, and possibly overlooked, gameplay innovations of the last few years? How has the growth on online, persistent play affected the way strategy games are developed? Has the rapidly expanding mainstream audience changed how strategy games are targeted, or is the genre at risk of turning into a ghetto? As the market moves towards free-to-play, micro-transaction-based gaming, how will strategy gaming adapt while maintaining fairness of play? Is there still room for traditional, boxed strategy games?

TAKEAWAY: Several experienced strategy developers will share their own perspectives on the future of the genre, offering insights on both game design and the challenges facing the genre in the coming years.

INTENDED AUDIENCE: Although primary of interest to strategy game developers, the session will also be relevant to anyone interested in how a game genre evolves and reinvents itself in the face of a changing market.

I’ve been on a couple podcasts recently in which I talk about my newest game – the Facebook-based Dragon Age Legends. The first was the strategy-focused Three Moves Ahead, which also addressed my talks/columns on theme and meaning in games. The second was the The Digital Life, in which I was paired with veteran design Brenda Brathwaite to talk about the emerging format of social games. I can’t promise that I don’t repeat myself between the two, but they are both worth a listen for developers interested in this field – and for fans interested in my next game!

GDC 2010 is now in the books, and it will be a hard one to forget because the whole conference seemed to be obsessed with one thing, which I summed up in this tweet. Or, as Sirlin puts it here: “Facebook, Facebook, Facebook, Facebook, Facebook, Facebook, Facebook, Facebook, Facebook, Facebook.” Off the top of my head, here are the highlights and lowlights of this fixation:

• The long-running Casual Games and Virtual Worlds Summits have vanished entirely from the conference, presumably eaten up by the new Social Games Summit.
• Ngmoco’s Neil Young describing the growth of free-to-play online games as “the most significant shift and opportunity for [game developers] since the birth of this business.” This shift fundamentally changes the way game are made because developers can now launch early and adjust based off play patterns and user metrics.
• Zynga’s Mark Skaggs, formerly of EA, praised metrics as the answer to most game design problems. Much has been made about their discovery that pink was the best color for advertising Zynga’s other games, but the telling point was when Skaggs said that “if a player repeats something, it’s fun.”
• My old Spore teammate Chris Hecker railed against external rewards as a true motivator as they can mask an otherwise dull game. Further, focusing primarily on metrics can actually make the game worse because they can overvalue external rewards, which are easier to measure. Chris also leveled this broadside at metrics-focused companies: “If you are intentionally making dull games with variable ratio extrinsic motivators to separate people from their money, you have my pity.”
• Carnegie Mellon’s Jesse Schell walked back from the ledge of his now infamous DICE talk on pervasive rewards systems, saying that doomsday is not inevitable. He went on to explicitly draw the line in a new war between persuaders (developers who want players’ money) and the rest of us (who want to give the players joy). When addressing persuaders, Schell actually used the phrase “you know who you are.”
• Zynga’s Bill Mooney offended the entire independent games community in his acceptance speech for Farmville at the Choice Award by defining the Facebook game as “just as indie” and then trying to recruit everyone in the audience, many of whom have open disregard for Zynga. Josh Sutphin had a message for him: “Learn some fucking tact.”
• Brian Reynolds, who is now Zynga’s Chief Designer, showed up on no less than three panels to point out repeatedly that social games need to be social first and games second. Farmville‘s crop-withering mechanic, in particular, was referenced as a not-fun mechanic that compels people to play out of a sense of shame. (What if my real-life friends see how poorly I am maintaining my own farm?)
• Daniel James of Three Rings puzzled over the phrase “social gaming” as he felt that his old games (such as Puzzle Pirates) were far more social than Farmville, which is a primarily single-player game in which players pass around “tokens.” At multiple times during the conference, James expressed his serious ethical qualms over the path social gaming was laying for the industry. So many of the methods for making money are thinly-veiled scams that simply exploit psychological flaws in the human brain.
• At a panel on why “dinosaur” designers are flocking to social games, Reynolds, Slide’s Brenda Brathwaite, Noah Falstein, and Playdom’s Steve Meretzky all praised social gaming as a new frontier where radical and rapid innovation exists, in contrast to the more conservative world of AAA retail games.
• Will Wright pointed out that the astonishing growth of Facebook (and Facebook gaming) more likely resembles an S-curve than a power law curve. Thus, although this new market is indeed enormous, the upward sloping curve will level off at some point, so we should be careful not to make exponential predictions.
• Sid Meier only briefly touched on Civilization Network, his new Facebook project, in his conference keynote, but what else needs to be said? Sid Meier is making a Facebook game! (Quite literally, in fact, as Sid is doing his usual designer/programmer thing.) Further, the three primary designers of  the Civilization franchise (Sid, Brian, and myself) are all now making social/online games.

What is to be made of all this? Meretzky made a key point in the dinosaur panel that, with free-to-play games, there is no more separation between game design and game business. Every change to a game’s balance might immediately and significantly affect revenue. Will it go down because the virtual items for sale are now less desirable compared to the free ones? Or will it go up because the player is now inconvenienced enough to buy a boost? Or will it go down because the inconvenience has driven away enough of the core fanbase? (I made a similar point in my Nov 2008 column on designing free-to-play games.)

The question on most developers’ minds is the following: what is the role of the game designer in this new world where business and design mix in such fundamental ways? The answer to this question drives fear in the heart of the boy or girl beating inside most professional game developers. Brian Reynolds himself often pointed out that the role of Zynga’s Chief Designer is not actually as important a position as one might imagine. At the VCON Summit, Eric Goldberg of Crossover Technologies suggested that companies “use the tactics that make the most money possible… that your staff can live with.” At that summit’s keynote, David Perry talked about the morally dubious “treasure chests” of ZT Online, which are engineered to prey on gambling addicts and provoked a visceral response from Sirlin:

This egregious, unethical practice is the kind of thing he should have presented as extremely dangerous. If you are “playing to win” in business, yeah, you’d do that. But doing so is damaging to the lives of our own customers… I mean personally, I’m embarrassed to be part of an industry that so blatantly manipulates people like rats in a skinner box, and isn’t he embarrassed about that too?

This debate over business-vs-design spawned a thread at Quarter to Three in which game developers are expressing their feelings over Farmville and its ilk:

It’s not social games as a threat to game design, it’s money-driven treadmill games that’s a threat to game design. A coworker identified a similar problem with a money-driven free-to-play social game, in which they specifically destroyed the balance in key ways at times in order to persuade the players to pay money to fix their own game balance. It is a war. It’s suits versus the creative people. (link)

I can’t believe one of the most important figures in strategy gaming [Brian Reynolds], the guy who had a major hand in bringing us absolute classics like Civ 2, Alpha Centauri, Rise of Nations, and Rise of Legends is now Chief Designer for those creeps at Zynga. (link)

I don’t like that at all. It turns my art into a business intent only on making as much money as possible. And while making money is the goal for the large industry, the fact is that we’re still as much about creating great experiences first and foremost, and the money is a happy second. With Farmville and such, the premise is to make a lot of money, and that is the drive that informs every single decision. (link)

Making the game worse can make it generate more revenue. The lesson is to focus on generating fast bucks over improving the artistic quality of your game. Enjoyment isn’t as important as long as they keep paying and playing. The dividing line flaring up is an old one; are games an artistic endeavour furthering culture or are they just slot machines to be designed for revenue maximization? (link)

Farmville makes overt use of known psychological techniques to influence and control behaviour and ties that directly into revenue generation. . . . When you have games industry professionals from large companies arguing that we shouldn’t worry about making a game less enjoyable as long as it generates more revenue – to me that is something to be concerned about. (link)

Farmville‘s formula is simple. Make it easy to scream forward to the point where you can’t properly spend your coins anymore without spending real money. . . . Do not misunderstand me, I am saying, without any ambiguity, that doing this is wrong. I see very little difference between this and tactics at stores such as raising the price of something, removing functionality, and slapping a “On Sale 40% Off!” sign on it. (link)

The question will be, when it comes to tuning Brian Reynold’s Facebook game, will the guiding principle be increasing Zygna’s revenue or making the game more fulfilling? (link)

The Zynga guy said, you need to identify what people are doing most often in a game, because that’ll be the most fun activity. If that were true, the funnest activity in Starcraft is building Zerglings and the funnest in late-game Civ IV is clicking END TURN. (link)

Obviously, developers are wary of how Facebook gaming will change the industry in the years ahead. (Compare the importance of business metrics now with 1997’s Ultima Online, which lead designer Raph Koster points out “wasn’t designed around any business model in particular.”) The irony is that Facebook games typically share four characteristics that really do promise great things for both gamers and designers:

• True friends list:  Gaming can now happen exclusively within the context of one’s actual friends. Multiplayer games no longer suffer from the Catch-22 of requiring friends to be fun while new players always start the game without friends.
• Free-to-play business model:  New players need not shell out $60 to join the crowd. Consumers don’t like buying multiplayer games unless they know that their friends are all going to buy the game as well. Free-to-play removes that friction.
• Persistent, asynchronous play:  Finding time to play with one’s real friends is difficult, especially for working, adult gamers. Asynchronous mechanics, however, let gamers play at their own pace and with their own friends, not strangers who happen to be online at the same time.
• Metrics-based iteration:  Retail games are developed in a vacuum, with designers working by gut instinct. Further, games get only one launch, a single chance to succeed. Most developers would love, instead, to iterate quickly on genuine, live feedback.

These four pillars are the reason why many game developers are flocking to Facebook. (Of course, many of these characteristics are not exclusive to Facebook, but combining them together with such a large audience makes Facebook the obvious choice right now.) However, Jesse Schell is right; a war is brewing over who will call the shots. However, the question is not simply one of suits-vs-creatives. The question is will designers take the time to learn the business, to learn how to pay the bills while also delivering a fantastic game experience? As BioWare’s Ray Muzyka put it during a panel on connected gaming, ultimately all decisions are made with a goal to make money, but the goal may be short-term revenue (“can we sell more blue hats tomorrow?”) or long-term growth (“does our community believe in what we are doing? are we creating life-long fans?”). The successes will not come from open conflict between design and business but from developers who internalize the tension and attack the problem holistically.

I have to admit my own reservations about this transformation; game design itself simply might be not as much fun as it used to be. I cannot easily sum up how enjoyable brainstorming a game is during the early, heady days of blue skies and distant deadlines. With a release-early-and-iterate mentality, these days are now over, for good. Games will no longer be a manifestation of an individual’s (or a team’s) pure imagination and, instead, will grow out of the murky grey area between developers and players. The designer-as-auteur ideal is perhaps incompatible with this model, but I believe the best game designers are the ones willing to “get dirty” – to engage fully with a community to discover which ideas actually work and which ones were simply wishful thinking. Loss of control is never fun, but as Sid is fond of saying, the player should be the one having the fun, after all, not the designer.

My keynote on theme-vs- mechanics went well. I’m getting positive feedback so far although I am curious where people may have felt my arguments were not as strong. I’ve posted the slides in the sidebar, but here is a direct link. Also, the talk was written up a couple places online, with the Destructoid piece almost being a transcript:

• Destructoid
• EDGE Online

This year at GDC, I am giving one of the keynotes at the Serious Games Summit. Here’s the description:

Theme is Not Meaning
Speaker: Soren Johnson (Designer & Programmer, EA Maxis)
Date/Time: Tuesday (March 9, 2010)   11:15am — 12:15pm
Location (room): Room 133, North Hall
Experience Level: All
Summit: Serious Games Summit
Format: Summit Keynote

Session Description
A game’s theme does not determine its meaning. Instead, meaning emerges from a game’s rules – the set of decisions and consequences unique to each one. What does a game ask of the player? What does it punish, and what does it reward? What strategies and styles does the game encourage? Further, when theme and rules are in dissonance, the designer cheats the player while also compromising his or her original vision. This can often lead to significant failures in the serious games space. In this opening Serious Games Summit Keynote, game designer Soren Johnson explores the critical question of how to produce meaningful experiences that are uniquely tied to gameplay vs. the content wrapped around that play?

Readers of my Game Developer column will recognize that this talk is an offshoot of my recent set of columns on how a game’s theme and meaning need to work together or risk alienating the audience. Hopefully, the two formats (print and lecture) will support each other instead of being redundant. I’m looking forward to the Q&A as I expect quite a few people will differ from my conclusions.

I am also participating in a panel at the AI Summit on supporting game designers:

Answering the Designers’ AI Wish List
Speaker: Brett Laming (Lead Programmer, Rockstar Leeds), Richard Evans (Lead Simulation Engineer, Maxis), Soren Johnson (Designer & Programmer, EA Maxis), Chris Jurney (Senior Programmer, Double Fine Productions), Adam Russell (Games Studio Manager and Lecturer, University of Derby)
Date/Time: Wednesday (March 10, 2010)   5:15pm — 6:00pm
Location (room): Room 310, South Hall
Experience Level: All
Summit: AI Summit
Format: 45-minute Panel

Session Description
We asked designers from all across the industry to answer a questionnaire of probing – and even outright crazy questions. The intent was to get their heads and assemble a sort of wish list. We then present their answers to a panel of top-notch AI designers and programmers and ask them… how would you go about granting this wish? In what promises to be the most forward-looking session of the AI Summit, this panel should give us all a look into not only what the designers would like in their games, but some ideas on how to address the difficult obstacles in AI.

Idea Takeaway
An impression of how much AI technology can accomplish, an insight into the technical design process of experienced developers. This session should be kind of fun and wacky!

Hope to see everyone at GDC, my favorite week of the year!

A few hours ago, I twittered about Denis Dyack’s Develop talk on how narrative is going to overtake gameplay in importance:

SorenJohnson: Hey Denis, if you put the narrative in front of the gameplay, you are no longer making a game. You’re making a movie. http://bit.ly/193Qdz

Harvey Smith responded to my tweet, challenging me on defining everything as either a game or a movie. Then Clint Hocking jumped in. Followed by Rob Fermier. Then Brenda Brathwaite suggested we start using the #gamedesign tag. (I had just started using #dyackrant, but too late…) Then Ian Bogost. And David Jaffe. And Damion Schubert. Even John Romero made an apperance. It felt like a virtual post-GDC Fairmont chat. The discussion is now spiraling out to larger and larger circles – just search for “#gamedesign” – and I’m not sure how long it will carry forward but it was an interesting experience. Twitter is quite poor at helping outside readers understand the context of most tweets, but as a pure social activity for members of the discussion, it is currently unrivalled on the Net.

Update:  in_orbit did some voodoo with the Twitter API to produce a threaded version: http://orbit.vect.org/misc/gamedesign.html. Hey, this Web thingy is pretty cool!

Before my GDC panel this year, AI & Designers: Mind the Gap, we did a preliminary e-mail thread as a warm-up. For readers who couldn’t make it to the conference (or to the panel itself), our back-and-forth might give a little taste of what the discussion was like. Of course, some of the questions were only ultimately answered during the panel itself, but it’s still worth a read for developers interested in the topic.

Here’s the cleaned-up transcript:

Soren Johnson: So, GDC – and our looming panel – is about three weeks off, so I figured it might be a good idea to do some pre-panel chatting to help get our ideas rolling. My original thoughts for this panel come from my own experience as a designer and an AI programmer. Essentially, I’ve always enjoyed being able to do both jobs at the same time because there is just so much overlap between the two. If I was only an AI programmer, I feel like I would get frustrated with designs that are impossible for an AI to handle. And if I was just a designer, I would regret not having total control over how the AI performs because that is a core part of the user experience. However, most of the industry separates these two roles, and I am curious how well it works. It seems like one of the two sides would always be dominant, depending on the make-up of the particular companies and probably to the detriment to the game. So, how has this tension worked (or not) for your teams? What are the best ways to manage this process? Any horror stories from past projects? Other thoughts?

Tara Teich (AI Programmer, Double Fine): There were two areas of interest for this topic to me.  The first was the issue of the different mindsets of designers and programmers.  Frequently, the issues I’ve had have come into play because designers and programmers come to the table basically speaking a different language.  A designer asks for feature X and the programmer goes “oh, ok, great” and goes off to implement it.  The result isn’t what the designer was asking for at all!  Basically, designers think of the experience of the player, programmers think of the how of implementation and they’re not always the same thing.

The second was about planning for change.  A good AI programmer will know that designers are GOING to change their mind and will build space into their system for as many aspects of it to be changed or even reversed as possible.  But if the programmer doesn’t do that, every new request from design results in a frustrating complete re-write of the system.

Alex Hutchinson (Creative Director, EA Montreal): My favorite part of the job is collaborating with engineers as I see the overlap between design and engineering as the heart of what makes games unique and special. I also think that it’s the path to getting more than either side could do on their own – my new way of working is basically to very clearly articulate the ‘why’ of a feature, then have no more than a couple pages where I try to work out the actual nitty gritty of the design. My goal with that is to have basically 80% of the idea clearly articulated, then I hand over ownership of the feature to the engineer, and we have regular discussions about it and eventually the goal is that they present it back to me and they’ve not only filled in the remaining 20% but added another bunch of stuff themselves, so we get more (hopefully) than if they’d done it on their own, or if I’d written down a hermetically sealed spec doc.

That said, it also relies on both sides being smart, easy to work with and fond of collaboration not dictation, so it’s based on people IMO.

Soren: Have you, or anyone on the list, experienced much with trying to put the AI parameter tweaking or simple algorithmic mods directly into the hands of the designers? It seems this would go hand-in-hand with building a flexible AI system instead of one overly specialized, like you mentioned. However, something like this was attempted in Spore before I came on-board, and we eventually ripped it out because there were just too many gotchas for the designers to trip over because the interface separating them from the code was too weak. I imagine it could work though, but I wonder if it would be worth the overhead of worrying about all the edge cases that probably will never be hit.

One question I always find interesting is whether a design idea should be judged separately from the AI’s ability to use it. Apparently, DoW2 is having issues with this as their AI doesn’t seem to be able to handle many of the special abilities available in the game that ARE still fun for the humans. With Civ, I was constantly resisting features like this – I avoided paratroops, invisible units (spies, submarines, hidden nationality units like privateers) – because I felt that the time spent on building AI to handle these special cases would be better spent on just the core AI problems. To me, it was just literally a cost/benefit tradeoff decision. However, I’m not sure if I made the right decision as players love these type of units. (and, inevitably, whatever units I cut were added by the looser expansion teams…) So, when does the plus of a player enjoying a tricky feature outweigh the minus of a hobbled AI?

Tara: One of the choices I’ve made on occasion is to just make it look “good enough.”  If you have an element that is really fun in multiplayer, and your game is very multiplayer-centric, then leave that feature in, and just make it look like the AI is utilizing the feature.  I’m not sure what the DoW2 issues are, I’d be interested in looking at the examples, but sometimes something is fun to the player not because it’s effective but because it’s unique.  And just seeing the AIs utilizing that feature and looking like they are “having fun” with it is sufficient from a player experience POV.

In terms of Soren’s earlier question about just handing the knobs and tuning parameters to the designers, I’ve found that to yield mixed results for similar reasons that you cited.  Too many knobs means they have to completely understand the underlying mechanics of the system instead of just being able to tune in the harder/easier dial that they really wanted.  I found for RTS games they really liked to give input on which units the AI would build and in what order, which type of battles the AI would prefer to fight, but the specifics of how to fight that battle, which builder should create the unit etc was up to me. Fun. 😀

Adam Russell (AI Lecturer, Derby University): Sorry for the delay in responding! I too am fascinated by the complex interplay between game AI engineering and gameplay design. I agree with you Soren that it’s very difficult to separate them cleanly and that’s what makes it such a fascinating area for me. As a programmer, I loved being given the chance to influence the game design through my AI architecture even though I couldn’t pretend to be a true game designer. The key issue for me is if both “sides of the fence” are in fact contributing to the game design (for example an 80/20 split as Alex suggested), how do we reconcile or align their contributions so they’re not pulling in different directions or contradicting each other? One way of looking at that is as shares on a linear spectrum of design scale: “Designers plan down to this level of granularity, AI fills in the rest of the details.” But both AI and design must consider game-spanning features in their own different ways, so the scales sort of conflict.

Another way of looking at it that I find very appealing is if we try to make the contributions orthogonal to each other: “Designers request diverse experiences of these kinds, AI builds a systematic infrastructure that knits it together into a logical whole.” Then for me it becomes about what representations the AI should offer to design, and the AI almost becomes a foundation or a space in which the design can move. Of course, that space should ultimately be built for the design, so there is kind of a circular process here. Design lays out the themes that give rise to the AI foundations which then defines a space within which they can do design.

For me this all goes back to Tara‘s point about the disciplines speaking two different languages. It’s frustrating but good that they speak two languages, because that gives them orthogonal concerns which can coexist. But it’s an ongoing challenge to keep the experience designs anchored in the AI framework, and the AI framework driven by the need to deliver key experiences. In my view both sides must give up ownership of certain issues which are best answered by the other. AI programmers must give up the desire to reduce everything to one generic system of moving parts (because this undermines the uniqueness of the experience design), and game designers must give up the desire to control experiences down to a very high level of granularity (because this undermines the robustness of the underlying AI frameworks).

I suspect this problem is less acute in strategy genres than in my area of action-adventure character AI. It seems that strategy designers are reasonably close to the mindset of AI programmers because they think in a very holistic way about game mechanics, whereas a lot of action-adventure designers have pretensions toward recreating experiences from linear media such as film, which conflict badly with AI systems (e.g. “make it so that they always do this when the player enters the room at that moment”).

On the other hand, that similarity of mindset in the strategy genre might be a recipe for trouble, given what I said earlier about the need for orthogonality? I don’t know because I really have no development experience in the strategy genre.

Josh Mosqueira (Creative Director, Ubisoft Montreal): The DoW2 examples are, I think, legacy from the same issues we had on Company of Heroes (both games use the same tech). Ability use was something that always dogged us, so much so that for CoH we scripted all that behavior into the missions. For MP, it was tricky. When to pick it, how to use it without being too effective. In the end, we lived by a Tara’s mantra… it doesn’t need to be perfect, it just need to be good enough.

Now, whether to keep or axe a feature based on how well the AI can use it… that’s a tricky question. Speaking purely as a designer, I’ll always err on the side that having cool units and abilities like paratroopers and invisible subs add to the gameplay. I agree with Tara, as long as the AI looks “good enough” when using these units I think it’s a win-win. Then again, I take a very player-centric POV. I rather have as many cool toys as possible.

Now a question… what designer/programmer assumptions do you guys run into all the time while working on AI?

The one I do quite often is that the AI should be “hard” and punishing.

It’s an attitude I get often… that only “hard AI” is fun. I get this from designers and programmers. Whenever I say, “the player should be able to predict the AI” the reaction is “where’s the challenge in that?” To which I answer that while we may think we don’t want predictable AI, we need to give the players enough cues so that they can make “smart” decisions to beat the AI (without making them too transparent). I love Halo for this.  Why do we always want to punish the player to prove our AI is smart?

This is something I spend a lot of time working on, understanding what the function the AI serves in the game. For me it has to be more than just challenge because if that was just it, then the Gombas in Mario Brothers, or the waves of Space Invaders are all we need.

I like to think that AI is our greatest tool to control the dramatic pacing of the game, but if you ask me, it’s our greatest storytelling tool. No, I am not talking AI actors but using AI to craft a proper intensity curve that has the right peaks and valleys to create an experience where the player feels like a bad ass (the peaks), and when he’s scrambling and being reactive (the valleys – which make the peaks that much sweeter).

Basically, the AI should be seen as the players’ “event coordinator” or “party planner.” In other words, it’s not the cut-scenes or powers that make a game fun, it’s the AI. AI is in charge of the player’s morale. When people talk about their game experiences, say with Half-Life 1, everyone remembers when they first time they run into the marines and how they used cover. The “oh shit” moment defined the player’s narrative of the sequence. Powerful stuff.

Maybe I feel this way because I’ve worked on too many games were the AI is brutal towards the player and it’s a knee jerk reaction. I’ve been guilty of being too hard on the player.  But part of me does think that for AI to evolve we need to shift its function from being only about challenge and obstacles.

For example, take this great article on Game AI: http://www.bit-tech.net/gaming/2009/03/05/how-ai-in-games-works/1. There is nothing in there about what the role of AI in games is.  Granted,  the article is about “How Game AI Works” but this is something I always find I run into. We tend to focus on the details (effective use of cover, believable reactions, smartness) that we lose sight of the real intent – fun.

Which brings me to the topic of collaboration. Not being a programmer, I won’t pretend to know how best to design an AI. What I focus on is trying to convey to the programmers what the intent for the AI is, how does it add to the game experience and what things I want to be able to tune to control the intensity curve. I know that for every variable I get to tune, there are dozens of knobs that the AI programmers have to implement and tune themselves, which is why I like focusing on how the AI impacts the player’s experience. How should it react, how should it challenge the player, how does it look smart without being too smart.

Alex: Yeah, I agree with the drive toward punishment as being a big problem – often people seem to confuse AI that will ‘destroy you’ with AI that is ‘good.’

I know that Sims 3, for example, is working on a big system where AIs can form long-term goals, such as ‘own a mansion,’ then build a plan, then step through all the behaviors that lead up to that goal. So the sim will pick up the paper to get a job, go to work for X period, buy only essential goods, save their cash, get promoted by working hard, focus only on important relationships, and then eventually buy the mansion. And when you describe it to a player it sounds amazing, but the problem is it’s essentially invisible to the player – they won’t see this glorious narrative, they’ll only see a few outcomes. My argument is you could have either scripted it, or made it semi-random and to the player, it’s the same system. The AI engineers obviously argued with me on that, but unless you’re going to invest in a strong system for showing the player the plan and the execution of the plan, it’s not interesting IMO.

Similarly, in action games, engineers are arguing with me at this very moment that they should do the ‘smart’ thing, and take cover appropriately, never expose themselves, sprint to new cover when their cover is breached and what that would essentially do is remove any chance for the player to win in a fun manner. If I flank an enemy, I want him to react in shock, show me that he knows his cover is breached, and then essentially let me shoot the crap out of him. If he flees and I miss him, I am no longer having fun.

I think the essentially point for me, as Josh points out, is that AI is there to support the player experience, not to be ‘good AI’ whatever that means, in and of itself. 🙂

Josh: That’s one of the issues I have with working on AI… if the player cannot see how the AI works, then it doesn’t really matter how “smart” it is. I hear you on the cover deal, Alex, I am having the same arguments here.

As a former infantry sergeant, I know the smart thing to do is to move from cover-to-cover and use concealment. Thing is, if a player cannot “see” all that fancy leap-frogging, then it doesn’t matter. It’s just frustrating. This is why I always argue we don’t want “smart” AI, we want reactive AI. The AI needs to react to the player in a way where the player can, by mastering the game, predict the AI’s reaction and feel like a bad ass when they flank and AI position. A common thing I get is for an AI programmer to show him some cool behavior using a top-down camera, but then when I ask to see it from the game’s default POV, I have to break his heart and show him that I can’t see it so I cannot appreciate the clever cover-seeking AI.

While this is very true of action games, it’s also true for RTS games. It wasn’t until we added a ton of barks (about 20K lines) to the Squad AI system for Company of Heroes did people really start to appreciate it. Before speech went in, a common comment was “the AI looks too chaotic, not sure what they are doing.” Then when we added speech, the reaction to the same system was “Man, that’s cool, they’re covering each other and, look, that guy is trying to lay down suppressive fire.”

It’s all in making sure that the hard work that goes into AI can be appreciated by the player.

Tara: The one place where a lot of that smart cover behavior is successful is when you have friendly teammates.  When you’re in the lines with them and you see them doing the leapfrog behavior, that’s great.  But you’re totally right, without dialog for them to say what they’re doing, to the player it still probably wouldn’t parse well.

Soren: I definitely appreciate the limits of “hard” as opposed to “fun” AI. The thing is, they both have their place, depending on what type of game you are making. For symmetrical strategy games, the game should still be fun/challenging once players have mastered the systems. Many strategy games fall down on this front (listen to Tom Chick talk about how Empire: Total War loses interest once the player masters the mechanics here) as the challenge for the player is just learning how to juggle multiple plates, not actually engaging an AI as an equal player. On the other hand, I was painfully aware from developing Civ that we don’t want our AI playing cutthroat games like a human would (i.e. being willing to backstab the player at any time just because it suited them). It’s a tough problem, but at the very least, I think it is important that they AI be able to handle all the game options in a symmetrical setting because strategies are often good or bad only relative to the choices of your opponents. (If the AI never uses submarines, I don’t need to build any cruiser to see them.) Of course, for asymmetrical games, like most shooters, the purpose of the AI is quite different, and it is irrelevant if the AI can use all the abilities the player has.

Josh: Excellent. Controversy!

Well, not really since I agree. It’s a conundrum, especially for symmetrical games as you mention. The AI needs to be deep enough so that it provides the right challenge for your 5th, 50th and 500th game.

How do you all handle how saleable you want the AI to be? Granted, not so much an issue in action games, since most AI does not live for more than 30 seconds and you can use tuning to handle challenge, but you’re right, for strategy game this is a balancing act.

On CoH we tired (and failed) at making the AI more “efficient” and ruthless as a game went on, but that didn’t work out. It was too obvious you were playing an AI, because human opponents, even our hard-core professional players didn’t play that way.

Tara: Could you elaborate on what you mean by “efficient and ruthless” and why that was a failure?

I worked on real-time strategy AI for about 5 years, so I’m curious to hear your perspective on it.  My philosophy was always to make the AI as hard as I could make it because it still wasn’t gonna be as good as a human.  Then add difficulty levels that crippled it on the easier levels and give it some perks on the higher levels because making a non-cheating AI that’s better than a human… well, I don’t think we’re there yet.  Partially because it makes no sense trying to encode things by writing complex AI that players figure out from intuition when we can just “cheat” and get the answer in one line of code.

Soren: Let’s phrase the issue a different way – especially in light of our specific topic of designers and programmers. What was the reason that the CoH AI ultimately failed? Was it a lack of AI resources or time? A flawed development approach? Or was there anything about the design that was out of step with what the AI programmers could reasonably accomplish? And if so, how much of the core game experience would you be willing to change if it meant a more robust and interesting AI?

It’s ok if the answer is “not much” or “that wasn’t really the issue”, but I want to take a stab at figuring out how to prevent the AI ultimately failing in future projects. How could the designers and programmers collaborated better in this case so that a better conclusion could have been reached? Or is this problem just intractable?

Alex: There’s also the secondary issue of all the other departments – as hinted in Josh’s email, I think bad animation or bad audio can also kill the AI. You could have a strong design and a great implementation, but if it isn’t communicated then it’s going to fail. In several recent focus tests (and this is more applicable to action games than strategy games), I’ve seen people say the ‘AI was bad on this level’ and the problem was actually a bad or missing animation. Players often confuse and overlap the feedback with the function.

The writers of Rock Paper Shotgun just finished a series on what games made them gamers. For the final installment, they asked developers and other critics to contribute their own stories. I wrote one up although my examples tend to show how I became a designer, not necessarily a gamer:

Legacy of the Ancients: Although heavily influenced by the Ultima series, LotA was a lot more accessible and had an interesting twist – no experience points! A few quests rewarded the player with better attributes, and equipment of could be upgraded, but I never had to wander the wilderness gathering up XP from hapless monsters. After slogging through all of Bard’s Tale over a period of months, playing LotA was a revelation to me. The focus was on exploration and adventure, not grinding, so much so that as soon as I beat it, I sat back down and finished it again in under eight hours. I learned from LotA that we don’t need to make players “earn” their fun with camouflaged treadmills.

Seven Cities of Gold: I was a Spanish conquistador discovering the New World – except it wasn’t the Earth that we already know. Instead it was a new one, randomly generated inside my computer – different enough to surprise but similar enough to feel real. Further, the suggestive allure of my Commodore 64 spinning for multiple minutes creating new continents and mountain ranges and river valleys was immense. It was the future, and I knew it. I learned from Seven Cities that the best game content didn’t need to be hand-written.

Adventure Construction Set: I finally got to make a world of my own! Too bad it’s locked away on a floppy somewhere in my parent’s basement, but the experience of building my own little game definitely made me dream of doing it for real someday. More importantly, ACS showed me the value of a data-driven design – new games could be built entirely on top of a fixed code-base. The design space was defined by which parameters could be altered, which raises an interesting question I am still trying to answer about who it the primary author of a game – the programmer who exposes the variables or the designer who fills them in?

A couple months ago, I had the privilege of talking to a group of Stanford freshmen about the potential of games to matter, not just to a mainstream audience but to academia itself, as a medium as valuable as any other. To their credit, they asked fantastic follow-up questions, which pushed me on many of my assumptions and helped me think through my reasoning. Thus, I’m sure I could do a much better job on this topic the next time around (got to work in the ReDistricting Game, for one thing). Until then, here is the promised link to the slides if anyone wants to peruse them.