Friday, November 10, 2017

How to Write a Rule: Theoretical Frameworks

I went looking for a video that would explain theoretical frameworks with wonderful images and conceptual relationships, like this video explaining changing education paradigms ... unfortunately, theoretical frameworks are not sexy.  In fact, they're mostly explained by very, very dull sociology PhDs trying to encourage graduate students to use them.  I watched three of these torture-scapes.  I would not recommend sitting through the whole of that last link, nor any link associated with it.

Basically, a theoretical framework is what our grade 4 teacher tried to make us understand about writing essays: that the point is not to just give information, but to research in order to determine what part of the content is yet uncertain.  Why, for instance, did the Roman Empire collapse?  The essay is an attempt to answer that question.  Part of the essay should explain why the answer is feasible, or possible, and how precisely that it makes a contribution to existing arguments that have already been made.

No one expects a 4th grader to produce a contribution: but we do expect graduate students to do so, even if it is a very, very small contribution to a very, very negligible part of the discipline.  At least it's a contribution. If we're not making a contribution, there's no point.  It would only prove that we know what others know; and that's what your undergraduate degree was for.  We expect more if you're going to keep studying.

Okay, putting this in the context of games.  You're settling down to make a new rule, or set of rules, for a game or a new game you're designing.  The principles are the same.  We want to know, what problem is this rule meant to solve?  How will it fit into an existing framework, so that it works with other rules?  Why is your approach to the rule feasible, or practical?  And, finally, how does your rule make a contribution to the game itself?

If your rule seems to solve a problem that other rules have already solved, and you can't explain to others why that's not the case, then you've failed.  If your rule wrecks other rules that work to solve their problems, then you've failed.  If the implementation of your rule is difficult and hard to understand, or so time consuming that players won't use it, you've failed.  Your rule has to contribute, not obscure, undermine or confuse.  If you're not clear on how your rule contributes, your thinking process is muddled.

Let's look at the creation of a rule as an example.  For this, I'll choose a rule that I haven't written; and is, in fact, a problem I haven't solved.

The problem:  As part of an adventure, the players are faced with climbing a mountain that will enable them to reach the lair or a creature, or the entrance of a dungeon.  The mountain, perhaps within a range of mountains, is steep and dangerous.  The characters have no specific mountain climbing abilities.

The proposed contribution:  The mountain-climbing experience will be interesting, immersive and ultimately a game in itself, providing the players with the some of the tension we would expect them to have if they had to actually climb the mountain.

The problem has not, to the best of my knowledge, been solved.  I have run into other mountain-climbing rules, but these are generally flat and lifeless and feature details focused on measuring distance, not providing a legitimate immersive experience.  Remember, what we're looking for is Bogost's procedural rhetoric. Furthermore, the rule has to fit into existing rules: so we can't change the character-design by adding extra pieces and logic that doesn't then fit into the rest of the system, nor can we change rules about falling, nor adjust varying rules applying to dexterity benefits and the thief's ability to climb walls (which, it must be noted, are very different from sheer rock surfaces).  To be immersive, the rule also has to fit the player's actual personal experience with rock climbing in the real world, at that experience is also a "rule" that has to be reflected in the rules we write.  Finally, the rules can't be excessively complicated or incompatible with the ideal of "tense, thrilling danger."  Too many rolls, too many calculations, too much problem solving will ruin the proposed contribution.

Ideally, I think it should be possible to resolve the mountain-climbing experience in about 30-45 minutes; if the rule-system is elaborate enough to allow creativity, and the procedure direct and easy-to-understand, something that would take as long to play a hard game of chess would fit our goal.

That's a high bar.  But if you're not willing to compete at this level, take your ball, go home, stop game designing.  You're not suited for this.

What structure is needed?  That's what I spoke about in the last Rule post:

  • How do we incorporate time and space into the system, in order to let the players control the experience without relying upon random rolls that serve as a pass/fail result?  What sort of preparation can the players make regarding the mountain that will change the parameters of their experience? How will their control of time and space eventually lead to the wager they'll have to make on surviving the challenge?
  • How many paths up the mountain can we provide?  Can we do this without having to map the entire mountain, which would only mean having to map the next mountain and the mountain after that.  What designs can we incorporate into the rules that will make the mountain's structure fit into the rule set as a random collection of possible surfaces/routes, so that: a) before the players climb, they can pick a route; and b) during the climb, they can learn about the environment well enough to strategize upon risking a different route?  How many times can this decision be incorporated into the rule system?
  • Can we get along without a single death-save die roll?  Can we minimize the number of rolls, hinging them on the player's decisions, or increase the number of rolls with really ridiculously low chances of failure?  If the players are moving along a ledge, and are forced to make ten rolls to succeed, and each has only a 1 in 500 chance of failure, does that increase or decrease the immersive quality of each roll?  We can either start with a minimal number of rolls, increasing their frequency as the players make bad decisions, or we can start with an excessive number, decreasing rolls as the players make good decisions.
  • How many effects can we include in the results?  There's more to lose than lives; there's equipment, loss of hit points, loss of body parts (if it is very cold, frostbite), the inability to act (forcing someone else to save the victim), a chance of being separated from others, unconsciousness, delusion, hunger, thirst, a loss of spirit to go on and whatever else we can include.
  • What rewards can we provide apart from the success of reaching the obvious goal?  What else can be found or learned on the mountain?  What skills can be acquired from the ordeal?  What status can be gained, if there are others coming along or others who know of the party's intent?
  • And for those who will perceive the problem can be solved with magic, what updrafts, steady winds and dangers might be present for those who believe they can simply fly or levitate their way to the top?  If a teleportation spell is used, are the players then trapped on the mountain top until the spell can be reused, unable to get down, because they don't know the best route?  Being D&D, we want to consider issues like this as well.

Always, the manner in which these questions can be answered best rests in solid, detailed research into actual mountain climbing.  Considerable research.  And a great deal of brainstorming.

Let's leave it here for the time being.  Give it some thought.

2 comments:

Drain said...

I made a stab at this recently. I wasn't even happy with my sandcastle when in you barge to flood it into a wet mound of inadequacy; thank you for that.

Seriously: climbing could be a whole RPG by itself, it's just that rich and intricate and difficult to replicate. Doesn't help that it is a feature that is only present on occasional instances, meaning it's very easy to file away for a later day each time it comes up.

For now, abstraction will have to do, but it is a topic I would love to give some more thought.

kimbo said...

Interesting direction, Alexis, i really like principle based problem solving, yet finding and articulating principles in a useful way is surprisingly difficult. The pregame background career minigame in Traveller is a good example of ruleset that was fun to many and has lived long in memory yet was designed for very specific game circumstance.

As a hiker (but not climber nor mountaineer) is see in the mountain climbing minigame the two main decision variables for a party.... time and risk: take the longer safer routes or the quicker/more dangerous ones, (or additionally the more stealthy routes). Extra time has its own complications (supplies, exposure, weather change, risk of detection/encounter or ambush) but trading off time vs risk would seem obvious to this non-climber.

Tangent.... Alexis, have you seen Triz principles of problem solving...
Part of it is a list 40 of standard solutions to all known mechanical problems, one could see them as solution archetypes to engineering problems, useful for insight into potential solutions.
http://www.triz40.com/aff_Principles_TRIZ.php

K