December 31, 2008

Don't be the first, be the best

The other day, I was talking to a friend about Dark Age of Camelot, a game I didn't try until 2007, even though it's been out since 2001. I was complaining to my friend, a longtime DAOC fan, about how frustrating I'd found the quest journal. Right off the bat, it bothered me that there was no functionality for sorting quests. I consider the ability to sort quests based on location and difficulty the bare minimum, and even my favorite WoW mod doesn't do everything I wish it did.

What really got to me though was that it didn't have a highlight, checkmark, or some other way to easily tell which quests were completed and which weren't. I spent a lot of time scanning through the text of all my quests to see which ones to turn in, and I'd often miss one, which made me do a lot of backtracking to towns I thought I was done with. Since questing is one of the most common activities in the game, I think it should be one of the easiest actions to perform.

My friend listened to all these criticisms patiently, and then said, "Yeah, but DAOC was the first game to even have a quest journal! They invented it!"

I thought about this for a minute, and tried to figure out if he was actually right. Then I decided that while this was an interesting piece of history, it made no difference whatsoever. Even if I'd known that information when I was still playing the game, there's no way that could have helped me be less frustrated with the feature.

Live games require constant improvement

DAOC is almost 8 years old now, which is an impressively ripe old age for any videogame. But it costs the same amount of money per month that brand new games do, and is therefore a direct competitor of all those new games.

Innovation is a beautiful thing, don't get me wrong. When a game comes out with a cool new feature, it tends to get major points and earn them customers, as well it should. But once a competitor takes your great idea and improves it slightly, players can't be expected to know or care who came up with the idea originally. Game features are held to a standard of excellence which is generally getting higher and higher over time, as new games make small innovations.

Luckily, as long as your game was a good one to begin with, the amount of small improvements you can make over time is almost limitless. EVE online does a great job of relentlessly making improvements to their game. If any scifi game is going to take away marketshare from EVE, it's not going to be because its devs got complacent and let their game get crusty.

Of course, it should go without saying that the word "improvement" is a subjective one, and not all changes will be viewed positively by players. Successful changes to a game make players feel as though the game's been distilled into a more ideal version of itself, not that it's been changed into something else entirely. Players should be left thinking "how did we ever live without this?"

As designers, we need to make sure that our games improve over time, because players ultimately only care about whose game is the best, right now. This is a good thing for all of us, because it means that an upstart game really does have a chance to take players away from the presiding juggernauts. All you have to do is make a better game. It may not be easy, but at least it's fair.

December 28, 2008

Design Lessions from Manual Labor

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

Job: Carpenter

I spent ten years restoring Victorian houses with my dad, from building porches to shingling roofs to remodeling bathrooms and building additions.
1 - Measure twice, cut once
In game development, it's easy to think of tuning mistakes as being free and very easy to correct. When building a house, with real materials, cutting a sheet of drywall one foot too short means that you have to find a place cut it down further and try to reuse it, or if you've really messed up you'll have to throw it away entirely.

The consequences for game development mistakes may not be so obvious, but they're there, and many "insignificant" problems can add up to the cancellation of your game or the failure of your company. Just because your work may be easy to iterate on doesn't mean you shouldn't try to get it right the first time. Death by papercuts is the most painful way to go.
2 - Know what standards your work will be held to
Building codes are an essential aspect to construction that most people have never even heard of. There is an exhaustive set of rules for every type of building project, and official inspectors must be sent out to approve a structure at various stages of development.

It's very important to know the rules before you start building a house, or making a game. Your work may look and play great, but it could be causing performance problems on the server, or your UI element may not be legible on a standard definition TV. Your beautiful fire effect may be using up five times its allotted particle budget.

It's much easier to find out what the rules are and then follow them than it is to retrofit a structure or game to those rules after the fact. Sometimes you might even have to tear everything down and start from scratch.
3 - If you touched it last, you're responsible
Another interesting aspect of building codes is that the legal responsibility for any problem falls on the shoulders of the last builder to have touched the structure. If you're reshingling a house, and you find rotten wood in the roof, it becomes your responsibility to make sure that wood is replaced. If the roof collapses later, you'll be the one held legally responsible.

The same is true for building videogames. If you inherit some data or a feature from another person, and they didn't do a very good job on it, who do you think will be held responsible when the game gets bad reviews? The guy who no longer works at your company, or you, who slapped some fresh paint onto rotten wood and tried to pretend nothing was wrong?
4 - Do your work in the right order
I've painted a lot of rooms. When you're building the room from scratch, painting is the easiest thing in the world, because you can do it before you've put down flooring, light fixtures, wood trim, or anything else that you'd normally have to avoid getting paint on. You can just do a whole room in an hour with a roller, and the only thing that gets messy is you.

Painting a room that is already floored, trimmed, and furnished is incredibly hard and time consuming. Taping off trim, covering carpets and moving around furniture make the task take forever, and if you mess up you're going to be buying the homeowner some expensive new carpet.

There isn't always a choice which order you do your work in, because you'll often be asked to go back and touch up a room or game feature that's already existed for awhile. However, when you do have the chance to start from scratch, make sure you're doing things in the right order.

Job: Landscaper

When I was a kid I'd cut the lawn for my dad, relatives, and people in our neighborhood. The summer before college I did some actual landscaping; I dug holes for holes for planting trees or for burying wires and sprinkler systems.
5 - Take a moment to make a plan
Nobody pays the neighborhood kid by the hour to do grunt work. People usually just offer a number for the job, say 20 dollars to mow all their lawns. Because of this, I learned that the less I planned, the more time I took, which meant making less money. If I could save enough time on the first 4 lawns to fit in a 5th lawn, I could make 20% more money that day.

Whether you get paid by the hour or not, being as efficient as possible is always a good thing. You'll get more work done and have more time to take on new responsibilities beyond your own job, which is the best way to get a promotion.
6 - Cutting corners always has consequences
Losing 20 minutes to go put on sunscreen may seem like a big waste, but it's not nearly as bad as the 4 days you'll spend lying in bed with blisters. That was a painful and obvious consequence, but every shortcut has consequences of some kind, even if they're harder to see.

There are times when skimping on quality has to happen in games, but you're kidding yourself if you think there aren't consequences. Your team may evaluate the consequences and decide they are ok with them, but it's beyond naive to just assume that everything will be fine.

December 26, 2008

[Game Genre] is not dying

It's insane how many versions of the same story I see posted every year:

"PC gaming is dying! Console gaming is doomed! Adventure games are dead! 2D games are gone forever! The fantasy genre has shuddered its last fetid gasp! The monthly subscription business model is destined for extinction! Flight simulators, we hardly knew ye! The tactical RPG: gentle giant of a lost golden age!"

Supply and Demand

I don't know where these people were on the first day of freshman econ, but as long as there is a demand for something, it will be profitable for somebody to produce that thing. Demand may increase or decrease over time, and the market may get tougher, but it's very unlikely to disappear.

Smart companies are going to produce games in the genres that have the least competition. Say there are only a few hundred thousand people in the world who want to buy adventure games, but there are practically zero adventure games being released per year. A smart company with a well-placed game that's reasonably good can practically guarantee themselves some decent sales.

There are some very smart developers out there, who've set themselves up with presumably 100% of the market share for some incredibly specific game genres: according to their homepage, 3 Rings has 3 million people playing their massively multiplayer pirate-themed puzzle game, and 500k playing their massively multiplayer wild-western tactical rpg. Why make another fantasy game when you can corner the market on a new genre that you've just invented?

The Gold Rush

Every time some smart person makes a boatload of money on a new demographic or genre, there's a huge subsequent rush and glut of content in that space. This happens in every medium: Look at CG family films post-Pixar, comic book movies after Spiderman, e-commerce websites in the 1990's, or children's fantasy novels after Harry Potter. Eventually, there are enough people jostling around for dominance in the space that it's no longer a license to print money, and the market will start to stabilize and fall off, sometimes drastically.

Right now, the glut of fantasy MMORPG games is driving people to start looking for opportunities in other spaces. But imagine twenty years from now, if all those other genres become so successful that the fantasy genre is pretty sparse. Someone smart will decide they should make a great fantasy game, retire early, and spark a whole new boom of fantasy games.

