Mike Darga's Game Design Blog

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

2010-02-28T13:09:00.000-08:00

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.

8 Posts You've Probably Never Seen

2010-02-01T23:42:00.000-08:00

Today my best friend told me that I'd better start blogging again soon, because I get all antsy and stressed out if I go too long without writing. He's totally right.

All kinds of crazy and scary and exciting things have been sucking up my time and brainpower, but I see the light at the end of the tunnel now. Here's a little half-post to try and tide me over in the meantime.

These posts were all written when <10 people were reading the blog. Some of the stuff from that time is probably better left unseen, but I still like these well enough.

They also include some good advice to myself that I could use a reminder of lately. When I'm feeling overwhelmed is the most important time to stay calm and work smart, but also the most difficult time to remember that.

3 Common Pitfalls For Design Teams

3 Design Guidelines That Will Improve Any Game

You Are Always Teaching Your Players

Collaboration Advice For Distributed Teams

Perfectionists Don't Want To Learn

Think More Like A Scientist

Your Easy Tutorial Is Ruining Your Game's Difficulty Curve

Players Care About Functionality, Not History

How Valve Is Designing Their Community's Behavior

2009-12-17T02:55:00.000-08:00

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.

One Year And Thank You

2009-11-28T19:14:00.000-08:00

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.

Do Great Games Take A Decade?

2009-11-19T00:47:00.000-08:00

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.]

Players (And Designers) Learn Faster With Tight Feedback Loops

2009-10-25T16:40:00.000-07:00

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.

Designing Your Audience

2009-09-30T23:24:00.000-07:00

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.

How A Designer Thinks

2009-09-17T21:05:00.000-07:00

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.

The 3 Flavors Of Enemy Design

2009-09-13T14:45:00.000-07:00

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.

The Hierarchy Of Awareness

2009-09-05T02:09:00.001-07:00

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.

Don't Waste Your Fiction

2009-09-03T20:46:00.000-07:00

I read today on Rock, Paper, Shotgun about an experiment that sounded like a brilliant idea. A group of researchers created the same game twice - once as a completely abstract set of game mechanics, and once with a fiction and narrative layered on top of those same mechanics.

I thought this would be a perfect illustration of how a game's fiction helps to contextualize a game's mechanics and to inform gameplay.

I tried playing Woosh (the abstract game) and was intrigued. I was a ball that had to roll around and get to a certain point in the map to pass each level. To do so, I had to grab onto little widgets, which started a laser shooting through a patch of red fog. Depending on which way I carried the widget, and (sometimes) how fast, the laser would move up and down. Then I could solidify the laser's path into a platform and roll up it.

I was pretty excited to see how Waker (the game with a fiction) would contextualize such a strange set of mechanics. But then it didn't, at all. It turns out that game is about grabbing onto little widgets to shoot a laser shooting through a patch of fog that changed direction etc etc. The only difference is that instead of a ball you are now a cat, and instead of a door, the exit of each level is a piece of a little girl's dream. The game mechanics are every bit as abstract as in the other game.

Waker presents an interesting story of having to rescue a girl from a dream she can't wake from, and some lovely audio and visual ambiance. But it doesn't try, even a little bit, to explain why the mechanics do what they do, or to clue me in on the kind of gameplay that will be successful. Why does that laser thing move the way it does? What makes it solidify? Why does running left sometimes make the beam lower, and sometimes make it raise? Why does "dying" to different hazards teleport me to different points on the map?

Let your gameplay drive your fiction

The more simple your game is, the more difficult and dangerous it is to try and fit mechanics to a fiction, instead of the other way around. What would have made sense for this sort of gameplay?

For the mechanic of moving up and down based on the player's left-right position, it might have been interesting to make the game about a very heavy character. If the entire level tilted right and left as the character moved across it, and the laser maintained its direction, it would immediately be clear how to manipulate the laser.

For the mechanic of moving faster increasing height, there are plenty of examples from actual physics. If the player were pulling a kite or a plane or a parachute, that mechanic would be instantly recognizable and intuitive.

Why does the path of the laser become a path? It could be exhaust from the plane that freezes, a sawblade that cuts off the tops of walls, an underground drill that makes a tunnel, almost anything.

None of these are million dollar ideas, but I think they illustrate how even the flimsiest justification of a game mechanic is better than none at all. We should never miss an opportunity to help our players feel more comfortable inside the logic of our games.

Glossary

2009-08-29T14:07:00.000-07:00

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

Career Lessons This Recession Has Taught Me

2009-08-23T18:04:00.000-07:00

The economy is terrible, unemployment is up, and all we hear is doom and gloom. Despite all that, a lot of game developers I know are suddenly thriving. In many cases, these are people who weren't doing particularly well before the bust.

The bad economy has turned into a great windfall for those people who have learned and applied the lessons it has to teach us. Here are some of the ones I've learned:

Nobody is looking out for you

It's so easy to be complacent when things are going well - an ok raise, a decent project, and a mostly-not-terrible boss are all it takes to keep most people sitting in the same job for years.

When companies cancel bonuses, skimp on raises, and generally freeze advancement, it suddenly becomes much easier for us to see that we need to look out for ourselves. Since the economy got rough, several of my friends (and myself included) have switched companies, gone solo, or started side projects. Every one of us wishes we'd have gotten the nerve to do it sooner.

Be generous when networking

While you're at it making opportunities for yourself, take the time to give some help to those around you. Helping out other people in their careers feels great, especially when things aren't going so well in your own career. Even the lowest person on the totem pole at a game company can kickstart someone's career by forwarding along a resume to the right person.

As I've mentioned before, I think people worry too much about networking with people who are in positions of power. If you surround yourself with people you respect and enjoy working with, and help them succeed, the results will be positive one way or another.

Don't assume people will be able to return the favor (again, you're the only one looking out for you), but often helping other people goes hand in hand with helping yourself. You never know where your next opportunity may come from.

Market your differences

If there's anybody whose career is legitimately doomed by all this mess, it's the unremarkable developer. That person who's got a little bit of experience, has adequate skills, is a nice enough guy, and worked on that kinda alright game always seems to be the one who falls through the cracks.

When it comes down to who will be promoted, who will be laid off, or who will be hired, companies always seem to give the short end of the stick to the average, forgettable guy. Don't be one of these people.

The industry right now is a great place for seasoned masters, mad geniuses, and eager neophytes. If you've been around awhile or are just really good, you can get that hefty salary even in a recession, because people don't want to take any chances. Sell yourself as the guy who can do the work of 3 mediocre designers for only 1.5 designers' worth of salary.

Likewise, if you've never had a game job before, there are companies eager to hire you too. You can learn the ropes, be molded to the kind of employee they want, and by corporate standards you're effectively free.

Just be honest; If you're a newbie, you'd better not try to represent yourself as something else, because people will see right through it anyway. By the same token, desperate veterans who try to pass themselves off as a bargain will also look very suspicious to a hiring manager.

Fear breeds mediocrity

Don't let this bad situation paralyze you with fear. There's a lot of "I'm just lucky to have a job at all" and "I'm sure if I worked somewhere else I'd be just as frustrated" going around these days, no to mention some "I'm just going to keep my head down and get through this."

All of these sentiments are completely rational, but nevertheless the kind of thinking that can turn you into that nice guy whats-his-name who's unemployed. Fear is always the enemy of a successful career, it's just harder to see in prosperous times when even the unsuccessful people are still doing ok. In times like these, the difference between successful and unsuccessful careers can mean the difference between having or not having a career at all.

