February 28, 2010

The Prisoner's Dilemma, The Striatum, And The Dragonmaw Shinbones

I just finished rereading Satisfaction, which is one of my favorite psychology books (and therefore one of my favorite game design books). I really recommend reading it yourself, but here's one of the theses in a nutshell: Greg Berns believes that the Striatum is the region of the brain that controls how satisfied we feel, and that it is best activated by unpredictable stimuli.

Have you heard of the Prisoner's Dilemma? It's a scenario in game theory that examines how willing people are to make themselves vulnerable to betrayal:

Two suspects are arrested by the police. The police have insufficient evidence for a conviction, and, having separated both prisoners, visit each of them to offer the same deal. If one testifies (defects from the other) for the prosecution against the other and the other remains silent (cooperates with the other), the betrayer goes free and the silent accomplice receives the full 10-year sentence.

If both remain silent, both prisoners are sentenced to only six months in jail for a minor charge. If each betrays the other, each receives a five-year sentence. Each prisoner must choose to betray the other or to remain silent. Each one is assured that the other would not know about the betrayal before the end of the investigation. How should the prisoners act?
If both prisoners implicate each other, both will be punished. If both "cooperate," they will each be punished minimally. If one tries to cooperate but the other betrays them, the betrayer will go free, but the cooperator will be punished severely.

By remaining silent, a prisoner opens the possibility to not be punished at all, but must also willingly make themselves vulnerable to the worst punishment if they are betrayed.

Uncertainty can be very satisfying

In the last chapter of the book, Berns returns home after traveling the world to apply everything he has learned to his marriage. While examining the psychology of relationships and the temptation of infidelity, he examines the effects of the Prisoner's Dilemma on the Striatum:

In a brain imaging study of the prisoner's dilemma, Jim Rilling, a postdoctoral student in my department, found that parts of the striatum were activated when people cooperate. Given the close relationship of the striatum with reward and action, he naturally concluded that social cooperation is rewarding to the human brain. But it was not the act of cooperation alone that activated the striatum; it was mutual cooperation.

By design, mutual cooperation does not always result in the best outcome for each participant, not only because cooperation entails risk but also because it depends on making yourself vulnerable, which, in turn, creates opportunities for betrayal.

Whether it is a romantic relationship or a business deal, cooperation means uncertainty. When you do cooperate, and the act is reciprocated, the novelty of this outcome is picked up by the striatum. Perhaps that is the reason mutually reciprocated acts feel so good. The fact that cooperation doesn't always happen is exactly why it is so satisfying.



If you're like me, it's not hard to think of lots of moments from games when people were supposed to be cooperating but didn't: people getting the team killed in MMOs, Spies in EVE, players in shooters griefing the hell out of their teammates, etc.

What reading this quote really brought to mind for me, though, was a moment in World of Warcraft when an enemy and I managed to cooperate [I played on a PvP server]. As Bern predicted, it was very satisfying and has became one of my favorite memories from that game.

Dragonmaw Shinbones

At around level 30 in WoW, players of the warrior class are sent on several quests to gather resources which NPCs then turn into set of Brutal Armor for them. By level 30, most areas players quest in are contested zones, meaning that on PvP servers players often run across players from the enemy faction and have to fight.

Blizzard is careful to make sure that quests lead players from opposite factions to the same places at around the same level, to facilitate this conflict. One such place is the Angerfang Encampment, an out of the way location most people would never go except for the few quests that lead there (one of which being the quest for the Brutal Armor).

I was sent to the encampment for some Dragonmaw Shinbones, and happened to get there at the same time as a warrior from the other faction, presumably on the same quest. We traded deaths back and forth a few times, until ultimately one of us accidentally aggroed the local miniboss, whose army killed both of us. I don't remember whose idea it was, but one of us started to try and call a truce so that we could work together.

At this point I should mention for those that haven't played WoW that Blizzard does a great job of making the two factions feel at odds. Words typed by one faction are garbled to the other, and players on PvP servers aren't allowed to have characters on more than one of the factions. So the only way the other warrior and I could begin to form a truce and kill the boss was to use lots of emotes such as /bow /point /wait /sorry /ready etc.

We spent the next hour fighting enemies in the quest zone for our shinbones, and killing the miniboss as he respawned. We had to learn some new ways to fight, because all of our AoE powers would affect each other as well as the mobs. It was hilarious and terrifying when we died because I accidentally sent him running into a crowd of enemies. At one point, more players from his faction showed up and he even stopped them from killing me.



It was the only in an online game that I felt I'd had a reason to form an alliance with an enemy. That warrior and I probably killed each other hundreds of times after that in the battlegrounds without even noticing, but that temporary alliance was a great experience that shook up my expectations and made me feel as though I was part of a real world for a little while. I'm sure this sort of thing must've happened in multi-faction PvP games such as DAoC and Shadowbane, but I never played either of those very seriously.

