Theory: How to Be a Good Playtester

My last post got me in the mindset of playtesting, and having done a fair amount I thought I might write up some lessons I’ve learned. These aren’t gospel–different testers and designers can relate in different ways. However, I think these are good baseline principles to use when you’re testing for someone you don’t know personally.

1. Give reasons for feelings. “This isn’t fun” is useful so far as it goes, but it doesn’t give the designer guidance as to how the game should change. If you’re going to express a feeling like “this isn’t fun” or “I was bored,” include a “because” statement. “This isn’t fun because I can’t catch up once I’m behind” and “I was bored because it took so long to get from the campsite to the mountain” capture the feeling but also tell the designer where to focus his or her attention.

(This is also a very good way to avoid fights with significant others.)

2. Prioritize your feedback. Stream-of-consciousness responses can be very helpful, but it can also be difficult to tell what’s a big problem that absolutely must be fixed and what’s just an idea to consider. If the first thing someone says is “maybe the combat should use cards instead of dice,” they might be saying that they hated the combat or they might just be thinking out loud. It’s especially confusing if the next thing the person says is “the rules for flying are completely broken!” Give big problems first and work your way down.

3. Be polite. This is one of those things that can’t be emphasized enough. It’s OK to say that the game was bad, and why. It’s not OK to say that the designer is bad. The internet forum rule “attack the post, not the poster” applies here as well.

A long time ago I was taught the “sandwich” method of giving feedback: say something good, then something bad, then something else good. People are much more receptive to criticism when it’s surrounded by some positivity, so it’s clear that you’re not just hassling them. I can’t recommend this approach enough.

4. Play according to what the rules are, not what you think they are. Make sure you’re doing what the rules tell you to do–and only what they tell you to do. When the rules are ambiguous or you’ve fallen into a situation the rules don’t cover, it’s critically important to stop and at least make a note of the problem. Deciding on an answer and just keeping on is actually the worst thing you can do, because then the designer doesn’t know there’s an issue. A bad rulebook will most assuredly come back to bite the designer later.

5. If the game works under normal conditions, try something weird. Once the game has been tested enough to work when played as intended (it’s OK to ask if this is the case), do something the designer might not have intended. What happens if, in a wargame, you ignore the provided trenches and just charge the enemy lines? Or if you absolutely refuse to charge the enemy lines and never leave the trenches? What if you just never take any offensive action at all?

Testing how the game responds to odd behaviors is important in making sure that there isn’t a dominant strategy lurking. It also helps check the connection between mechanics and theme, by making sure that actions which are bad in-theme are punished by the mechanics. In a game about the German blitzkrieg of France it might be OK if France can win just by playing defense–but if the Germans can win that way something is wrong.

There’s a hilarious story about the testing of Pret-a-Porter that I think really captures the value of trying something you don’t think is optimal just to see what happens. It’s in this video, starting at 12:40, and only takes about three minutes. Take a look if you get a chance.

One thing that isn’t on the list is “be good at the game.” You don’t have to be a skilled player of a game to test it. Most people who play a game won’t be very good, just as a matter of math–only a fraction of players will take a game seriously enough, and practice it enough, to become strong contenders. As a newer player you represent the majority perspective, and your feedback is valuable.

Don’t be intimidated by the idea of playtesting. If you’re at all interested in doing it, or if someone asks you to test a game that you think looks neat, just jump right in when you get the opportunity. You might end up enjoying it or you might not, but I promise that if you keep these five principles in mind you’ll be a solid addition to the testing corps.

Theory: Playtesters and Designers Are Not In a Hierarchical Relationship

I saw an interview a long time ago–I regret that I can’t find it now–in which a game designer was asked how much of a contribution a playtester has to make before he or she gets credited as a designer. Like everyone who’s been to law school I have an aversion to “fighting the hypothetical,” but that question has always struck me as coming from an inherently wrong place. It assumes that playtesters are junior designers, and they are no such thing. Playtesting and designing are separate skills deserving of separate respect.

Good designers are not necessarily good playtesters, and vice-versa. Design ability does not confer the patience to test a game over countless permutations, nor does it grant the unique insight that enables great playtesters to look at a game and see unexpected ways in which a player might approach it. What’s more, design ability does not include the communication skills that are so important to giving effective playtest feedback. On the flip side, playtesting experience may not prepare someone to confront a blank sheet of paper and find a game there. An adept and valuable playtester may also have insight that primarily goes in one direction: he or she may be able to tell that something isn’t working, without necessarily having an opinion as to how it might be fixed. Playtesters and designers simply bring different things to the table.