If we can succeed in such a hostile job market, imagine how well we'll do when we take these lessons and apply them in a booming economy. Meanwhile, the best defense is a good offense. In short, it's hustle time.

My Interview with FanToPro.com

2009-08-09T10:52:00.000-07:00

Steven Savage is one of those amazing bloggers who is constantly churning out good content, speaking at conventions, podcasting, the works. In short he makes me feel like a slacker. His site, Fan To Pro, is a career blog that focuses particularly on turning that hobby you love into a paying gig.

Steven asked me a few questions related to my own transition from game fan to professional designer. In the interview, we talk about breaking in, networking, mentoring, and how game design careers are evolving.

1.Do you have any interesting insights to share on your career in gaming that may help people who want to break into gaming? How did you get in, why, what worked for you, and how did your hobbies/interests play into it?

I originally went to college as a music major, and then bounced around a bit before deciding what I really wanted to do. Once I decided I wanted to be a professional game designer, I decided to get a degree in writing, which I peppered with as many electives as possible in media, design, art, and technology. I got a design internship with Maxis (now EA) working on Sims games, ended up staying there full time for a few years, and now I'm a combat designer for online games.

All you need to be an entry-level game designer is to be smart, love games, and work well with other people. You needn't have shipped a game to make a game, no matter what the job description may say. All people want is some assurance that they're not hiring somebody terrible. The best way to ease employers' minds is to have some good games on your resume, but there are other ways. You can make some games in your spare time, do some internships, or both.

Internships are short term, low risk investments for employers. Interns come with an expiration date, so there's a minimum of fuss if they decide they don't like you. On the other hand, people tend to expect so little from interns that it's very easy to be impressive. Do as many internships as you can! I only did one game design internship. If I was smart I'd have interned at 4 different companies throughout college so I'd have had more prospects and be able to negotiate my first salary more.

When you're in college, you can skew your education towards your passion, even if no obvious game development classes exist at your school. Most professors these days love assigning free-form projects and papers, because they recognize that people do better work when they're working on something they care about. I worked on software documentation and internship applications in my writing classes, designed game interfaces in my usability classes, and analyzed games for papers in classes on gender, media, culture, economics, and psychology. You can forge your own path, and most professors are happy to help you do so.

Also, make sure you spend a lot of time working on group projects and making games with other people. Yes, it's easier to just work alone, but game development is all about collaboration, and group projects are the best way to practice for having a real job. Whenever I interview someone who has made a bunch of games all alone, I worry that they must be a selfish prima donna who'll be no good at working on a team.

2.Do you have insights on any other career areas?

Game design is a great job for people who are generalists; game design, writing, and acting are the only three jobs I can think of where just about any experience can come in handy. Great game designers come into the field from all sorts of backgrounds. I've worked with designers who've had previous careers in scientific, musical, theatrical, literary, artistic, military, and culinary jobs. I even know one designer who used to be a city bus driver.

It's not that any of these careers is the ideal training ground for a budding game designer, but the kind of people who make good game designers are the kind of people who soak up knowledge wherever they go, and make a point of applying that knowledge to new situations. This is a critical behavior when playing games, and I think people who make a habit of thinking critically in their daily lives are much better at manufacturing situations that allow players to do so.

In particular, I think game designers can never know too much about psychology. Fun is something we can never directly give players. We have to and allow empower them to construct it for themselves, using the tools we provide. Players do whatever they want, and the concept of fun is defined and experienced entirely in their heads. Designing a game that will cause players to have fun is like designing a room that will make people tango.

Developers ship games all the time that we think are fun, and then we don't understand why our players and reviewers don't have fun playing them. There's a saying in the industry that you can't ship yourself with the game. If only we could walk into each player's house and help them learn the controls and what to do when, they'd surely start to have fun, but that's not how it works. We have to teach our games how to teach our players how to have fun, and ultimately that all comes down to psychology.

3.What role did/does social media and technology play in your career?

Most game designers probably spend less than half their time actually designing things in the traditional sense. The rest of their time is spent implementing those designs, creating and managing data, fixing performance problems, etc. Even the process of writing documentation can be very elaborate, if you're doing special things with a wiki, a database, or excel. It's a highly technical job, and depending on where you work it will require programming/scripting experience, or at the very least mastery of some proprietary tools and editors. Personally, I find myself frequently using small tools and scripts that I've written to automate parts of my work.

Social networking is something I've been notoriously grumpy about in the past, but I've been making an effort to utilize it more. I made extensive use of Linkedin in my last job search, and I do recommend that everyone at the very least make a profile there and keep it current. Even if you never do more than that, recruiters will start contacting you. By joining some relevant groups, I've participated in some interesting discussions, connected with new people such as yourself, and gotten some leads that ultimately led to job offers.

When I had to make a difficult career decision a couple of months ago, I was able to solicit advice from some game designers and creative directors who were a lot further along in their careers than I was. These were people I'd never even have met without my blog and Linkedin. It was very useful to be able to zoom out like that, and get a survey of opinions and advice that went beyond that of my close friends and coworkers.

Social media also teach us lessons that apply to games themselves, particularly online games which are a social medium unto themselves. MMORPGs, Steam, and Xbox Live all incorporate concepts of social networking technology, and in return they influence those same social networks. Linkedin profiles come with a score to tell you how complete your profile is, which is a concept right from videogames. Team Fortress 2/Steam let me look at a friend's profile, and see what achievements they've recently unlocked, or what new games they're playing, which is a concept directly taken from social networking sites.

4.What do you think is the best way to reach and encourage people interested in gaming careers? Is this extensible to other careers?

I really enjoy direct mentorship, when possible. I've found it very satisfying to train junior designers and interns over the past few years. My first boss in the industry (a great designer named Charles London), really helped point me in the right direction. Having someone like that at your first job can make a huge difference in your career, so I do my best to try and help people out the same way.

However, that's not a very efficient way to reach people. Part of the reason I started blogging is that I wanted to be able to reach a larger group of people and become part of the larger discourse on game design. As I mentioned earlier, Linkedin is also a great way mentor and be mentored by people you might never have met otherwise.

5.What role did networking and informal connections play in your career?

I'm pretty terrible at networking for networking's sake, although I do think I've gotten a bit better about it in the past year. Networking has become more and more important for me over time, but it's generally the sort of networking that happens naturally as a result of working with people you really like. I've got a group of people who I've loved working with, and would recommend for a job without question. Similarly, I have a group of people who I know would do the same for me.

What I think most people get wrong about networking is they become overly concerned with making friends with people who are already in positions of power. Networking can happen at any stage of your career and still be useful. A lot of my contacts in games are people I've known since before either of us worked in the industry - people from college, and even one or two from high school. If you surround yourself with skilled people whom you respect, it's inevitable that some of you will eventually become successful enough to help each other out.

6.What do you see the future of gaming careers evolving?

I think job descriptions, particularly in design and production, will become more well-defined. Design as a discipline is something that large companies like EA have only acknowledged on a wide scale in the past few years. Previously all design work was done by producers. Some companies have producers that do project management and schedule people, and others have development directors to do that work, leaving producers as quasi-designers.

Some teams have lead designers, some have lead developers, some have executive producers, some have creative directors, and some have all of the above. Creative directors at some companies work on many projects, and outrank lead designers and executive producers. At other companies the creative director works on only one project, and may be subject to direction from an executive producer. Some designers write code, some write stories, some do nothing but write design docs.

In short, this industry is still a big primordial mess. Different companies, or even different teams within the same company, completely reinvent the wheel when it comes to structure, process, project management, compensation, and career path.

