Sunday, 27 March 2011

About gaming/designing LOTR: part II

Another post in the behind the curtain series and a direct continuation of the previous post. I've been neglecting my posting a little, mostly because I've been fucking busy. Not to say I haven't been posting, just not as much as I'd hope to or as much as I had hoped. Now, to business...



Last time I tried to look at what "gaming LOTR" would look like from different perspectives. I concluded that for a successful game, the "accuracy" of the story would need to be purely accidental and post-festum, on the other hand, if we put the accuracy first it would fail as a game. I indicated a third way, which included
a) playing by the rules most of the time to ensure a successful game and
b) fudging the dice and ignoring the rules when they violated the accuracy of the experience

Personally I deem this unsatisfying, and as usual, you're welcome to disagree. What I'll be doing for this post however will be looking at how to take this third way and making it more satisfying and better than either of the first two ways. In other words, how to design a LOTR game.

1. Why fudging
To satisfy the criteria of the "accuracy" of the roleplaying experience, we, as a group use two fundamental methods: agreement and denial. We agree what fits and deny what doesn't. This is not denial in a negative sense, because it is used to preserve the group's aims (in satisfying their expectations).

Agreement is easy, while denial is often more jarring, because it requires a little more deliberation, a judgement call, it knocks us out of the zone because something wrong first has to emerge, before we deny it. It's a hiccup in the play process.

The disagreement must often comes from the dice, because (in theory) we as a group agree to what we're doing here, what our expectations are and find it relatively easy to agree and sustain that. The dice on the other hand are mute and deaf. They don't communicate with us, they can't respect our agreement and roll as they will. Traditionally, they're the most common source of the wrong element of our experience that disrupts the expected accuracy. And that's why we fudge.

2. What to do about it
Now, you might not consider fudging a problem, in which case you're excused and need not read on. But here are a few things you can do about it. I generally consider there to be three obvious buffers that remove or at least seriously lower the need for fudging: I-fix your expectations, II-successfully ignore the system, III-fix the dice. Let's take a quick look at those options.

2.I. Fix your expectations
I established that we fudge a die when it doesn't fit our group's jive. Now, the question is why? There's a disconnect between what the dice do and what your group is doing. A very easy thing (easy in theory, because it requires a lot of shifting of mental gears) is to adapt your expectations to what the dice are doing.

Figure out what the game's results are, what it does. I've whined enough about my aesthetic disagreements with D&D. But hey, that's definitely not D&D's fault. It's my fault when I expect D&D to do something it's not designed to do. So shift those gears. Figure out what your game is doing, how it works, what kind of fiction it produces. Frex, since I was looking at the manual just yesterday: Battletech RPG has a 2d10 roll for resolution where 10s explode but just a double 1 is a fumble. Which means this is a system where critical successes are a lot more likely than fumbles: what kind of action does that suggest? And don't just take one bit of rules in isolation, look at the whole mechanism.

What does the game that you're using do? Does it fit what you're expecting? Embrace your game's rules or change the game. I remember a GM talking about how some of their players were insisting of playing normal, average people in Scion. Why? If a game does something, do it.

2.II Successfully ignore the system
God knows I've done my fair share of this over the years. It's a double edged sword. On one hand it allows you to run just the kind of game you want, but on the other hand it can lead to all sorts of strange cockups (which I have no intention of talking about here).

In the case of old, less well-defined systems, it becomes a necessary part of the GM's toolkit. Grognardia's James Malizewski has said a few times that in his opinion the "killer DMs" of early D&D were guys who were sticking to close to the rules and rolling dice for everything. In short, they weren't leaving any room for judgement calls, no attempts were made to subdue the dead letter of the rules to the living, dynamic fictional reality that the group was creating.

The lesson is simple: when the rules contradict your group's jive, kill the rules. Ignore them, brush them aside. The most simple and functional aspect of this is learning, over the years, when exactly to call for rolls and how to apply the results. An experienced GM will know when to tell her players when to reach for the dice and when to just narrate their success, as well as how to interpret the results. This seriously lowers the chance of "wrong", unexpected or frustrating outcomes.

