Posts Tagged ‘game design’

Le fraise sans merci

Monday, July 13th, 2009

I often get bogged down in the process of game design shortly before playtesting. In part, this is often because I get bogged down in revisions and edits. However, often I simply get daunted by the process of making the components.

I’m mainly talking here about board and card games; to playtest an RPG, you generally need to write some adventures, but what the heck, no one ever playtests RPGs anymore anyway. But at some point when developing a board or card game, you have to actually make boards and cards.

Aside from the physical making — index or business cards get you a long way in game prototyping — I often need to make up a whole lot of relatively arbitrary game tokens. If I’m writing a game about the secret politics of a restaurant kitchen after all the humans have gone home, I’m going to have to stat up a lot of creatures with Influence, Ruthlessness, and Deliciousness. And how do I know what a rutabaga’s Deliciousness is relative to a chanterelle? Presumably less, but how much less? How about a parsnip? Is a strawberry more or less ruthless than a ripe Camembert?

Worse, I know that the vast majority of these I will get wrong, because the main problem of early-phase playtesting is getting the asset distributions sufficiently right that you can figure out whether the core mechanics are worth saving. The task of spending a ton of time producing components that will probably survive only a single playtest is a daunting one, and one that often confounds me for a long time.

Failure Modes in LARP

Thursday, July 21st, 2005

I am, in some respects, a rather grim individual. One of these respects is that I tend to respond to the conclusion of a project by introspecting a while on what went wrong. (I try to stay positive, but this generally means an occasional ray of light among the grim. (This is why I never publish my postmortems of anything; they’re depressing. And vulgar.))

Anyway, last weekend I was on staff for a LARP, and I’ve been mulling over places I erred. Out of the internal discussion, I’ve noticed a few distinct types of failure in assembling a LARP. And never one to resist a taxonomy, I share them here.

Failures of Conception: Sometimes, an idea that seems clever just isn’t. Or sometimes there are bits of gameplay that would never have worked, but you didn’t manage to put two and two together. Case in point from the game just past: in game, there were two ways to learn a new skill. You could brew a potion using the alchemy system, generally having to pass through three to four intermediate steps and using up consumable resources. Or you could find a tutor and spend ten minutes getting taught the skill. Individually, both mechanics seemed reasonable. Side by side, I feel like a dope.

Failures of conception are frustrating, because you can’t really explain them away — you screwed up, no two ways about it. At the same time, they’re the easiest to learn from. The error is usually clear, and often you can draw some nice principle to blog about, which is pleasant.

Failures of Implementation: Sometimes bits of gameplay didn’t work because they didn’t work like they were supposed to. You ran out of time, someone else on staff misunderstood the packet, the crucial prop broke, whatever. It didn’t work right. The classic example, in my experience, is the political mechanics for The Bear in Winter, the Victorian steampunk game a crowd of us ran in January of 2004. I got caught up in making really badass maps, ran out the clock, and failed to finish the asset lists. It was basically unplayable. It’s possible that the mechanic would have proven a terrible failure of conception — it was a little avant-garde — but I don’t know; it never got its chance. (To this day, I want to run a game where I can take it for a spin. If you’d like to play in a small-scale experimental diplomatic simulation, bug me about it and maybe that can happen sometime.)

Another example, to my mind, is the combat mechanic from The Camel in Summer (the game from last weekend — yeah, there’s an Animal in Season motif going on there (huh, now I want to run a 1920s expatriates game called Coq au Vin)), which I realize some people feel was a failure of conception. The original idea was an attempt to make hand-to-hand combat, which was not really appropriate to the Arabian Nights bazaar setting, vaguely embarrassing. It was akin to your generic non-boffer LARP combat mechanic, but in place of rock-paper-scissors, we were going to use Rockem Sockem Robots. At the last moment, we couldn’t find Rockem Sockem Robots, and used a travel set of Hungry Hungry Hippos instead. Unfortunately, the table we used didn’t stay level, which made it sort of pointless; Hungry Hungry Hippos is very easy when you have a slope in your favor. It’s possible the mechanic would have been problematic in any event, but we don’t really know; the tilt pretty much spoiled it.

Failures of implementation drive me nuts, because there’s not much you can draw from them other than “shit happens”. They also cause arguments; I get most defensive when someone is critiquing a failure of implementation as if it were a failure of conception. I can’t really defend the gameplay in question — it didn’t work. At the same time, I don’t feel like we can say much useful about it other than on a theoretical level based on what we instinctively feel ought to work, and purely theoretical arguments about LARP are best resolved with nerve gas. (See? Depressing and vulgar. Well, violent, anyway.)

Emergent Failures: Intrinsic to the form, emergent failures happen when the players behave in unanticipated ways that cause gameplay elements to collapse. Arguably, this is a subtype of failures of conception, because in theory you should have been able to anticipate that the behavior at issue might happen, but if you can anticipate everything the players might do, there’s not much point in running the game from where I’m sitting.

An example of emergent failure is the underutilization of the alchemy system in The Camel in Summer. Many of the potions you could make affected the combat system — healing, powerups, etc. The dysfunction of the combat system, therefore, meant there was no demand for a lot of what you could do with alchemy.