Trying to fit playtesters and designers on the same ladder undervalues both. It elides the many skills each possesses, collapsing them into “people who make games” in order to force similarities that aren’t necessarily there. They should each be understood as having their own hierarchy, and should be measured against those in the same field, so that they can be evaluated according to how well they do their respective jobs instead of how they do each others’.

Efforts to “promote” playtesters into designers grow, I think, out of a sense that playtesters’ contributions are undervalued and that making them into designers will get them the recognition they deserve. I appreciate where people with that goal are coming from, but turning skilled playtesters into designers doesn’t do anything to get playtesting respect. If anything, it suggests that playtesters don’t need to be respected until they’ve “graduated” to designer status. That cure may really be worse than the disease.

The right solution here is simply to push recognition for playtesters. Acknowledge them more prominently. When you meet a good one, recommend him or her to others. Don’t cast playtesters as merely junior designers. Recognize and value the unique skills they bring to the table.

Theory: Themes and Expectations

In thinking about themes for Over the Next Dune, I was reminded of Fantasy Flight Games’ Android. Android was widely, and in my view unfairly, criticized for having a divide between its gameplay and its narrative. It’s a cautionary tale about how themes are interpreted: players rely on a theme’s common associations, and if you’re going to do something different you have to help players bridge the gap.

In Android each player is a private detective trying to solve a crime. At the start of the game there are several suspects. Players put tokens on the suspects which represent evidence that points toward or away from that individual being the perpetrator. At the end of the game whichever suspect the evidence weighs most heavily against is arrested.

Many players hated the way Android handles investigation. The game never tells players who “really” did it, and there’s no smoking gun. It doesn’t flow like a conventional police procedural, where the investigators follow a trail of evidence from A to B to C until arriving at an irrefutable conclusion. Rather, evidence simply accumulates until there’s enough to declare someone the responsible party. A lot of people felt that they were being asked to do a bad investigation, and that the whole game was basically an exercise in framing someone.

However, in my experience as an attorney the accumulation of evidence is exactly how most criminal investigations go. It’s unusual to “break the case open” and be 100% certain about who committed a crime. Even theoretically objective, science-driven evidence like DNA analysis is frequently subject to interpretation and vulnerable to error. Most cases involve evidence that’s still less reliable, like eyewitnesses (studies have shown that eyewitnesses are frequently wrong, even when they say they’re sure about what they saw) and peoples’ recounting of conversations (try to remember everything you said to someone this morning, word for word–it’s not easy, and that’s with no pressure!). All the police can usually do is gather these pieces of evidence, knowing that they aren’t what one might wish for, and see if they sum up to an adequate level of proof.

Android’s problem isn’t that its investigation was implemented badly. To the contrary, I would say that Android’s investigation is unusually realistic. The problem is that many players’ expectations aren’t met. A lot of people go in anticipating the type of procedural story we see on TV and read in books, with a clear right answer to find, and they’re inevitably disappointed.

The lesson of Android, I feel, is that in choosing a theme designers must keep in mind what players will expect. If a game is going to provide something different, the designer needs to go out of his or her way to help the players see where the game is coming from. Android neither delivered what players were looking for nor explained why it wasn’t going to, and so it has consistently been criticized for not doing things it was never meant to do.

I’ll wrap up with an I’m-not-getting-paid-for-this moment: Android can still be found on the shelves and at significant markdowns online. I encourage you to pick it up. It’s much different from other games on the market, and is worth trying out.

Theory: Succession Wars and Not Having Enough Players

This weekend I was forced to confront an issue that’s been lurking in Over the Next Dune’s development for a while: what happens when a group wants to play cooperatively, but has fewer than five players? To answer that question, we have to look at a game that grappled with the same problem–and that, I feel, got it wrong.

Fans of Battletech–the classic game of giant fighting robots–might be familiar with The Succession Wars (“TSW”). TSW was a zoomed-out giant fighting robot game in which five interstellar empires battled for supremacy. Instead of controlling a few robots, each player controlled one of the empires, moving its armies and trying to take over the other players’ territories. If you imagine Risk in space you have something of the idea.

TSW’s map was arranged in a circle, with each player having a piece of the circle. As a result, at the start of the game each player shared a border with two other players. In a five-player game, this arrangement is OK. Everyone starts with two players to worry about, and things are even.

Unfortunately, it turns out that that balance is very fragile. My friends and I tried the game once with four players. It was an unmitigated disaster. The rules direct that when there are only four players, one player plays two of the neighboring empires (the purple and green on the map). Hence, those two empires each had one “safe” border–my friend was quite reasonably not going to attack himself. Not having to divide their forces to cover two fronts gave those empires an enormous numbers advantage where they were actually going to fight. That game ended with the player controlling two empires steamrolling the opposition.