These types of cyclical changes in supply and demand happen all the time. Celebrities make too many movies and start to annoy people, only to lay low for ten years and then make a comeback. Music and fashion go out of style and come back in again. Conservatism and liberalism come in and out of power, as one group takes things too far and people rush to support the opposing side.

This is how the world works, people. Enough with the doom and gloom.

Design Lessons from Customer Service Jobs

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

Job: Tech support

A friend of mine owns a webhosting company, and in college I picked up some shifts as a tech support rep. This was a great job for a student, because the calls were intermittent and I could do it while I studied or did homework.
1 - People can recognize problems without understanding them
As I've covered in another post, game designers need to take every problem seriously.

When a customer reports something to you as specific as "my router is broken," don't get caught up in their theory. If they could tell things like whether their router was broken, they wouldn't need to call you. Focus on the symptoms of their problem, not their theories as to what might be wrong.

If you're more open-minded, you'll be more likely to realize what their real problem is, and if you focus on the router solution, you'll just end up getting into an argument about how their router is working fine.

Same goes for game development: don't focus on what people think the problem is, focus on the experience they are having, and diagnose the problem for yourself.
2 - Small effort on your part can have big results for customers
It's within your power to make people happy, and often you don't have to even go out of your way to do it. As a customer service rep, it's important to parcel out freebies to make up for inconveniences. It's always worth it to give someone a free month of service compared to losing that customer's business forever. It's easy for you, and makes a big difference to them.

In game design, surprisingly small changes can make people happy, be they your coworkers or your player base. Even just giving someone more information can go a long way to making them happy. Make a point to let someone know you're going to fix that bug they hate, and they'll begin cheering up long before they actually see the fix.

Job: Home Depot tool rental

One of my jobs in high school was working at Home Depot on the weekends. I worked in the tool rental office, where people would come in looking for a metal grinder, floor buffer or generator for the day.
3 - Know your audience
In the tool rental where I worked, we had at least 3 different levels of each type of tool: Small jobs, pretty hefty, and industrial. All of them worked just fine, but you'd never want to rent someone a 4 inch hand sander if they want to sand an entire hardwood floor, or a floor sander for a furniture building project. One of the most important aspects of my job was figuring out what people needed, and to try and match the right kind of tool to the right kind of job/expertise level of the user.

This is still one of the most important aspects of my job now that I'm a game designer. Almost any design decision is valid under some set of circumstances. Try designing a PvP system without knowing what game it's for. It's impossible to do this well. How central is PvP to our game? What level of expertise does our average player have? What platform is this game for? The ideal PvP system for WoW, Warhammer, Halo, Counter Strike, and Peggle are all very different.

I don't necessarily think designers need things like user stories in every design doc, but take a moment to discuss and agree what kind of game you're making, and for whom.
4 - If someone thinks it's your job, then it's your job
When it was time for my lunch break, I had to walk through the whole rest of the store to get back to the break room. Home depot employees all wear the same uniforms, so every day people would stop me on the way to ask me for help. One busy Saturday, I never made it to lunch at all, and after that I had to start walking around the outside of the building.

If you're a game designer, people outside of your discipline don't understand or care about the difference between a content designer and a combat systems designer. They just know there's a bug that needs to be fixed. It's your responsibility to either fix that bug or direct them to the person who can. There's no such thing as "not my problem."

Job: Various sales shills

I spent some time selling ad space in local newsletters, ad space on diner placemats, and pages in those crappy coupon books high school students are always selling. I also was one of those annoying high school students selling the books. Being a salesman was my least favorite job ever.
5 - High rewards are more motivating than low cost
Whether you're selling something, convincing an engineering team to implement a feature for you, or designing reward systems, bang for the buck is what counts. Even if something only costs a dollar, it has to be worth more than a dollar or people won't want it. Not to mention the fact that cheap things are actually seen as less desirable to most people. Strangely, the easiest way to sell something to people is to charge them double what it's worth, but convince them that it's worth triple.

This also has implications for your career and writing resumes. Game design is a very subjective and often squishy discipline, but it's important to find ways to measure your success so that you can make people see that you're good at your job.

An easy tutorial can ruin your difficulty curve

I've been playing the new Prince of Persia, and it's a huge success in many ways: The visual style is beautiful, the level design is amazing, the puzzles are just challenging enough, the death penalty is perfect, the characters are likeable. I even like hitting the interact button on the princess over and over, just to hear the little bits of banter between her and the prince.

The combat, though, is becoming really frustrating. At first, I thought it was just bad combat design. But now there are videos on youtube of people stringing together great combos, while every fight is taking me ten minutes or longer to whittle down their health:

After seeing this, I realized that there's a good system there, the problem is that I just don't understand how to use it. I never learned how to use the counter system properly, but now I'm 2/3 through the game, where that knowledge seems to be required to advance.

Require understanding of mechanics early

I played the tutorial at the beginning of the game, but I don't think it ever required me to specifically counter an attack, or if it did it let me squeak by with just countering one attack by luck.

In a game that's about countering and stringing together combos, the tutorial should have specifically required me to counter 5 attacks in a row before continuing, and to build up a long combo against an easy enemy.

Because the tutorial and first few bosses let me win without playing well, I find myself completely stuck in the endgame, without the necessary skills to succeed, and no way to learn them in a safe environment.

Mechanics can be too hard; tutorials can't

Don't be afraid to require players to master each isolated element of your game early on. It's important to require a player to learn the basic mechanics of your game, under controlled circumstances, before completing the tutorial. If a player can't counter 5 times in a row against an enemy that's not a threat, then you'll just find out right away that the gameplay mechanic is simply too hard.

You may encounter some players who just hate a particular game mechanic and no longer want to play your game, but it's much better for them to find that out now than 12 hours in.

Your game can be very difficult, but that difficulty should come from complex interactions between mechanics, not from an individual mechanic itself. Think of playing guitar: A music teacher will never let a student learn how to play a chord before that student has learned how to hold their instrument correctly. Good technique isn't necessary at all to play a very slow song with only one chord, but you don't want to wait to learn good technique until you're playing more difficult music and you've already developed lots of bad habits.

Make tutorials skippable, but replayable

For players who are masters at a game genre or replaying the game, it's important to let people skip the tutorial. Just make sure they can come back to it at any time, if they realize they're in over their head. Maybe even have the game watch for signs of a confused player, and remind them that they can revisit the tutorial. If your game is really slick, you can actually pepper in some easy teaching enemies and some tutorial text into the next fight, just to remind the player of the skills that they're missing.

It's certainly fine to make a gameplay element harder and harder as the game progresses, such as requiring quicker reflexes to counter or string combos together. But don't think you're doing your players any favors by "saving" them from learning the basic techniques that you'll later be requiring to move forward in the game.

Tutorials don't need to be early

If you really can't bring yourself to make the initial tutorial for your game a little more comprehensive, shake up your assumptions about when tutorials have to take place. People assume they need to only happen at the beginning of a game, but they can be placed wherever they give the player maximum benefit and minimal intimidation.

If blocking and countering don't become important until later in the game, then don't worry about teaching it in the first five minutes. But when you do decide to teach it, make sure players are actually required to learn it properly before you let them continue!

December 23, 2008

Create Heroic Moments In Group Combat

Tobald has written a post lamenting the fact that healers are so often blamed for a wipe in MMO boss fights:

...So once I'm able to cast spells again, I find all 4 group members seriously wounded, and not close enough for a Circle of Healing. I do my best with Prayer of Mending, but need a lot of time to keep the tank alive, during which the dps are killed. I keep the tank up for a long while, but with just the two of us we finally wipe. And of course the dps guys blame me. Why didn't I heal them, yadda yadda yadda. I try to explain, but they won't listen.

Healer Responsibility

Tobold's teammates seem to be jerks who were tossing blame around unfairly, but I think this is a great example of how player behavior is a direct result of game design. In most role-based (i.e. tank, healer, nuker) group content, tanking and healing are simply much more unforgiving than other roles, and healing is often considered the most stressful role to fill.

