I’m rather fond of the game.  In fact, I’ve created a collection of 20 new scenarios for it, which you can find over here.  You’ll also find some musings on Haunt design (also partially applicable to strategy) and some reference tables I used while doing it.

I also made a WarCraft 3 Map inspired by the board game for Blizzard’s 2006 Halloween mapping contest, though it didn’t work out as well as I’d hoped.  Turns out that introducing a bunch of new rules and objectives half-way through the game doesn’t go over as well in a real-time Internet game as in a turn-based face-to-face one.  Who’d have thought?

Suppose you were designing Go Fish.  You need a bunch of cards divided into several groups (ranks), but each member of the group is interchangable, so your first thought is probably to print a deck of cards with 4 identical copies of each of 13 symbols–a set of playing cards without suits.  However, as the reader is doubtless aware, you can play many games other than Go Fish with a deck of playing cards–but most of them require suits, and not just ranks.  If you print 4 slight variations on each of 13 symbols instead of 4 identical copies, your deck is still just as good for playing Go Fish, but now you can play a lot of other games you couldn’t play before; more people will buy your cards, because some people who don’t care about Go Fish will buy them for playing, say, Bridge.  You get more, happier customers, and you can even sell books containing rules for more games to play with your cards without the cost of actually manufacturing any additional game components.

Playing cards are a good example of an extensible game system–you can easily reuse the same components for playing many different games (or variations on a single game), because they are generic without being redundant.

Take a look at another game:  Betrayal at House on the Hill.  This game features a variety of different scenarios that use the same basic rules but vary in their details, goals, and–you guessed it–playing pieces.  Depending on the scenario, you may have zombies, vampires, ghosts, demons, wolves…you get the picture.

One of the core rules of Betrayal is that when you damage a monster, it becomes stunned, and you flip its token over to expose a large “S” symbol on the reverse side.  However, a few scenarios have special monsters that don’t become stunned when you damage them, so the designers made both sides of those monster tokens identical.  They probably thought they were making the game easier to use, since you wouldn’t need to worry about which side of the token was up, and maybe you could find it more easily–but they also made it much more difficult to use those tokens in any scenario other than the one they were designed for.  If players want to create their own scenarios–or if the publisher wants to make an expansion–those monster tokens have no way to indicate that the monster is stunned.

And in fact, the results are much worse than that–the designers overlooked the fact that there’s a special item that can be used to stun any monster, even if the monster isn’t normally stunned when it takes damage.  (Maybe that item was added later?)  And they’ve already published revised versions of the scenarios to fix a variety of problems discovered after publication–and some of those changes cause previously unstunnable monsters to now be stunned normally.  Oops.  If they’d included the “stunned” side on all the monster tokens in the first place, this would be no problem–but they printed themselves into a corner, and now players need to make up another way to keep track.

There’s also a few tokens that have different things on each side, but neither of them is “stunned.”  In this case, it’s understandable why there’s no “stunned” side–there was no space for it; they would have needed to print extra tokens (and possibly complicate some other mechanics) in order to fit them.  And you can probably use whatever is printed on the reverse as a stand-in for “stunned” if you have to.  But many tokens are completely identical on both sides.

Betrayal also features some scenarios with a group of interchangable monsters, and others with monsters that are similar, but need to be distinguishable.  For example, there are 6 “specter” tokens, and they’re all the same.  But there’s also 6 “evil twin” tokens that you need to tell apart, so they’re numbered (evil twin 1, evil twin 2, etc.).  Once again, if they overlooked something, or if they ever want to change the scenario, or if anyone wants to re-use those tokens in a new scenario, they can’t have 6 unique specters in the way they can have 6 unique evil twins, because they just didn’t write the numbers on.  They didn’t think they needed them.  But adding numbers to the specters wouldn’t have hurt anything, and it would have made the game more extensible.

The game also has some very interesting dice that are numbered from 0 to 2 twice (six sides, two each of 0, 1, and 2).  Sure, it’s not a big deal, but they could have printed the numbers in different colors or arrangements to make the duplicate sides distinguishable, just in case you ever need to have a 1/6 or 1/2 chance of anything.

I suggest the following rule-of-thumb:

No two symbols should be identical without a good reason.

The backs of the cards in a standard deck are all the same, because their function is to conceal the card’s value.  The fronts are all different.  “Cost savings” might be a valid reason, but I’ve seen a lot of games with two-sided tokens punched out of the same cardboard sheet as one-sided tokens (or tokens with two identical sides).

In general, two sides of a token should be distinguishable, even if they mean the same thing in your game (at the moment).  Two separate tokens should be distinguishable, even if they are interchangeable in your game (at the moment).  If you need dozens of small or detailed tokens to be interchangable, this might not be practical, but in many cases it is.

Doing this not only allows your players to create new games or variants from your components (increasing the value of your game for free), it also means that if you decide to make revisions (or expansions) to the game, you keep all your options open.

One of the hardest parts of comparing the effectiveness of two player options–for example, turning invisible versus hurling a fireball–is often finding a common basis for comparison.  Let’s face it, in terms of their immediate effects, those probably accomplish completely different things.  They probably synergize in different and complicated ways with a whole host of different circumstances and strategies, so we don’t do them justice if we consider simply swapping in one for the other in an otherwise identical strategy, and their effects on the game’s final outcome are probably (intentionally) virtually impossible to predict in the general case.  We’re comparing the proverbial apples to oranges.  Where do we even begin?

Resources

As usual, there’s no silver bullet, but one widely-applicable strategy is to abstract the game state as a set of resources, by which I mean quantifiable assets that can be expended to change the course of the game.  For example, ammunition is a resource–you can use it up in order to fire your weapon, which is one of the ways you can affect the game’s outcome.  “Mana” (or energy, power, etc.) often serves a similar role in fantasy-themed games.

Hit points are a resource; they allow you to not die when you suffer damage.

Game money is a common resource; it’s often used to obtain other resources or paid in order to accomplish actions like securing a safe place to rest, bribing in-game characters, etc.

Perhaps most importantly, time is a resource–sometimes in-game time and real time are separate resources.  There’s generally a limit to how many things you can do at once, and/or how long it takes to complete an action (and if the game limits the amount of real time you can spend doing something, it’s a resource you use up while you’re observing, thinking, planning, etc.).  Often there are game actions that only cost you time, and no other resource.

The set of resources can vary a lot from game to game, and sometimes there’s more than one way to abstract a single game into different piles of resources.

But once you’ve made this abstraction, you can express a lot of the things that happen in the game as conversions between different resources.  For example, maybe a healing spell looks something like this:

Healing Palm:  Converts 25 mana (spell cost) and 1 round of your time (casting time) into 100 hit points (spell’s effect)

A fireball reduces enemy resources (hit points) at a cost of your own (mana, casting time).  A teleport spell uses up mana (spell cost) but saves time (the time of traveling to the destination by conventional means).  Taking a defensive stance might cost time (that could have been spent attacking, for example) but conserve hit points when you get attacked.

Of course, not everything can be easily expressed as resources, but this abstraction still often allows for a more simplified comparison.  Even if an action has a weird effect that’s hard to quantify, you can usually express its cost (or opportunity cost) in terms of resources, and then at least you only have a wacky unknown on one side of the scale.

Duty Cycles: Refreshing Resources

Once you’ve identified some resources, you should figure out how and when each of them is limited.  Ask yourself:  how do I get more?  What happens if I run out?

In the classic RPG, at the end of an adventure, the party goes back to town, stays at an inn, and emerges bright and fresh the next morning, with all of their health, spell points, etc. restored to them.  If this is the primary way you recover after fighting, then those resources basically need to last you until the next town–at which point any extra you may have remaining doesn’t matter.  Many other games have a similar expectation that you “refresh” all of your resources in some regular cycle.

But not all resources necessarily refresh on the same time scale.  If you’re in the middle of a battle, your time is probably tightly budgeted, and every second you spend casting a healing spell or rooting through your inventory for a potion is giving your opponent “free” attacks against you–but between battles, you may be able to change your equipment, rearrange your inventory, and cast as many spells as you want without worrying about how much time it takes.  If you’re trekking through the wilderness, you may be able to recover some resources by sleeping in your tent every night–but if you run out of supplies (food, potions, etc.) you can’t get any more until you reach a center of commerce.

The different schedules for refreshing resources are extremely important, because they’ll usually tell you exactly where to make a distinction in your analysis between “short-term” and “long-term,” and they’ll tell you which variables are strategically important in each timeframe.  If your mana gets reset every hour but you slowly build up victory points over the length of the whole game, that already speaks volumes about how to strategize in the game.

