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.

November 28, 2008

3 design guidelines that will improve any game

In general, I disagree with people who try to teach design as a long series of rules to follow. I believe that any good game design depends heavily on context. The best death mechanic in a PvP game might not be the best decision for a PvE game; the best control scheme for a 3rd-person brawler won't necessarily feel good in a first-person shooter, the leveling curve must feel different between a "casual" and a "hard core" game, etc.

I'm a very systematic, process-oriented designer, and so I tend to think that the best way to design is to establish a list of values, then work through a thorough design process, using the values and context to weigh each design decision. I'll write a much longer post on this later, I'm sure.

All those caveats aside, I do believe there are 3 very generic guidelines that can improve any game, and that I will always follow in every game that I design. 2 of them are about teaching players, and 1 of them is about usability, so I suppose that gives a pretty accurate picture of what my priorities are.

1. If you want to change your players' behavior, you need to change your game design.

Letting players loose on your game for the first time can be a very jarring experience for new designers. It's the moment that you often find out the game that you thought you made isn't the game your players think you made. And the players are always right, so let me save you months of frustration by telling you not to try and fight it.

Almost all of the funniest war stories game designers tell each other are really about the difference between how the design team expected the players to use a system, and how the players ended up actually using it. There are some very famous example of this effect, which deserve a post of their own later. The important thing to take away now is that the players are not just crazy. They're using your game in the way that they've been encouraged to, either mathematically, psychologically, or socially.

Practically any behavior can be encouraged, discouraged, or prevented by careful game design, especially reward systems. If players are misbehaving, it is likely because the game design is allowing or even encouraging it.

2. The game must teach the player what the game expects the player to know.

I was watching a friend play Mirror's Edge the other day. He'd been playing it for several days, and was well over halfway through the game. After reinforcing in mission after mission that the game is about running across the rooftops, relying on speed and agility to save you, the game suddenly stumped us with a new requirement: After trying everything we could think of to get high enough to jump over a barbed wire fence, we finally noticed that when we stood on the ground next to the back door of a truck, we had the option to interact with the door, and enter the truck.

After all the learning we had done in the game, the game suddenly required us to know that it's possible to hide in the back of a truck and wait for it to be driven through a checkpoint. This was something the game never taught us previously, which made us angry when we finally realized what we were expected to do. We had been trying to play the game the "right" way, and suddenly the game decided that the right way was now the wrong way. Which leads me to a sidenote...

Corollary 2A. The game should never teach the player to do something the player is expected not to do(!!)

While it was frustrating to waste so much time on what should have been a simple task, the real damage may have been done to our ability to enjoy the game in subsequent levels. My friend and I have now both been trained to think that Mirror's Edge is a game that's almost always about finding a way through the rooftops and using speed and agility, but also sometimes a game about clicking on the back door of a truck to hide in them.

For the remainder of the game, when we are presented with a challenge that we can't figure out, we will now be compelled to doubt that there is a movement-based solution to the problem, and start walking around trying to interact with things that never did anything before, just in case the designers decided to throw us another curve ball. Walking around and clicking on things is specifically what the game is not intended to be about, so by adding that to the list of problem-solving options at our disposal, that unnasuming truck is forcing players away from the core of the game's fun.

This example also serves to illustrate how important guideline number 1 is: if your players are walking around slowly clicking on things when you want them to be flying through the landscape having fun, figure out what aspect of your game encouraged that behavior and remove it.

3. Whatever actions the player will perform the most often must be the easiest actions to perform.

This guideline doesn't just apply to designing games, but to designing anything at all. (Despite this being a game design blog and me being a game designer, I believe that many tenets of good design apply to any type of product.) Because of that, it will actually be easiest to convey with examples from industrial design.

Take a look at this image of an alarm clock's UI buttons. There are tiny buttons to change the time zone, the year, the time, and a giant snooze button. What's the ratio of the number of times you want to tell your alarm clock to snooze versus do any other thing such as change alarm time, set the time or date, or anything else? I'd guess in my case it's over 100:1. How silly would it be if the snooze button were the same size as, or even smaller than, the time zone button?

A hammer only does two things, and one of them is much less common, but still important. This hammer is a pretty fancy model with an ergonomic grip and a curved handle. Which do you think the shape of the handle is optimized for, hammering in nails with one side, or pulling them out with the other? It actually looks like they've put some effort into angling the claws so that there'd be better leverage when pulling out nails, but I can guarantee you they wouldn't allow nail-pulling comfort to interfere with nail-hammering comfort or effectiveness.

Ok, these are insultingly obvious examples, but there are lots of videogames that are more like a swiss army knife, where you've got to locate and deploy the tool you're looking for before you can use it. Depending on the action you're trying to perform, even hitting one extra keystroke, clicking one extra mouse button, or expanding one extra menu page can build up into a huge amount of perceived inconvenience over tens and hundreds of hours of use.

I'll delve into this more later, but let's take some quick examples from an MMO. In this type of game, there are a set of actions that players are frequently expected to perform:
  • Determining how difficult a challenge an enemy poses
  • Looting mobs
  • Finding and accepting quests
  • Turning in quests
  • Evaluating a given piece of gear against current equipment
  • Purchasing new abilities
  • Joining a team