TSW was balanced around the idea that everyone would need to pay attention to two borders at once. Putting one player in charge of neighboring empires freed those empires from the need to defend against each other, which broke that cardinal rule and ultimately broke the game. The neighbors controlled by a single player effectively had twice as many forces to deploy on the border each was going to contest, which proved to be a dominating advantage.

The lesson I took from TSW is that when one player needs to “sub in” for others, controlling multiple players’ pieces, the rules must ensure that the player cannot combine those pieces to become more powerful than the other players in the game. TSW tried to avoid that sort of combination with a rule that the player in charge of neighboring empires could not pool their money or forces, but by allowing a strategic partnership between the two empires it ultimately failed to prevent the single player from having more resources than everyone else. OtND needs to avoid that mistake, and next time we’ll apply TSW’s lesson to our case study.

Something Completely Different

The playtesting project is winding down, just in time for the group testing I’m hoping to get in this weekend. On Friday I’ll have a couple of fixes for issues that have arisen, along with a bunch of playtest data and some thoughts on the results.

Since Over the Next Dune will really be taking over soon, I wanted to take a moment to talk through an idea that’s been bouncing around in my head. I’m always a little wary of working on a second project when the first is at the difficult testing-and-refining stage; it’s easy for the new project to become an excuse for avoiding the grindy part of game design. However, I think it’s safe if we all agree to keep this brief for now. 😉

The idea is this: in writing, one can use things like sentence structure to make a point. In Frankenstein the main character tends to use long sentences to describe nature, giving a sense of the natural world’s power and constancy, while using shorter sentences when describing what he himself did, suggesting his agitation and hurry. Can the same thing be achieved in game design? How far can one use the structure of the game, not just to make the game work, but to focus attention and bring about a reaction in the players?

I’m envisioning as a test case a miniatures game patterned on the Dynasty Warriors series of video games. In those games one plays a character who fights his or her way through hordes of trivial and easily-defeated opponents on the way to a final one-on-one confrontation with a villain. By hordes I mean hordes–tens of people attacking all at once. There’s a clear break between the waves of thugs, who are not especially dangerous and are mainly there to be swept aside in ways that emphasize how mighty the player is, and the “boss” at the end who is a legitimate challenge.

The game would be built from the ground up to create that sense of escalating tension and player empowerment. Everything, from the rulebook to the rules themselves to the playing field to the miniatures, would contribute to it. For example, each player might control some thugs and a major warrior. The rules for the thugs would be brief even to read, inculcating from one’s first exposure to the game the idea that these pieces aren’t important and that the player can dispatch them quickly. By contrast, the rules for doing battle with the opponent’s leader-warrior would be much lengthier, so that before one even begins play one has the sense that that battle will be more involved–that it will deserve more focus.

It’s just an idea, but it’s one I think could be a lot of fun. Dynasty Warriors games are rarely critical darlings, but they have a devoted fanbase; for all their technical sins they work as power fantasies. A minis game aimed entirely toward delivering that same sense of I am awesome could be a blast. Perhaps the next project after OtND?

Theory: The Limits of Rules

In discussing game design postulates, I proposed that one of them should be that a game is defined by its rules. What happens when someone acts in a manner which is plainly objectionable, but is not specifically addressed by the rulebook? Where are the limits of a game’s rules?

The classic example of this, in my mind, was suggested in one of Dave Sirlin’s articles: kicking your opponent in the shin. Obviously that’s not acceptable, but it’s very rare for a game’s rules to cover physically striking the opponent (contact sports aside). Surely games which do not explicitly make hitting illegal do not include hitting–but why?

Another, somewhat murkier example, can be found in a story about the Babylon 5 CCG that made the rounds years ago. For those not familiar with the game, it was based on a TV show which might be very briefly summarized as “the United Nations in space.” Like its namesake, the CCG was heavily political; it was played in a group and everyone was encouraged to wheel and deal.

As I remember it, the story went as follows: a husband and wife were playing in a game with several other people. One of couple offered the other a foot rub in return for attacking another player (or not attacking, or something). The other accepted, and the rest of the table was irked. I think there’s general agreement that this deal was fishy, and I agree, but I’ve never had or heard a really satisfactory explanation as to why.

Sirlin’s discussion of this sort of behavior concludes that “[a]ny reasonable person would consider ‘no cheating from outside the game’ to be part of the default rule set of any game.” That’s fair, but it’s more useful for tournament organizers than for designers. If I were running a tournament I could respond to a cheater who argued a lacuna in the rules by citing Sirlin. As a designer, saying “players shouldn’t cheat” doesn’t tell me when they’re out of bounds, or how far the bounds should extend.