Converting Resources

Once you’ve abstracted a lot of your game choices into resources, you’ll want to try to ensure that the usefulness of each resource is fairly consistent.  You should start by looking at two things:

1)  The efficiency with which one resource can be transformed into another (for example, turning mana into health with a healing spell).

2)  The efficiency with which one resource can be substituted for another to accomplish a given effect (for example, using mana to make a more powerful attack versus taking an extra round to make two attacks).

By doing this, you can begin to build up a picture of the conversion rates between different resources (even if they can’t be freely converted all the time).  If a regular attack deals 100 damage, that suggests the time it costs you to make that attack is valued at around 100 damage.  If there’s also a special attack that deals 150 damage at the cost of 10 mana, that suggests a point of mana is considered around 5 times as valuable as a point of damage.  And so on.

These conversions generally won’t (and shouldn’t) be exactly the same across all actions; you get strategic depth by making some resources more valuable for some things and less valuable for others, and the game should probably be taxing the player some of his resources when he wants to perform an unusual conversion.

By varing the efficiency of different resources, you can establish which actions are “staples” (things that you do a lot, or when you don’t have any particular reason to do something else) and which are specialized tools that you use only when the circumstances require it.  For example, if the wizard is supposed to rely primarily on spells rather than physical attacks, his spells should be more efficient, giving him an incentive to switch to physical attacks only in unusual cases (like when he runs out of mana, or when an opponent is immune to magic).

You can also establish what positions you want to be in, and what positions you want to force your opponent to be in–for example, if your attacks deal more damage (for the same cost) when you stand on higher ground, then standing on higher ground is a tactical advantage, because it allows you to use one of your resource conversions (time into damage) more efficiently.

Many games have a resource hierarchy, where resource A can be converted into (or substituted for) resource B, but not the other way around.  This establishes that some resources are more valuable because of their flexibility (even though they might not be more efficient).

You should also look for resource conversion cycles–ways that you can convert one resource into something else, and then eventually back into the original resource; for example, sacrificing health for mana, and then using a healing spell.  You usually want to avoid having any cycles that generate resources from nothing (where you get back more than you put in), but remember that time is usually a limited resource, so even if you end up with more of the other resources than you started with, if you lost valuable time, it’s not really something for nothing.

Conversions between resources on different time scales are particularly important, and often signal some of the most important strategic trade-offs in a game.  For example, maybe you can spend some gold (a cumulative resource that has no maximum and never gets “refreshed”) in order to buy a potion that you can drink to restore health (a resource that gets automatically refilled every game day).  You’ll get back all your health anyway if you can just survive to the next day, and the same cannot be said for your coin, so this is a poor exchange–unless, of course, you aren’t going to survive to the next day without that potion.  The goal then becomes to survive using as few potions as possible, so that when a new day dawns and you have maximum health, you also have as much gold remaining as possible.

Conversions that go the other way (trading ephemeral resources for more permanent ones) are dangerous to have in a game, but sometimes workable.  The ideal way for the player to use those conversions is to trade all of his short-term resources for long-term ones right before they expire, which means the player effectively has the ability to generate long-term resources every refresh period, but that the amount generated depends on how well he manages the short-term resources.

This can lead to very bizarre strategies, especially when the number of refresh periods is variable–for example, in some CRPGs (Final Fantasy or Legend of Dragoon, for example) you can convert battle actions (a resource only relevant on battle timescales) into HP (a daily resource), so it makes perfect tactical sense to deliberately start lots of battles with weak enemies (or prolong battles after enemies have nearly been defeated) in order to maximize your longer-term resource.  This is counter-intuitive, and doesn’t make sense from the perspective of the game’s story, but that’s what the mechanics support.  This sort of conversion always raises red flags for me.

As for the rest…

You may recall, back at the start of this article, I used a comparison between a fireball and invisibility to begin this discussion, and the canny reader may be wondering exactly what resources could possibly represent invisibility.

Depending on the exact function of “invisibility” in the game, and the goals of the game, you may be able to abstract that as denying your opponent the use of certain actions (like targeting you with an attack), thus forcing them to do something less resource-efficient instead and/or saving you resources he might have taken away (like health).  Or maybe you can look at it as depriving your opponent of information, decreasing his ability to find the best use of his resources.  But in some games, you probably just aren’t going to be able to give it a rigorous representation in the resources abstraction.

But even if you can only analyze some parts of a game using resources, that still makes the analysis as a whole easier, by reducing the number of special cases you need to worry about.  It also gives you a nice measuring stick–even if you can’t precisely quantify the effects of a choice, you can compare it to other choices that you can quantify.  And the more of the game you can understand, the better an intuition you’ll develop about the remaining parts.

On the face of it, this is rather odd.  Games are fundamentally about making decisions–whether strategizing or just “playing around”–and adding in random outcomes can only reduce the amount of control the player has.  Why would so many games engage in such an apparently self-defeating behavior?  Other than the ones that are doing it to get your money, I mean.

Well, I think there are three significant reasons a for game to include randomness…

The Spice of Life

Randomness can be used to help ensure the game is different each time you play.  Confronted with a given situation, many players will repeatedly make the same choice–partly out of habit, but mostly because what seems like a good choice the first time will probably continue to seem like a good choice (in the absence of strong indications otherwise).  If the player is presented with a different choice each time he plays, or if a single choice leads to different outcomes, then the player is more likely to have an original experience.  In short, randomness can add variety, or generate content.

If this is the only purpose, then ideally, the randomness doesn’t affect the game’s difficulty, just it’s “flavor.”  However, it’s difficult to ensure that all outcomes present equal difficulty to the player.  More importantly, randomizing the success (or degree of success) of an action is often the easiest way for the designer to add randomness, so sometimes that is used to add variety (through cascading effects on the game state and player strategy) even though it primarily affects how favorable the game is to the player.  With a large enough sample of random inputs, the overall affect on difficulty may be fairly predictable.

Of course, players don’t always make the same choices–especially if those choices didn’t work out so well last time.  Players who are competing with one another are especially likely to vary their choices in an attempt to out-guess each other.  So even if the rules of the game don’t explicitly include random variation, there’s usually some introduced by the players themselves.

Risk Management

A related reason that designers may introduce randomness into the results of players’ actions is simply to complicate the game’s strategy.  Managing risk is a basic but fairly complicated task; the more uncertain players are of the results of their actions, the more they need to think ahead and plan contingencies.  Instead of simply determining the strategy with the best outcome, players need to weigh risks and consider an ever-widening array of eventualities.  This increases the cognitive complexity of the game and provides a good way to make the player lose.

Note that it’s still not actually necessary for some random outcomes to be strictly better than others, just for them to be contextually better.  The appearance of a red stone is better for me than the appearance of a blue stone if I’m prepared to use the red stone (but not the blue one) to my advantage, even if there’s nothing inherently better about one or the other.  To a certain extent, players can orchestrate their own risks if they merely have the tools (and the strategic incentive) to wager on one outcome or another.

And again, this type of variation doesn’t necessarily need to be built into the game.  Players who are competing with one another generally need to anticipate each others’ future decisions–and there’s usually some uncertainty about how your opponent will choose to act, even if the rules themselves are completely deterministic.  However, this relies either on hidden information (your opponent makes a choice without full knowledge of the game state, or you don’t learn of his choice until some time later) or upon player mistakes.  Perfect players with perfect knowledge of a nondeterministic game will always act the same way (though figuring out what way that is may have as much complexity as preparing for random choices).

Fuzzy Wins

The final reason I can see for randomness–and really the only (principled) reason for some random outcomes to be strictly better for the player than others–is to reduce the chances that the better player wins.

That may seem like a very bizarre goal, but it makes a lot of sense if you think it through.  Games are often very complicated and involved activities, and we often want to emphasize the game’s subtleties and variations, but at the end of the game we reduce the player’s entire game to one bit of information:  either they won, or they lost.

Naturally, we expect the better player to win.  But what happens if you play again?  Do we want the same player to win every single time–even when the players are very closely matched?  Do we want the best player in the world to have a 100% win rate against the second-best?  That doesn’t really seem fair; it certainly doesn’t seem representative.

Imagine we’re trying to gauge the relative skill of two players by who wins or loses.  If the better player always wins, then we can tell who’s better, but not by how much.  The loser could be almost the winner’s equal, or he could be the worst player ever to live, and we couldn’t tell the difference.  By reducing a lot of information (the entire game) down to a single bit, we lose a lot of data.  This is called quantization error; we’ve changed the average value of a signal (who plays better) in the process of compressing it.