What I hope will happen over time is that we'll start to learn from the software industry, which has been around longer and is much better at regulating itself as an industry as a whole. There is no right way to make a videogame, but there are many wrong ways and we need to stop blundering back into them over and over again.

I also hope that the industry, especially design, will manage to pry apart the two concepts of seniority and management potential. There are many great designers who are terrible managers, and many great managers who are terrible designers. Only a precious few people are good at both, and it's ridiculous to “reward” someone for succeeding at their job by forcing them into a second job, if they are not likely to succeed at performing it.

Stop Trying to be Productive

2009-07-27T23:35:00.000-07:00

I'd be willing to bet every game developer in the industry has worked or will work a 12 or 16 hour day at some point in their career. This happens because there's too much work to do and a big deadline coming up, and people find themselves desperately in need of ways to increase productivity. The game industry is rife with horror stories of mandatory 12 hour days and seven day weeks, aka crunch time.

It's also common for a team approaching a big deadline to suddenly become a black hole that starts sucking in developers from other teams, or absorbing other teams entirely. While I was working at EA, the Godfather team pulled in extra people from all over the company until it became monstrously huge. There are people who worked together on that game who never even met each other.

There's a reason things like this happen. Working more hours or throwing more people at a project does increase productivity, at first. The problem is, returns from such brute force methods diminish rapidly. Once diminishing returns kick in, efficiency takes a nosedive, ultimately hurting productivity. This might not happen for a few weeks or even a couple of months, but it will happen. Brute force productivity is simply not sustainable.

Don't forget, productivity = efficiency x effort. People who work 12 hour days are trying to increase productivity by increasing effort, but that increased effort can lower efficiency and cancel itself out. It's easy to get stuck in a negative feedback loop: focusing too much on productivity ultimately hurts efficiency and therefore productivity. In the long run this leads to people working under miserable conditions and not even getting any extra productivity out of the deal.

The path to true, lasting productivity is through efficiency, not effort. If you can manage to become more efficient (spoiler: you can), productivity will take care of itself. Focusing on improved efficiency allows people to either be more productive in the same amount of time, or to work less and get the same amount done. Even if people choose to work less, they'll become happier and more energetic, ultimately increasing efficiency even further.

Focusing on efficiency is a positive feedback loop, and the benefits can be huge. One investment of a week working on a usable development tool or a well-written design doc can pay off over months or even years of development.

Beware people who treasure productivity

Ironically, it always seems to be the people who pride themselves on their productivity that waste the most effort. People who focus too much on productivity will spend 12 hour days fighting against bad tools instead of spending 2 hours fixing the tools, or they'll reimplement the same feature 4 times because they didn't take the time to discuss all the details or write a design doc.

These people never want to "waste time" on things like meetings, documentation, or tools. They complain that these things take time away from doing "real work," and rightly so. Spending time on that sort of thing does hurt productivity in the short term, which is exactly why productivity is the wrong goal to have.

Don't get me wrong, some people have good reason to be wary of meetings and documentation: they've worked on a team where so much time was spent on process and meaningless meetings and overdocumentation that efficiency and productivity went right out the window. Improving efficiency has a point of diminishing returns to watch out for just like anything else, but in my opinion it's the lesser of two evils by a long shot.

Make the switch to efficiency

I learned the hard way what a red herring brute force productivity can be. I pulled allnighters left and right in college, and I brought those habits over into my work life once I left school. It actually took me a few years to realize how much effort I was wasting and to wean myself off of 12 hour days.

The funny thing is, getting more done in less time feels like cheating at first. Staying at work all hours and living like a zombie feels much more like Good Old Fashioned Hard Work, and it's hard to accept that you can go home while the sun is still up and still be productive.

Something that really helped me was to find a good compromise: I started working 10 hour days, but made sure that all my time after 8 hours was spent on something that would help my efficiency. I spent that time doing things like programming tools to help me get my work done faster, updating documentation, and mercilessly pruning my email inbox. Gradually I became efficient enough that I felt comfortable bringing my work day down to 9 hours, then 8.

The hardest thing for me to learn has been to push back on deadlines that would require work to be rushed out the door without being properly thought out. Redesigning and reimplementing work is one of the biggest wastes of time I've seen in the game industry. Take the time to get things right the first time, even if that means you've got to push your schedule out a few days. Iterate on whiteboards, on paper, and in meetings, when it's still free. The time you save in the long run will absolutely be worth it.

Glossary: Productivity

2009-07-19T15:30:00.000-07:00

Defining terms is an important step in the design process. There are some concepts for which I find it useful to create new or more specific definitions when discussing game design. See a collection of all glossary posts, here.

Productivity versus Efficiency

One of the reasons I feel the need to define things here before talking about them is that people love to take terms and twist them to mean whatever is most convenient.

Under its original economic definition, productivity is a synonym of efficiency: getting more done with the same amount of resources. Classic productivity was hard to achieve, so people craftily and unconsciously morphed the word into something that was a more easily attainable goal. Instead of efficiency, which was what being productivity used to mean, people just started using the term to refer to getting things done in general.

Usually when I hear people use the term productivity these days, they use it to refer to the fact that they got a lot done in a day or how busy they feel. I'm going to adopt this modified definition of productivity:

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

A great example of productivity and efficiency together is an automated factory. However, since productivity is an equation, it's possible to be productive without being efficient, as well as to be efficient without being productive. People who follow The 4-hour Workweek and other such methods attempt to get the same amount of rewards for much less effort, through increased efficiency.

On the other end of the spectrum, it's much more common to find productivity without efficiency. I used to work 16 hour days and 7 day weeks. I got a huge amount of work done, but work was all I ever did. I was being very productive, but at a huge cost. Therefore my efficiency was very low.

Glossary: Diminishing Returns

2009-07-12T13:50:00.000-07:00

Higher costs aren't always more rewarding

I haven't owned a TV for a few years, and I'm thinking about buying one soon. The other day I was at Best Buy, looking at their giant wall of TVs, and I started playing a game. I tried to look at the size and picture quality of each of the TVs, and try to guess how much they would cost.

As you can imagine, it was pretty easy to guess which TVs were the cheap ones and which ones were more expensive. Cheap TVs are small and don't look very good, and nice TVs are huge and look great.

What wasn't very easy to guess, though, was how much extra cost a given amount of size or picture quality would add to a price. On the low end of TVs, an extra 2 hundred dollars will buy you a much nicer, much better looking TV. On the high end, though, two TVs of the same size might have a price difference of a thousand dollars or more just because one has a slightly faster refresh rate or a higher contrast ratio.

At any given time, there is only a finite range of mass-market TV technology. If I decided to spend $10,000 on a TV, the difference in quality that TV would have over a $5,000 model would not be nearly large enough to be worth it, and that $5,000 TV is probably only somewhat nicer than the $2,500 model. This is a perfect illustration of diminishing returns:

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.

Different efficiencies diminish differently

The four kinds of efficiency that I defined the other day all have their own dangers when it comes to diminishing returns.

Process efficiency, my favorite type of efficiency, attempts to gain greater rewards from the same amount of resources by way of improved methodologies. This is very useful to a point, but teams that overdo it tend to find themselves in incredibly rigid structures that can start to take more time and energy to participate in than they save.

Improving volume efficiency by decreasing costs can be very effective, but eventually the amount of quality lost to increase costs further will begin to become an obstacle. Even free games will have a hard time getting players if their quality drops too low.