Just as game designers are held responsible for anything that makes a game unenjoyable, healers are ultimately held responsible for any player who dies. People don't want to hear about the mitigating circumstances that stopped you from doing your job well, they just want you to do it. If a dps player does too little dps which causes the fight to go on too long and the group to wipe, not many people will correctly diagnose the problem. In their minds, the healer still "should" have saved them.

Tanks and Healers are often called on to correct mistakes, and will be blamed more than other roles. Even when other players could have helped by using crowd control or standing closer to the healer, Tanks and Healers stand out as the scapegoats.

Create heroic moments for other roles

I don't think the solution to this problem is to make healing easier, but to make sure that other players are presented with do-or-die moments where it's their responsibility to perform certain duties or be blamed for a group wipe. Many games have already introduced moments like this for tanks, such as additional enemies who spawn and need to be taunted, bosses who randomly change their target from time to time, etc.

In most MMO groups, roles such as controllers or nukers almost always outnumber tanks and healers, but those roles aren't often given their big moment to make or break the fight.


Ways to challenge DPS/Nukers:
  • Several weak enemies that share a health pool or constantly heal each other, requiring AoE attacks.
  • Enemies that are invulnerable or very resilient until hit by a crit or a very large burst damage attack. This could be a moment for a DPS class to save their special attack for.
  • Enemies that regenerate health at a constant rate, requiring a coordinated effort between 2 DPSers to take them down.
  • Enemies that do more and more damage over time, and must be speedily killed before they become too dangerous.
  • Enemies that have especially high effectiveness at low health, and must be DPSed quickly through that stage.
  • Enemies that heal their friends, become enraged, or otherwise punish the player if they are hit with a lot of damage from a single attack, encouraging DoTs and fast hits.
Ways to challenge Controllers:
  • Enemies who can't be hurt but must continually do damage to stay alive. Root, snare, or hold abilities can incapacitate them long enough to deprive and kill them.
  • Extremely strong enemies who begin weakening the moment they enter combat, and must be kept alive but controlled for some time before fighting them.
  • Enemies who become enraged or otherwise immune to taunt at certain times, and can only be contained by control powers.
  • Enemies whose cast times and attack speeds are directly affected by snare and slow debuffs, meaning controllers should always be applying as many slow effects as possible.
  • Enemies who decide to self-destruct at low health, with a self-destruct power that damages both enemies and players. Controllers can quickly contain them to prevent them from running at a teammate and to funnel their damage toward other enemies.
Note: These challenges should be generalized enough to emphasize what game mechanic the player is using, not what specific powers they are using. Stick to broad categories requirements like burst damage, sustained damage, any snare power, any control power, or any AoE power, rather than a specific debuff that only one class can dispel.

Give every player a chance to be the hero or the scapegoat, from an early level, and players will not only learn to be better players, they'll be more involved and satisfied, and have better stories to tell people about your game. If you're lucky, they may even become a little more empathetic toward their tanks and healers and the pressure they're under.

December 21, 2008

Think more like a scientist

Game design is not a science, but like almost anything, science teaches skills which can be extremely useful in game design. If you've followed good design practices, but your design isn't working how you expected it to, it's a good time to put on your scientist hat and start investigating.

Before starting to track down a problem, take 5 minutes to define the problem, and make sure you and your coworkers actually agree. This will save tons of time. If the cause of the problem is exactly what you need to deduce, at least agree on what the symptoms of the problem are (for example, "nobody seems to want to play a tank in our game").

The scientific method

This is actually a very broad topic, but the 4 steps that we all learned in 5th grade science class are described by the Hypothetico-Deductive Model:

  1. Gather data ( observations about something that is unknown, unexplained, or new )
  2. Hypothesize an explanation for those observations.
  3. Deduce a consequence of that explanation (a prediction). Formulate an experiment to see if the predicted consequence is observed.
  4. Wait for corroboration. If there is corroboration, go to step 3. If not, the hypothesis is falsified. Go to step 2.
Let's walk through this process for our class shortage problem, which is a pretty common type of problem for MMO designers.

1. Gather Data

Is there actually a tank shortage? Everyone at your company seems to think there is, and there's a lot of wailing and gnashing on the message board from players, but it never hurts to actually check the data.

Every development team should be able to get access to statistics related to how players are playing and what they're doing. Engineering and Operations should be able to help you out with this.

Say you have 5 classes. Are 1/5 of your players playing tanks? You'll need to define some rules for how this can be evaluated. You can't just check how many tank-class characters have been created. Maybe they're not used. In fact, the ratio between actively used tanks and abandoned tanks may be useful info to you.

If more than one class can tank, or if there is a class that can choose through spec to either be a tank or not be a tank, you'll need to find a way to evaluate that as well.

Eventually, you'll have a clear definition of what it means to be playing a tank, and how many poeple are doing it, in relation to how many people you'd like to be doing it. If the ratio doesn't match your intentions, then you do in fact have a problem.

If the numbers match up to your intentions, but people still complain, it may be possible that you need to redefine your problem. This is why spending time defining problems and gathering data is so important.

Your intentions could be wrong. If there are 10 classes in the game, and only 1 of them can tank, and each team of 5 requires 1 tank, you won't have enough. Or perhaps it turns out that players find it necessary to bring 2 tanks to every fight. These are other flavors of the problem that you should also consider: maybe you need to add more tanking classes to the game. Maybe you need to change your instances so that 2 tanks aren't considered necessary. Keep digging through data until you identify a problem that sticks and your team agrees is worth solving.

2. Hypothesize

Assuming we decide there actually is a tank shortage, it's time for us to brainstorm reasons this shortage may be the case.

  • Tanks don't have enough interesting things to do in a fight, and are boring.
  • Tanks have too many difficult things to do in a fight, and are too high pressure.
  • Tanks aren't easy to level up with, because they deal too little damage.
  • Tanks aren't effective in pvp, because abilities like taunt don't affect enemy players.
Rank these hypotheses in order of likelihood. If your game emphasizes pvp a lot, the pvp cause may be a likely solution. If your game has a lot of solo content, it may be that leveling isn't fun for tanks.

Decide which problem to try fixing first. At this point, you'll need to back through the first few steps again, and agree exactly what the problem is, as well as determine some way to gather data on these sub problems, leading back to this step, developing hypotheses.

For example, tanks may be boring. If we can agree that may be true, we can gather data on this problem. How do we do this? Let's monitor some expert players and some unskilled players fighting through an instance, and gather data.

  • How many times does the tank switch targets compared to other classes?
  • How many times a minute does the tank use powers compared to other classes?
  • How many different powers does the tank end up using per minute?
  • How much chatting do tanks do while tanking, as opposed to other classes?
  • Etc.
Keep discussing more and more specific problems, until you feel you've arrived at something you can actually experiment with solving, e.g. "Tanks are required to use too few powers in most fights, and are boring."

3. Predict/Experiment

Make a prediction as to how to solve the problem: "Adding some more tanking powers to the tank class will make them less boring, and thus more desirable to play."

Develop an experiment to see if this is true. For our purposes this can be as simple as adding some new powers to the tank on one server, and seeing if usage rates improve on that test server.

It is important to follow some rules of good experimental design though: Make sure there is a control group of tanks with the old abilities, and that there is only one variable changing at a time. You can't test this change the same week you make overhauls to a bunch of other classes, and then draw useful conclusions about the fact that more people seem to be playing tanks. Solve one problem at a time.

4. Corroborate

If people seem to think playing a tank is much more fun with more abilities, the experiment has succeeded, but we still need to figure out if we solved the real problem, or if we solved the problem under all conditions.
We can add those powers to tanks, and wait to see some new data come in for tank usage. We may have solved the problem, but don't forget that we initially had a list of 4 problems:
  • Tanks don't have enough interesting things to do in a fight, and are boring.
  • Tanks have too many difficult things to do in a fight, and are too high pressure.
  • Tanks aren't easy to level up with, because they deal too little damage.
  • Tanks aren't effective in pvp, because abilities like taunt don't affect enemy players.
We may now see that people start playing tanks once they've leveled up, but that they are still very unpopular for pvp and leveling. Maybe there is a 5th problem that we haven't identified yet. Or maybe new players have started playing tanks more, but existing players may still need to be educated on the new changes before their behavior changes.