In light of this issue, I’m considering modifying the postulate as follows: a game is defined by its rules and by the resources the rules make available to the players. When a player takes advantage of a resource not permitted him or her as part of the game’s design, the player is playing a different game just the same as if the player were using a mod or following a house rule.

This adequately addresses Sirlin’s example. Street Fighter and similar video games assign to players as resources their respective in-game characters (including special moves, hitboxes, canceling opportunities, and everything else that makes up a fighting game character). They also give players control over those characters, with all the skill, practice, and talent that players may bring to that control. Leg strength and pain tolerance are not resources provided to the players, and hence the game does not include the use of those resources.

I think it also provides a satisfactory answer to the spouses’ deal in the B5CCG. While the right to negotiate was provided by that game’s rules, foot rubs were not. As a result, offering and accepting one were outside the game’s parameters. From the perspective of the game in progress it was poor form and perhaps even cheating; from the perspective of the game’s design the spouses had begun playing a variant where some players begin the game with a special resource not available to others.

I’ve written more drafts of this post than any other, and even now I’m not entirely certain that I’ve reached a good resting place. Are there issues with the new postulate that I haven’t addressed? Situations it doesn’t answer? Let me know what you think.

Love Letter and Keeping Decisions Interesting

I had the opportunity a little while ago to play Love Letter. I wasn’t sure what to expect, but it turned out to be a great game–fun, a bit silly, easy to learn, good for a group that’s looking for something light. What particularly struck me, though, was the way its designer approached the very last decision players make. I went into the game expecting that to work one way, found that it was in fact completely different, and I learned a lot from the innovative solution.

For those not familiar with Love Letter, it essentially goes as follows. The game is played with a small deck of cards, each with a value and some text that does something when the card is played (e.g., look at the card an opponent has in hand or try to guess an opponent’s card to knock him or her out of the round). Players begin each turn with one card in hand. On his or her turn a player draws a second card, and then plays one of the two. When there are no cards to draw each player shows the card remaining in his or her hand, with the highest value winning the round.

The example of card text above suggests a fundamental strategy in the game: get information to make your plays more effective. Playing “look at an opponent’s card” first makes it much easier to guess that opponent’s card and knock him or her out!

In addition to cards that give information by their text, players can glean useful data by keeping track of the cards that have already been used. There are two Princes in the deck; if both have already been played, then no one has another in hand and “Prince” cannot be the right guess.

Most card games treat gaining information as strictly good, and use the last play as a reward for doing it well. Tichu rounds, for example, often involve a player with a strong hand tracking cards played (and the implications of those cards for what opponents have in their hands) until he or she knows the optimal order in which to put forward his or her remaining cards. If everything goes well, the last play is a formality that seals the player’s win.

Love Letter takes a different approach. At the start of each round, a random card is taken out of the deck and put aside without revealing what it is. As a result, one almost never reaches the point of having complete information. Even if one has carefully tallied all of the cards played, and made good judgments about what opponents are holding based on that information, one will still go into the last play with some uncertainty.

When we first encountered the take-out-a-card rule I was mystified. Introducing uncertainty to the last play seemed to take away the reward for gathering information–that “locked in” moment where one has complete knowledge of who is holding what and can make perfect moves. Preventing players from reaching total information, I felt, meant that the game could never amount to more than guessing; more informed guessing over time, perhaps, but guessing nonetheless.

Yet, as we played I noticed that the set-aside card changed the dynamic a great deal from what Tichu had accustomed me to. As a round of Tichu goes on it can become less interesting; the player with the best hand gets more information, increasing his or her control over the round, while the others see what is happening and start going through the motions. By contrast, everyone was engaged in rounds of Love Letter until either the round ended or they were knocked out. Keeping some uncertainty, even in the last play, meant that the last player could never set up a guaranteed victory and the other players could always hope to luck out.

In designing OtND I want to make sure that the players are making interesting decisions. Love Letter showed me that I need to expand that rule: those decisions should be interesting until the very end. Tichu is great, and its substantial rewards for gathering information are a part of its experience. However, I think OtND is closer to the casual Love Letter than to the brain-burning Tichu, and that the former is therefore a better model for OtND’s design.  I’ll be keeping an eye out during the playtesting project for situations where the endgame is locked in, and if that happens frequently we’ll explore ways to keep OtND engaging in the later rounds.

Theory: Zileas’ List of Game Design Anti-Fun Patterns

One thing I greatly respect about Riot Games, makers of League of Legends, is that they design according to rules. I don’t think they structure their analysis quite like I am on this blog, but the fundamental approach of logic-ing out problems through comparison to established principles is very similar.