Piggyback efficiency can be improved by generating more and more rewards from the same set of resources. Making more spinoffs and expansion packs and ports is a great way to improve piggyback efficiency, but doing it too much can earn your franchise a reputation for making games that are just the same code rereleased every year, and begin to hurt sales.

Luxury efficiency, with its focus on spending extra costs to achieve higher quality, starts requiring more and more time and resources to create any measurable difference in quality. If a game company can make a game with a Metacritic score of 80 in 2 years, and a game that gets a 90 in 4 years, how much more time would it take to reach a score of 100? Eventually, spending more time and money may eventually stop improving the game at all, or even result in it being cancelled.

Diminishing returns in game development

Every rewarding activity can be expressed as an efficiency, and every efficiency is subject to diminishing returns of some sort. Diminishing returns come into play very often both for those creating a game and those playing it.

For both developers and players, practicing something returns huge skill gains at first, and then diminishes to very small skill gains as a high level of expertise is reached. This is also known as the learning curve.

When thinking about a problem for too long in one stretch, it takes a lot more effort to have a good idea. In this case, the diminishing returns are caused by simple fatigue. Working 16 hour days and pulling allnighters, two bad habits of game developers, are doubly damaging. These types of diminishing returns not only cause a drop in efficiency for that day, but they also cause sickness and low performance on subsequent days, lowering efficiency even further.

Diseconomy of scale, known to most people from its description in the book The Mythical Man-Month, refers to the tendency of larger groups of people to be less efficient. This can be seen both when developers try to throw more people at a project to get it out the door, as well as in the difficulties players have organizing 40 person raids.

There are also technological diminishing returns. How much more effort should be spent on the rendering technology of a game before those hard-earned rewards become hard to notice?

Diminishing returns as a game mechanic

Diminishing returns are also a great tool that game designers can use to keep any particular behavior from becoming overpowered or exploitive. They're particularly useful in combat balancing, but there are also some more general uses.

City of Heroes and World of Warcraft both use diminishing returns as a PvP combat balancing tool, but both use them in a different way. In CoH, there are diminishing returns on how effective various stacked buffs can be on different classes. After a character is already buffed, subsequent buffs are less effective.

In WoW, the durations of control effects become diminished if a character is affected by more than one in a 15 second period. If a player is stunned and then stunned again, the second stun lasts only 50% of its normal duration. A third stun lasts 25% of its normal duration, and the fourth stun won't be applied at all.

WoW's rest XP system is really just a disguised form of diminishing returns, in that players become less effective at gaining XP if their playsessions last too long or are too frequent.

Glossary: Efficiency

2009-06-29T09:50:00.000-07:00

Every reward comes with a cost

Writing this blog has been very rewarding so far, both personally and professionally. Writing about game design helps me clarify my thoughts, makes me a better writer, and helps improve my game design skills. It's also been a great way to make connections with other designers, and to market myself in a tough job market.

Blogging is financially the cheapest hobby I've ever had. I already had a computer, and an internet connection, and Blogger is free to use. However, blogging can cost a large amount of time and energy. Every post I write costs some time to write it, and an idea for a post, which is usually generated out of some time playing games, making games, reading, or discussing design.

Blogging about games is a good choice for me from both a rewards standpoint and a costs standpoint. The rewards it offers me are rewards that I care about a lot, which makes any time I spend working on this blog time well spent. On top of that, many of the costs it requires are things I'd already be doing anyway: I play games for fun, make games for a living, and enjoy discussing design with my friends and colleagues. I even kept a journal of design notes for years before starting this blog, which means that all it really costs me is the time to write the posts.

Because it doesn't cost me much additional effort to create this blog, and the rewards it generates are things I value highly, blogging about games is efficient for me:

Efficiency: The ratio between the cost of an action and the perceived value of its reward.

Not all rewards are valuable to everyone

All our resources (time, money, energy, concentration) are finite, so it's not enough to generate rewards. We have to make sure that the rewards we're generating are rewards we care about. Which of course means we have to know what it is that we really care about.

It wouldn't be a great idea for my brother to write a game design blog. He's not a writer, plays few games, and has no background designing them, so the time cost of writing a game design blog would be very high for him.

But even if he could snap his fingers and magically have a game design blog, the rewards it would give him aren't rewards he particularly cares about. He has no real desire to make games for a living. He's training to be a police officer, so the rewards of writing a game design blog would seem very low to him. In other words, my brother wouldn't find writing a game design blog to be an efficient use of his time at all, even if he could magically do it in 5 minutes per day.

4 kinds of efficiency

There is no recipe for efficiency. It's more like an equation, in that there are several different inputs and outputs, all of which can vary. There are different ways to achieve lower costs, or to achieve greater rewards, and in an ideal situation both can be achieved at once.
1 - Process efficiency
My degree is in writing and I've been writing for a long time, but unfortunately the process of writing is something that takes me a lot longer than I'd like. There are some amazingly prolific bloggers out there that manage to post several long posts per day, which for the sake of this example I'll assume means they are much faster writers than I am.

This is good old fashioned efficiency as most people would define it: generating greater rewards from the same cost, which usually results from an improved methodology or process. As the saying goes, "work smarter, not harder."

2 - Volume efficiency
Mixed among the game development blogs I read are a few that would be more aptly described as news aggregators. These sites don't really create much of their own content, they just link to other blogs or reprint press releases from companies with a minimum of commentary. These websites tend to be marked by their huge volume of posts per day.

This method of efficiency involves decreasing all costs as much as possible, in the hopes of increasing volume. This may sound similar to process efficiency, but I believe the difference is an important one.
3 - Piggyback efficiency
Before I started blogging, I already designed games professionally. I played and dissected lots of games, and took notes on things I found interesting. In effect, I was already doing most of the work required to write this blog, so its cost is very low. It's a lot like using a river or a windmill to generate electricity; because those resources are already there, harnessing them to generate a reward costs very little.
4 - Luxury efficiency
On the other hand, there are bloggers like myself who don't post particularly often, but (I'd like to think) generate results of a higher quality. I think this is partially because I spend so much time worrying about process efficiency at work all day, and taking a leisurely pace for personal projects is a nice change.

That aside, it's also because I think that's what distinguishes my blog from the sea of other game development blogs out there. I write my blog as though I were writing a book, both because that is the kind of blog I like to read, and also because I have half a mind to turn it into a book at some later date.

This is not to say that I wouldn't like to turn out quality writing more quickly. I still want to improve my process efficiency when it comes to this blog, but hopefully that's just a question of practice.

Efficiency in game development

Any successful team or company you can think of in the game industry is likely to be succeeding on at least one of these types of efficiency, and really great ones are likely to be efficient in 3 of the 4 ways. I don't think all 4 types at once is possible, because luxury efficiency and volume efficiency are usually mutually exclusive.

There are quite a few teams in the game industry that try to compete based on process efficiency. The ones I've seen that are the best at it are expansion pack teams and other teams that have to release games on an extremely short and regular schedule. When I worked on The Sims, my team pushed 2 expansion packs and several other SKUs per year. There was no way to come close to this volume without a very disciplined process.

Volume efficiency isn't something that was prevalent in the game industry until pretty recently. Iphone games made by very small teams for very little cost in very little time are the best example I can think of of the "fast food" mentality in game development.

Using the same engine for multiple projects, reusing code on a sequel, and releasing expansion packs are all also good examples of piggyback efficiency. A great example of piggyback efficiency in the game industry is EA, who ports their games to multiple game platforms and creates incremental sequels. I consider the Madden Football franchise the pinnacle of piggyback efficiency.