The solution to this problem is called dithering.  You can get a much better average result if there’s some randomness in the outcome of the game; instead of the better player always winning, we want him to usually win, and to win more consistently the greater his skill.  We can determine that player A is much better than B but only slightly better than C if he beats B 95% of the time but only beats C 60% of the time.  Even though the individual games where A loses seem unfair, in a larger context, they give us a more accurate picture of how well each of the players are doing.

And really, a game is much more interesting if there’s a chance of an upset.  There’s not much excitement in watching a game when you know the outcome; there’s not much satisfaction in winning if there’s no risk of defeat; and most players probably won’t play very often if they’re certain of losing.  Introducing a little noise into the outcome makes the game more interesting all around.

The amount of noise you want is really a stylistic choice; as the outcome of a game becomes more random, the difference of player skills it accommodates increases (you can play better/worse players with the same chance of an upset), but the harder it is to play the game competitively–for a serious competitor, to play better and still lose can be extremely frustrating.  Therefore, you generally want more randomness in a game meant to be played casually, and less in a game meant to be played more competitively–but you don’t want to go too extreme in either direction.

Now, it might be objected that players are generally not perfectly consistent in how well they play; even in relatively simple and purely deterministic games, such as chess, there’s a lot of uncertainty in the outcome of a game between two similarly-skilled players.  This is entirely true–you can’t completely get rid of randomness in most games, even if you want to.  But that doesn’t necessarily mean you shouldn’t introduce more.

And there’s another principled reason to want dithering, even if players’ performance is already random–it would be nice to be able to measure the difference not only between players, but between strategies.  If strategies A and B both lose to strategy C, we haven’t learned anything about which is better, and we can’t say that the person who uses A against C played better than the person who used B (or vice versa).  If strategy A wins 40% of the time and B wins only 10% of the time, then we can say that strategy A is a better response to C than B is, even though A still usually loses.  And being able to say that is useful not only for analyzing the game, but for learning it, too–it means players can see that moving from B to A is an improvement.

So it’s not so surprising that lots of game include randomness, and even randomness that affects little besides the outcome of the game:  despite appearances, it can actually make the game more fair overall, even though a given play may seem less fair.

Unfortunately, most players have neither unlimited patience nor perfect memory, so that typically doesn’t happen.  Players who want to play your game will generally want to start with as little time commitment as possible, and they won’t remember everything you tell them.  So in order for them to play the game, it has to be possible to learn at least some things as you go along.  The game has to be self-documenting: the game itself needs to contain the information necessary to play it.

This doesn’t mean that you should have a button in the game that brings up the player’s manual (though perhaps you should), but that players need to be presented with context-sensitive help giving them information relevant to their current situation.  If the player wanted to simply hear everything you want him to know presented in the order you think is best, he’d be reading the manual.  What he probably actually wants is precisely the information that will get him safely through the next ten seconds of his game.

This is challenging for a couple of reasons.  First of all, it means we have to be flexible in the order concepts are presented–if the explanation for feature B doesn’t make sense until you understand feature A, then if the player manages to grab feature B before looking at A, we have a problem.  Secondly, we need the documentation to be concise and separable–we need a way to quickly and conveniently inform the player of just want he wants to learn, without flooding him with information that’s extraneous to the task at hand.  And third, we need to somehow figure out what the player wants to know–and determining intent is rather difficult.

However, I am happy to report that many programs actually do a pretty good job of this, and some general tools exist for making it easier.

Tooltips

One great tool is the “tooltip”–a small bit of information that pops onto the screen describing something the user is looking or pointing at.  Tooltips are becoming quite common, and it’s because they do their job very well:  they provide information on the object of the user’s attention, and (usually) only on that object.

Because they appear only on a specific cue, we don’t clutter up the screen with information the user isn’t interested in, and the user can easily seek more information about anything on-screen simply by pointing at it.  And if tooltips get in the way of experienced players, it’s simple to include an option to turn them off.

The idea of tooltips generalizes to the practice of attaching a description of something to that thing; in a tabletop game, it might be putting the rules for a card or a playing piece on that piece.  Customizable card games can be easy to learn (though they often aren’t) despite having an enormous number of rules, because each of the cards includes most or all of the information needed to understand that card.

Of course, while tooltips are a great method for presenting information to the user, nothing about them makes the information particularly easier to write–many programs are plagued by confusing or uninformative tooltips.  They really only help with the third problem from my list, not the first two.  If you’re not careful, you’ll end up documenting your user interface but not the game itself (or vice versa), and that’s generally fairly unhelpful.

Technical Terms

Games each have their own set of rules, which are often abstract and somewhat arbitrary.  In order to describe them clearly and concisely, it’s often helpful to define your own technical vocabulary.  If you play a lot of video games, you’re probably familiar with a lot of common technical terms:  hit points, buffs, cooldown time, save points, line-of-sight, fog-of-war, and so forth.  Assigning specific names to abstract game concepts helps the player to understand how the different parts of the game interrelate, and makes further discussions of what happens in the game much smoother.

Your terms don’t even need to be words–symbols are frequently just as effective.  Once you’ve trained the player to associate a heart symbol with hit points or a circular arrow with cooldown time, you can construct interfaces that are smaller and easier to read without losing any information.

Once you’ve defined some terms, they also provide a convenient structure for supplemental help.  One of the great things about the web is that it’s taught everyone that you can get more information about a colored word or phrase by clicking on it; this provides a way for the designer to make more detailed information readily available to the player at a time that the player is thinking about it–again, without cluttering the screen with lots of complicated information unless the player asks for it.

However, one common trap here is to use the same word to refer to two related but different things.  It’s easy to end up using “attack” to refer sometimes to a “standard” weapon use and other times to any offensive action, to reuse a taxonomical term as one of its own sub-categories, to apply the same name to a culture and a political faction, and so forth.  While this sort of re-use often seems natural when you begin talking about the concepts, it can quickly mire you in confusing or ambiguous exchanges, and I think it’s usually worth the effort of inventing another term in order to avoid re-use.

And of course, there’s a more fundamental problem with defining your own technical terms:  they don’t make any sense until you explain them.  This can be helped somewhat by choosing intuitive terms, but you probably still need to explicitly define your terminology, and that creates another layer of documentation the player has to climb through to figure out how things work.  So this helps with problem 2 from my original outline, but may exacerbate problem 1.

Tutorials

Another classic technique for introducing a player to a game is to have a highly structured game session, where the player is exposed to the game a little bit at a time, explaining things along the way.  This has the potential to control the order in which the player learns things (which can be a great help with problem 1), and if structured well makes it much easier to anticipate what the player is going to want to know.  However, it can also feel tedious and restrictive if not done well.

The biggest trap here is to make sure that the tutorial doesn’t hinder players by explaining something they already understand.  Sometimes you have repeat-players, or people who have learned something about the game from another source (anecdotes, the manual, etc.) and if they’re trapped in a lengthy explanation of something they already understand, it wastes the player’s time and can become frustrating extremely quickly.  Any non-interactive segment of the tutorial should be skippable, and the interactive portions need to avoid being too tedious for a player who already knows what to do (frequent interruptions, forced pauses, and disabled game features tend to be bad).

Sometimes you can make the entire tutorial skippable, but that goal tends to conflict with making it interesting, because it means that nothing really important to the rest of the game can happen in the tutorial.  The best way to help the player learn is usually to spread out the information over as much real gameplay as possible, and compartmentalizing it into a small, skippable segment doesn’t accomplish that.

Remember, this is supposed to solve the problem of the player being too impatient to learn everything from a manual–if playing the tutorial feels like reading a manual, it doesn’t accomplish much.  Additionally, skipping the tutorial outright isn’t a good option for someone who has learned only half the information from other sources, but we still don’t want to bore that player with tedious segments teaching things he already knows.

I think that covers the three most common tools for addressing the three problems I outlined (in reverse order, naturally), though there are others.  Remember, there’s still no substitute for simply explaining things well, and none of these should be seen as replacing normal documentation–you probably do still need a user’s manual.

More precisely, I don’t like the fact that they’re free-for-all; there are many individual free-for-all games that I rather enjoy, I just wish they were organized differently, and I tend to enjoy them less than other people seem to.

Like many of my gaming preferences, I imagine this is partly just due to my own individual personality, but I also think it’s partly that free-for-all games tend to suffer from several systemtic problems.