2.III Fix the dice
Both of the above methods are ok. In short, they tell you to either "love it or trash it" or "know when to roll". What they both do is to be a step ahead of the fudging. You don't need to fudge because
a) the result is now part of your expectations
b) you're using a different game altogether (which, presumably, fits your expectations)
c) skip the rules that you have learned will produce unsatisfying results, learn not to roll at all instead of trying to fix it after the dice mess up

That's all cool but they're not design. Which is what we were aiming to talk about here. Well I was, at least. So let's look at this third option more closely.

3. The design step
I started this inquiry more or less with that example of a game in which Frodo is basically killed by a troll and the GM fudges the dice to save him (because hey, Frodo is supposed to survive). When such a dissonant result happens in play, when the dice violate our expectations, the most common thing is to ignore or fudge, as described above.

Another common thing to do, that has been done since the dawn of time, is houseruling. It's just that we haven't been using it for this, not usually, at least.

All design is houseruling. Every single game you ever bought or played, even the glossiest hardcover from that big publishing company is essentially a homebrew. (Now, obviously, there's always good design and bad design.)

People play games and then they go "You know it would be cooler if this worked like this." or "I think this is unrealistic, this would feel more real." or "That thing is more useful than this other thing, we should make this other thing more useful, too.". We drift and push and nudge, it's just that we rarely write it down or take it to its full conclusion. Sometimes we simply have to start from scratch.

So, ok, back to that Frodo example. The ringbearer, following the rules, dies and that's obviously bad (in respect to "what are we trying to do here"!). So the GM overrules it. And usually we would just let that slide past.

What follows is what I consider the most important bit of this series so far.
Take a breath.

Instead of just letting it slide, let's pause for a moment and step back. Let's ask some questions. What are we trying to do here? Why was whatever just happened (Frodo dying) bad in respect to that? Will it happen again? Why? (Which parts of the mechanics and elements our play are causing it?) Things like that.

A simple thing the GM could do instead of just waving this ruling past would be to write down a very simple "houserule". He should spell out his technique, his trick, formalize it. Something like: "When the ringbearer dies, introduce some element of the game world that will save his life." Now that's suddenly a rule. Something to fall back onto.

It's a pretty sucky rule, really, but it's the first step. We're changing the basic assumed rules and building towards something that fits. And that's design.

Over time, that could change into something completely different, maybe it wouldn't even be spelt out in a rule like that...but the final effect would be the same: Don't let the ringbearer "just die". The best thing would be to ensure this through some invisible interplay of other rules and mechanisms, points, dice results, etc.

To use an example I already used a long time ago: in the card game Bang! you have one Sheriff, one Renegade and a number of Outlaws. If the Sheriff dies, the Outlaws win. If the Outlaws and Renegade are dead, the Sheriff wins. The Renegade wins if he's the last one alive.

What happens is: the Renegade will start killing the Outlaws, because if he starts killing the Sheriff, the Sheriff will be overwhelmed and the Outlaws will win.

There's no rule that says "The Renegade should attack the Sheriff first." It's the interplay of other mechanics and goals that suggests it. That should be our "Frodo doesn't die."

Something that the rules harmoniously suggest, lean towards, support, without putting it up in front of you like a brick wall. And when your mechanics do that, then you've made a game that fits your expectations by design.

Now, I'm not saying a LOTR RPG (or the upcoming LOTR RPG) should have a specific rule like that. What I'm saying is, the theoretical designers should look at the books, read them, figure out the common themes, the reoccurring elements, the norms...extrapolate the common expectations and then make a game that, by design, supports and suggests those themes. Without putting a brick wall in your face.


--
Man, these posts are becoming really fucking long. I will cut here and I hope to continue this soon one way or another. No more LOTR next time, but I'll still be talking in circles around the same points that I'm trying to make.

No comments:

Post a Comment