Below is a list, originally posted in 2010, of some of the rules Riot’s VP of Game Design uses. I’m reposting them here because I like to keep them handy, and as food for thought. Don’t worry if you aren’t familiar with LoL, DotA, or the other games referenced–the rules are stated in a way that doesn’t rely on the examples.

* * *

I’ve been asked a few times, “Why don’t you do stuff like Rupture (from DOTA Bloodseeker) in LoL?”

I usually respond — Rupture contains several basic design ‘anti-patterns’. I thought I’d post for the benefit of those who are interested what strong anti-patterns I am aware of.

So… Here are a few that come to mind…. Note that you can find an example of each of these somewhere in our game at some intensity level. Sometimes this is just bad design. Sometimes this is because we got something else in exchange. Design is an optimization — but these anti-patterns are of negative design value, so you should only do them if you get something good in return.

To be clear, LoL has a number of abilities that use these anti-patterns. Sometimes it’s because we got something good in return. Sometimes it’s because we made design errors. However, we generally avoid them nonetheless, and certainly use them a lot less than other games in our genre.

Note: All WoW examples refer to original and BC WoW, not cataclsym.

Power Without Gameplay
This is when we give a big benefit in a way that players don’t find satisfying or don’t notice. The classic example of this is team benefit Auras. In general, other players don’t value the aura you give them very much, and you don’t value it much either — even though auras can win games. As a REALLY general example, I would say that players value a +50 armor aura only about twice as much as a +10 armor aura… Even though +50 is 5x better. Another example would be comparing a +10 damage aura to a skill that every 10 seconds gives flaming weapons that make +30 damage to all teammates next attack (with fire and explosions!). I am pretty sure that most players are WAY more excited about the fiery weapons buff, even though the strength is lower overall.

The problem with using a “power without gameplay” mechanic is that you tend to have to ‘over-buff’ the mechanic and create a game balance problem before people appreciate it. As a result, we tend to keep Auras weak, and/or avoid them altogether, and/or pair them on an active/passive where the active is very strong and satisfying, so that the passive is more strategic around character choice. For example, Sona’s auras are all quite weak — because at weak values they ARE appreciated properly.

Burden of Knowledge
This is a VERY common pattern amongst hardcore novice game designers. This pattern is when you do a complex mechanic that creates gameplay — ONLY IF the victim understands what is going on. Rupture is a great example — with Rupture in DOTA, you receive a DOT that triggers if you, the victim, choose to move. However, you have no way of knowing this is happening unless someone tells you or unless you read up on it online… So the initial response is extreme frustration. We believe that giving the victim counter gameplay is VERY fun — but that we should not place a ‘burden of knowledge’ on them figuring out what that gameplay might be. That’s why we like Dark Binding and Black Shield (both of which have bait and/or ‘dodge’ counter gameplay that is VERY obvious), but not Rupture, which is not obvious.

In a sense, ALL abilities have some burden of knowledge, but some have _a lot more_ — the ones that force the opponent to know about a specific interaction to ‘enjoy’ the gameplay have it worst.

Good particle work and sound — good ‘salesmanship’ — will reduce burden of knowledge (but not eliminate it). We still would not do Rupture as is in LoL ever, but I would say that the HON version of Rupture, with it’s really distinct sound effect when you move, greatly reduces the burden of knowledge on it.

In summary, all mechanics have some burden of knowledge, and as game designers, we seek to design skills in a way that gives us a lot of gameplay, for not too much burden of knowledge. If we get a lot more gameplay from something, we are willing to take on more burden of knowledge — but for a given mechanic, we want to have as little burden of knowledge as possible.

Unclear Optimization
This is a more subtle one. when players KNOW they’ve used a spell optimally, they feel really good. An example is disintegrate on Annie. When you kill a target and get the mana back, you know that you used it optimally, and this makes the game more fun. On the other hand, some mechanics are so convoluted, or have so many contrary effects, that it is not possible to ‘off the cuff’ analyze if you played optimally, so you tend not to be satisfied. A good example of this is Proudmoore’s ult in DOTA where he drops a ship. The ship hits the target a bit in the future, dealing a bunch of damage and some stun to enemies. Allies on the other hand get damage resistance and bonus move speed, but damage mitigated comes up later. Very complicated! And almost impossible to know if you have used it optimally — do you really want your squishies getting into the AOE? Maybe! Maybe not… It’s really hard to know that you’ve used this skill optimally and feel that you made a ‘clutch’ play, because it’s so hard to tell, and there are so many considerations you have to make. On the other hand, with Ashe’s skill shot, if you hit the guy who was weak and running, you know you did it right… You also know you did it right if you slowed their entire team… Ditto on Ezreal’s skill shot.