Allow me to break this into separate cases.  Broadly speaking, there are two major free-for-all structures: games where players can obstruct each other and interfere with one another’s chances of winning (such as Clue, StarCraft, Quake deathmatch, etc.), and games where players are competing to fulfill independent goals as quickly or as effectively as possible (e.g. bowling, golf, races (sometimes), high-score competitions, etc.).

I don’t have anything in particular against the second category, except that it’s really composed of single-player games masquerading as multi-player games.  If I’m just trying to get a higher score than everyone else, there’s no need for us to play at the same place or time.  The games are often fun, but if I’m actually going to go to the trouble of arranging to play a game with a group of people, I’d like to, you know, play with them, not play in separate games and then compare high scores.

Policy vs. Politics

So that leaves the first category, where the multiplayer is justified by the fact that one player’s actions can actually affect the gameplay of another (this is the more typical case).  My chief complaint with these is that there’s a tendency for them to trivialize any actual gameplay-driven strategy in favor of (for lack of a better word) politics.

Here’s how it tends to happen:  your opponents each have, at their disposal, one or more tools that they can use to interfere with your attempts to win.  Additionally, you have more opponents than you have allies.  This means it is extraordinarily unlikely that you can win through sheer skill if your opponents all decide to cooperate in stopping you–collectively, they just have a lot more resources than you do.  If you throw your obstacles in front of your best opponent, and a dozen opponents all throw their obstacles in front of you, your opponent is almost certainly going to win, even if you’re a significantly better player.

Thus, no matter what the actual rules of the game are, your primary goal is to convince your opponents to fight each other instead of you, because unless you do a pretty good job of that, it often doesn’t matter what else you do in the game.  The game ends up being decided based on who looks the least threatening, or who is most popular among the other players, or who happens to take the turn right after the last ready obstacle has been played.

Now, granted, manipulating other players into doing what you want instead of what’s in their best interests is a complicated and subtle art, and the precise methodology probably does vary a little depending upon the rules of the game.  But the gameplay is no longer the primary activity.

And there’s nothing inherently wrong with that, if that was the goal.  But it’s less interesting to me, personally, and I think the result really belongs in a different category from other games; the game here is just being used as the background for another activity.  If the gameplay was the goal, then the design has failed (this is actually a game balance problem, according to my proposed definition).

Of course, there are some exceptions to this rule–some games manage to use free-for-all gameplay without emphasizing the politics above all other aspects.  Here are some traits that I think help games keep politics under control:

Lots of Hidden Information.  A game doesn’t really enable politicking if you don’t know anything about the other players’ positions.  You can’t rally everyone to stop the imminent victory if you don’t know that someone’s about to win, and you can’t systematically undermine a single player if you don’t know what moves disadvantage him more than other players.  It’s also hard to give someone reasons to attack someone else instead of you if you have no way to establish that the other guy is a bigger threat.

Forced Opposition.  Some games (FPS deathmatch comes to mind) are arranged so that you are pretty much forced to fight whoever you run into (because that’s the way you get points, and the other guy can kill you quickly if you don’t defend yourself), and so that the people you run into are largely random.  Sometimes it’s hard even to tell who you’re fighting until one of you wins.  Since you can’t effectively target specific opponents, politics doesn’t play much of a role–on the other hand, the game also plays suspiciously like a bunch of short one-on-one matches rather than a coordinated free-for-all.

Restricted Cooperation.  Games where you can act to someone else’s benefit (rather than just to someone else’s detriment) make the problem worse; if the best that someone can hope for is that you’ll leave them alone (rather than actively helping them), players are less likely to form alliances.  However, this one is hard to manage to any great degree, because even if there’s no way to directly help someone, it’s often possible to aid someone indirectly by distracting or restraining a third party that would otherwise target them.

Fast Pace.  If players are required to act so quickly that they can’t make appeals to each other, this limits the amount of politcking.  However, if it’s easy to determine and target the current game leader, spontaneous cooperation is still a definite possibility, so I think this one reinforces the others more than it stands on its own.

Win Ratio

A lesser, independent complaint I have against free-for-all games is that I don’t win at them as often.

Of course, that sounds selfish, and of course, the game is supposed to be more important than who wins.  But, nontheless, people like to win–that’s not going to change any time soon.  And the more teams you divide people into, the fewer players get to win any given game.

It is also true that people feel more satisfaction for winning when they know that the odds were against them, and less frustration for losing when they don’t expect to win, but I don’t believe it balances out; I think people generally feel it more when they lose five games in a row than when they win one six-way free-for-all.

And it doesn’t take very many consecutive losses before people begin to say things like “I just can’t win today” or “why am I playing so badly all of a sudden?”  People have lousy intuitions for randomness, and won’t expect long streaks to be nearly as frequent as they actually are, so when they lose lots of games in a row, they won’t think “OK, that’s to be expected every now and then,” they’ll think “wow, I suck.”  And that’s not what we want the player to think.

However, this drawback can be mitigated by allowing multiple winners, or “runners-up.”  Some games, because of their structure, need to end as soon as someone wins–others can easily let the winner drop out while the remaining players compete to see who can win next.  On the other hand, this feeds into the third issue with free-for-alls…

Inconsistent End Times

Lots of times, players want to do something together when the game is over (sometimes play another game–sometimes something completely different).  If some players drop out of the game before others are finished, this can cause problems.

Many free-for-all games don’t suffer this problem at all.  Many that do have this trait are generally played in a setting where it doesn’t matter.  Nontheless, there is a tendency in some free-for-all games to have an “elimination” mechanic (where you win by being the “last man standing,” rather than the first to achieve some goal, or best at the end of a time limit).  This can result in some players being unable to participate for significant portions of the game.

Alternatives

Two-team games are nice.  I think that a lot of games could do well to introduce (or place further emphasis upon) modes with two competing teams, rather than one-on-one or free-for-all styles.

One-team games can also be very interesting–games where all the players are working together to “beat the game,” which behaves somehow algorithmically (e.g. a computer AI, random card draws and dice rolls, etc.).

On the other hand, some games just don’t scale up gracefully.  If the game really only works as intended in a one-on-one matchup, then you really can just leave it at that.

In fact, what worries me most are the games “for three or more players,” as those tend to have gameplay that obviously falls apart in the absence of politics (though there are some exceptions to this, as well).

My primary principle here is that if you want people to focus on the gameplay, then they should be able to win by playing the game well–not only by playing the other players.  If you enjoy politics-centered games, I wish you many happy hours playing them, but they are just not the same thing as strategy games.

There’s no “magic bullet” that is going to make this problem go away, but there are good design practices that can make it easier.  In this post, I’m going to discuss my favorite trick:  building in stability.

Lots of times, people think of balancing as simply tweaking the numerical parameters of the game, after everything else is done…how much a fireball costs relative to a lightning bolt, how much damage you can do with a battle axe compared to a dagger, how much faster than a soldier a thief can run, and those sorts of things.  This is an important step in balancing, but it’s hard to make more than fine adjustments at this stage.

Think of these numerical parameters as the ballast in your game:  you can use more or less in different places to compensate for unexpected forces.  But your most powerful tools are the shape and structure of the game, which determine how much stress it will be under and how the forces will be distributed.  If the hull is full of holes (or is so thin that holes are invariably created), trying to solve the problem by shifting the ballast is a difficult and desperate strategy.  If you design the game’s overall structure to be sturdy, you won’t have to.

What does this mean in concrete terms?  Two (related) things:

1. Strategies that are similar to the best strategies are also pretty good (doing something nearly perfect produces nearly perfect results)
2. A small change to the parameters of the game (like the cost of a fireball) produces only a small change in the optimum strategies.

The first is good because it decreases the chances that the designer will be surprised by an effective strategy she didn’t anticipate.  If there are a dozen things that are individually really bad moves but that turn out to be an awesome strategy when done in exactly the right combination, you may never know it exists until some player randomly stumbles across it and uses it to clobber your game’s balance.  It would be bad even to discover that a strategy you knew about, when refined to a slightly greater precision than you used in testing, suddenly becomes much better than you imagined.  Unless the designer knows (at least in general terms) what the good strategies are, and how good they are, there’s not much chance of the game being balanced.

If the strategies that are “close” to the best strategies are also good strategies, then it becomes easier for the designer to find all of the general areas where good strategies reside, so she won’t be as likely to be surprised by one she missed.  Additionally, even if she doesn’t pin down the perfect execution of a strategy, she’ll have a general idea of how good the perfect execution is going to be, and so can still take it into account.