Surprising doesn't have to mean punishing

There are actually lots more examples of this kind of thing in WoW, which is surprising because it's known for being so accessible. Being surprised in an online game doesn't necessarily imply having all your possessions stolen or your corpse camped for hours at a time. Sometimes it means players or a giant monster invading your city, or a bunch of level 1 players ganging up on a level 25. If you ask players if they want to be surprised, they (and I) will almost always say no, but the truth is we like the way it feels from time to time.

WoW is a game that's very good at leaving loopholes for interesting experiences while still being a "casual-friendly" game. These kinds of shenanigans don't really hurt anything, and are usually pretty easy to avoid if you're not in the mood. WoW could probably be better about making important areas like auction houses inaccessible to enemies, and the zombie event should probably have never happened on PvE servers, but PvP Servers in WoW usually manage to feel chaotic and dangerous without making player feel as though they have lost control over their playtime. This is something worth emulating.

December 17, 2009

How Valve Is Designing Their Community's Behavior

In the past week, both Valve and Blizzard have rolled out huge, long-awaited patches to Team Fortress 2 and World of Warcraft respectively.

The patch notes for WoW's 3.3 patch are just staggering. There's some great stuff in there: they've finally fixed their Looking For Group tool, added new content, and made tweaks to every class as well as a huge amount of powers, missions, and items. It took me about 20 minutes to wade through all the text in the patch notes.

TF2, on the other hand, received 7 new items and about 40 achievements. Presumably those patch notes would take about 2 minutes to review, right? Except TF2's patch notes have taken over a week to reveal themselves and still aren't finished yet.

The patch notes for TF2's War Updade are complete with challenges, conflict, a narrative, rewards, and even merchandising. In other words, it has many aspects in common with a game.

I've talked before about how Valve uses every opportunity to teach their players, but I've been really impressed at the lengths to which they've gone to entertain and motivate them this time around.

Good community members > good players

The really amazing part of this update, though, is what it communicates about Valve's values to their community, and how it reinforces it.

I've spoken about designing your audience before, in the sense of making sure you have the right players, but Valve is taking this a step further and designing how their community actually behaves.

Take a look at both of these posts. Notice anything in common? Both of them include players being called out by name for their great contributions, and rewarded with unique items that can not be acquired through the game:
Note: Pretty much any time we reveal a new weapon, somebody on the forums claims they thought of it first. But this time, assuming it’s Tom Francis and jibberish, they are absolutely correct. As a special thanks to them for doing our work for us, they'll each be getting a unique version of the Equalizer of their very own.
Think for a moment about how important and powerful a statement this is. By playing the game well, players can help their class get a new item this weekend, which is cool in itself. But by making some fan art or posting an insightful suggestion on the forum, they can receive a completely unique in-game item that nobody else will ever be able to own.

TF2 is also known for redistributing player maps as part of the game proper, which is great exposure for players who contribute to the community that way, especially if they'd like to break into the industry.

By rewarding their players so enthusiastically for the behavior the company values, Valve is making a very clear stand for what is important to them in their community, not to mention causing no end of evangelizing. Imagine how many people this guy will end up convincing to play Valve games in his lifetime.

It's a really interesting contrast to WoW's community-developer relationship, which has been famously rocky this past year. It often seems like WoW devs' main form of interaction with their playerbase lately is to yell at them for misbehaving (which as any parent will tell you actually encourages misbehavior).

This is one of the reasons so many other people like Valve so much: they realize that their players are worth much more than money, and treat them accordingly.

November 28, 2009

One Year And Thank You

Well whaddaya know? Yesterday was first anniversary of the day I started this blog. This year passed surprisingly (disturbingly?) quickly, and has been an exciting time replete with career changes, interesting discussions, and new friends with which to have them. This blog has helped provide me with all of those things.

The most useful thing about all this writing, though, is how much it's helped me to refine and clarify my thoughts on game design as a discipline and a career, and my place within it. I've learned a lot in the past year about what parts of game development I'm best and worst at, and what my goals and values are.

Even if I never had any readers at all, that kind of self-knowledge would be completely worth the time and effort of blogging. This is especially true within the context of job interviews: It's amazing how easy and comfortable that whole process is when it's just an extension of the conversation I'm having all the time here.

I also use this blog as a place to make public declarations that I know will make me feel like an idiot if I fail to live up to them later. It's the place where I design the kind of game designer that I want to be, and harness peer pressure to be better at living up those ideals.

Writing this blog would be a good experience even without any readers, but I do have a bunch of readers and other people that have made it a great one. I'd like to thank all of you, as well as call out some specific people.