There are two companies that should come to mind when I mention luxury efficiency: Valve and Blizzard. Both of these companies take large amounts of time and money to make their games, but every one of them is of extremely high quality and is generally very successful. This is the most difficult form of efficiency to pull off, because it relies on the ultimate success of each new project. A failed Blizzard title would be a much bigger failure than a failed EA game or a failed iphone title. For a classic example of luxury efficiency gone wrong, see Duke Nukem Forever.

Design Lessons from Performing Arts Jobs

2009-06-10T23:48:00.000-07:00

I've learned several important design lessons from my work in various non-design jobs. See the full introduction, here.

Job: Acting, Singing, Dancing

I spent ten years or so (from age 12 to 21) studying the performing arts in various forms. I played instruments, worked as a dance coach, performed in plays, sang in choirs, and spent my first two years of college studying classical voice.

Most of the lessons from each of these disciplines apply to the rest as well, so I'll just write these up as though they were all one job.

1 - Lazy practice makes for lazy performance

A classic problem among performers who are just starting out is that they feel embarrassed giving a full performance in rehearsals, preferring to "save up for the show." It feels strange during rehearsals to break into tears or to passionately kiss someone, but the people who hold back for weeks before a show are never really able to commit fully on the big day.

In any activity, the habits we build from day to day condition our mind and body to perform those actions by reflex later on. In game design, I think it's very important to hold ourselves to the standard of whichever role it is that we want.

If you want to become a professional designer, lead designer, etc., don't wait until you've achieved that role to start thinking and behaving like one.

2 - A shared vocabulary is important

When watching an expert group of dancers or musicians rehearse, it's astonishing how quickly they can communicate. Various forms of music and dance all have their own highly specific language to aid in communication. A musician who has learned their discipline, but not its language, will never be able to collaborate successfully, and this is also true for game designers.

3 - Small goals are more satisfying

Becoming a virtuoso dancer, actor, or musician is a such a gradual undertaking that it's almost incomprehensible. After a day of rehearsal, it's impossible to really know if you've gotten any closer to your eventual goal - it can take decades.

Performers solve this problem by focusing on much smaller goals: learning choreography to a specific dance combination, practicing scales, learning new songs, etc. Game designers need to apply this same strategy when it comes to making sure that players feel satisfied. Doling out small tasks that lead toward a larger goal is something that RPG designers do very well, although it can be difficult to not overcompensate and give the player such small tasks that they never feel they've achieved anything.

4 - Reputation counts more than skill

I once saw one of the dancers in my troupe drop his partner on the head. He was generally a very good dancer, but he had quite a hard time finding partners for the next few months. All the girls saw him as someone who might injure them.

Game development is similar, in that actual skill level is almost completely ignored in favor of how easy people are to work with. Or rather, skill level is important to your reputation, but can be cancelled out by having a reputation for being hard to work with.

5 - Smart leaders delegate to trusted experts

Directing a play is a ridiculously complicated job. No one in their right mind would attempt to handle staging, set construction, lighting, music, choreography, and publicity on their own. The best directors find trusted experts, and shop out responsibility and power to them. Those leads then delegate further: The musical director is appointed by the director, and in turn appoints an orchestra leader, a vocal coach, and a choreographer. The choreographer then appoints a dance captain.

When successful, both plays and videogames are the product of multidisciplinary groups, unifying their efforts toward a common goal. Wagner referred to this as Gesamtkunstwerk, or total artwork. Strong creative leadership is essential to such a synthesis, but micromanagement is destructive.

6 - Know when to blend in

There are times to show off, and times to be part of the group. Singing ten-part harmony in a chorale is very different from singing a duet, which is very different from singing a solo aria. Likewise, dancing as a Rockette is very different from dancing as a prima ballerina.

Great performers always take advantage of their moment to shine, but also know how to collaborate unselfishly. Game designers are particularly bad at this. Ask yourself how important the feature you're working on is. How central is it to the game as a whole? Your painstakingly-simulated weather system may not be warranted in a game about riding dinosaurs off of sweet jumps.

Learn Your Lesson and Let it Go

2009-05-24T14:09:00.000-07:00

Like everyone, game designers make lots of mistakes. We might lose players because of bad design decisions, or water down our game by trying to appeal to too many kinds of players at once. We might make a bad impression on someone who can influence our career, or vouch for someone who turns out to be untrustworthy.

We might work on a game that gets horrible reviews, design a feature that ends up being the worst part of the game, or pour years of our lives into a game that gets cancelled or a company that goes bankrupt. Or, it might be something as small as introducing a bug that ends up breaking the build.

In some cases, we can recognize these problems and smooth things over, but sometimes the damage is irreparable. In cases like these, all we can do is quickly learn what lessons can be learned, and be on the lookout for our next chance to apply them.

It's really ok to move on

When your balloon escapes, you don't start climbing fire escapes to chase it; you buy a new one and tie it to your wrist. When you drop an ice cream cone, you hopefully don't eat it off of the ground; you learn not to eat and dance at the same time.

One of the hallmarks of a veteran designer is spending less time and energy lamenting mistakes, and more time and energy on preventing those problem from recurring.

People who chase missed opportunities rarely succeed at recapturing them. Without a time machine, we'll never get a chance to catch that winning touchdown pass we missed, and in real life barging into weddings usually doesn't get us a second chance with the one who got away.

What we can do is analyze what went wrong, build a pattern in our mind that will allow us to recognize our next opportunity to make a similar choice, and move on with our lives. This is the essence of learning, and it's what we ask our players to do all the time in our games. Even in games that let players rewind, those who can't learn from their mistakes will be trapped forever, in an endless failure loop.

Luckily, this kind of learning is one of the things that humans are best at. It's the essence of science, interpersonal communication, and especially playing games. In fact, some people think that this kind of learning is the entire reason that games exist. Making games is really just a very elaborate metagame itself, so it's no great stretch that we should ask ourselves to learn from our mistakes.

Player retention vs re-acquisition

Here's a good example of how fixing problems can't change the past:

Now that we've used a black box to fix the problems a game has, we can go out and get all those old players back, right? Well, maybe, but not necessarily. If it takes 10 times as much effort to get a player as it does to keep a player, it might take 50 times as much effort to get an old player back, once they've decided our game is crap. Some players may have had a bad enough experience that they'd never come back if we paid them.

What'd we waste all the time fixing the problem for then, if it can't actually get our players back? Improving our player retention gives us another chance to succeed with new players. We need to work on making sure the players have are sticking around, because retention is more important than acquisition. If our player acquisition is not good, then now we'll need to work on fixing that too, but only after we've made sure that our retention is high enough.

Maybe after a while, good word of mouth might spread to our old players, and then we'll have another chance to bring them back, but maybe those players are lost to us forever and we'll have to focus on making our new players happy. If drastic amounts of players have left the game, and the new players coming in are very different from the old ones, we may find ourselves with a whole new set of problems to solve.

Worse consequences, stronger lessons

Those players we lost may actually be a better lesson to use than if we had managed to get them back. In a way we spent or consumed those players. They taught us how to fix the game, but now they may be contaminated or otherwise invalid to us. Next time we'll be sure to be more careful about those particular kinds of problems.

Maybe the game lost so many players that it ends up dying, but in that case we'll be sure not to make those same mistakes again on our next game. If we do, then maybe survival of the fittest should apply, and we shouldn't be making games in the first place.