The second trait is important when you get to the stage of shifting the ballast around, because it ensures that the game will react in some sane and predictable way to those shifts.  If a small change in your game’s parameters sometimes radically alters the optimal strategies and sometimes produces no noticeable change, it’s going to be very difficult to fine-tune the balance of the game.  It’s much easier if you can “home in” on a balanced set of parameters gradually.

This trait also means that you don’t have to find the perfect set of parameters for your game–because something close to perfect is going to be pretty good, since a small change only produces small changes.  You only need to get close to the right parameters, and your game will be pretty well balanced (and of course, you can continue to make gradual changes to get better and better).  This can save innumerable headaches later on.

Control as a Utility Function

In order to analyze the mathematical properties of game balance, we need to describe the player’s goals.  Therefore, we introduce the abstract concept of control, defined to be the amount of power the player has to change the outcome of the game (and in particular, to ensure that player wins).  When analyzing a game’s balance, we assume that players are trying to maximize their control (in order to maximize their chances of winning).  In the language of economics, this is the player’s utility function.

As in economics, we don’t usually know precisely what this function is–in fact, we probably don’t want to be able to know, because if the player could ever figure out exactly what this function is, he could theoretically find the exact optimal strategy for the game, which would probably take most of the fun out of it.  So we actually want this function to be too complicated for us to exactly figure it out.

However, we can often make some general observations about this function without knowing its exact solution.

Marginal Return

In most games, players can make trade-offs along some continuum.  This might be explicit in the mechanics, such as a trade-off between having an avatar with more strength or more intelligence, but it can also be more abstract, such as a trade-off between aggressive and defensive behavior.  If we think of these assets as variables in the control function, we can look at the marginal utility of each, or how much control the player gains by getting a little more of one asset (e.g. how much more influence the player has over the game’s outcome if his avatar is a little stronger).

Though almost all games actually work in discrete units, it often simplifies the analysis if we pretend the player’s choices are continuously divisible, and then (for those familiar with calculus) we can look at the marginal utility as being the derivative of the control function with respect to that variable.  If our game math is well-behaved, we can expect the discrete solution to be similar to the continuous approximation.

Of course, the marginal utility of an asset is rarely constant–in fact, we usually don’t want it to be.  It may depend on the current level of that asset, and also the current levels of other assets.  But, again, we probably don’t want to be able to solve for it exactly, as that would make playing well too easy for the players.

Perfect Equality

One might imagine that we want everything to be completely even–no favoritism of one assset over another, no fancy circumstantial rules…essentially, for the marginal return of each asset to be a constant.

The catch here is that all strategic incentive to choose one strategy over another has been eliminated.  Sometimes that’s a good thing–you may want that for choices that are intended to be purely stylistic, rather than strategic.  But this has become a cosmetic choice, and we need to have some other choices if the game’s going to have any hope of being strategically interesting.

∂²C/∂a² and Diminishing Returns

So, stylistic choices aside, we presumably have some real strategic considerations for the player, and that means, at some point, that one asset’s marginal return must be higher than another’s.  At this point, the player may ask why he shouldn’t simply put all of his resources into the asset with the highest margin.  It’s a fair question–but, of course, we hope our game is not so easily solvable.  So the asset that has the highest margin now must not always have the highest margin, and that means that the margins have to change. 

There are a few ways this can happen.  The first interesting property of an asset’s marginal value is how that margin changes as the asset changes–for example, does the marginal value of another point of strength go up or down as you become stronger?  (For the folks who’ve taken calculus, this would be the second derivative.)

The easiest thing to do is to apply diminishing returns–to cause the marginal value of an asset to decrease the more of that asset the player already has.  This means the second derivative is negative.

In the example depicted in figure 2 (above), an optimal strategy is obtained by dividing resources between assets a and b, because the marginal value of either decreases as its absolute value increases.

Notice in the third graph that the control function is almost flat around the position of optimum strategy–strategies near that point are nearly optimum.  If we wanted to shift that optimum strategy a little to one side, or make it a little higher or lower, that should be relatively easy, because the function doesn’t change dramatically in its vicinity–making fine adjustments to the game’s balance will be relatively easy.  Contrast this to the opposing case of increasing returns:

In this example (figure 3), a player who wishes to win is forced to adopt a very extreme strategy in order to do well, because the more invested the player becomes in a particular asset, the more valuable continued investment in that asset becomes.  The control function is very steep near the optimum strategies, because small changes around those points represent trading off between one asset with a high marginal value and one with a low marginal value.

The optimal strategies are probably not hard for the player to find (they just pursue their first thought to its logical extreme), but calculating the maximum effectiveness of these strategies may be difficult, because the curves are so steep–a small error in the calculations will result in a large error in the predicted effectiveness.  Additionally, a small change to the parameters of the game can result in a major change in the effectiveness of one of the optimum strategies (again, because the curves are so steep), but if we want to move the optimal strategies horizontally, it requires drastic changes to the game.  This game will be easy to play, but hard to balance.

Note that the concavity of the marginal returns has not been considered in this analysis.  Those pictured in figure 2 are concave up and those in figure 3 are concave down (which is likely the most sensible way to contruct them, given the constraints), but the same general conclusions hold even if this is not the case.

∂²C/∂a∂b and Synergies

The player can be induced to shift attention from one asset to another as the object of his attention drops in marginal value, but another way to curb the tendency towards excess is to increase the value of another asset.  If the value of asset a increases as I invest in asset b, then I am more likely to shift resources towards a (if the effect is mutual, I’m likely to divide resources between them on an ongoing basis).  You can think of this as a synergy between a and b, and in terms of calculus, this means that ∂²C/∂a∂b > 0.

Notice the changes in the axis labels compared to previous graphs (we are now examining ∂C/∂a as a function of b, rather than a, and vice-versa).  The final graph is very similar to that in figure 2, and a similar analysis applies.  In fact, with only two variables, mutual synergy looks pretty much the same as diminishing returns, except with a constant offset in overall control.  However, it’s useful to examine synergies separately, because we often have more than two variables, and synergies (or anti-synergies) can cause specific combinations of assets to perform better or worse than others.

Anti-synergies look pretty much like you’d expect:

Compare with figure 3.  Again, the player is forced to specialize to be effective.

Isolated anti-synergies aren’t necessarily a bad thing, if you really intend for two tactics not to be mixed (for example, if you don’t want any hybrid fighter/casters in your game, then you can make “fighter” attributes and “caster” attributes anti-synergistic).  However, the sharp curves near the optimal strategies mean that you can’t fine-tune the trade-off; it remains an all-or-nothing deal unless you make drastic changes to your game.

Breakpoints and Discontinuity

The actual mechanics used in many games don’t always make such nice, smooth curves as depicted in the examples above.  Many games have breakpoints, places where the marginal value of a variable makes a sudden jump up or down (if we’re pretending our game units are continuously divisible, these often manifest as discontinuities or points of undifferentiability in the function).

The sharp corners in the control function (where the angle of the line changes suddenly) make it harder to balance strategies in that area, because the strategic implications of small changes in the game’s parameters become less predictable.

Discontinuities in the control function are even more noticeable.  Small changes in the game’s parameters may gradually affect the optimal strategy until you get up to the breakpoint, and then your changes may have no effect at all on the strategy for a long time, before the changes become drastic enough to jump to the other side of the discontinuity.

 Additionally, it’s possible to be very close to the optimal strategy, yet produce very poor results–this makes it more likely that you’ll overlook the strategy in testing, and punishes players disproportionately if they make a minor error in the execution of this strategy.

Synopsis

Though we often don’t know the control function (and don’t necessarily want to), examining the general behavior of specific interactions of your game mechanics can often reveal clues to the game’s overall stability.  Smooth, gradual changes–especially near good strategies–make the game easier to understand and to adjust later on in the development process.

Though many of the examples above may seem woefully simple–we probably wouldn’t think much of a game where the optimal strategy was actually to split resources exactly evenly between all possible pursuits, for example–the same general reasoning applies even when the game systems become more complex.  You can gradually hone the parameters of your game to achieve greater balance if your broader game mechanics are “well behaved,” but steep slopes and sharp corners lead to an unstable system that’s difficult to calibrate.

This doesn’t tell you how to balance your game, or even how your mechanics should work–but it does provide some rules-of-thumb to make your game easier to balance in the long run.  If you want to balance your game, don’t just focus on the ballast–focus on the hull.

This is not the first time I’ve seen this idea, though I think it’s the first successful implementation I’ve played.  In a talk I heard about Sly Cooper 3 (previously mentioned in this post), it was revealed that they had tried to develop levels where you’d play several characters in the same area, one at a time, with each character able to watch the actions of the characters you’ve previously played as they repeated what you’d done.  Sadly, Sucker Punch was unable to keep the replays consistent–even with extensive measures to synch up the random number generators, things just wouldn’t play out the same way.