Use Pattern Mis-matches Surrounding Gameplay
I won’t go into too much detail on this, but the simple example is giving a melee DPS ability to a ranged DPS character — the use pattern on that is to force move to melee, then use. This does not feel good, and should be avoided. I’m sure you are all thinking — but WoW mages are ranged, and they have all these melee abilities! Well… Frost Nova is an escape, and the various AEs are fit around a _comprehensive_ different mage playstyle that no longer is truly ‘ranged’ and is mechanically supported across the board by Blizzard — so the rules don’t apply there ;p

Fun Fails to Exceed Anti-Fun
Anti-fun is the negative experience your opponents feel when you do something that prevents them from ‘playing their game’ or doing activities they consider fun. While everything useful you can do as a player is likely to cause SOME anti-fun in your opponents, it only becomes a design issue when the ‘anti-fun’ created on your use of a mechanic is greater than your fun in using the mechanic. Dark Binding is VERY favorable on this measurement, because opponents get clutch dodges just like you get clutch hits, so it might actually create fun on both sides, instead of fun on one and weak anti-fun on another. On the other hand, a strong mana burn is NOT desirable — if you drain someone to 0 you feel kinda good, and they feel TERRIBLE — so the anti-fun is exceeded by the fun. This is important because the goal of the game is for players to have fun, so designers should seek abilities that result in a net increase of fun in the game. Basic design theory, yes?

Conflicted Purpose
This one is not a super strong anti-pattern, but sometimes it’s there. A good example of this would be a 500 damage nuke that slows enemy attack speed by 50% for 10 seconds (as opposed to say, 20%), on a 20 second cooldown. At 50%, this is a strong combat initiation disable… but at 500 damage it’s a great finisher on someone who is running… but you also want to use it early to get the disable — even though you won’t have it avail by the end of combat usually to finish. This makes players queasy about using the ability much like in the optimization case, but it’s a slightly different problem. If the ability exists for too many different purposes on an explicit basis, it becomes confusing. this is different from something like blink which can be used for many purposes, but has a clear basic purpose — in that place, players tend to just feel creative instead.

Anti-Combo
This one is bad. This is essentially when one ability you have diminishes the effectiveness of another in a frustrating manner. Some examples:
– Giving a character a ‘break-on-damage’ CC with a DOT (yes, warlocks have this, but they tuned it to make it not anti-combo much at all)
– With Warriors in WoW — they need to get rage by taking damage so that they can use abilities and gain threat — but parry and dodge, which are key to staying alive, make them lose out on critical early fight rage. So, by gearing as a better tank, you become a worse tank in another dimension — anti combo!
– With old warrior talent trees in WoW, revenge would give you a stun — but stunned enemies cannot hit you and cause rage gain… So this talent actually reduced your tanking capability a lot in some sense! Anti-combo!

False Choice — Deceptive Wrong Choice
This is when you present the player with one or more choices that appear to be valid, but one of the choices is just flat wrong. An example of this is an ability we had in early stages recently. It was a wall like Karthus’ wall, but if you ran into it, it did damage to you, and then knocked you towards the caster. In almost every case, this is a false choice — because you just shoudln’t go there ever. If it was possible for the character to do a knockback to send you into the wall, it wouldn’t be as bad. Anyhow, there’s no reason to give players a choice that is just plain bad — the Tomb of Horrors (original module) is defined by false choices — like the room with three treasure chests, all of which have no treasure and lethal traps.

False Choice — Ineffective Choice
Similar to above, except when you give what appears to be an interesting choice that is then completely unrewarding, or ineffective at the promised action. An older version of Swain’s lazer bird had this failing… Because the slow was so large, you could never run away in time to de-leash and break the spell and reduce damage, and in cases you did, you’d just dodge 20% of the damage at a big cost of movement and DPS — so running was just an ineffective choice.

Or We Could **** the Player!!1111oneoneone
This is where you straight up screw over the player, usually with dramatic flair, or maybe just try to make the player feel crappy in a way that isn’t contributing to the fun of the game. These range in severity, but examples usually are spawned because the designer is a pretentious wanker who likes to show what a smart dude he is and how stupid the player is. I do not respect designers who engage in this pattern intentionally, and encourage any design lead out there to immediately fire any of your staff that does. I do understand that it can happen inadvertently, and that you might cause some of this stress on purpose in an RPG for character development.. And of course, I love you WoW team despite the ‘playing vs’ experience of Rogue and Warlock, as you DO have the best classes of any MMO, and they look even better in Cataclysm…. But, on Bayonetta, did the developers really think the stone award was a good idea? But I digress…