This learning process is very important to being a good game designer, and is one of the main assets that experienced designers possess over the most talented new designers. Properly analyzing mistakes and recognizing opportunities to apply that knowledge is a skill of its own.

Becoming better at learning from our mistakes and knowing when to apply those lessons is the best shortcut there is to becoming much better designers, much more quickly.

Designing a Black Box (Part 5)

2009-05-16T20:55:00.000-07:00

This is the fifth and final post in a series about data mining games to discover why players are quitting.

Read Part 1 here
Read Part 2 here
Read Part 3 here
Read Part 4 here

Which players matter more?

After working through the previous 4 steps, we should have a list of some very specific player demographics, based on both the type of players that are unhappy and the reasons they are unhappy.

For example, here are some hypothetical examples of groups that our unhappy players could fall into:

Social players who find it hard to find a casual guild
Expert raiders who are out of content
Beginners who aren't prepared well enough by the tutorial
PvP players who can't find anybody to fight
PvE players who are sick of being killed
Latecomers who can't play with their high level friends

All of these problems can be solved, but not all of them can be solved for every game, and certainly not all at once. We'll have to decide which of these player/problem combinations are the most in need of our limited development time, and also in which cases our efforts will be the most effective.

This can be a very difficult question to answer. Some games fail to define their key audience well, which means the argument about which leaks to plug will likely be very hard to resolve. Other games get too greedy, reaching out to a new demographic at the cost of angering their loyal fanbase. Star Wars Galaxies is a classic example of a game that tried to reach a new demographic and failed, losing many of its old players without gaining many new ones.

There are a few obvious factors in prioritizing which problems to address:

Which player types are the most important to retain?
Which problems are causing the most overall players to leave?
Which problems are causing the most of the key audience to leave?
How early early in the game are players encountering those problems?
How easily/cheaply/effectively can those problems be fixed?

Most designers probably think of these factors, but there are a couple very important factor that most people neglect:

How much of the damage has already been done?
How many of these players are we acquiring?

If our game launched 5 months ago with a horrible PvP experience, that fact has probably been announced loudly by reviews, fan sites, and angry ex-players. If we then decide to spend tons of time and money to improve the PvP experience, it's unlikely any players who enjoy PvP will be left to notice. We can try to entice them back, but perhaps it's been decided for us that our game is no longer a PvP game, even if we intended it to be. If PvP was all our game had going for it, we're probably already doomed, but if there are another group of players who are enjoying the game, it's probably wiser to improve what our game is already doing somewhat well.

Similarly, if only a very small percentage of our new players tend to be PvP players, and they all quit, fixing PvP may be addressing a demand that is not actually there. In order to be able to retain players, we first have to acquire them. Happy Farming Town Online will never draw many PvP players in the first place, so even 100% retention of PvP players won't ever really do us very much good.

Once a game is launched, its players define it. If we thought we were making a game for one group of people, and that group snubs it but another group likes it, we'd better get to work making the game suit the players who actually care about it. We can worry about getting other players once we're sure that we're taking care of the ones we've got.

Reach out to the right players

Once we've decided to fix a problem that a particular group of players is having, we'll have to actually design and implement a fix to that problem, not to mention make sure the problem is actually fixed. Once that's done, we just have to let those players know that those problems are fixed.

Since we used our black box to divide players into groups and problems in the first place, it should be possible to write in the functionality to send mass emails to groups of players, without even having to know which players fall into each group. By using a data driven system in this way, we can help specific players without even having to know which specific players those are. This should both stop players and developers from abusing the system, as well as avoid the majority of privacy concerns.

In a subscription-based game, communicating with players by email can be a dangerous thing. I heard a funny story from a friend about how a company sent a big update email out to all its players, many of whom had apparently forgotten they were still paying for it. Upon receiving the update email, a huge chunk of lapsed players promptly unsubscribed.

In my opinion this shouldn't be a deterrent. Hopefully a good black box system would prevent so many players from entering that limbo state to begin with, and even the data of which players were driven to quit would help us make the game better in the long run.

Once we've rolled out a change and an announcement tailored to a specific player group, we'll probably also want to track data for how well it worked. How many players came back? How long did they stay? If they've lapsed again is it a new problem or the same problem?

Don't rule out temporary fixes!

Fixing the game's problems is our ultimate goal, but sometimes is makes sense to temporarily compensate for those problem until they can be fixed.

If we find that the leveling curve is too slow in a particular area, or a level range seems to be a complete disaster, we can give every player in that zone or level range some bonus XP or free levels to get them past the rough patches. If a group of players who tried out PvP servers is having a miserable time, we can offer them free transfers to PvE servers, or give them some free PvP gear tokens to get them started off on the right foot.

In drastic cases, it may even be wise to disable a feature entirely rather than let it drive players away. We can also offer some playtime free or at a discount. If there are some problems that will take a long time to fix, even just announcing our intention to do so is something players really appreciate.

Advanced uses of black boxes

Even once we manage to plug all of our big player leaks, there are plenty of tasks that this type of data mining can be useful for:

How can we turn all the average players into happy players? This will follow a very similar process as making unhappy players average.
Which kind of marketing is successful with different kinds of players? We can experiment with different kinds of marketing in different time periods, and see how that affects our player acquisition and retention.
What is the best price point for our game or subscription? We can test out different prices and fees on subgroups of players to find out where the sweet spot is. It's possible that we'd keep many more players, and make much more money, by making our game cheaper.

Conclusion

All this may sound like a lot of extra work when we could just post a survey on our forums or make people fill out a form when they unsubscribe from the game. It really is worth it, though. Systematically identifying problems is a huge advantage over interviewing players, because players are not game designers and often don't consciously recognize the true causes of fun or frustration. For that matter, even game designers often bark up the wrong tree and rationalize or misinterpret bugs.

Targeting announcements and incentives to a particular group is incredibly powerful when done correctly, because it shows players that we've responded to their specific needs, even if they were unspoken. To players, this feels like we're reading their minds, or that we have the same priorities they do.

This sort of trust is very powerful when it comes to making longterm fans of a game or a company, and I believe it's more integral to success than most developers will ever realize.

The Tortoise and the Hare

2009-05-08T00:43:00.000-07:00

As you've probably noticed, I've been thinking a lot about player retention this year.

Back in February, I took some subscriber numbers from EVE Online and Warhammer Online and made some projections as to what their subscriber numbers were at that time. This involved some educated guessing, and some blind speculation.

EVE seemed to be a game with low player acquisition and high player retention, while WAR so far had shown high acquisition, but low retention. I ended up hypothesizing that EVE was in the process of passing WAR in subscription numbers, and that more or less everyone would be completely shocked when they realized this:

EVE is old and gruff and complex, and a little bit crazy. WAR is new and loud and very well marketed. It'd be the game industry equivalent of Tom Waits outselling 30 Seconds to Mars.

So who's winning?

Today EVE is six years old and WAR is six months old, and they've both announced subscriber numbers of "over 300k." I was a few months off on the timing, and I was apparently dead wrong that anybody besides me would find this event to be so significant.

In January, Warhammer's numbers were also announced as "over 300k," so it's hard to guess if those numbers have stabilized, are still falling, or are increasing again. I believe that 350k is a round enough number that a company would announce "over 350k" if they had broken that threshold, so I assume both games are fluctuating somewhere between 300k and 350k.

EVE's current numbers are significantly lower than my estimate (I extrapolated that they were at 323k back in February). EVE officially had 236k subscribers on June 2, 2008, and 244k at the start of 2009, which is a very modest growth of only 8k players in 7 months. However, their growth so far this year has been much faster:

We started out the year with around 244,000 subscribers and in five short months we've had a 22% growth in subscribers. In the past couple days we surpassed the impressive milestone of 300,000 active subscribers.

Why does this matter?

What I find so interesting about this situation is that we have two games, both somewhat niche and aiming for fans of PvP, at approximately the same number of subscribers. One is good at attracting players, and seems to be getting better at retaining them. One is good at retaining players, and getting better all the time at attracting them. I'm extremely interested to see what happens from here.

It actually seems that both games are shoring up their weaknesses. EVE has seen no shortage of scandal this year, which I'm sure has been great for publicity and player acquisition. WAR seems to no longer be losing players, and has taken strides to bring back lapsed players.

These two games, occupying a similar niche, have arrived at almost exactly the same subscription numbers, at the same time, by very different means. This is about as close as the market can provide to controlled conditions. We'll be able to see how each of the games adapt and progress from here, and how well each approach works over time.

Perhaps both games will level off around 400k, and we'll see that 800k players (plus however many Darkfall has) is the size of the current PvP market. After all, a million players is quite a bit more than most people ever believed PvP games could secure. Perhaps after a certain market cap is reached, the PvP games will stop growing organically and need to rely more on enticing players from each others' audiences.

Maybe we'll see that EVE really does have another ten years of growth left in it, as it continues to become more accessible and while keeping up its high levels or retention. Maybe WAR has distilled its true target audience, and that same 300k players will be playing the game until they unplug the servers.

Right now, these two games combined have about 5% of WoW's subscribers (600k versus 13MM). If those ratios stay constant as WoW continues to grow (and I do believe it's reasonable that 5% of WoW's players end up becoming fans of PvP), games like these can continue to grow at a healthy rate without ever having to directly compete with WoW. If WoW was a successful sushi restaurant, PvP games would be the fat, happy cats who live in the alley behind it.

Still Speaking of Data

2009-05-05T22:56:00.000-07:00

All my posts on data-driven design lately have been bringing a lot of data-loving new readers to the blog, who in turn have been pointing me toward no end of interesting stuff to read and think about. It's bordering on overwhelming, in fact.

Nels Anderson has a great series of posts going which touches on data. In it, he links to a surprisingly interesting talk by Malcolm Gladwell on Spaghetti Sauce and making your customers happy by not listening to them.

He also mentions a GDC talk by Valve's Mike Ambinder, which goes into some detail about just how many different kinds of user testing Valve actually does.

Speaking of Valve, Left 4 Dead Stats have gone live, and there also seem to be some surprising changes to TF2 coming up soon. According to Robin Walker, you can try just about anything as long as you've got good enough communication with your players:

Shacknews: Any plans for consumable items? And will these items be tied to each class, or carried over to all of your classes?
Robin Walker: The short answer is: possibly. Part of the reason we want to do this kind of design work in TF2 is because it's a product in which players send us a ton of great feedback. This means we'll quickly find out if we're screwing up, which is an amazingly useful thing when we want to try new things.
Shacknews: Should we expect to see more item slots--chest, feet, elbows--added in the future?
Robin Walker: See the "possibly" answer above.
Shacknews: Will players be able to trade these items?
Robin Walker: This is a good example of the kind of decision we'll be listening to the players around. If it's something they all want to do, then yep, you can expect us to do it.

For those of you who have had your fill of data for awhile, don't worry. I plan to wrap up the black box series with the next installment, and then we'll find something new to fixate on for awhile.