Cursor*10 barely scratches the surface of what could be done with this idea, and I’ve already heard speculation on various ways the concept could be extended, but the failed attempt of another game to incorporate this idea raises a red flag.  What steps should future games take to avoid a similar fate?

Accuracy of Recordings

The most obvious requirement for this to work is that the replays really need to do the same things that the player did originally.  This sounds simple, on the face of it, but has profound implications for how the game is conceptualized.  For example, if you record one avatar’s action as “attack enemy X,” and then that enemy dies before you get to that point in the replay, what do you do?  You run into a similar problem if you just try to record the player’s input; pressing a button often has different results depending on the circumstances under which it is pressed, so if those circumstances change, your re-enactment might deviate from the original.

The only practical way I can see of pulling this off is if you record all of an avatar’s actions in some “circumstance-agnostic” format.  For example, instead of recording that an avatar attacked an enemy, record that it attacked a particular area.  Instead of recording that it picked up an item, record that it grabbed at a certain location.  Instead of recording that it walked through a door, record the actual points in space it moved through.

This affects not only how you format your recordings, but also how you have to define your game mechanics.  If your recording says that the player attacked an area, rather than a particular enemy, then your game needs to allow attacks at nothing, and your engine needs to be capable of determining what (if anything) in the target area can be affected by the attack.  The abstractions required for the recording place cascading requirements on the game mechanics, the implementation, and even the user interface.

Stability of Relevance

Any game of this sort is going to demand that the player do some planning ahead in order to be effective, but there are limits to what you can expect the player to plan.  The game becomes uninteresting fairly quickly if most of the actions taken by a previous avatar cease to be relevant, so what seems to make sense in one iteration needs to mostly continue to make sense in successive iterations.

For example, suppose that the second avatar closes a door that the first avatar went through, and this prevents the first avatar from passing in the replay.  From that point on, the first avatar’s actions probably no longer make sense, because they’re happening in different locations than intended; that single change has invalildated the entire rest of the replay.

If a single aberration in the context of an action renders the rest of the replay useless, then it’s going to be very hard for the player to gain any significant benefit from the earlier avatars.  The more common and the less predictable these aberrations are, the more likely the game is going to fall into degenerate behavior.

Instead, it’s better to limit the scope of the repercussions a single change has.  In Cursor*10, if you open a box with one cursor, revealing a staircase, and then open the same box earlier with your next cursor, the first cursor still goes and clicks on the box, which no longer produces any effect.  But the first cursor does not go up the staircase, which is what normally happens when you click on one.  Going up the staircase would invalidate all the rest of that cursor’s actions; ignoring the click only invalidates the one, and the rest of the things that cursor does can still be useful.

Just as you don’t want a small change in an action’s effects to send a recording out of synch with the world, you also don’t want a small change in the environment to cause cascading changes that render previously recorded actions meaningless.  For example, suppose one avatar spends a long time attacking enemies as they come through a door, preventing them from reaching other parts of the game world.  If a later avatar can cause those enemies to take a different route–say, by distracting them, or closing the door– then all of the first avatar’s attacks are just going to hit air, wasting his effort.

Having really big repercussions for a few clear, pivotal actions might make an interesting puzzle for the player, so you don’t necessarily need to entirely eliminate these sorts of things.  If the one big gimmick of the level is, say, that the avatar doing one particular task needs to avoid stepping on the toes of all the others–that might be interesting in a limited context.  But if they’re common, or easy to do by accident, then there’s a large risk that they’ll disrupt the recordings to the extent that they become almost useless.

Basically, your game mechanics should be designed so as to tend to keep replayed actions relevant, rather than to tend to render them obsolete.

Time Limit

At some point, you need to stop playing with the first avatar and move on to the second.  In order to keep the cooperative element interesting, you probably want to play about the same length of time with every avatar–if some avatars quickly “die” or otherwise stop, then they’re only relevant to a particular subsection of the game.

As such, you probably want some kind of “time” limit, and you probably want that to be the only restriction on how long you can play (rather than having, say, a health bar).  Of course, game time doesn’t need to equate to wall time–the limit could be a certain numbers of turns just as easily as a certain number of seconds.

In the same vein, in order to facilitate easier cooperation between avatars, you probably want to keep the current time prominently displayed to the player, so he can keep track of when a certain thing from a previous avatar is going to happen–then again, there are also reasons you might want to keep the time a secret, as will be discussed towards the end of this post.

Restricted Randomness

One could potentially have a randomized level, that’s different each time you start an entirely new game.  Cursor*10 actually has some randomness (in the floor with all the boxes, the box containing the stairs is different each game).

However, you don’t want random differences between different iterations of a single game–that will tend to make it harder to plan and reduce stability.  So anything that’s random should be chosen randomly once, and then recorded, so that it will happen the same way for future avatars.

I wouldn’t recommend trying to use a pseudo-random number generator to regenerate the same numbers each time–one difference in the circumstances triggering the random numbers and everything thereafter is wrong.  Instead, I think it would be safer to explicitly record the random results in some way that associates them with the event for which they were generated (and not just by virtue of being in chronological order).  But that’s just an implementation detail.

So What Could You Do?

You could get a lot of mileage out of this idea just by constructing a larger game world or taking it into a different genre, but here are some more specific ideas of game mechanics that might be interesting in such a game:

Synchronized Actions.  For example, the classic two-button security door–you need to press both buttons at once to open it, so a single person can’t do it.  So you press one button with one avatar, and the other with a later avatar–but you need to have the first avatar give some sort of signal so that the second avatar can press it at the right time, like counting “one, two, three.”

The farther apart you place the buttons, the more difficult synchronization becomes, and the more tricks the player may need to come up with to get in synch (though there’s limits to how hard this will become, depending on how well the game clock serves as a synchronization device).  For two adjacent buttons, maybe the first avatar starts 3 steps away and advances at a regular pace.  For two distant buttons, maybe you need a third avatar to set off somd kind of widely-visible signal (like a flare, or an alarm) in order to syncrhonize the others.

Interleaved Actions.  Maybe two avatars need to cooperate in order to do a series of actions in the right order.  For example, one operates a crane to pick up and drop boxes while another operates conveyor belts to move them around.  The controls for the two machines are far apart, but you need to alternate between them in order to move things into the right configuration.

Of course, this could potentially require the player to do a lot of detailed planning in order to get it right, so be cautious how heavily you rely on it.

Temporary Interference.  If one could arrange for the actions of an early avatar to be foiled in a very specific way–such that the recording is perfectly capable of accomplishing the action, if only a certain obstacle were removed–then the previously invalid actions of one avatar could be rendered effective by the actions of a later avatar.

For example, suppose you’re playing whack-a-mole, but the moles are so fast that they always duck out of the way when they see the hammer coming.  One avatar plays the game, and misses with every swing.  Another avatar comes along and somehow hinders the moles (blinds them, slows them, etc.) so that they can’t dodge.  This time, all of the first avatar’s hits connect–thereby triggering some other result the player needs to win the game.

The trick here is that you need to block the player’s actions after they’ve been performed–if you prevent them from being performed in the first place, then the recording won’t contain the right actions to accomplish them after the obstacle has been removed.

Distinctive Avatars.  There’s no rule that all the avatars need to be interchangeable–some could have unique abilities, forcing you to perform certain tasks with certain avatars.  Some abilities might work in conjunction with other avatars.

Replay Select Avatars.  If the game becomes long or complicated, then replaying every avatar every time could become frustrating.  Instead, one can envision allowing the player to play each avatar once, but then go back and replay a specific avatar of his choice, replacing its previous actions with a new set while keeping all the other avatars’ actions in tact–say, in order to correct specific errors only clear in retrospect.

However, this makes it much more likely that the player can invalidate the actions of other avatars.  For example, in Cursor*10, you probably had one cursor hold down the button that creates the stairs so all the other cursors could go up.  If you could replay just the cursor holding down the button, and do something else–all the actions of the other cursors no longer make sense.  So in order for this to work, either you need to eliminate this kind of dependency between avatars (a substantial restriction), or else replaying an old avatar is going to be considerably more complicated than playing a new one.

I’m looking forward to seeing all the interesting things that future games will do with this idea; it can accommodate a lot of different types of gameplay, and it has that strange flavor of a rule that’s natural and consistent while still being surprising.  I think it opens up a lot of possibilities still waiting to be explored…