Very Severe: The original tomb of horrors D&D module is the worst in existence. Good examples are the orb of annihilation that doesnt look like one and instakills you and all your gear if you touch it, and the three treasure chests where each has no loot and deadly traps and no clues that this is the case.

Severe: There’s a popular wc3 map in China where you enter a bonus round, and have a 2% chance of just straight up dying rather than getting cool loot.

Situationally Moderate:Horrify + fear kiting from a competent warlock who outgears you in WoW. Guess what? You die before getting to react, while watching it in slow motion!

Mild: Stone award in Bayonetta. So… you barely get through the level for the first time, then get laughed at by the game with a lame statue of the comic relief character, and a mocking laugh. Please — maybe a bronze award and a 500 pt bonus might be more appropriate? The player might have worked VERY hard to get through the level, espec on normal and higher difficulties.

Non-Reliability
Skills are tools. Players count on them to do a job. When a skill is highly unreliable, we have to overpower it to make it ‘satisfying enough’. Let me give you an example: Let’s say Kayle’s targeted invulnerability ult had a 95% chance of working, and a 5% chance of doing nothing when cast. We’d have to make it a LOT stronger to make it ‘good enough’ because you could not rely upon it… and it would be a lot less fun. Random abilities have this problem on reliability — they tend to be a lot less satisfying, so you have to overpower them a lot more. Small amounts of randomness can add excitement and drama, but it has a lot of downsides. There are other examples of non-reliability, but randomness is the most obvious one. Abilities that require peculiar situations to do their jobs tend to run into the same problems, such as Tryndamere’s shout that only slows when targets are facing away from him.

Theory: Game Design Postulates

I said last time that “awkward rules are bad” felt like a postulate. After some further consideration, I believe I was mistaken in seeing a postulate there. However, it did get me thinking about underlying ideas in game design; just because awkardness-is-bad might not be a postulate doesn’t mean there aren’t any.

Now, I haven’t taken a math course for a very long time. However, in my memory (and a very brief internet search seems to agree), a postulate is something that can’t be proven through logic, but is so self-evident that it can be assumed as a foundational matter. In Euclidian geometry, a line can be drawn between any two points because it’s sensible for that to be true; one can’t prove it by building up from something else, but it’s so intuitive that there’s no cause to dispute it.

By contrast, “awkward rules are bad” is not as foundational as the properties of a line in geometry. A game can work with awkward rules. Furthermore, it’s not self-evident that awkwardness in rules is a problem. I grew up playing Avalon Hill wargames, and at the time I found their somewhat arcane rules charming. I enjoyed the challenge of figuring the game out, and when I had succeeded I felt like I had joined a select group who were initiated into a secret (admittedly the secrets were things like “how the wind rules interact with artillery smoke to block line of sight over the battlefield,” but still). Nor can I say that the proposition is inherently unprovable. If awkward rules are a problem, there ought to be reasons why and examples showing it.

With that said, I would like to lay down two things that I think really are postulates:

1. Fun is the goal. My interest here is in creating fun games. This blog isn’t about things like the prisoner’s dilemma; that’s a game, true, and it has fascinating implications for the field of game theory, but it’s not meant to be entertaining. My objective is to make fun games, and to understand better how one goes about doing so.

2. A game is defined by its rules. When one plays by different rules, intentionally or unintentionally, one is playing a different game. Monopoly is an enormously different experience when one puts money under Free Parking; strategies that work in a fighting game played without a timer will surely fail when the timer is turned on. (Seriously, turn the timer on. The designers included it for a reason. I can tell you from experience that the game will be better.) To participate in, understand, evaluate, and ultimately learn from a game one must play it by its rules; otherwise one is studying some other game.

The second postulate shows why the rulebook for Over the Next Dune needs to reflect how it is actually played, an idea I tripped on a bit in the last post. If OtND has any value (and I hope it does!), I want people to play it. If they are playing some other game they are not getting the value I want them to receive. In fact, I am concerned that they will get much less, because the game they are playing has not been tested and may very well be terrible. (OK, Over the Next Dune might also currently be terrible; part of the project here is to make it better!) Making sure that the rulebook is correct will help guide players to what I anticipate will be a good experience.

Neither of these postulates, however, directly addresses the issue of awkward rules. We’ll take that up in the future.

Theory: What is “counterplay?”

When I was in college I took a lot of political science courses. In those classes we confronted, again and again, the problem of definitional confusion: arguments started and persisted because people were using the same words to mean different things. It was impossible for theorists to agree on what the implications of “realism”* were, because they had different understandings of what “realism” meant!