Since I'm breaking my first cardinal rule (don't just post a bunch of links to things), I may as well break my second cardinal rule (don't post to apologize for a lack of posting), just this once. Sorry about the two week lag there.

Generally I prefer to write more substantial posts less often rather than lots of short posts, but hopefully I'll settle into a bit of a better rhythm soon. Apparently getting too busy to post just as your blog receives a huge influx of readers is a tale as old as time. In the meantime, please subscribe!

Designing a Black Box (Part 4)

2009-05-03T01:58:00.000-07:00

This is the fourth post in a series about data mining games to discover why players are quitting.

Read Part 1 here
Read Part 2 here
Read Part 3 here

Correlation Versus Causality

By this time, we've hopefully made some large generalizations about what makes our players unhappy and begun to investigate them. During this process, we'll have to be careful not to throw out the baby with the bathwater: When a player has a bad play experience and logs off for 2 weeks, how do we know which of the experiences they had were the bad ones that caused them to log off, and which ones were neutral or even enjoyable?

Every experiment needs a control group. We need to see how happy players are playing the game, so it becomes obvious how players who are unhappy are different. There are some events that correlate with a player logging off but don't cause them to log off, such as returning to a city, or checking the auction house. It's obviously a mistake to decide that entering cities or putting objects up for sale makes players angry or causes them to quit.

We are also likely to find many events that cause players to log off, but are not a factor in how long the player stays logged off. For example, when given the choice, most players will log off at a natural "stopping point" such as completing an instance, finishing a quest chain, or hitting the next level. Players who are unhappy are likely to log off at these moments, but so are players who love the game and are having a great time. This commonality makes it clear to us that players who are leaving the game aren't doing so because they hate completing goals.

When we see both unhappy players and the happy player control group tend to hit a new level, purchase their new powers, and then log off, we can recognize that those events are not causal to staying logged off for a long time. However, once our players are split up into happy and unhappy piles, we may notice that the unhappy players took much longer than the happy players to reach that next level.

This could turn out to be because the unhappy players have a higher rate of deaths per hour, or that they fail missions more frequently, or that they don't have enough friends in the game to help them, etc. The control group allows us to make comparisons that lead us down a string of clues and help us determine what's going wrong.

Identifying happy players

In order to create a data set for our control group, we'll need to determine which players are happy. Since our black box uses time spent logged out as an indicator of unhappiness, let's consider happy players to be those that stay logged out for the lowest amount of time.

However, we should also keep in mind that it's definitely possible to play a game every day and get burned out enough to quit. We may find that hardcore players who are unhappy may still play more often that the happiest casual players. In this case we might want to look at logout times between sessions over a timeline, and place players who log in frequently but less often than they used to in the unhappy category.

Other symptoms of unhappiness

This black box is based on the amount of time players spend logged off, but there are many different ways that players may indicate their unhappiness with the game. We may need to create more than one black box, or just base ours on a different criterion for happiness. Every game and playerbase is different, so there are no rules to follow every time. If we understand psychology and our audience well, we'll hopefully always have the means available to diagnose and solve problems.

For example, if our game is based on microtransactions, a decrease in buying things could be an indicator of unhappiness. If our game includes a large social element, it's possible that unhappy players might abandon all other features and start using the game as a glorified chat room. Such a player would be held to the game by their social connections alone, and be very likely to quit if any of their friends did. This type of player could be identified by an increased ratio between standing in town chatting versus other gameplay activities.

Player archetypes

While there are some problems with a game that generally all players will dislike (some of which we covered in Part 3), any playerbase is likely to be made up of a diverse group of players who value different things and have fun in different ways. Because of this, it's helpful to split players into subgroups by playstyle or personality.

There have been many attempts at defining some generic player archetypes, but defining custom archetypes suited to a partular game works better in my opinion. When I worked on The Sims, we talked about our players in terms of Storytellers, Builders, Moviemakers, and Powergamers. Not every player fit perfectly into one of those archetypes, and most players fit into more than one, but they were a useful way to discuss new features and their intended audience. Each of our developers tended to favor one of those groups as well, and after awhile we started to consciously advocate for our constituencies, not unlike senators.

Just as we've defined happy players and unhappy players, we can also define data sets for each player archetype, and split those data sets further by hardcore and casual, soloers and groupers, beginners and experts, or any other divisions that are useful to us. Once we've done that we'll have many sets of data that describe our players in some detail and give us a much higher resolution when analyzing those data. Players (and their corresponding data) can move around between data sets over time, as their temperament, level of involvement, and happiness change.

The reason it's important to make these distinctions is because the same events may take on different significance to different players. A player who loves PvP may take a string of crushing defeats as a challenge to play much more often, while a casual socializer may quit the game in disgust. Hardcore raiders who begin standing around all day in town talking may be bored of the game's content, but socializers and crafters may make that their main activity and remain quite happy.

The other thing that tracking data by archetypes does is illustrate which kinds of players like the game and which do not. Perhaps casual socializers aren't very interested in the game. If the game is an MMOFPS PvP fragfest, maybe that's ok. If the game is Happy Farming Town Online, we'd better make sure those players are happy, because they're the only players we've got. Ultimately no game can make every player happy, and personally I prefer to make games that are clearly for some groups of players, and clearly not for other groups of players. The more specific the groups we're catering to, the better we can do so.

Finally, some results

At the end of this step, we should have some detailed hypotheses about each of the player groups in our game, how happy they are, and what sort of things we suspect make them unhappy. In other words, we're now on step 2 of 4 of the scientific method. Steps 3 and 4 are outside of the scope of this series, but we'd have to test our hypotheses with some experiments, and verify our fix by waiting for some data to be gathered that corroborates our hypothesis of what was wrong and that we fixed it correctly.

In the final installment, we'll look at how to present the right fixes to the right players, and finally use all this data and analysis to bring back some lapsed players.

Continue to Part 5

Designing a Black Box (Part 3)

2009-04-22T00:00:00.000-07:00

This is the third post in a series about data mining games to discover why players are quitting.

Read Part 1 here
Read Part 2 here

It's never too soon to find problems

If we're developing a black box for a game that's been out for a year, and has a stockpile of data already, it's pretty obvious we can just jump right in and start analyzing. People seem a little more hesitant to start gathering data on a game that hasn't even been released yet, but that's exactly what we should be doing. The great thing about basing our black box on the amount of time since players have logged out is that we don't need any paying customers to start getting data.

This system will start working as soon as we start letting normal players play our game under normal circumstances, which probably happens in alpha or beta. To clarify, I consider "normal players" to mean non-developers who are hopefully from our intended audience. I consider "normal circumstances" to mean that players can play as much as they want, as often as they want, with no level caps or dev commands.

Once these conditions are met, we can start looking at the amount of time between play sessions right away, and start finding our largest player leaks before the game has even launched. If a player doesn't want to play the game for free, we can bet they won't pay to do so.

Once the game has gone live, and a billing cycle or two has elapsed, we can begin to examine our assumptions about the correlation between time since logout and actual cancelled subscriptions. Perhaps we'll see that players tend to log in to the game as infrequently as once every two weeks and still remain active in the game for a long time, or we might see that an absence of even four days signifies a player who is thinking of quitting. In the short term it's ok to just take our best guess.

The more data, the merrier

We can refine these numbers over time, and begin to build sophisticated profiles and criteria based on level of involvement, character advancement, and even playstyle. We might find that danger point for all players might be an average of a week without logging in, but more likely the number will be different in different contexts.

Perhaps any player who has played less than 30 hours or is below level 20 is unlikely to return if they don't play every day. Perhaps max level players in casual guilds can log in once a week for raid night and once a week for a crafting session and still remain enthusiastic about the game.

We can become more and more ingenious with our detective work over time, tracking demographics, guild dynamics, important players and guilds who have a kind of social gravity among other players. We can compensate for local holidays, cross reference the patch notes of our game and of our competition, and even analyse crazy things such as how the color palette of different zones impacts the duration of play sessions. Let's not go crazy quite yet, though.

Solve the biggest problems first

Before we get to any finicky analysis, demographics, playstyle, and all kinds of other subtleties, let's just make sure our game will be around long enough for us to do so. When solving problems in game design (or any discipline really), there are always some "low-hanging fruit" problems which can be diagnosed and corrected much more easily than others.
First of all, what percentage of our total playerbase is unhappy? If it's only 5 percent, then we're doing a pretty good job already, and will probably just need a few tweaks. If it's 40 percent, things aren't looking good. If the number is growing every month, we're making things worse or our game is out of content. If the number is going down, our endgame is more enjoyable than our leveling, or our fixes are making people happier.

Let's take all of our available data, from every player who has ever quit or shown signs of quitting, and graph it. Let's look at the broad generalities. For each unhappy player, let's look at some statistics about whichever character they played the most in the last month:

How many hours the player has logged on that character
What level the character is
What class the character is
How often the character dies
What zone each death was in

Wait a minute, we've got this beautiful mountain of data, and we're standing back a mile away to see how it smells? Where's the digging and sifting and rolling in it?!
Don't worry, we'll get there. Big problems before small problems. Just looking at those four data sets, and combinations thereof, can give us a quite a bit of information about our most obvious problems. It will also suggest exactly where we should start combing through data for more clues.

How bad is bad?

Using wow as an example, let's imagine some potential data points and what they would tell us. If the unhappy players seem to be distributed evenly in the level range, that's more or less a good sign, and probably indicates that our game just isn't cut out for some people. If lots of players play to the level cap and then quit, we're likely in need of some better endgame content, but at least the early game is fun and we know where to focus our efforts.
If there's a big spike in unhappy players at level 10, this is a medium to terrible problem. Players might be feeling lost after the starter zone, the tutorial might not be preparing them well for the world, or maybe there is a problem with high level players griefing lowbies. These problems are all solvable and pretty small. However, players may just be deciding that the game is horrible early on, and fixing that level 10 spike might just turn it into a level 15 spike. We'll be able to get some idea by seeing what percent of our players make it to max level, but we'll also just have to wait and see.

Hopefully any low level problems are just potholes, and fixing them will pave the way for players to enjoy the game up to the level cap, but there's no way to know for sure until we start fixing things. Unhappy players at a low level is a very dangerous problem, and is an even bigger emergency than unhappy high level players, because new players will be entering the game, growing frustrated, and quitting before you can even address the problem. This is one reason that it's hugely important to get the jump on solving these problems before the game has gone live.
What else can we tell from a quick glance at these data? Let's take a look at how often players die, combined with some of the other information:

If players are dying very often in every situation, the player health and damage table may be tuned too low.
If players are dying very often in a certain class, that class may be a bit in need of a buff.
If players are dying very often at a certain low level, the tutorial may need some work.
If players are dying very often at a certain high level, the itemization for that level range may be too sparse or ineffective.
If players are dying very often at a certain low level in a certain low level zone, that zone is too hard or high level players are griefing them
If players are dying very often at a certain mid level in a certain mid level zone, that zone may be too hard, a focus of PvP, or contain a nasty roving boss mob.
If players are dying very often at a certain low level in a certain zone that is higher level than they are, the world may be laid out badly or in a confusing manner, so that low level players can't tell where they're supposed to go.

The ability to visualize and cross reference data can tell you quite a bit about your game that you might not have realized before, or at least give you some leads to start working on. Take a moment to glance over the lists in Part 2 again, and see if you can't pick out a few more sets of data that would be useful to examine.

Next, we'll begin building profiles of different kinds of players, and looking at how different patterns may emerge for each different player type.