Of course, you may always end up solving a problem too well, and have to tune it back down a little bit. Nerfing overplayed classes or buffing unpopular classes is continuous process in games. No matter what you do, some players will always deny the problem was solved, say the problem was solved too well, or claim that the problem never existed in the first place (and often all 3 opinions will be present in a single forum thread).

Just don't even consider any problem solved to the point that you have to stop paying attention to it. This this process can help you refine the game further and further over time to match your goals, or even change to match new goals.

December 20, 2008

Design Lessons from Waiting Tables

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

Job: Waiter

For 3 years in high school, I worked at an Italian restaurant. I was going to lump this in with several other jobs, but now that I've thought about it, there were so many good lessons here that it deserves its own post.
1 - Boredom is your enemy
When people have to wait 20 minutes for their food to come, they become incredibly irritated. If they receive their drinks after 1 minute, a bowl of hot bread after 3 minutes, soup after 8 minutes, drink refills after 10 minutes, salad after 13 minutes, and more drink refills after 16 minutes, the same 20 minute wait for food is much less noticeable.

I think the implications of this lesson for game design or even management should be pretty clear. Parcel out small rewards frequently, in addition to large rewards less frequently.
2 - Learn to recognize when people need your help
Constantly make yourself available to people. If someone needs your help, they need to be able to find you easily. Always check in with people to make sure everything is going smoothly, especially right after you've delivered something to them, be it a plate of pasta or a new set of player powers.

Eye contact always means that someone wants to speak to you. Make a sweep around the restaurant or the conference room or the office with your eyes, and it will always be immediately obvious who wants to say something to you. They will be looking directly at you, often raising their eyebrows, and sometimes opening their mouth slowly, like a fish.
3 - Control expectations
The restaurant I worked at had delicious, slightly famous oven-fired pizzas. But they took 45 minutes to cook. On Saturday nights, people often came for dinner before going to the movies at a nearby theater, and it was important to make sure people knew what kind of wait they were getting themselves into (while assuring them how great the pizza was).