The problem emerged again in the law. I vividly remember my property law professor in law school explaining a case in which a landlord and tenant had written up a rental agreement including the phrase “quiet enjoyment,” which they had seen in a do-it-yourself guide. They used it to mean “while it was quiet and enjoyable to live there.” Unfortunately, they had employed the term completely incorrectly; in property law, “quiet enjoyment” is a technical term having absolutely nothing to do with whether the neighbors are loud or whether the tenant likes the apartment.** As a result, when the relationship turned sour the case was unusually difficult to resolve. The meaning of this key term in the agreement had shifted as the landlord and tenant stepped through the courthouse door, completely changing the nature of their dispute.

I sometimes see the same issue in game design. In particular, this comes up in discussion surrounding League of Legends, an extremely popular online game. The designers of League of Legends speak frequently with the playing public, and in doing so they talk a lot about the need for “counterplay.” Unfortunately, there seems to be a definitional divide between the players and the designers (and between different players, and perhaps even between the designers?). As a result, players in these discussions sometimes arrive at conclusions the League designers disagree with–and, just like in political science, arguments start.

What, then, does “counterplay” really mean? It’s clear both from the phrase and from the League designers’ usage that counterplay means something like “you can’t just stomp all over the other player, he or she has to be able to do something about what you’re doing.” However, that definition is about like the “bouncing screen saver” approach to Over the Next Dune; it’s a helpful shorthand but to do real work we need something a little more thought out.

I feel that the most useful way to approach the problem is to break the phrase down into two parts: counter and play.

Counter means that the opponent can respond in a way that makes the opponent’s situation more advantageous than it would otherwise have been. This might mean completely negating the action (Magic: the Gathering’s counterspells), or just mitigating its effects (in League, using Leona’s “W”–a shielding spell–to block some of the damage). Mitigation can even involve an axis completely separate from the attack. For example, in Legend of the Five Rings there are cards that gain offensive power as the opponent destroys one’s resources; these do nothing about the loss of resources, but can help enable a comeback. The key is that when a player acts, the opponent does not have to simply accept being worse off.

Play means that the counter-action(s) the opponent can take are interesting for both the player and the opponent. A good example of this is Vi’s “Q” in League. The Vi player can push “Q” to get ready to charge, and let go to charge in a direction of the player’s choosing. However, the opponent can see Vi getting ready and has the opportunity to dodge out of the way. This leads to some fascinating mind games:

Opponent: “if I just keep going in the direction I am, I will be predictable and Vi will hit me. Should I turn around? If I do that I’ll be out of position to retaliate. What about a stutter-step, so I keep going in the same direction but I throw off Vi’s aim? I’ll end up closer to her, but I’ll have to time it precisely. OK, what if I . . . .”

Vi’s player: “My opponent needs to retreat toward teammates, so she’ll probably keep going in that direction. However, I don’t want to get too close to the opposing team. Maybe I can act like I’m going to charge that way, and then force the opponent to turn away from her team . . . .”

All of this happens in a second or less. It’s a game-within-a-game, and it’s a lot of fun. Getting inside the opponent’s head, correctly predicting his or her choices, and making the right play in response feels great.

Now imagine the opponent just had a button that stopped Vi’s charge. The opponent doesn’t have to do anything, there’s no cost to doing this, the opponent can do it as many times as he or she wants. Just push the button and Vi’s charge stops dead. That would be a counter, but it wouldn’t be interesting. There would be no play in it.

Hence, counterplay means that opponents can respond to a player’s actions in ways that help the opponents stay involved in the game and that are interesting for all involved. Just stating the definition is enough to explain its importance. A game that’s involving and interesting sounds like a good one, doesn’t it?

What I particularly like about this definition–what I think makes it better than intuitive understandings–is that it provides measurable benchmarks. If you want to know if there’s counterplay, ask: what can the opponent do in response? Do those actions improve the opponent’s position? If so, by how much? Do the opponent’s responses create a layered situation that’s interesting for everyone? By answering these questions you can determine in as close to a quantitative way as possible how much counterplay a situation or design element has.

Take it from a lawyer: it’s no fun to find out you’ve had a pointless argument with someone you more or less agreed with, just because you misunderstood each other. I think this definition of “counterplay” is useful enough to put into practice, and it’s the one I’ll be sticking with going forward. I can’t make everyone on the internet use it, but if you see it around here, you’ll know what I mean. 🙂

* This is not a great example–realism is actually a long-standing and well-understood theory. I hope, however, that it gives the flavor of the arguments.

** It has to do with who owns the property, but this isn’t the place for a detailed discussion of the concept; if you’re curious or have a legal question, please see the disclaimer.