The items to the bottom of this list aren't as common as the ones at the top, but the first two on the list might be performed several times PER MINUTE, and the next two many times per hour. It's important in an MMO that those tasks at the top of the list can be performed almost effortlessly and without conscious thought, and those at the bottom of the list can be found very easily by a new player without having to resort to a manual or webpage.

Again, take note of how this rule interacts with the previous rules: Players need what's important to be easy, but if the "wrong" things are presented to them as the most easy to do, they'll be taught to perform those actions frequently, and if you want to stop the players from doing something, look at what aspect of your UI design is encouraging them to do so and change it. One quick example: if your game is not about players tracking down and terrorizing other players, don't show enemy players and their screennames on the rader/minimap.

I hate to encourage the idea of immutable game design rules, but I do believe that any designer who follows these 3 guidelines will produce games that are of higher quality and more likely to be perceived of fun, regardless of their mechanics.

November 27, 2008

3 Common Pitfalls For Design Teams

Over the past few years, I've noticed 3 difficulties that design teams of all shapes and sizes seem to have in common. Fortunately, these problems are all easy to diagnose and correct, with a little discipline.

1. Good designers talking past and frustrating each other because they've failed to agree what problem they're trying to solve.

Many "bad" design suggestions are actually good solutions to misdiagnosed problems.

If you've ever heard a very smart person suggest what you think is a very stupid solution to a problem, chances are that the two of you simply don't agree on what the problem is. This happens constantly in game development. Everyone may agree that a feature needs some work, but don't assume that everyone is on the same page with regard to what is wrong with it.

Solution: Taking 5 minutes at the beginning of a brainstorming meeting to list and prioritize the problems that need to be solved can save everyone a huge amount of misunderstanding, frustration, and extra work. It will also make the meeting much shorter, and provide a criterion by which to evaluate proposed solutions. For example, if problems have been listed and prioritized numerically, a solution that improves problems 2 and 3 but makes problem 1 worse can be easily discarded without argument.

2. Rushing through brainstorming and design to implementation, only to throw away all that work later.

Iterating mentally, on paper, and in brainstorms is easy and cheap. Redoing work and throwing away features is hard and expensive.

Game design is often like one of those old parables about a mischevious genie: you have to be very careful how you phrase your wishes. Often getting exactly what you said you wanted can result in gameplay that is unsatisfying, frustrating, or easily exploitable. This is especially true in MMOs or other large games where many systems can have strange interactions.

Sometimes an otherwise well-designed system can interact in strange ways with your player experience or IP. For example, it's a common practice to fight weak enemies at the beginning of a game, and work up from there, but if you're making a Superman game, you'll have to think very carefully about how weak those enemies will be before it seems strange that they pose a threat. Perhaps the easiest enemies in a Superman game should be soldiers with flamethrowers, when in a World War II game those might be the most difficult enemies at the end of the game.

Solution: Fully write out docs for any new system or feature, even if it's one that will be "just like we did it last time" or "just like the one in game x." Even if the feature manages to be the same as it was before, the game surrounding it is not. Make note of features that are likely to have strange interactions with the new system, and follow up with the owners of those systems to make sure an ideal interaction is agreed upon and recorded in the design doc.

Make a point to think about and discuss how aspects of the game will actually FEEL, not just how much effort it will take to implement them. Describe it out loud, act it out, or draw it on the white board. Also make sure to consider how the game will feel when the player fails, not just when they succeed. It may feel fine for Superman to throw around a bunch of bank robbers, but how will it feel if one of the bank robbers actually kills Superman with his pistol? Maybe that enemy shouldn't be in the game at all, or maybe Superman shoudn't be able to die in the first place.

3. Thinking of polish as something that only happens right before the game ships.

Real polish is a mindset or value, not a stage of development. It's something that begins in preproduction and never ends, not a coat of paint to apply right before the game ships.

Developers like Blizzard and Valve are known equally for the quality of their games and for the long amount of time they spend working on them. Clearly the extra time gives them opportunity for lots of iteration, but I'd wager that given a hard deadline both those companies would make a more polished game in one year than many other dev houses.

There are lots of problems with roughing something in and intending to go back and polish it later:

  • If the person who was intending to fix it either forgets, moves off the team, or leaves the company, it will either never be fixed, or be fixed by someone who did not originally implement it, taking longer and possibly even introducing more problems.
  • If the team was reserving 4 months at the end of production for polish but ends up having to ship the game 4 months early, the game will have lots of unpolished content, instead of less content that is still polished.
  • Revisiting content or a system to add more polish often requires more time from Art, Engineering, and QA, all of whom may have considered themselves finished with the element in question. This will either cause the schedule of the whole project to need reshuffling, or result in the feature never receiving the polish at all.
  • If a polished version of a feature is never considered during initial design, it's possible that it will be implemented in a way that does not allow the additional functionality to be added in later. Then the only two choices are to tear out the system and reimplement it, or to leave it unpolished.

Solution: Always take the time to polish designs, implementation, and tuning as much as possible right up front. If it's absolutely impossible to get something polished properly due to tech that's not yet implemented, at least make tasks or bugs for each of the fixes needed and hold onto them, so the fixes won't be forgotten.

Planning to spend time at the end of the project to further polish is a great idea, and can make a big difference to quality, but it's important to develop as though that time will never come, because it often won't.