People who helped make this blog possible

I'd never have a blog at all without Penelope Trunk. She entertained and enlightened me with her blog for quite some time before eventually convincing me that I should start a blog of my own, and that I should just jump into it whether I knew what I was doing or not.

Joel Spolsky showed me that having a blog could be a useful outlet for someone who's frustrated by the state of their industry, and that there are more productive ways to communicate than ranting. I set out to write a blog that would be "like Joel's, but for games."

Around eight years ago, I stumbled onto Raph Koster's old webpage and spent a lot of time digging through all the game design writing there. This was the first time I had thought seriously about becoming a game designer. His descriptions of how difficult and frustrating it could be to make games that stood up to player interaction the way developers expected them to intrigued the masochist in me.

At some point I really need to just hire a webdesigner and make myself an actual portfolio page with an integrated blog, etc. In the meantime, tweaking one of Douglas Bowman's blogger templates has served me pretty well.

People who help make this blog successful

This blog would be much less successful without all the people funneling traffic my way, leaving insightful comments, or just posting great posts of their own which get me thinking. I'm definitely also leaving out a bunch of people, but here are ones that really helped get me on my feet:

Simon Carless (Game Set Watch)
Steven Savage (Fan To Pro)
Tesh (Tish Tosh Tesh)
Nels Anderson (Above 49)
Eolirin
Ysharros (Stylish Corpse)
Brian Green (Psychochild's Blog)
Damion Schubert (Zen of Design)
Steve Gaynor (Fullbright)
Gregory Piatetsky (KD Nuggets)
Tobold (Tobold's MMORPG Blog)

Thanks everybody! I plan to keep this blog going until I run out of things to say, which I can't imagine happening anytime soon. Now I just need to get better at posting on a regular schedule.

In the next year, I also plan on testing out some more interactive features, such as interviews, guest posts, and Q&A.

November 19, 2009

Do Great Games Take A Decade?

Jamie Fristrom reminded me of an old Joel Spolsky article which claims that any major piece of software takes 10 years of development time to really get good.

The part of Joel's post that really intrigued me at first was the idea of purposely having a small launch, so that only the die-hard early adopters would be around to see the problems that you've shoved out the door.

I've mentioned this before, when discussing how EVE and WAR arrived at 300k subscribers by such different paths:

EVE had a very small playerbase to witness its early its mistakes. It actually had a fairly troubled launch: It reviewed much more poorly (with a 69 Metacritic) than WAR did (with it's 86 Metacritic). But nobody remembers that, because nobody was playing it. EVE corrected many of its problems while it still had a very small userbase of devoted players, before trying to reach out to a larger market. WAR probably made fewer mistakes with its launch, but it made them in front of many many more people.
What's especially impressive, though, is that many of those early adopters have been remarkably loyal to the game to this day. I saw an interview recently where CCP's CEO stated that ~20% of EVE's subscribers from its launch month (May 2003) are STILL subbed to the game.

This makes me think that a small launch strategy might be the way to go (although I doubt many other companies would have the discipline to pull it off).

[Did anybody else see that video? I'm having no luck finding it again.]

The part of the article that is haunting me, though, is the idea that it takes ten years for a piece of software to really mature. It struck me as a bit ridiculous at first, as something that only makes sense for something huge like an operating system. However, the more I think of it, the more examples I notice of games that fit this profile.

Ten year juggernauts

At first it sounds a little crazy that it would take a game 10 years to really hit its stride, but our first instinct is to only think of the time that a game has been live, not the years of development before release.

CCP was founded in 1997, and developed a board game "in its first three years" to help finance EVE. I can't find anything specifically stating when EVE's development began, but it seems to have been sometime 1999 or 2000. EVE is now a ten year old piece of software.

As of this month, so is World of Warcraft, according to Rob Pardo:

But if you do want to try to be that No.1 MMO, it's hard, because not only are you going up against the five years of development we had, you're up against five more years of development that we've had since the game launched.
I find this interesting because from what I've seen so far of the Catyclysm expansion and its revamp of all the old content, I think this will be the year that WoW finally reaches its full potential.


Team Fortress 2 is also a ten-year game. What we now know as TF2 began development in either 1998 or 1999, depending on how you look at it. The timelines on this one are a bit confusing, since TFC was actually a spinoff of an even earlier TF2 incarnation(!), and development may have been suspended for some amount of time, but ten years of linear time have definitely passed.

I also think it took until this year for TF2 to really grow into itself. The class balancing, new gameplay modes, unlockable weapons, and achievements would be sorely missed if the game were reverted to its launch day state. Once the final classes receive their updates next year, I expect the game to feel really complete.

Everquest II is an interesting example, because its launch was a bit rough but its live team is often said to have drastically improved the game in the years since then. I know some people who have tried or returned to the game recently and who have been really blown away by how much they like it.

I can't find any exact info about when development began, but Everquest's success resulted in the formation of SOE in 2000, I'm guessing that game will soon reach its 10 year milestone as well.

So, what do you think of all this? Does it really take that 10 years for these huge software projects to become great? Would you invest that much time into a game if you knew it could be as great as EVE, WoW, or TF2?

I'm beginning to think I would.

[Edit: Eolirin in the comments pointed me towards a great post on a similar topic from Bill Harris. I particularly like his term "inkblot" to describe the slow process of games gaining quality, players, and notoriety.]

October 25, 2009

Players (And Designers) Learn Faster With Tight Feedback Loops

I will never be good at Starcraft. Never ever ever. It's a great game, and fascinating to think about, but playing it against real people usually makes me quit in frustration pretty quickly. On the other hand, I'm great at learning new songs in Rock Band. My brain lights up like a Christmas tree every time I play that game.

This says a lot about my brain (great at music and sequential tasks, terrible at juggling multiple simultaneous tasks), but it also says something interesting about the nature of these two games.

When I make a mistake in Rock Band, the game makes sure I know about it that very instant: A piece of the UI shatters like broken glass, the audio for the note doesn't play properly, my performance meter goes down, and my note streak is broken. On top of that, notes show up hundreds of times per minute, patterns of notes show up many times per song, and each song is short enough that it can be replayed many times in an hour.

Because of this, Rock Band is one of the easiest games to learn. I don't necessarily mean that it's an easy game to be good at, but it is an easy game to get better at. If even the worst beginner sits down and plays the same song a few times in a row, their performance will immediately start improving.

Conversely, losing a game of Starcraft can take hours, and I can never really pinpoint where I went wrong. Something very early in the game, such as making the wrong number of harvesting units, or failing to expand at the right time, or deciding to progress down the wrong tech tree, can have adverse effects much later. This problem is also exacerbated by the fact that Starcraft, like most strategy games, is a slippery slope game.


Timely information feeds learning

Games like Starcraft and Chess, which can have long periods of time between between decisions and the consequences of those decisions, are very difficult for players to learn. This shouldn't be too surprising – any book on pet training, child rearing, or romantic relationships will tell us that a delayed reward or punishment for an action is confusing.

Your dog can't tell that the treat you just gave him is for the trick he performed 20 minutes ago, and your significant other will only be frustrated when you snap at them today because of something annoying they did last week. Gamers are the same way – the more immediate the feedback to their actions, the more quickly good and bad behaviors can become reinforced.

Strategy games obviously delay their consequences on purpose, and I'm not saying Starcraft should be redesigned to be more like Rock Band. However, I do think Blizzard could add in some sort of special learning mode that would notify the player in real time of mistakes that would not normally be apparent until much later.

If beginners could see status messages like “your economy is falling behind, try producing more gatherers” or “your factory has been sitting idle for x seconds” or “your opponent is producing tier 2 units already, time to upgrade,” it wouldn't help people become experts at the psychological aspects of the game, but it could help terrible players like me start to learn from their mistakes more effectively.

Feedback loops in game development

Just as players learn much faster by seeing the immediate results of their decisions, so to do game developers. If we don't see results for too long after making decisions, it's easy to forget what the other options were, which of our arguments and thought processes were flawed, or even who was responsible for a particular decision.

Worst of all, if a game takes too long to make, employee turnover becomes a problem. Bad people get fired, and good people leave for greener pastures. If the people who witness the results aren't the same people who made the decisions, only the most disciplined designers will manage to glean any useful lessons.


Show me a game designer who has only released code to players twice in ten years, and I'll show you a mediocre designer who is learning much more slowly than they could be [unless they were constantly playtesting that whole time]. Most of the best designers I know have shipped many games in a short period of time, started out on live games where changes are released almost immediately, or worked at studios that are constantly letting people playtest their work before the game ships.

Like all designers, these people started out with a lot of wrong thinking about how to make games, but they very quickly had their bad ideas shattered and their good ideas reinforced. Just like Starcraft, success in game design is a slippery slope. The first year of your career as a game designer sets the trajectory for everything you will ever do, and if a player never even plays one of your designs until your 3rd year in the industry, you've already fallen behind.

For those of you looking to start careers in the game industry, try cutting your teeth on a live team or expansion pack team. Experienced designers usually choose to move off of these teams for the exciting new project, and as a result they are more open to newbies. Likewise, starting out by working on games with very short production cycles is another good option.

The average game project is getting very small these days, so it's a perfect time to start out as a new designer on an iphone game, flash game, facebook game, or live MMO. Shipping a lot of games now will give you the accelerated learning you need before tackling that masterpiece later.

September 30, 2009

Designing Your Audience

Last week, I made a comment that I should have realized would need some explanation:
Learn to recognize which parts of your game and playerbase aren't important. Your favorite part of the game may be something the playerbase doesn't care about, and there are some players who care about things that it isn't in your best interests to focus on.
I probably shouldn't have mentioned this in passing before I had a chance to do a longer writeup on it. That's a fairly sinister-sounding quote, after all.

So what did I mean by this? Why wouldn't I want to just always make all of my players happy all the time? The short answer is that's exactly what I do want. The longer answer is that if you end up with too many different groups of players who want opposing things out of your game, you'll eventually arrive at a situation where any decision you make will anger one of the player camps.

Aside from bugs and generally shoddy development, the biggest cause of /ragequits is developers and players not agreeing on what the game is supposed to be:

Players thought it was an RPG with FPS elements, developers shipped an FPS with RPG elements. Players thought the game was supposed to be mostly grouping with some soloing, developers preferred mostly soloing with some grouping. Players expected open world territorial control PvP, developers implemented consensual sport PvP.

These are very small differences in opinion that don't matter at all, until they matter more than anything and all your players have quit.

Just like every other aspect of the game, your playerbase must be carefully designed and crafted. Here's how:
1 - Know what game you're making, and for whom
If your design team can't agree on what the game's about, how can your playerbase possibly be expected to agree with your design team?

Your gameplay will determine which players will enjoy your game, and which players you intend to enjoy your game should be the driving force in all your gameplay decisions. It's not important whether you start the game with an idea of the players or an idea of the gameplay, it's just important that they both support each other.


If you wait until you have real players to start trying to make them happy, it's already too late. The game has to be tailored to the audience before the audience even exists. This can be challenging, but there are lots of shortcuts.

You can do it by treating some designers as spokespeople for the player groups you expect to have, you can define a set of archetypes that you keep in mind while designing, you can write user stories, or you can just try make a game for another game's audience and steal them.

It doesn't matter how do you it, but you have to figure out who your players will be and what game they'll want in time to actually start making it.
2 - Keep your design focused
Feature creep is arguably the worst problem in the game industry, as well as the software industry as a whole. It causes financial problems and scheduling problems, and it also causes a fragmented playerbase.

Sprawling game designs such as RPGs are the most prone to feature creep, which in my opinion explains why so few MMO gamers are actually happy. It's incredibly difficult to support divergent gameplay styles in a way that doesn't result in each style's features harming the other's gameplay.

For example, Blizzard has enough resources to put huge amounts of effort into both PvE and PvP, but even they barely pull it off. WoW players are constantly arguing over which type of gameplay that game is supposed to be about, or angry that one is receiving more content, better itemization, relevant balance changes, etc.

The best way to avoid feature creep is to make a firm choice as to what game you're not making, and which audience you're not trying to appeal to.

By adding every feature under the sun to your game, you might attract more players, but I can guarantee you that those players will be less happy. Think about whether you want to have a huge audience of unhappy players, or a small audience of happy players. It's a trick question though, because unhappy players quit, while happy players multiply.


3 - Market your game honestly
Stop giving players false hope. If you know that your game isn't a PvP game, isn't a solo game, isn't a crafting game, etc, all you have to do is make that clear up front. Nobody wants to be the bad guy in the dev chat who tells all the nice crafters and all their nice money to take a hike, but it's much better than leading them on and then disappointing them.

If you feel ashamed to tell your players honestly what your game is about, that's a pretty great sign that you game isn't about the right things.
4 - Dance with the ones that brung ya
Once your game has players who aren't on your dev team, it's too late to change what game it is. You can only make it a better and better version of itself, even if you screwed up and made the wrong game.

Once players are playing your game, even for free, they've invested themselves in it. Players always talk about how they've paid money and deserve a service, but that's not actually what's making them mad. Once they've invested their time and attention in a game, they've given you something much more precious than their money and you've reached the point of no return.

Even when you've designed and marketed a game for a specific audience, you'll still have some players from outside your audience show up and try it out. These players will be mad that the game isn't a game for them, and demand that you change it. Sometimes you can accommodate them without alienating your existing players, but sometimes you just have to have the self-restraint to allow them to quit.

I'm hugely impressed by CCP's new game Dust 514. After being assaulted for years by complaints of EVE not being exciting enough, CCP didn't cave in and dilute their game to include those players who were outside of their intended audience. They made an entirely new game just for those players. This is a perfect way to make a new group of players happy, without that gain in happiness costing some happiness from another group.


Time to pick on poor SWG

Star Wars Galaxies is an example that's been beaten to death, but for good reason. That game suffered from all of the problems I've mentioned here. It tried to support every style of gameplay there is, from politics and city management to crafting to avatar combat to dogfighting in spaceships.

It was seemingly designed for fans of every part of the Star Wars universe but the movies, and then inevitably marketed to people who had only ever seen the movies. Once its audience was distilled to only people who really liked SWG's gameplay and everyone else had quit, the devs decided to try and fix their mistakes.

They rereleased the game with a new design that would appeal to all of the players who had quit (who wanted it to be more like the movies), except those players didn't really care anymore. The loyal players who had remained rightly felt this was a slap in the face and began quitting in droves.

The new Star Wars game seems to have much more in common with the failed SWG revamp than it does with the original SWG. The funny thing is that this time around everyone is incredibly excited about it. This is because we can all tell what that game is trying to be, and hopefuly because it's being marketed honestly.

Nobody wants their players to quit, and it's always a bad thing to make any of your players unhappy. However, if you let your design get too diluted and your playerbase get too fractured, you'll end up in a position where it's unavoidable.

If you decide which potential players are and aren't important long before the game ships and market the game honestly, then you'll never have such a divided playerbase that you have to make those kinds of tough calls. This hopefully also means you won't see so many players /ragequit.

September 17, 2009

How A Designer Thinks

Eric and Sandra over at Elder Game run what I consider to be the best blog on MMO game design, and one of the best game design blogs in general.

Sandra just posted a succinct piece of advice about another, possibly too-succinct, piece of advice: "think like a designer."

This is a very important piece of advice, and I've seen many aspiring and even experienced designers fail interviews for being "too playerish" or "not designerly enough." But what does that mean exactly? Here's Sandra's post:
“Learn to think like a designer, not a player.”

You’ll hear this a lot from game developers giving advice to would-be designers. And it’s not wrong … but taken at face value, it leads to being a sub-par designer. There’s no value in mimicing what you think a stereotypical designer would do.

Better advice: “Learn to understand how different types of players (including you!) experience your game, and analyze that like a designer.”

Not nearly as memorable, but way more accurate.

There's still something missing

Sandra has a great point; considering your whole playerbase is very important. I think there's one more detail that both versions only hint at: Think about your whole game. This is implied by "think about your whole playerbase," but it's so important that implication alone doesn't do it justice.


In my experience, taking a high-level view is especially difficult and important for designers of MMOs and other large, multifaceted games. We have so many competing features, playstyles, and subcommunities within our games that it's very easy to get hung up on just a small set.

Here's what "think like a designer" means to me:
Learn to think about your game and playerbase holistically. The classes, features, and gameplay style that you enjoy are only a small part of what is important to the playerbase as a whole.
We spend so much time as designers reminding ourselves to be detail-oriented that thinking of the game as a gestalt is sometimes easy to forget. Balancing between these two competing modes of thinking is what can really make a designer great.

Speaking of more advanced design thinking, I think this advice also comes with a counterintuitive but important corollary:
Learn to recognize which parts of your game and playerbase aren't important. Your favorite part of the game may be something the playerbase doesn't care about, and there are some players who care about things that it isn't in your best interests to focus on.
That may sound a bit mean or negligent, but there's no faster way to game design failure than trying to please everyone. If you can learn to tell what's not important, you'll be a better designer than just about everyone in this industry. Much more on that subject another time.

All this advice rolls off of the tongue less trippingly than "think like a designer," but it's a great point that we often give people important advice without bothering to clarify what our advice actually means.

September 13, 2009

The 3 Flavors Of Enemy Design

I hadn't really noticed it, but I seem to avoid writing about whatever sort of design I'm currently doing all day at work. The past few months are the first time in my career that I haven't been involved in designing AI or enemies, so I find myself wanting to write a few posts about that.

When deciding on a high-level design for the opponents in your game, it helps to decide first which of the 3 major groups you'd like your enemies to fall under:

1 - Enemies that follow the rules

There are many games with AI opponents that never do anything a player can't reasonably be expected to do. This type of enemy is often referred to as "bots" and used as a substitution for players in games that are multiplayer-focused.

With good enough AI scripting, it's possible to make enemies that mimic real players, with the same abilities, limitations, and even behaviors. Playing against AI is never exactly the same as playing against a player, but they can definitely feel similar enough to feel like good practice, to a point.

In this sort of game, players will feel cheated and angry if the AI does anything that they can't do themselves.
Examples:
Chess, Starcraft, Madden, Unreal Tournament, Street Fighter, Poker, Battlefield 2142
When to use them:
This sort of enemy works really well as a way of easing players into the game and preparing them for matches against real human opponents. For this reason, it generally make sense to tune these enemies to be clumsier and easier to defeat than a human would be. Despite that, these enemies are generally the kind that make the most sense to have a high level of awareness.

It's also possible to make very very challenging AI settings for people who can't find a human partner that can challenge them, but chess is the only example I can think of where this is very common.

2 - Enemies that break the rules

There is a similar class of enemies for whom breaking the rules is a possibility. They tend to have most of the same abilities as a player and generally seem like players, but they will occasionally break the rules in the service of modifying difficulty.

It's certainly possible to make AI cheat to be more difficult, but good designers also make them cheat downward, which is to see start losing a little bit on purpose if they get too far ahead. This is also known as rubberbanding, a form of negative reinforcement.
Examples:
Many racing games, many strategy games (most notably the Civilization series)
When to use them:
If you're thinking of your AI opponents as a replacement for other players, rather than a training tool, it might make sense to allow them to break some rules. This sort of AI design tends to focus a bit more on matching the player's ability and making sure that the game is challenging, but not too challenging. It can ensure that the player always feels they have a chance to win (or lose) right up to the end of the game.

3 - Enemies that ARE the rules

The most common type of enemy, by far, is that which operates in a completely different realm from the player. This type of enemy not only operates outside the set of game mechanics that the govern the player, but actually becomes a part of those mechanics.

Games that use this type of enemy design tend to have many different types of enemies, which vary from location to location. This enemy variation becomes a part of the game's content and level design palette.


It's also very common for games to use this sort of enemy design in boss battles, where there tends to be a puzzle to solve, a weakness to exploit, or a pattern to memorize. Unlike the previous two enemy types, this sort of opponent is not used to teach the player how to play against other players.

In the most extreme examples, the entire gameplay of a game can consist of learning how to defeat new and varied enemy types, in increasing numbers and more complex combinations.
Examples:
The God of War series, the Diablo series, the Halflife series, World of Warcraft, the Zelda series (especially their boss fights), the Super Mario series, the Ninja Gaiden series, the Metroid series, almost all shoot-'em-ups, and on and on.
When to use them:
My guideline for when to use this sort of enemy is when you'd like to present players with a more reactive form of gameplay, where they change their tactics based on which enemies they are fighting.

It also works well in games that are very content-heavy (shooters, RPGs). In games like this, enemies that try to fight like players are likely to become monotonous over time, or much easier as the player figures out all of the AI's tricks and shortcomings.

Should you combine enemy types?

Generally I'd say that it only makes sense to have one kind of enemy in your game. If you've got a really good reason, it can make sense to combine them, but there aren't very many examples I can think of.

Champions Online's enemies are almost entirely the third type (totally seperate rules), except for player Nemeses, which are the first type (same rules as players). Time will tell if this was a good idea, but the rationale of using Nemeses to prepare the player for PvP seemed like a sound one, and Nemeses were already very special and seperate from all the rest of the enemies in the game.

September 5, 2009

The Hierarchy Of Awareness

I've done a huge amount of work on AI scripting and tuning over the years, and in the last year especially I've been thinking a lot about the different characters of NPCs: What kind of AI makes an NPC seem more or less frightening? What kind of AI makes an NPC feel more or less human?

I think the following 6 levels of AI awareness describe the difference between a very stupid, inhuman AI and a deviously frightening opponent that seems to think like a human.
Lvl 0 - I thoughtlessly follow a routine
Before there was any such thing as AI in games, we generally just dealt with completely scripted enemies that followed set movement paths and attack rotations.

Some examples that spring to mind are the aliens in Galaga and Koopa Troopas from the first Super Mario Brothers game. In modern games, it's generally not likely to see this sort of opponent except for "inanimate" objects and environmental hazards: moving sawblades, laserbeams, etc.

[Some stealth games and RPGs do put enemies on a predetermined patrol as the most basic part of their scripting, but since they change their behavior when they detect a player, they aren't truly Lvl 0 opponent.]

 
Lvl 1 - I blindly pursue a single goal
The racecars in Pole Position and the Hammer Bros from Super Mario are enemies that want something: they want to get to the finish line or throw a projectile toward wherever you're standing. They don't do anything but try to complete that one goal. This is really the most basic form of AI scripting.

[The ghosts in Pacman also mindlessly chase you at first, but they pay attention to whether you've  become able to kill them or not, which gives them a higher level of awareness than Lvl 1 enemies].

Lvl 2 - I think about only myself
These are NPCs that can change their behavior based on their own current state. If an enemy heals itself when its health is low, or tries to escape combat when outnumbered, they're thinking about themselves. Same goes for any enemy that realizes they have some sort of buff or invincibility and behaves more aggressively as a result.

There are lots of NPCs in games that heal themselves, self destruct at low health, or try to run away. World of Warcraft has examples of all 3 of these mechanics.


Lvl 3 - I think about other people
This is the level at which some NPCs can start to seem to have some personality or even deviousness. When a character in The Sims refuses a hug from a smelly person, or a group of enemies in Starcraft focuses fire on a damaged opponent, their AI is making decisions based on the state of another entity.

Another variety of this type of AI will change between offensive and defensive modes based on how much damage they take, or build "hate" or "aggro" toward enemies that damage it the most or in certain ways. This model is now extremely common in RPGs.

[Depending on how you think of it, the ghosts in Pacman that switch between chasing you and being chased are either thinking about themselves or other people. They either realize they are vulnerable or that their enemy has become invulnerable, but in this case the effect is the same.]


Lvl 4 - I think about what other people are thinking
Now, imagine if the ghosts in Pacman could calculate that you were trying to get to one of the power pills that would place them in danger, and start running early, or hug the center of the map. If they saw that a pill was already used up in an area, they would be much more bold. Suddenly the enemies in that game would feel much more intelligent, and be much more difficult to defeat.

AI that thinks of what a player's goals are and reacts to them are the approximation of a mediocre human opponent. Chess bots are the first thing that comes to mind when I think of this kind of AI.

Also, enemies in fighting games that try to predict the player's next move and preempt it are also on this level of awareness. If the fact that I've been playing more offensively causes an enemy to play more defensively, they're making decisions based on the fact that I will probably decide to keep attacking.

[I'm not sure if this is how the AI in fighting games actually works, though]

Lvl 5 - I think about what other people are thinking about me
This level of awareness in AI is pretty rare, mostly reserved for chess bots, RTS armies, and fighting game opponents. This is essentially AI that can trick you.

If a chess bot lures your bishop out of the way with a pawn so that it can capture your queen, or an enemy in an rpg feigns death until you let your guard down, these are all tactics based on making the player think something that isn't true.

Likewise any AI that has the ability to bluff and try to scare away a player that could actually attack them falls under this same umbrella. Generally I'd only expect to see this sort of thing in poker or strategy games.

Imagine in an RPG if enemies that have detected you in stealth didn't immediately go "HUH?" and look at you, but just subtly tried to walk toward you without indicating that they'd seen you. They'd use the fact that you thought they hadn't seen you to get in close before ambushing you at the last second. This sort of AI would be incredibly scary and make players very paranoid.



Human opponents and Yomi Layers

AI with an awareness level of 4 or 5 are generally the best way to prepare players to face off against human opponents, but they still aren't as dangerous as a real person. It's amazing how many more layers of deception human players are capable of, often without even realizing that we're doing it.

Check out this great article by Dave Sirlin about what happens when I start thinking about what you're thinking about what I'm thinking about what you're doing (and beyond). He refers to this as Yomi Layer 3, and apparently in competitive fighting games it's common for players to think about Yomi Layers 3, 4, and even 5.

The term "Yomi Layer" is probably new to you, but it describes a concept that should be very familiar if you've ever seen the The Princess Bride.

August 29, 2009

Glossary

I believe that defining terms is a very important step for game designers. So many of the concepts we deal with are so abstract and malleable that they can be interpreted in almost any way. The most basic description of our job is "making fun," and yet I've yet to see two designers agree on exactly what that word actually means.

Because of this, I think it's important to agree on definitions of terms in the context that you're discussing them, so that subjectivity doesn't become a problem. These glossary posts should help clarify some of the more specific terms I employ when discussing game design.

I'm not suggesting that these are neccessarily the "right" way to define these terms, but they are the ones that work best for me. I find it's much less important that a definition be correct than that everyone in a discussion have the same definition in mind.
Diminishing Returns
For any efficiency, the tendency of increasing costs to be less effective at increasing rewards. Diminishing returns may only apply above a certain cost level, or they may scale over the entire range of possible costs.
Efficiency
The ratio between the cost of an action and the perceived value of its reward.
Essentialism
1) Assuming something to be an absolute truth when it is only true in specific cases.
2) Mistaking correlation for causaulity as a result of such faulty logic
Fiction
The usage of metaphors to present game mechanics and gameplay as a cohesive and logical whole.
Game Mechanics
All stimuli the game presents a player with, in the hopes of encouraging or discouraging certain gameplay.
Gameplay
Anything that a player does or thinks as a direct or indirect result of a game's mechanics.
Narrative
A game's plot or story. This includes the conflict, specific characters and their arcs, the backstory of the world, and the happy ending.
Productivity
The amount of rewards generated in a particular span of time, regardless of how efficiently those rewards were generated or how much effort and resources they cost.
Productivity = (Effort x Efficiency)/Diminishing returns