And it’s holding the genre back.

If you’re reading a blog on game design, you probably already know how this works, but I’ll explain it anyway.  Each monster in the game keeps track of all the players (and sometimes other creatures) that he doesn’t like.  Moreover, he quantifies how much he dislikes each of them: he tracks every bit of damage you deal to him (and maybe to his friends), every negative effect you use against him, every good turn you do to any of his enemies (like healing them–or yourself, if you’re his enemy), and anything else you do that could be construed as hostile.  These numbers get fed into a giant equation that tells the game exactly how much he dislikes every particular person around him, and he attacks whomever causes him the greatest angst.

So, first of all, allow me to observe that this is a fairly pathetic attempt at artificial intelligence.  In the typical case, it’s probably better than attacking a random foe–but not by much.  And it’s more exploitable, too.  It arguably might reflect the way we expect certain dumb beasts to react, but it’s awfully simplistic even for that, and it certainly doesn’t reflect an opponent with any strategic intent.  It completely ignores teamwork (both for itself and its opponents), risk/reward, and even the relative hardness of different targets (like who’s wearing heavier armor, and who’s low on health).  This represents a foe who is acting entirely on impulse, without the slightest rational thought.

But that’s not the main problem here.

The real problem is that the games take this a step further, and actually encourage players to exploit the weaknesses of this AI.  In fact, many games present players with a wide selection of abilities designed specifically to manipulate this system.  There will be “taunt” abilities that make monsters angrier at you without actually harming them in any way.  There will be “hate-reducers” that encourage the monsters to go after someone else for no apparent reason.  The “tanks,” whose job it is to defend the softer members of the group from enemy attacks, often rely entirely on manipulating the hate system to do their job.  The designers no longer have the slightest belief that the monster is making a good targeting decision–in fact, the design assumption is that the monster will usually be manipulated into making the worst possible decision.

Do you see what has happened?  What doubtless started out as a quick AI hack has become enshrined as a primary game mechanic.  It can no longer be removed from the game, because other parts of the game aren’t balanced without it–some don’t even make sense without it.  If you changed the AI in one of these games, many abilities would no longer make sense, tanks couldn’t perform their role, and existing gameplay would fall apart.  Even if you eventually put it back together, the strategy of the game would be completely different (not that different is bad, but that’s an indication of the level of dependency here).

Now, if ever anyone working on World of WarCraft (or EverQuest, or whatever) decides they want to replace the AI with something else–even in a narrow scope–they can’t.  Not without throwing ordinary gameplay and game balance out the window.  Want to have a special boss that’s smarter than a regular monster?  Can’t do that.  Want to add some PvP?  Enemy players aren’t going to respond to taunts.  Want to create group monster behaviors for large-scale combat?  The players’ hard-earned abilities are broken.  Once you’ve exposed the inner workings of your AI and let players directly mess with its internal state, you’ve lost modularity–the rest of the system doesn’t work unless you keep that AI just as it is.

That doesn’t mean that these games don’t occasionally put in PvP or smarter monsters–but when they do, ordinary gameplay rules don’t apply, and many character abilities and roles around which the game is balanced no longer work.

And the fact that PvP is automatically unbalanced, and that I can never face an opponent with even a modicrum of strategic ability, is quite frustrating.  These games have limited their gameplay to a narrow, shallow, time-worn trail in order to keep using this one mechanic that wasn’t even a good idea in the first place.

It’s crappy for balance, too.  The frail “back row” characters’ strategy supposedly consists of being as effective as possible while keeping their hate below a certain magical threshold.  Creep right up to the edge of that threshold, and you’re playing perfectly.  Set one toe beyond that line, and suddenly the battle’s going badly.  The effects of your actions are extremely unstable.  There’s no flexibility or forgiveness built into the system, which means the difference between perfect gameplay and a rookie mistake is one tiny error.  The fact that you can’t actually see how much hate you’re generating or what the threshold really is certainly doesn’t help this, but even if you could, that’s still a stupid, pointless, and frustrating reason to lose a battle.

And for all its simplicity, this system doesn’t even succeed in being obvious or intuitive.  A new player is not naturally going to infer that he can help his team win by spending less time attacking the monsters and more time twiddling his thumbs.  There’s no rational thought behind that.  This isn’t even a rough approximation of either realism or strategy; it’s a secret voodoo formula that only makes sense to the initiated.

Alternatives

So what should these games do instead?  Am I advocating that we overturn all the precepts of MMO gameplay?  Abolish the tank?  Remove the reasons for attacking one player over another?  Make everyone the same?

Of course not.  But the gameplay shouldn’t revolve around playing your opponents for utter fools, either.  It shouldn’t require you to dance on the knife’s edge of disaster.  And it shouldn’t require you to be an expert on the secret inner workings of the game in order to understand the basic principles of strategy.

A balanced game has stable gameplay when all parties are trying to win.  The standard model of hate doesn’t allow the gameplay to remain stable when you face any opponent except one that you can jerk around like a wooden puppet.

Here are some more flexible options:

Battle Formations.  The distinction between front-row soldiers and ranged support wasn’t invented by MMORPGs, you know.  In real life, it works because the front row is physically between you and the enemy back row, and trying to cross that line entails anything from exposing your back to retributive attack to physically pushing your way through a sea of bodies, depending on the circumstances.  Add in rules like player collision, flanking, backstabbing (not just for rogues) and other such things, and it should be possible to build a system that naturally favors a front row/back row distinction.

Targeting Disincentives.  Of course, video games don’t have as much detail as real life.  Positions and postures are less precise, detailed collision models are computationally expensive, players tend to have less situational and spatial awareness than real life fighters, and so forth.  If you take the same basic idea and abstract away the physical realities, you end up with a system of disincentives.  Tanks stand next to back-row characters and activate some ability that causes nearby allies to take less damage, diverts damage from them to himself, or somehow penalizes enemies who attack the allies under his protection (e.g. counter-attacks).  Set it up right and you can make it so that attacking the enemy tank is tactically sound, even if your game doesn’t use the concept of position or distance at all.  This abstraction also makes it easier to create magically-themed and long-range tanks, should you find that idea appealing.

Targeting Incentives.  You can also do the reverse–generate good reasons to attack the tanks, independent of the other targets.  For example, give the tanks bonus damage when they’re not being attacked, or strong but easily-interruptible abilities, or let them cast debuffs that can be mitigated by attacking the caster.  This doesn’t usually scale as well to different battle sizes (since you need to worry about multiple tanks ganging up on one target), but it can work in at least some situations.

Coercion.  Some people, after hearing me rant about the hate system, assume that I’m against any abilities that coerces your opponent to behave in a certain way, but that’s not true.  Abilities that restrict what actions your opponents are allowed to take–like, say, disallowing the target from attacking anyone other than you–are completely valid (and already exist in most of these games, in the form of “stunning”).  Just make sure that their effects are defined in terms of what the target is or is not allowed to do, rather than in terms of how much the target wants to do something, and you can apply it to any AI you want, or even enemy players, without difficulty.  You’ll need to play with durations or intensities or something in order to keep the effects of these abilities smooth, rather than creating sudden breakpoints as in the hate system (stunning already has this problem), but that’s certainly a solvable issue.

Debuffs.  You can also just let the tank do their job of protecting the party by using abilities that directly reduce the enemies’ offensive capabilities.  In this case, the “tank” might no longer be called a “tank,” and he may not be the one who gets attacked, but that’s actually one of the most appealing things about this option:  you can balance the game so that it is completely tactically viable to attack the “tanks” (debuffers) and completely tactically viable to attack other members of the party.  Killing the debuffers first gets you back to full offensive capabilities quickly, which may or may not be your highest priority, depending on the situation.  Behold!  Strategic variability!

There’s no single option here that’s clearly the best route, but there’s no shortage of possible replacements for the current standard.  I think people continue to use the hate system because it’s easy to implement, and it allows players to feel smarter than the AI, but mostly they’re familiar with it, and players are familiar with it, and to do something new and different entails effort and risk.  But this system has kept games bound to a cheap, transparent hack of an AI for years, as it becomes more and more inappropriate, and its continued use is blocking much of the interesting potential of these games.  For the continued improvement of such games, this model has to die.

A more arbitrary notion is the concept of the player’s avatar becoming more “skillful,” through a convention commonly known as “experience points” (XP) or “levels.”  The idea is that, within the secondary reality of the game, the character (or other entity) controlled by the player is also practicing, learning, and growing in power, presenting the player with new or enhanced options within the game.  While most closely associated with role-playing games (RPGs), this mechanic is now pervading a wide variety of games, from shooters to puzzle games, rewarding the player’s accomplishments with additional powers, and sometimes greater options for customizing his avatar.

