It’s not the project at hand, but I haven’t been able to get my mind off of the idea of “reinforc[ing] the players’ feelings of might, prowess, and general awesomeness” when the players are directly competing. How does one create a situation wherein both players feel good about themselves and what they’re doing, even when someone is losing?

Legal analysis says that we shouldn’t just wander in the woods trying to answer this question. Instead, we need to define the issue carefully and find out what the relevant rules are.

As we cast the issue we need to be specific about the situation we’re dealing with. The answers might be different for games played by two people, for three people, for two people cooperatively, for asynchronous play over the internet and simultaneous play on the tabletop, etc. Knowing the limits of whatever answer we come up with is important.

Since this is a miniatures game, let’s assume that we have two people playing against each other on a tabletop. That has at least three advantages:

1. Having the players set against each other makes the question harder–and, I suspect, more interesting.

2. Allowing more than two players leads to tricky balancing considerations which could distract from the project as time goes on.

3. Two players against each other in a real-world, synchronous match is the classic setup for a miniatures game. Being traditional isn’t a good enough reason by itself, but if this game is similar to others from a macro-level perspective it gives us some points of reference and examples for comparison. Again, the goal is to focus on specific ideas and innovations; it’s not necessary or desirable to start from scratch in every area.

With that in mind, the issue can be framed as:

How can a two-player competitive game reinforce both players’ feelings of might and prowess, where the game is played synchronously in the real world?

(I omitted “general awesomeness” as a feeling because it’s not very descriptive–we’d end up with a whole new issue of what “generally awesome” feels like. I’m pretty sure that if the players feel mighty and like they have great prowess, they’ll feel generally awesome.)

The more I get into this the more interesting it becomes. Both players have to feel strong, but they’re facing each other IRL in a competitive enterprise. It’s a situation rife with opportunities for one player putting the other down, and we have to build them both up. I love it! Let’s talk rules next time.

League of Legends designer CertainlyT posted an interesting commentary about a special ability he crafted for the game. Some knowledge of League is required to follow along, but even if you’ve never played it you might enjoy seeing his process.

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.

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.

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.