December 17, 2009

How Valve Is Designing Their Community's Behavior

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

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

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

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

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

Good community members > good players

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

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

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

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

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

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

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

November 28, 2009

One Year And Thank You

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

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

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

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

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

People who helped make this blog possible

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

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

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

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

People who help make this blog successful

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

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

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

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

October 25, 2009

Players (And Designers) Learn Faster With Tight Feedback Loops

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

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

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

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

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


Timely information feeds learning

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

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

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

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

Feedback loops in game development

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

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


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

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

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

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

September 30, 2009

Designing Your Audience

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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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


Time to pick on poor SWG

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

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

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

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

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

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

September 17, 2009

How A Designer Thinks

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

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

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

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

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

Not nearly as memorable, but way more accurate.

There's still something missing

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


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

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

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

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

September 13, 2009

The 3 Flavors Of Enemy Design

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

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

1 - Enemies that follow the rules

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

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

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

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

2 - Enemies that break the rules

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

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

3 - Enemies that ARE the rules

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

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


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

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

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

Should you combine enemy types?

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

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

September 5, 2009

The Hierarchy Of Awareness

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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



Human opponents and Yomi Layers

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

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

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

August 29, 2009

Glossary

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

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

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

August 9, 2009

My Interview with FanToPro.com

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.

July 27, 2009

Stop Trying to be Productive

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.

July 19, 2009

Glossary: Productivity

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.

July 12, 2009

Glossary: Diminishing Returns

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.

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.

June 29, 2009

Glossary: Efficiency

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.

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.

June 10, 2009

Design Lessons from Performing Arts Jobs

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.

May 24, 2009

Learn Your Lesson and Let it Go

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.