While initially this may seem like a nice secondary feature, easily attachable to a wide variety of games, the addition of this mechanic often substantially alters the way a game is played and balanced–not always for the better.

Difficulty Curve 

The first and most obvious effect of making the player more powerful is that she can successfully confront more difficult challenges.  This usually isn’t a problem, since most games expect the player to confront successively greater challenges as the game progresses anyway.

However, the difficulty increase needs to be calibrated to the rate of the player’s increase in power (plus whatever actual difficulty increase you want).  This tends to be more difficult than adjusting an ordinary difficulty progression, because the normal difficulty is self-correcting:  a player for whom the tasks are easy will quickly solve them and progress to harder tasks, while a player for whom the tasks are too difficult will struggle with them and remain at one point in the game until she becomes skilled enough to handle them (I mentioned this in my discussion of why Difficulty is Hard).

The increase in player ability from XP tends not to be so helpful to the designer.  The players who are best at the game–that is, those who already have the most skill–tend to be the best at manipulating the system to get the most XP, too.  If you present multiple options for character advancement, more skilled players are more likely to identify the most effective or efficient ones.  In short, the players for whom the game is already too easy are the ones that tend to advance in “experience” the most quickly.

Additionally, if a player easily overcomes a challenge and moves on quickly, the player gets little practice–but tends to get as much XP (or more) as someone who struggles through it, because XP is offered as a reward for accomplishments.  By overcoming tasks more quickly or more thoroughly, the player with more skill–for whom the game is most likely to be too easy–builds up XP the fastest once again.

You can give the player less XP for winning quickly or easily, but this tends to be frustrating to the skilled players:  they feel they are being punished for playing well.  Additionally, if not implemented carefully, the skilled players will deliberately allow themselves to come close to losing for the extra reward–and, again, they can do this more effectively and reliably than the players with less skill.

One mechanism that is effective is to give players XP even for failed attempts at a level:  this way a player who fails the level several times before finishing it successfully will have more XP (at a given point in the game) than the player who breezes through, but the successful player does not receive less XP on any given attempt.  However, this only affects players who are so far behind the skill curve that they are actually forced to retry parts of the game–an outcome which we would otherwise probably want to make rare to prevent players from being frustrated.

It’s not all bad here; if you provide unlimited side-challenges (or repeats of required challenges, as mentioned above) that award XP, then a player who finds one segment of the game too difficult can always build up XP until they find it manageable, and then proceed.  But the increased instability in the player’s ability to overcome challenges still makes calibrating the difficulty progression difficult.

Snowball Effect

This is closely related to the difficulty curve problem.  If XP is basically given as an award to the player for overcoming challenges, and having more XP makes the player more able to overcome challenges, there is a danger that you’ll get a runaway accumulation–a higher-level player can accumulate XP faster, increasing his level, allowing him to gain XP faster still, and so on.

The traditional approach for combating this is to have an exponential decay in the effect of XP; the more XP you already have, the more you need to accomplish the same relative effect, and so the fact that you are gaining XP faster is canceled out.  Coupled with exponential increase in the XP awared for progressively more difficult challenges, this is fairly effective at keeping the player at the expected level for a given part of the game (based on the rate at which XP can be earned there compared to the XP required to advance).  However, if the player’s XP depends on little other than his progress through the game, one is forced to ask–why not grant the player abilities based directly on his progress and do away with XP entirely?

While this effect can complicate players’ progression through a single-player or cooperative game, it particularly becomes a problem in a competitive setting–if having more XP gives you an advantage in how quickly you can earn XP, then it’s probable the first player to get ahead will keep going and never look back, especially if players can directly hinder each other.

Games where players accumulate XP by fighting each other are particularly bad.  When the player who gets an early advantage is almost certain to win, players must labor under a foregone conclusion for much of the game, which removes much of the excitement and quickly becomes frustrating.  The high-level player has no suitable target for his abilities, and the low-level opponent has no way to compete.

WarCraft 3 minimizes this problem by allowing players to accumulate XP without directly fighting each other (through neutral “creep” fights) and by preventing most player units from acquiring XP at all, but I think it escapes serious difficulties mostly due to the fact that traditional RTS games have such a slippery slope that the game usually ends quickly after one side gains a clear advantage.  Most MMOs put strict level divisions on PvP and grant little or no XP for player kills.  In general, XP doesn’t seem to make a good primary mechanic in competitive games.

Undermining Player Tactics

Perhaps the most sinister problem accidentally introduced by blind application of the XP mechanic is that the goal of acquiring XP often runs counter to regular game goals, thereby forcing players to use unintended and counter-intuitive tactics to obtain XP, or forcing players to sacrifice potential XP in order to use effective tactics.  This is a Power Now, Pay Later trade-off, but one that can easily confuse the player, and these trade-offs tend to result in problems in most of the games that want to use XP.

There are a surprising number of subtle mechanics that penalize players for being efficient.  In some games, you need to fight every enemy (instead of cleverly avoiding them or prudently retreating) in order to earn XP for them.  In others, quickly dispatching a target that is generating opponents, while tactically sound, denies you the XP for the opponents it might have generated.  In still others, you gain XP with every attack, and so an enemy yields more if you kill it inefficiently (with weak attacks and defensive fighting) than if you fight it effectively.

This can theoretically be solved by ensuring that you always reward the player for effective and sensible play, but that’s often harder to define than it sounds.

This problem is particularly pernicious when the player is separately awarded XP in different categories for different achievements.  For example, when the player is given multiple characters with separate XP totals, or several styles or abilities that improve as they are used.

There are several problems that arise here.  The first is that, if you cannot benefit from all of these at once, then you can invariably increase your peak power by focusing on one or a few, and using them only.  This allows the player to increase in power more quickly at the cost of variety and versatility, which makes the game less interesting (fewer available options) and simultaneously easier than intended–hardly a desirable outcome.

This problem perversely reverses itself if you hit an XP ceiling–suddenly your most effective tool can no longer be improved, and so you forfeit all XP when you choose to use it, and must use an inferior option in order to continue accruing XP.  Again, the player is asked to choose between effectiveness and development.

It’s even worse if the player is given any tools designed to be used infrequently, or only in special situations.  If the player actually uses them infrequently, they level slowly, and prove to be weaker than other tools when they are needed, punishing the player for his earlier good judgment.  If they level so quickly as to be of appropriate power despite being used infrequently, then the player, by using them frequently, can quickly reach inappropriate power levels in the other direction.  The player is pushed, in the first event, towards ignoring his special tools in favor of leveling the general ones, and in the other, towards using the specialized tool so often that it becomes outrageously powerful and can be used more widely.  In either case, the specialized tool loses its intended function and gameplay is disrupted.

It may be argued that a game can be designed so that the point of the game is the accumulation of XP, and considerations of short-term effectiveness simply an obstacle to overcome–thereby making it perfectly acceptable if the concerns for XP utterly disrupt what would otherwise be appropriate gameplay.  But if you do this, you have something very unlike a normal game:  you are asking the player to focus entirely on the reward, instead of the gameplay.  This is the sort of design that turns games into an endless, tedious grind towards some dangled carrot and results in people paying other people to play the game for them.  Perhaps that is what some people want, but I would argue you are no longer designing a game, in the traditional sense, at that point; small wonder if the same analysis does not apply.

The Effective Use of XP

By this point, the reader may believe that I dislike the general idea of XP, but nothing could be further from the truth.  I revel in the advancement and customization of my gaming avatars, just as many of you probably do.  There are a great many games that benefit enormously from the inclusion of an experience system, which is why it is such a popular mechanic.  Used carefully, it makes playing the game more rewarding, adds depth and personality, and can even mitigate some problems with games’ difficulty curves, as already discussed.

But, like all mechanics, it should not be used in every game, nor should it be used carelessly or indiscriminately.  As I discussed in Burning Away Impurities, it’s easy to fall into the trap of thinking that you can make a great game by accumulation, simply throwing every good idea you’ve ever had into a pot and stirring vigorously, but it just doesn’t work like that.  Making a great game is as much about cutting out the bad and incompatible bits as it is about putting good ideas into the game; two things that are good individually are not necessarily good together, and two things that are good together are not necessarily good separately.

Game mechanics like experience are like spices.  By using them where appropriate, and in the amount appropriate, you can make great games.  But pile too much on, and you kill the flavor.