Emergent failures are one of the things that I realize really aggravate me about the essentially interactive-literature-style games we’ve been running. I used to run boffer games, with large staffs and an essentially players-vs.-staff narrative structure. When things went wrong in unexpected ways, it was possible to roll with it. The biggest game I ran, a weekend-long piece called Mysteries of the Sunken Hundred, went horribly awry on the second day. The players had failed badly at one plot thread, and were basically unwilling to do what had to be done to avoid catastrophe. So my co-GM and I sat down (after cursing a bit), brainstormed a few minutes, and drafted an entire new slab of gameplay to get the game back on track. We slotted it in, and none of the players ever realized we hadn’t meant to do it that way from the get-go. I can’t do that in an IL game. I don’t have the staff to make more than subtle changes to the flow of the game, and even if I did, the PvP narrative structure of the style makes it hard to help one player out of a hole they’ve gotten into without possibly screwing over another player.

Failures of Aesthetic: I almost hesitate to put this last category in, but I’ve seen (be honest; I’ve done) things that made the players absolutely miserable, but worked *exactly* the way the GM intended them to. I hesitate because I think the first three categories are more or less objective, while this one depends on the common but not universal proposition that if a player didn’t have fun, that is by definition a gameplay failure. Now, there are certainly times when players create their own unfun, but I find it useful to distinguish between gameplay that didn’t work and gameplay that did work but wasn’t fun. Case in point: I wrote a game once where the entire player group was killed by fiat halfway through and spent the rest of the game on the run from the spirits who collect the dead. There were a few players who felt, either in or out of character, that all good people ought to embrace their eternal reward, and were pretty upset about the whole thing. I think, on the whole, the conceit was worth it, but I still consider it a failure in part for that reason.

Dinosaur Mind

Tuesday, April 12th, 2005

At the GDC this year, I went to the Casual Games Summit, which wound up discussing a variety of markets underserved by the hardcore-centric status quo. One of the speakers noted, “People think that games for children have to be so simple. Have you ever looked at Pokemon? *I* can’t figure all those critters out.”

There’s an interesting issue there about the nature of complexity. Pokemon is intimidating to the uninitiated — there are several hundred of those little critters, with weird names and subtle distinctions between them. But it’s not really that *complex*; mechanically, it’s pretty simple (a little baroque, maybe, but not complex). Its complexity lies in the *diversity* of the game assets, and the fact that children can master this complexity is basically the same phenomenon as when six-year-olds memorize every dinosaur of the Jurassic through Cretaceous periods; kids are good at absorbing massive swathes of systematized trivia.

“Dinosaur mind” is a talent that fades for most people over time; I know I find my brain less willing to hold on to information I’m not going to need later, or that I can look up if I need to, as the years go by. Interestingly, I think gamers as a class tend to hang on to their dinosaur minds longer; I can cost out a GURPS 3e character without a book, and I know people who can debate the differences between the spell lists in the first and second editions of AD&D from memory. Probably it’s a matter of practice.

Dinosaur mind has implications for designing games for non-standard audiences. When designing for non-gamer adults, you can assume that your audience can tolerate at least moderate complexity, but not that they’re willing to memorize all sorts of fiddly bits. When designing for children, the opposite is true; it’s probably wise to place the complexity of a children’s game in the data, not the algorithm, to use a computing analogy.

More Gaming Terminology

Sunday, April 10th, 2005

I’d like to share some personal terms of art I use when talking about game design, because I will probably want to use them in the future, and it would be handy to be able to simply hyperlink to what I mean.

There are three dyads I want to talk about today. The first comprises brittle and robust; these terms discuss the scope of things that a game system can do. A robust system can handle a wide variety of issues and situations without breaking down. The HERO system, for example, is an RPG which places a high value on robustness; the implicit design goal is to be able to handle any concept within the game’s mechanics. Original D&D, conversely, is a brittle system; it’s pretty good for going into dungeons and killing things, but anything outside that scope requires the players to expand the rules somehow. (Arguably, this was a good thing for RPGs as a whole, by demanding large-scale rules innovation and ferment from the get-go, but that’s a different issue.)

The second pair of concepts is simple and complex, which cover, in essence, how much stuff you have to remember or reference in order to play the game. A system in which you have to roll a die and exceed a certain number to succeed is simple; one where you have to roll a die, apply a raft of modifiers, cross-reference with the difficulty of the task on a table, then roll another die, apply a different set of modifiers, and check another table, depending on the results on the first table, is complex. Some of you may know what I’m talking about here.

Finally, we have elegant and baroque, which refer to the relationship between the other two quantities. An elegant system has high robustness relative to its complexity; it is no more complex than it needs to be. A baroque system, on the other hand, is more complicated than it needs to be for its expressive power. This isn’t necessarily a bad thing; some systems are deliberately baroque in order to convey a certain flavor. Original Deadlands, for example, is extremely baroque, using all the major polyhedral dice, playing cards, and poker chips in its resolution system; some of this baroqueness, however, pays dividends in setting a tone for the game.