When making games, warn people how long something will take to implement, or side effects it might have, and make sure everyone is on board with it. Never assume that something goes without saying. [For that matter, never assume anything at all, and you'll always be better off.]
4 - Overestimate difficulty (slightly)
You need to account for the fact that something always goes wrong and things end up taking more time. If you build in some wiggle room for a problem and one never arises, people always appreciate things being slightly faster or better than they were led to believe it would be.

Just don't take this too far, or you'll become the boy who cried wolf, and nobody will trust your estimates at all, or start mentally adjusting them to find what they think the "real" estimates are.
5 - Know your limits, and ask for help
Diner Dash is the most stressful game I've ever played. If you want to know what it feels like to wait tables during the dinner rush, this game replicates it almost exactly. Game designers often find themselves with a similarly large number of tasks and customers to balance.

Multitasking can only take you so far, and each person has a different threshold of how much they can handle. For every game designer or waiter, no matter how good, there is a point at which they'll collapse under she sheer chaos of all the things they're trying to handle. Learn to anticipate that point from a long way off, and to ask for help! This is another way to control expectations.
6 - Recognize your specialties, and seek out those tasks
In a restaurant and in game design, there are lots of different ways to have a full workload. You can be a specialist, with one big project that's all yours, a generalist that works on a little bit of everything, or something in between.

If you're great at handling a million tables at once, or you prefer one really large birthday party or catering event, try to make sure your assigned tasks match up with your ability to do great work as much as possible. Which brings me to my last point:
7 - Your coworkers are the gatekeepers to your success
Think about the last time you got really bad service from a waiter or waitress. What made it so bad? Keeping you waiting for a long time before ordering? Messing up your order? Undercooked or burnt food? A dirty table?

These are all things a bad server could have caused, but they're also all things that someone else could have dropped the ball on. The cook can mess up an order or forget to cook it. The greeter can forget to tell the server they have a table. The bussers can forget to wipe down a table.

No matter what the trouble is, you're generally likely to hold the server responsible, because they're the most visible person. This is the same way with game designers. Like waiters, game designers have to rely on our coworkers to help us do a good job, and we'll look bad if they don't.

Because of this it's very important to make sure you have a good relationship with the people who create the product (cooks/engineers), the people who distribute the workload (greeters/producers), the people who clean up your messes (bussers/QA), and your fellow contributors (other waiters/designers). If any of these people decide that helping you do good work is more trouble than it's worth, you'll find yourself in a situation where it's impossible to succeed.

December 16, 2008

Rock-Paper-Scissors class balance is not fun when choices are permanent

Let's play Rock, Paper, Scissors: Ready, set, GO. Nice, your rock trumps my scissors. Good choice. Ok, best two out of three; I'll beat you next time!

Imagine if you couldn't change your choice

Now let's play the version of RPS that many games with open world PvP ask you to play: Everyone declares themselves rock, paper, or scissors, and then they're stuck with that choice forever.

Imagine your office was an ongoing game of RPS where everyone is forced to choose one move and then play that every time, even when it will make them lose:

Everybody gathers around to pick out some fabric and patterns and thread out of a box. You need to sew yourself a shirt with an R, P, or S on it, and wear it every day as part of your uniform. Now every time you pass one of your coworkers in the hall, see who wins!

In the meantime until you finish sewing the shirt, you're a "lowbie" who just automatically loses to everyone who's finished making theirs. After a week or so, you've finished your special shirt with an S on it. It looks great on you. You come to work, excited to finally have a chance at winning.

Unfortunately for you, your office has a lot of R shirts, and they always trumps your S. I pass you in the kitchen: you lose! Later you pass the IT guy on the stairs: you lose! At lunchtime you meet up with some friends: you lose! It seems that everyone picked R, and there's nobody around you can win against. How were you supposed to know everyone would pick R?

In the parking lot, you spot Bob, who's a P. All right, you finally win one, but Bob doesn't really care, because he's the one who wins against all the other R jerks in the office. Frustrated, you decide you should throw away your S shirt and start sewing a P shirt, so you can be like Bob and start winning for once.

After a week of working around the clock to sew your new P shirt (and losing the whole time), you finally have a shirt with a P on it like your frien Bob. You rush to work, excited. But wait, what? When you read your email, you see that the rules have changed and now the order has switched. All the Rs you were hoping to win against today now win against YOU! If you would have stayed an R, you'd have beaten all these guys, but now you lose even more than last week, because of a change you couldn't see coming.

This is how it feels every time someone levels up an MMO character, only to realize that the rock to their scissors is actually the most played class in the game. Or that the only that their class is good at killing turns out to have just been nerfed to the point of unpopularity. Or that the group they were supposed to be able to win against can now easily beat them, due to a rule change or patch.

It's especially bad in games with open "world" PvP, where you can be attacked by anyone at any time. While you're leveling up your character, any high level character can come by and stomp you, and by the time you're finally done you may be stuck constantly losing because of who happens to be playing the game as a given class on that game/server/day. Do you really have the patience to sew yourself another new shirt, or do you want to quit this game?

Ok, Let's try chess

You be a rook and I'll be a bishop. I'm very dangerous if you stand at an angle to me, and you're lethal to me if I stand straight on. We take turns moving, until one of us tricks the other into standing in the wrong spot, and wins. Now Bob shows up, and he's a Knight.

Which piece beats which, in a game of Rook, Bishop, Knight? Well, I guess nobody can tell for sure, because it's all a question of getting the other person into a situation where they're exposed to your killing blow. The knight is more versatile, but has shorter range. The bishop and rook have blind spots, but unlimited movement. [Pawns, queens, and kings would definitely not be balanced, which is why I'm leaving them out]

We all take turns dueling. This is more fun than the tshirts, but it's a little too easy to avoid danger once you learn the other person's abilities. The game is TOO balanced! [Actually, the way players tend to think, we'd be more likely to each complain about each other being "too hard to kill." Usually the only time a player thinks their class is balanced is when it's overpowered.]

Let's add a resource to spend. Every 5 turns, I can declare that you're snared, which makes your next move shorter. Now we've got to avoid danger, but also think one move ahead, and make sure that we're not going to be snared in a spot that gets us killed. Now if I know you've just used up your snare, I can play more aggressively for 4 turns. Let's add a die roll, so there's a 1/6 chance of a snare missing. We're on our way to a fun game that emphasizes our choices, not our classes.

Now for some Team Fortress 2

It's our first day of TF2. You decide to learn sniper, and I decide to learn pyro. We play 10 games of 1 on 1 deathmatch. Hrm, what do people see in this game? Whenever we're in an open field, you can easily snipe me, and whenever we're in a hallway, I roast you. Eventually you just start waiting for me in the open field, and I start waiting for you in the hallway. We're bored.

Oops, what button did I just hit? I'm a spy now? Hey, I can be invisible. I sneak out of the hallway and around the open field. I come up behind you and stab you in the back. Take that!

Now we start picking lots of new classes every time we die, and we start to learn about the game. If I kill your sniper in a hallway with a flamethrower, you come back as a demoman and bounce a few grenades into that hallway. You snipe me, so I come back as a double-jumping scout who's hard to shoot and is good at closing distance.

This is actually a lot like Rock, Paper, Scissors, except sometimes paper gets a lucky shot on scissors, and gets to do some gloating. Bob's online now, so we join his game. He's in a game full of all kinds of players playing team deathmatch. The enemy team has too many medics healing people, so our team all starts playing pyro to roast them. Oops, now their team is all engineers, and they're mowing us down. We send a few people in as spies, and then someone decides to play sniper to cover that open field. Even without a plan, the team begins to organically identify and fill needed roles.

Now the map switches to something with an objective, like capture the flag. We know there are a bunch of pyros in that hallway, but we have to get in there to complete our objective. Bob stays behind to play defense as engineer, while I go medic to heal you as a heavy.

Once the game gets into full swing, we've all got some interesting choices to make. The team balance calls for a sniper right now, but I'm not very good at it. Should I stay a class that I can play, that might not be as useful right now, or take my chances with sniping, because it could help my team win? I'm going to play this game every day, until I'm good at ALL the classes.

Supply and demand

Just like the tshirt example, TF2 involves people rushing over to the side that they think will be most powerful in a given scenario. Except they can turn on a dime. It takes 20 or so seconds to come back as a different class. If your entire team decides to become scouts to get past the snipers, it's a juicy opportunity for just one player to go pyro and wipe the whole pack of you out.

In this way, the maps and classes balance themselves. The more engineers there are, the more powerful spies become. But if you guess that the engineers will be expecting a spy, you can take a chance with a demoman or medic, which isn't as devastating but isn't what they'll be preparing for. If you think a few moves ahead of the enemy, you can trick them into walking into a trap. In this game, like our game with the chess pieces, what you do and who you are both matter. Choosing the right role at the right time can make up for a skill deficit, but the "wrong" class can win the day if it's played with enough skill.

Games to watch

There are several games, mostly shooters, that let you switch who you are and what you can do. Several of the Battlefield games let you pick up a weapon pack from a different class's corpse, and continue playing with their abilities. Team Fortress and Natural Selection allow you to switch very often, around once per life. Counterstrike lets you buy new weapons each round, as well as pick up other weapons instantly off the ground.

Planetside and Eve Online are MMOs that allow the player to build up training in lots of different areas, and then choose which ship or powers to use. Choosing roles happens less often in these games, generally requiring a visit to a hanger or a factory. It sounds like The Agency will allow players to swap out their powers by changing the equipment they're wearing. I'm looking forward to seeing this in action.

There's definitely a place for Rock, Paper, Scissors game design, but I think the stronger those trumping abilities are, the easier it needs to be to switch between Rock and Paper at a moment's notice. I like playing a single class in MMOs for hundreds of hours, but I want to know that my tactics and strategy will be able to win fights for me. I don't want to be left frustrated after a fight, wishing I'd have rolled a different class so I wouldn't have to lose so much.

December 14, 2008

Design Lessons from Working with Kids

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

Job: Swim Coach

Teaching kids to swim was a great job. I coached the age 6-12 group for a few summers in high school while I was on the swim team.
1 - Learning curves should be gentle, but have skippable steps
There's a pretty huge range in physical strength between a 6 and 12 year old kid, as well as a wide range of natural abilities. I coached some prodigies that seemed to be on their way to state records and olympic time trials, but others took weeks just to get into the water.

It's important to give very manageable steps to someone who's totally new. (Sit with your feet in the water for awhile; now try kicking while you hold onto the wall; now try kicking while I hold you up; now try kicking with a kickboard; now try using your arms too; now learn to breathe from side to side; now learn how to flipturn; now learn how to dive from the edge of the pool; now dive off the starting block.)

However, experienced players need to be able to skip these steps and have something challenging to do too. Juggling your attention between these two groups is very difficult but important.

Job: Babysitter

This was another one of my very first jobs.
2 - Use choices to mask requirements
"After we do the dishes, which movie do you guys want to watch?"

Try to always let your player feel like they are making a choice, especially right after requiring them to do something.
3 - It's much easier to manage strangers than friends
Kids who've never met you before the job behave a lot better than kids who've known you for 3 years as just some other kid.

It's a challenge to get results from someone who thinks they know better than you do. Include them in the decision-making process and they'll be more likely to respect your decisions.
4 - Players will always test the boundaries of the rules
"But Mike, my MOM lets me watch HBO all the TIME! Honest!"

Don't just design the game for how you want players to behave, design it to take into account how players want to behave themselves, which is often quite different.

Job: Math Tutor

I taught algebra to some high school students, and basic math to elementary school kids.
5 - Always ask people to demonstrate what they've learned
It's almost impossible to tell if someone has learned a skill or concept properly without asking them to execute it. Kids will just nod and smile when they have no idea what's going on.

Tutorials should ask the player to perform the action they've just been taught, even if it's something silly like moving and jumping. Just make it possible to skip the tutorial entirely.
6 - Never let fatigue set in
When someone has had enough, they have had enough. Trying to force a student or a player to keep going on something that has lost their interest will just build ill will for the next time around. Change gears often, and let people have the option to quit before an imposed time limit.

Design Lessons from Office Jobs

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

Job: Envelope stuffer

When I was 10 or 12, one of my neighbors started hiring me to help him mail out thousands of checks for his company. It was something to do with oil well royalties, if I remember correctly. I'm pretty sure this was the first job I ever had.
1 - Know when to use technology
After licking about 50 envelopes and stamps, I finally caught onto the brilliant idea of using a damp sponge. I still remember the awful taste, and the first time I gave myself a paper cut on my tongue.

Always keep an eye out for how much time a repetitive task is taking you. It's almost always worth creating a tool or script to do tasks like that over the long run.
2 - Think like a factory worker
Every time I showed up for this job, I'd find an overwhelming stack of envelopes, stamps, checks, letters, and names of people waiting for me. I soon realized that it was awkward and slow to take each package from beginning to end, and that I could take the entire stack through one step of the process before beginning the next step.

I'd label all the envelopes, stamp all the envelopes, group all the checks and letters, fold and stuff all the envelopes, double check everything, then seal all the envelopes. This was by no means a new idea, but I remember being pretty proud of myself at the time.

Unfortunately, game design is filled with lots of large repetitive tasks. When you can't automate them, tackling them like an assembly line is the next best thing.

Job: Admissions assistant

One of my jobs in college was processing applications to one of Carnegie Mellon's graduate programs.
3 - Never destroy information
Occasionally, an alumnus would email us to request a document, or would send us something relevant to their file. I was constantly amazed at how many storage rooms filled with old data from past students we had. There were separate rooms for applicants, current students, and recent graduates. Eventually, alumni files were moved to another and then yet another more obscure storage room.

Migrating files once a year was a few days of hassle, but the rest of the year we always knew where to find things. Also, the current files were kept close by where we could deal with them easily, while the older (usually irrelevant) data was a longer walk away.

When writing a design doc or doing any other design task, never delete your data. Move rejected ideas to a special section of the doc, or keep a file of things that would have been nice but there wasn't time for. You never know when some days in the schedule will open up to go back and add new features.
4 - Be grateful for good infrastructure
Universities have a huge amount of people making sure that day to day operations run smoothly, and even more that they bring in to pull off special events like graduation. My office started preparing for graduation 3 months ahead of time, ordering diplomas and frames, caps and gowns, and special regalia for students who seemed on track to graduate with honors, etc. The week of graduation, we spent hours setting up receptions and events.

Be nice to your IT and facilities people. They are constantly working on your behalf, and when they do their job perfectly, you don't even realize they've done anything.

5 - Rules are really just people

It was very interesting to work on the inside of the admissions process when I'd so recently applied to college myself. What I found particularly interesting was that the day that the deadline for new admissions came, nothing really changed.

If more materials came in, I still added them to the pile of work to do. It was at least a month before all the materials were ready to be reviewed, and possibly several more months before anyone actually reviewed them.

The thing that was strange about this was that the decision for how late to actually continue filing new applications delegated by my boss (who had more important things to worry about) to me.

The fact that some random undergrad would be placed in charge of enforcing or not enforcing the graduate admissions deadline changed the way that I see rules and tradition. There's always a person or group of people that is in charge of a decision, and you can change just about anything if you can convince those people.

The implication for game design is this: always be questioning things. A decision that was made arbitrarily and can be changed looks very similar to a decision that was made very deliberately and is set in stone. When it comes to improving your game, be sure you're not working within a box that's too small. Some walls are flexible, or destructible, or completely imaginary.

My life before game design

As any first year psychology student could tell me, I'm much more likely to value being a generalist, because of the fact that I am one myself. I've always been interested in a little bit of everything, and I love finding connections between things that don't seem related at all. I remember getting my first job when I was twelve, and since then I've always had at least one, plus a fairly wide array of hobbies in whatever field has intrigued me at that moment.

I didn't decide to become a game designer until I was 20 years old, but all the time I spent on other jobs and hobbies wasn't wasted. When solving a game design problem, I often find myself reflecting on lessons that I learned long before It had even occured to me that I might want to design games professionally. The best way to become better at designing games is to design games, but all other experience is as valuable as you allow it to be.

Looking for connections to game design is a little game I play when I find myself stuck with a task that I don't find interesting. Try to look deeper for lessons that are related to your passion. This tactic has made many college courses and dead end jobs much more interesting and applicable than they would ever have been otherwise.

Design lessons from visual arts jobs
Design lessons from performing arts jobs
Design lessons from working with kids
Design lessons from being an office flunky
Design lessons from waiting tables
Design lessons from customer service jobs
Design lessons from manual labor jobs

In game design, experience is never irrelevant

I'm always amazed at the myriad backgrounds of the other game designers I meet. In particular, it's fascinating to me what winding roads lead people into this career, and how those backgrounds end up becoming useful in our work.

Great designers come from everywhere

I've met excellent designers with backgrounds in writing, theatre, various sciences, various artistic media, the culinary arts, the military, visual design, music, production, martial arts, computer science, psychology, engineering, education, medicine, philosophy, construction, automotive, transportation, and on and on.

I used to think this was because game design was a relatively new career and no specific degrees used to exist for it, but I still seem to meet at least as many good game designers that have backgrounds in something wildly different from games as those with game design degrees.

I believe game design really is one of those fields where the wider your past experiences have been, the better you can become at it. As with fiction writers and actors, almost any experience that you've had can help you to be better at your craft. There are so many ways to learn something about psychology and motivation, why our brains think something is fun, how to collaborate with people, how to create an immersive fiction, how to methodically diagnose a problem, etc.

That's not to say that you shouldn't actively pursue game design as a hobby while you're doing all those other things. People who are constantly thinking about game design (or anything) are much more likely to recognize subtle connections and have epiphanies related to that topic, no matter how else they spend their time. Even slinging burgers or mopping floors will teach you something about the world or yourself that's useful in game design if you keep your mind primed and open to realizations.

Great designers stay curious

Once you've gotten a job as a game designer, don't see that as the signal to become complacent and stop looking to other areas for inspiration: play lots of games outside of your specialty; pursue interesting hobbies inside and outside of game development; watch your coworkers in other disciplines closely for lessons that are applicable to your job; read books across the whole spectrum of human knowledge.

Games genres are splintering and intermixing all the time, and there's no telling when your interesting side project could make you the perfect designer for a new type of game. I'm sure there more than a few designers have found surprising uses for their "unrelated" background or hobby (such as music, biology, car repair, parkour, economics, or ancient egyptian anthropology). A unique background makes you more qualified, not less.

December 13, 2008

Perfectionists Don't Want To Learn

It's great to take pride in good work, but after a certain point, perfectionism is really just another form of procrastination. It's something I've spent most of my life indulging in, and several years working to correct.

I think the thing that finally brought me around is this fourth-hand anecdote I read on Penelope Trunk's excellent blog:

Here's a story I heard from Alexander Kjerulf, who was talking about David Bayles's book "Art & Fear: Observations on the Perils (and Rewards) of Artmaking":

A ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of the work they produced. All those on the right would be graded solely on their works' quality.

His procedure was simple: On the final day of class he would bring in his bathroom scales and weigh the work of the quantity group; 50 pound of pots rated an A, 40 pounds a B, and so on. Those being graded on quality, however, needed to produce only one pot -- albeit a perfect one -- to get an A.

At grading time, the works with the highest quality were all produced by the group being graded for quantity.

It seems that while the quantity group was busily churning out piles of work -- and learning from their mistakes -- the quality group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of clay.

Think about this in your own life, even if you're not using clay. The more you practice, the better you'll get. But you can't practice if you think only of perfection. Practice is about making mistakes; perfection comes from imperfection.
Reading this story finally made me see the conflict between my desire for perfection and my image of myself as a person who loves to learn.

Believing that you can make something perfect now is believing that you will never improve. If you are constantly learning, your absolute best work now will be half as good as your average work later. Think of everything as a learning opportunity and you'll be excited to finish it and take on the next challenge.

If you can get it under control, meticulousness is a great quality to have. It can go from being something that holds you back and slows you down to being the steam engine that powers you to do great work. It's just a question of learning to recognize the right times to let it loose, and which tasks to aim it at.

Collaboration Advice For Distributed Teams

I got in a discussion the other day about the challenges of being a modder and working on a distributed team. Here are a few collaboration tips that have worked well for me, both on small mod teams and on large professional teams.

Synchronize your schedules

If you're having trouble getting a joint project done, schedule some time every night when everyone will try and meet up in person or virtually to work on the day's tasks. The amount you can get done when the other people are devoting their attention to the same problem is considerable.

I've been doing this a lot at work lately. Setting aside an afternoon to work alongside another designer, engineer, or artist means we can easily shoot files back and forth and iterate much more quickly and aren't blocking each other's progress. We've solved some very stubborn problems by getting an engineer, designer, and artist in front of the same machine for an hour, each making small tweaks until it works, then checking in all the files at once.

In an office, it can be very productive to get several people around one computer. Obviously you can't share the same computer with a remote team, but screen sharing and other tools can closely simulate that experience.

Know when you need to actually talk

There are some problems that take days to work out over email that could be solved in 5 minutes of face to face discussion, or over the phone. Learning to recognize these moments is an important skill.

Again, meeting up in person at a coffee shop or someone's place is a great way to make people accountable and get a lot done, as well as encourage much more bonding in the process. If you can't do that, try setting up everyone on a ventrillo server or at the very least a common chat room so you can all hear each other easily and not feel so isolated.

Working from home without a schedule takes a lot more discipline than showing up to work every morning and having a boss to tell you what to do, so team morale counts for a lot. This is also a great side effect of strategy #1: "It works! We did it!" is a great feeling that keeps you motivated to get even more work done.

Build a trusted team

Working together with the same person or people on several games or features is really valuable. You'll build team spirit, develop mutual respect, become very efficient, and develop a cohesive style. Collaborators who respect and trust each other are able to make up for each other's weaknesses, do better work faster, and ultimately enjoy their work more. This is very important for colocated teams, but possibly even more for distributed efforts.

But don't fear change

A good team may thrive on stability, but change promotes agility and individual growth. Since games, genres, teams, companies, and your abilities are constantly morphing, no two development environments are exactly the same.

There's a lot to learn about bringing new people onto an established team, coming onto an established team as the new person, working with different kinds of team structures, making games on different platforms, being a good boss, having a bad boss, having 10 bosses, etc.

Become comfortable in your situation, but don't cling to any situation. The game industry is a dynamic machine, and people who try to slow down the gears usually end up getting squashed between them instead.

Work on small, quick projects

You'll learn much more making 5 very fast games than half-finishing one slow one, and be more motivated. I designed 7 Sims 2 expansion packs in 3.5 years, and while those games weren't masterpieces, I went through every stage of development 7 times, while friends of mine shipped one game.

On such short cycles, I was forced to develop great instincts and learn to do things right the first time, and I became really efficient at preproduction, design docs, etc. Now I feel completely confident taking sinking my teeth into large MMO projects with much longer timelines. It's much easier to trust your decisions when you've seen them pay off several times in the past.

December 9, 2008

Don't forget to design good software

One of the most enjoyable and challenging things about designing videogames is that they have to succeed on many separate levels to succeed as a whole. Any bad element can be enough to sink the whole thing. This means that you have to trust your teammates and be suspicious of yourself. No matter how experienced you may be, there's a designer out there with twice your experience who has managed to screw up a good game.

I've seen beautiful software with bad gameplay, and amazing games held up by some pretty awful software. One of my favorite games is such a bad piece of software that after a year of playing it, I eventually, sadly, gave up on it. I still daydream that one day I'll reinstall it and the developers will have fixed all the crash bugs and awful lag and added a keybinding ui that works. I miss that game! No amount of good gameplay will save you if your software is so unusable or unstable that your biggest fan has to uninstall it.

Depending on what kind of game you're making, one aspect or another may be the most noticeable. People might not have much time to really notice the interface flaws in an 8 hour DS game, but that same UI might start driving people crazy and causing cancellations if it were inserted into an online game that people play day after day for years. Seemingly insignificant frustrations can become dealbreakers when compounded by time.
When you're working on a feature or some new content for your game, stop and take a moment to think how it will feel after 100 hours of accumulated play time. One extra click to loot a corpse can really stack up, when a player has fought 10,000 enemies, on 10 different characters, over 3 years. The extra 4 seconds it takes the game to load, or the small framerate drop due to bad implementation can start to drive people crazy.

People don't always quit games over big things. Big things ironically annoy enough people that they often get fixed fairly quickly. That one annoying detail that never gets enough complaints to be fixed can really get under someone's skin, and make them finally give up. Have you ever seen a couple start a big argument over something that you didn't even notice? Once something has a history of frustrating someone, their tolerance for it will become even lower than it initially was, and they'll begin to find fault in things that fresh set of eyes would never even notice.

As a designer, you generally can't hope to play your game even a tenth as much as your hardcore players. If you're testing your game and something seems mildly unresponsive or inconvenient to you, assume that one of your players somewhere is becoming so enraged by it that they're about to throw your game in the trash.

December 6, 2008

You are always teaching your players (Valve's Left 4 Dead cinematic)

[update: Valve posted about their intentions and process in making the intro video]

A couple of weeks ago, I watched the opening cinematic for Left 4 Dead, and I was really impressed how much it revealed about the game's mechanics and enemies. This is an excellent example of a game teaching players what they need to know.

The trailer teaches the player how to play the game, or in several cases, how not to. I'd been following the game for awhile when I saw the trailer, but assuming I knew nothing about the game at all, here's what I could learn by watching that video:

  1. (0:37) There's an enemy who cries, that you can hear from far away. If you shine a light on her, she'll go crazy with rage. Try to avoid her.
  2. (1:41) There's an enemy who can shoot out its tongue, disabling survivors and pulling them in. Kill this enemy before it manages to reel in your friends. This enemy seems to be most effective at attacking when everyone is busy fighting or otherwise distracted. It would be very good at picking off a single survivor.
  3. (2:00) Zombies are attracted to the red light on grenades.
  4. (2:21) There's an enemy who can run on walls and climb on things easily, and make huge lunges. He can knock down your friends and start mauling them, but if you get there in time you can save your friend.
  5. (2:34) Car alarms can be set off, and seem to attract huge waves of zombies in a way that normal noise does not.
  6. (2:58) There's a huge enemy that can take tons and tons of damage, and seems to disregard any collateral damage that it may do to the lesser zombies. He seems to focus on whatever survivor is hurting him the most.

After seeing this cinematic, a player can enter the game already armed with some data about how to play the game. But only because Valve made sure that the information they were giving the players was consistent with the actual game mechanics.

Imagine starting the game, being surrounded by enemies, and deciding to spend one of your precious grenades. How angry and frustrated would you feel if the zombies didn't follow the grenade like they did in the video, and you died? Or if the Witch aggroed you on her own, before being startled? You'd quickly discard all the information you thought you'd learned from the video.

At first I thought the brilliant move on Valve's part was deciding to teach players through a cinematic, but really every game's cutscene and trailer and box art have always been teaching players. Valve's brilliant move was noticing this, and making sure that what they taught their players was actually true in the game.

November 30, 2008

Solving MMO rewards for units of time

MMO Characters are Made of Time

In an MMO, what's the ultimate measure of success? A high level and the best gear, right? Well levels are really just an easier way of representing xp (a level 100 character is really just a 17billion xp character, but numbers like that are just too clunky for players to see). Experience points were invented as an attempt to approximate aquiring experience in real life, which of course can only be done by spending time on something.

Gear, powers, stats, and gold are also all just measures of time. You might have some really good stats, but you either played long enough to get a good drop, played long enough to level up higher and choose better abilities, or played long enough to earn some money to spend on the gear. Skills and crafting are the same story. If you've spent enough time improving them, they'll become high enough to reward you with more gold, stats, and gear.

Even player skill is usually only achieved by playing the game a lot and becoming an expert at it. While you might see a level 1 with lots of player skill, that skill was usually accumulated through many hours of gameplay on a different character or in another game. In that light, it's really no different from mailing some gold or gear from your main to your alt.

Ok, that's no big secret. Most MMOs reward players based on time played above all else. But we can use this fact to establish a system of rewarding players comparably for their time, however they choose to spend it .

Reward units and conversions

Let's invent a new unit of measurement called a reward-hour (rHour). It's a bit like a light-year. It measures of the rewards we expect an average player to receive in an hour of playing our game. 1 reward-hour can be made up of money, gear, stat points, reputation, new powers, or anything else with which the player can be rewarded. Let's stick with gold and xp for now. These values can be easily adjusted after the system is in place, so don't worry about exactly how much xp or gold is in an rHour. It could be different for every game, but still use the same system. That's why we'll just abstract it out to a variable.

1 rHour = some xp + some gold. It can be made up of any ratio of the two, but since we always want an rHour to be worth the same amount, we need to figure out a conversion rate between xp and gold. Then we can make rHours that are mostly xp and a little gold, mostly gold and a little xp, or about even.

It might seem strange to invent a new conversion rate between two dissimilar things, but it's really useful in game design. If we were making RTS units, we might decide that 1 unit of speed is worth 3 units of offense. We can make up conversions between any game elements we want, but it's our responsibility to make sure they feel fair to the player. More on this in another post.

Different rewards for different activities

Now we have the ability to express any activity in the game in terms of how it rewards the player gold and xp over time. This is important, because it will let us make sure we're not encouraging the player to behave in a way that we weren't intending. For example, we don't want players to get xp faster by standing in field killing (grinding) mobs than they do by completing all the great quests we're going to write.

We can start making different activities grant reward-hours of different xp/gold ratios based on how we want our players to play. I already mentioned that we want quests to give a lot more xp than just grinding mobs, so people are always encouraged to actually do the quests. To make sure all rHours are balanced, we'll have to remove some gold from questing to make up for all the xp we added. Going out and grinding mobs is probably a good way to make a few quick bucks, so that should give more gold instead of xp. We could also decide that crafting is really the best way to make a ton of money but no xp, but let's stick with combat and questing for this example.

Let's define a couple new units of measurement, for each of these two activities. We can define any number of these that we like, depending on how many different activities we want to reward. They're made of different ratios of gold and xp, but we can make sure they're worth the same amount, by converting gold into xp and vice versa.

[For example, let's say we decide 900xp and 100g are worth the same amount of time. If we want an activity to reward 50% more gold, it has to reward 50% less xp and vice versa. So a reward-hour that grants 450xp and 150g is worth the same amount as one that grants 1350xp and 50g.]

1 combat-hour (cHour) of rewards = high gold, low xp
1 questing-hour (qHour) of rewards = low gold, high xp

Actually let's divide each of those variables by 60 so we end up with combat-minute (cMin) and quest-minute (qMin). That will be more useful for the small units we'll need to measure quests.

Converting content into time units (and therefore rewards)

Now that we have units of reward for an hour of combat and questing, we can begin to use those values to define rewards for specific content.

The first thing we would need to do is figure out the average length of time for a single player to kill a creature of their level and recover from that fight. This could be calculated using combat tuning data, but for these purposes let's arbitrarily choose one minute, since it's a nice round number.

Let's say a quest requires a player to kill ten mobs, in an area that takes 5 minutes to walk to, and each of those mobs spawns with 1 other non-quest mobs that the player will have to fight. To finish this quest, the player will have to walk for 5 minutes, fight for 20 minutes, and walk back for 5 minutes.

That should yield rewards in the form of:
5qMin + 20qMin + 20cMin + 5qMin -> 30qMin + 20cMin. These values can then be converted back into xp and gold based on the equations we've established.

We had some choices here as to which rules we follow for rewarding the player. I chose to include walking time as valid qMins, as well as the time that the player is fighting. Different games could follow different rules. A different designer might choose to "pay" the player for travel time, but only at a discounted rate, which they represent in a new type of reward-hour specific to travel time.

As long as every designer on the project follows the same rules, the player should always be rewarded fairly and consistently for their time.

Because it can account for the time a player spends traveling, or fighting extra mobs on the way to a quest objective, this system should provide sizable rewards for quests, even just delivery quests that only require traveling to another location. Time estimates can be confirmed in testing, but reasonable estimates should be possible at the time of content creation.

Advanced uses and automation

It's also possible for this system to take random drops into account, using expected values based on the quest items' drop chances. If a quest requires 10 of an item that has a 10% chance to drop, the rewards can be estimated based on the player having to kill 100 mobs instead of ten.

If gear and/or stats were incorporated into the reward scheme, it would become possible to start tracking rewards in item-hours (iHour), making it easy to calculate the frequency and quality of gear rewards and even the drop rates rare items should have. If a quest chain took 2 hours to complete, and rewards only one item at the end, it can be worth 2iHours. If that same item dropped from a random critter, it would be tuned to drop with a sufficiently low rate so that its expected value coincideded with killing the number of mobs that would take the player 2 hours.

As you can see, the calculations would quickly become cumbersome. But because we've been careful to establish rules and formulas, all of the calculations could easily be automated. The ideal implementation of this system would be built right into the quest editor, estimating time based on quest parameters and allowing the designer to estimate completion time and tweak the overall reward with a tuning modifier. An advanced editor could even allow each location to be identified in world space, and estimate combat/travel time based on mob densities in those areas.

Once the system is automated, we can also introduce curves to the rate at which rewards are gained (slowly at level 1, quickly later), and a curve for how many rHours it takes to gain a level (much less than 1 rHour at level 1, many many rHours later). This system can be used to calculate the total number of hours required to reach the level cap, the total amount of quest hours in the game or a given zone, etc. This way we can find a zone that is light on content for the amount of time we expected a player to spend there.

Data-mining can also be used to calculate rewards that players are actually earning per hour, which will allow us to go back and refine our calculations as time goes by. We can use statistical analysis to check if the average player spends their average hour within the middle of the bell curve, and to see how fast or slow the best or worst players seem to be progressing.

As you can see, this system could become the tuning backbone for the whole game. It will scale to be as large and complex as we allow it to. It could take several days or even weeks to implement, depending on complexity. However, over the life of an MMO, which might contain many thousands of quests, mobs, items, bosses, etc., a simple method for reliably tuning rewards for them would cumulatively save months of effort.

November 29, 2008

Why variables are a combat designer's best friend

When people find out I design videogames for a living, and invariably ask me "yes, but what do you DO," I often joke that if you sat behind us and watched us work all day without knowing our job titles, you might think we were a bunch of accountants on casual Friday. MMO Combat Designers in particular spend a large proportion of our day dealing with numbers in various forms. For example, every power, item, piece of gear, aggro range, AI profile, and character are all big clouds of data, comprised mainly of a huge amount of numbers, with a few text strings (display name, description) thrown in.

A misconception that many people have about tuning a game is that designers actually go through and type in specific numbers for every value in the game: "This creature will have, hrm, 247 points of health, and its attack will hit for, oh, let's say 37 damage every 1.7 seconds." If you've got thousands of creatures in your game, the first pass of tuning alone would take an incredible amount of time to enter and test, and more importantly, revisions would be incredibly hard to do. If you decide you need to revise all [5 thousand!] of your enemies to have 8 percent less health, and you've entered them all by hand, there's not much to do but have a good cry and cancel your weekend plans.

This is where abstraction (also known as variables or references), comes in. Using a variable to stand for a number is a common practice in all aspects of game development and programming, but your first exposure to it was probably 7th grade algebra (If A = 5, and B = 2A, then B = 10).

You can create a central database for your game where different amounts of health and damage are defined and assigned variable names, for example Normal_Creature_Health and Normal_Creature_Damage. Once defined, you can now use these variables to tune a creature in a way that does not require literal numbers: "This creature will have 1.5*Normal_Creature_Health as its hit points, but its attacks will only do .5*Normal_Creature_Damage."

Setting tuning up with variables has several benefits to designers and players:

Benefit 1. Any other designers who look at this creature can clearly see that it's doing less damage than other creatures but has more health, without having to look through several other sets of data for comparison.

Benefit 2. The variables Normal_Critter_Health and Normal_Critter_Damage can be defined in a central location, and dynamically multiplied by level (Normal_Critter_Health at level 1 = 40, while Normal_Critter_Health at level 2 = 44, etc).

Benefit 3. The same is true for other pieces of data. Perhaps a creature marked as Epic gets its health points multiplied by a further 1.5, after its level has been taken into account.

Benefit 4. Now when defining creatures, all that's important is making sure the creatures are balanced against each other. As long as a big brute has lots of health, and the weakling caster has very little health, in a ratio that is properly balanced, it won't matter later when someone need to go back and tune Normal_Creature_Health to be 235 instead of 892.

Benefit 5. These numbers can be abstracted even further. If most brute creatures have 1.5*Normal_Critter_Health hit points, and most casters have .7*Normal_Critter_Health, why not define new variables called Brute_Health and Caster_Health? Suddenly, instead of having to type a number at all for a creature's health, it becomes possible to just choose its category from a list that includes Brute, Caster, Healer, Hostage, 5_Man_Boss, Exploding_Barrel or anything else that will come in handy for your game. Then, if you like, you can still have the option of adding multipliers to those values per creature, or just leave the field for modifiers off and agree to never worry about an individual creature's health again.

Benefit 6. Tuning health through these variables will always allow your players to accumulate knowledge of how difficult a given creature will be, and to feel more like a master of your game. (How to keep players informed, mastery, and the benefits of standardization are all likely candidates to receive posts of their own some time soon.)

After seeing how variables work for creature health, it's not much of a stretch to see how they could be applied to other areas of the game.

  • You could add in damage numbers to match all of the creature types (Caster_Damage, Brute_Damage, 5_Man_Boss_Damage) and allow those to be called by an attack power.
  • You could define variables for small chunks of a given attribute, and apply those to gear (This sword gives the user some damage and some health, in the amount of 3*Item_Damage and 2*Item_Health).
  • You could tune quest rewards based on fractions of XP_Hour, the amount of XP the player is intended to be able to earn per hour .

There are also ways to get the functionality of variables without a game engine needing to support it. I have a friend who worked on a game that didn't have much in the way of editors or tech support for designers, so he created a big spreadsheet that handled all his variables and dynamically generated a ton of data, which then then pushed to the game data with the use of a script he had written. It saved him a lot of time, but obviously this method can be a lot more dangerous if you're not as good with scripting as he is.