applied RPG Design Patterns

[talysman]

John Kirk referred us to his work in progress, RPG Design Patterns, a few threads ago. I didn't say anything at the time, although I thought the book is shaping up very nicely as an import design tool. aside from the obvious steps of thinking "what could I use as a design pattern for X?" and then looking it up, the diagram system, although quirky, can be pretty useful when sketching out the way your RPG will work. I'd advise everyone to do this long before you write down any text. it helps to clarify how the system will work and possibly identify parts of the system that can be "factored" to make the whole game run more smoothly and make it easier to explain (and understand.)

as an example, here's a game I'm working on called "Meet the Neighbors". it was my first attempt at the September Ronnies, using "Suburb" and "Hatred" in a game where the players are all members of one family trying to fit into a new neighborhood. I didn't finish writing up the text, so I never submitted it, although I would still like to complete it.

so, since I wanted to figure out the rules in more detail and test a symbol set I made for just this purpose, I sketched out the character creation, suburb creation, neighbor creation, and conflict resolution parts of the game and printed them as a PDF. I need to fix the arrows so that it's easier to tell the difference between broken and solid arrows, but the page otherwise looks good. I figured I would post it as an example of how to do it; plus, I'd like to see some other people here sketch out sections of their own rules, or rules for games they're familier with, so that we can all practice reading and designing rpg structures this way.

I hope someone finds this helpful.

[Mike Holmes]

Excellent point, John. I've often tried to give the advice about "factoring" as you're refering to it, but it's hard to explain what it means. But, let's say you have two resolution systems, side by side, in your design. Well, put them down as diagrams next to each other and look for similarities. What you can find are ways to either make but one system out of both (making play easier to learn), or even better to link the systems together to create a synthesis of the resolution products that didn't exist previously.

Your example is nifty.

Thanks,
Mike

[talysman]

Your example is nifty.

in case anyone is interested in doing the same thing, doesn't want to do the diagrams by hand, and doesn't want to create the symbols from scratch, the tool I am using is a free (as in GNU) dungeon cartography program called AutoREALM. I created a custom set of icons (61 KB) which you can download, drop into the AutoREALM library folder, and immediately use. I think. I haven't tested adding icon sets.

incidentally, the icons are editable. the only graphic element that wasn't created directly in AutoREALM is the spade symbol on the Card icon; it's from the standard Windows Symbol font.

[talysman]

oops, don't click on the icon link; right=click and save instead. otherwise, your browser may try to open the file, since it's in XML.

also, to create PDF with it, you will need a PDF print redirector, such as Ghostscript or PDF995. you can also save AutoREALM maps as BMP or JPEG, to insert into other documents.

[John Kirk]

Your example is nifty.

I concur.  I am honored that you would go to the trouble of doing this.  You have done an excellent job of replicating the diagram features.  If it would help you in any way, I would be happy to provide you with a .doc or .rtf file containing my own versions of the icons.

Your own game diagram indicates you are constructing a nice Contest Tree, which should serve well to create a sense of rising tension within a scene.  There are a couple of issues I would like to point out about your diagrams, as it might help you and others in using them.

First, you have "Hate" modeled with both a filled and empty circle.  The nature of the gauge, whether high values are good or bad (or both) should remain consistent throughout the diagrams.  Now, I imagine that the real issue here is not whether you understand which is which, but in the fact that contest diagrams usually contain gauges from more than one character.  So, it becomes ambiguous in these cases what "good" means (i.e. for what character are we talking).  If you look at the gauge diagrams in the book, I often put a subscript next to the gauge name (such as Hate₁ or Hate₂).  The idea here is to tell the reader what character possesses the gauge in question and also lets the reader know how to interpret the circle (good for whom?)  Usually, this means that gauges possessed by character₁ lie on the left side of the contest icon and gauges for character₂ lie on the right side.  Although, this is not always the case.

Second, there should only be two inputs to contest icons, one for each side.  And, they should have the same essential nature (gauge vs. gauge or set of gauges vs. set of gauges).  Note that a die roll is a gauge, so there's nothing wrong with comparing a die roll to a fixed number threshold in the diagram.  The point is that a contest icon represents a comparison of some sort.  It does not specify what kind of comparison is being made, only that one is being made.  But, to compare two things, they need to be of the same nature.  You need to compare apples to apples rather than apples to oranges, if that makes sense.  My guess is that you intend for "matching groups and friends" and "Hate" to feed into an unnamed gauge of some sort and that is what is being compared to the die roll.

If you really want to compare more than two things, then you should use the "dial" icon, as you have done for the "anti", "conditional", and "pro" gauges.  But, even in this case, the inputs should be of the same essential nature.

I hope that all makes sense.

[talysman]

Your own game diagram indicates you are constructing a nice Contest Tree, which should serve well to create a sense of rising tension within a scene.  There are a couple of issues I would like to point out about your diagrams, as it might help you and others in using them.

First, you have "Hate" modeled with both a filled and empty circle.  The nature of the gauge, whether high values are good or bad (or both) should remain consistent throughout the diagrams.  Now, I imagine that the real issue here is not whether you understand which is which, but in the fact that contest diagrams usually contain gauges from more than one character.  So, it becomes ambiguous in these cases what "good" means (i.e. for what character are we talking).  If you look at the gauge diagrams in the book, I often put a subscript next to the gauge name (such as Hate₁ or Hate₂).  The idea here is to tell the reader what character possesses the gauge in question and also lets the reader know how to interpret the circle (good for whom?)  Usually, this means that gauges possessed by character₁ lie on the left side of the contest icon and gauges for character₂ lie on the right side.  Although, this is not always the case.

Second, there should only be two inputs to contest icons, one for each side.  And, they should have the same essential nature (gauge vs. gauge or set of gauges vs. set of gauges).  Note that a die roll is a gauge, so there's nothing wrong with comparing a die roll to a fixed number threshold in the diagram.  The point is that a contest icon represents a comparison of some sort.  It does not specify what kind of comparison is being made, only that one is being made.  But, to compare two things, they need to be of the same nature.  You need to compare apples to apples rather than apples to oranges, if that makes sense.  My guess is that you intend for "matching groups and friends" and "Hate" to feed into an unnamed gauge of some sort and that is what is being compared to the die roll.

If you really want to compare more than two things, then you should use the "dial" icon, as you have done for the "anti", "conditional", and "pro" gauges.  But, even in this case, the inputs should be of the same essential nature.

I hope that all makes sense.

it does, although it raises a few questions. I corrected Hate (but not Community) a little while after posting the PDF. since this diagram is for player vs. NPC conflict resolution, Hate should be an open circle in all cases, while Community should be a filled circle in all cases. I will be sure to change that later.

however, the way contest icons work suggests I need to add more contest icons to the chart. Hate and the matching groups/friends gauges don't work the same way; Hate is a threshold (all dice with a result less than Hate are discarded,) but the set of gauges forms a set of number to match. it's an odd structure I use sometimes in my games called "motif matching"; it works a little like a table lookup, except the table is unique to each character and is built during chargen and improved during play. perhaps I should use a table lookup icon instead?

what I think needs to be done in general is to have the dice vs. Hate contest first, then compare the dice that pass the first contest to the list of groups and friends on the character sheet to determine how many successes were earned. the NPC side works in a similar manner, but with the PC's Community score instead of Hate; plus, there's an extra step I left out, where any dice above the Abuse threshold are counted towards the total amount of Abuse in the scene.

the improved version of conflict resolution is here, although it still needs tweaking.

I'd like to see an rtf document of the original icons, to see if they are usable directly within OpenOffice.org. if they aren't, I'll just use AutoREALM.

[Mike Holmes]

Hey, looking at John's diagram, something occurs to me. And this might be covered in the document, but I've forgotten if it has. But how do you signify recursion?

For instance, in my game synthesis you have to guages smashing together to create a new guage with dice in the middle. But you can "drill down" on any of the individual guages before the fact. Rather you can start at any infinitely small level, and create a new guage that then conflicts with another guage, which creates a new guage which conflicts with another, etc, ad infinitum. How do you indicate that recursive loop without it simply looking like a simple loop?

Mike

[John Kirk]

How do you indicate that recursive loop without it simply looking like a simple loop?

Don't say that!  Only a simple loop?  Take a look at the gauge diagrams in the Game Summaries section of the RPG Design Patterns book and find all of the instances of loops consisting of positively reinforcing arrows in the conflict resolution systems.  What you'll find is that they appear in the following games:

Capes (which actually has three - wow!)
Dogs in the Vineyard (which is actually part of the reward system)
Inspectres (also part of the reward system)
My Life with Master (Self-Loathing in conflicts against townspeople and Weariness in violent conflicts against townspeople)
The Pool (Winning conflicts adds dice to a character's Pool)
Sorcerer (Successes can be carried over from conflict to conflict)
Torg (conflicts provide cards, which are used to win conflicts)
Universalis (oops!  The arrows in that diagram are backward between the Coins and dice.  How did we miss that one Mike? :-)  It'll be fixed in the next release.)

That's some pretty austere company.  The only traditional game there is Torg, and I'm thinking it was ahead of its time in that regard.

A reinforcing loop like this represents what we've called a "Steamroller" effect in the past.  It is a powerful tool for a game designer to have in his tool box.  Don't trivialize it.  The power of a Gauge Diagram is that you can see this effect graphically with little effort.  You don't have to go digging through rules.  It stands right out and says, "Here I am!"

It seems to me that you're thinking of Gauge Diagrams as some kind of process flow chart.  They aren't.  They don't say, "Do this, then do this, then do this".  Gauge Diagrams represent Currency flow, not process flow.  So, they say, "Currency flows from here to here to here."  They are more akin to electric circuits or plumbing than computer flow diagrams.

[Mike Holmes]

A reinforcing loop like this represents what we've called a "Steamroller" effect in the past.  It is a powerful tool for a game designer to have in his tool box.  Don't trivialize it.  The power of a Gauge Diagram is that you can see this effect graphically with little effort.  You don't have to go digging through rules.  It stands right out and says, "Here I am!"

I'm only saying that they're simple loops in that they're not recursion. None of the examples you give are actually recursive. That is, they move the process forward, they don't delve inward. For example, we put a rule in Universalis that says that one shouldn't use nested contests. Nested in this case refering to a true recursion. That is, you'd start a complication, but then to determine the number of dice in a pool you'd start another complication inside that complication. For example, you have a massive battle between two armies, and the leaders are fighting inside it head to head. Well, you can just put their dice in each pool, or you could (theoretically), have them have their own complication to see how many dice come out on each side to be added to the pools in question in the primary complication. And in that fight, you could have the functioning of a particular spell be a complication to see how many dice it adds to the leader fight complication. And then you could have a complication that looked at how some material component aided the spell, to add dice to the spell, to add dice to the leader fight to add dice to the overall battle.

That's recursion, you suspend the current loop while you do a loop inside of the current one. With the potential to get as infinitely detailed as you want drilling down. Now, again, in Universalis we said not to do this because when we playtested it, it was horrendous to try to keep track of where you were at. It's fun, actually, but given the ability to go off on a recursive loop at any point, often large complications never resolve. In fact, I had an entire four hour session devolve into one long set of back and forth recursions before rolling the dice at the end of the contest to see if the city survived the attack by the bombers intent on causing the volcano to erupt onto the city destroying it.

Which was satisfying in it's own way. But we could see that there would be no way to enforce completion of any particular complication started. Rather than put some complicated rules in about only so many recursive attempts or something we settled on just one complication at a time.

Now, in my game Synthesis, I have something sort of in between in that you start at a low level of detail, and "roll-up" to the final contest. But it's somewhat the same idea. Heroquest specifically bans having extended contests inside other extended contests ("No nesting!" again). But the idea is intriguing there. Let's say you have a contest that's designed to last several sessions of play - why not allow extended contests inside of it to resolve either a round or an "unrelated action"?

So I'm not sure we have an example of a game that actually uses the concept of recursion, but I think that we're very, very close, and that you can play some games that do exist using recursion as an advanced technique. So I think it might be good to have a diagraming method for this. OTOH...

It seems to me that you're thinking of Gauge Diagrams as some kind of process flow chart.  They aren't.  They don't say, "Do this, then do this, then do this".  Gauge Diagrams represent Currency flow, not process flow.  So, they say, "Currency flows from here to here to here."  They are more akin to electric circuits or plumbing than computer flow diagrams.

I'm not sure if this makes a difference or not. That is, I guess that a recursion loop could be represented this way, but I think you definitely lose someting about the description of the currency flow. Not noting that currency is coming from new loops conducted while other loops are suspended, instead implying that currency from the current loop is simply fed into the next loop.

Universalis (oops!  The arrows in that diagram are backward between the Coins and dice.  How did we miss that one Mike? :-)  It'll be fixed in the next release.)

Yeah, like I went over every chart in detail, right. I guess I just figured that Universalis was pretty straightforward and that there's no way you'd mess it up. ;-)

Mike

[John Kirk]

I think I see what you're saying.  What you're looking for is a Contest Tree with an infinite depth and infinite width.

There isn't any good way to diagram that as the technique stands right now.  About the best thing I can recommend is what I did for the diagram in the Contest Tree pattern description.  There, I added a textual description to the output of the Contest Tree stating that the result could be applied to higher level contests.  You could do something similar.  I suppose you could also add inputs that state they could come from lower level contests as well.

[Mike Holmes]

Yeah, but that still doesn't imply recursion. If I have an input arrow that says, "Input based on output of other contest" or "output can be applied to other contest" that sounds just like the Sorcerer roll-over rule. Or what I have in Synthesis right now in some ways. Do contest, add results as input of new contest. When what I want to indicate is:

1. Declare contest A.
2. Halt contest A to declare new contest B to determine some input to contest A.
3. Halt contest B to declare contest C to deternine some input to contest B.
4. Resolve C, add input to B.
5. Resolve B, add input to A.
6. Resolve A.

Is that any clearer? FILO, First in, Last Out. But you can go back and forth as with any FILO stack operation:

1. Declare contest A.
2. Halt contest A to declare new contest B to determine some input to contest A.
3. Halt contest B to declare contest C to deternine some input to contest B.
4. Resolve C, add input to B.
5. Halt B again to declare a new contest D to determine some input to contest B.
6. Resolve D, add input to B.
7. Resolve B, add input to A.
6. Resolve A.

You probably got it the first time, but I wanted to be sure so you can see how simply indicating that previous contest input can be put in doesn't really cover where things come from.

Mike

[Vaxalon]

Are you halting the contest, or postponing STARTING it until the smaller contest is concluded?

[Mike Holmes]

I think halting is accurate as a term. Though it may be halted at any point in the procedure prior to rolling. To be clear, in Universalis, the procedure is to start a complication, take an indefinite number of rounds accumulating dice pools regarding the complication (including narration of situation that explains the activations), and then to resolve when everyone is satisfied with their dice pool. With this method, in the middle of the rounds of accumulating dice pools, a player would declare a new complication (by the usual method of narrating something he controls trying to cause a change in something he doesn't control), and the current complication would be suspended, those dice pools put aside and recorded as to what they're for, the new complication played through in it's entirity, including resolution and spending of coins. Then you go back to the originally interrupted complication, go back to rounds of activation, presumably actvating newly created traits from the nested complication that was just completed to create dice for the pools of the original complication.

In practice when I played this way on those few occasions that I did before we disallowed this, players sorta skipped the step of creating new traits in the sub-complication, and simply did narrations that were justifications for putting dice directly into the original complication's dice pools.

There were two reasons for why we decided to disallow nesting like this. First, it's complicated as all hell. I mean one nested complication isn't too bad. But once you open this gate it's like opening Pandora's Box. Nobody wants to allow any complication to complete without adding a new complication to it. Which means that you get into several layers of recursion as the new complication is halted to start another, and that complication is halted. And then you come back to some complication finally, and it gets interrupted yet again. People lose track of what's going on, what pools are for what, etc.

Don't get me wrong, I like complexity, and enjoyed all of this. But even I had to admit that at some points it was just too much. What happens is that, eventually, everyone just gets sick of the addition of complications to complications and has to browbeat anyone who's thinking of coming up with yet another so that you can ever get back to the first complication. As I said above, there was that one session where if I hadn't reminded everyone that we were running out of time for the session, we wouldn't have been able to end the complication that had been declared 4 hours earlier at the beginning of the session. Yes, it took us about 4 hours to do one complication. Which turned out cool, since the one complication became the entire plot. But sans the pressure to finish up, it would have gone on forever and ever.

In some ways nesting is simply too cool for it's own good.

The second reason we disallowed nesting is because of the problem of distortion of the bounds of the complication. This is extremely difficult to describe unless you've seen it happen. Basically if you allow actions to occur during a complication, they can't help but be in some ways a resolution of the complication. For example, if I have a complication that's about a guy trying to shoot another, and I allow you to narrate your guy diving behind cover, then even if I win, there are limits to what I can reasonably narrate as the result of the complication. In fact, some players basically try to get away with resolving the complication entire before the dice are even rolled. "I activate Rolf's Run's Fast Trait - uh, he runs around the corner and out of sight."

We went with what was basically the easiest rule to prevent this, which was that you simply don't narrate anything in a complication, you just build dice pools. Yes, you can sorta narrate previous facts or cite situation to justify the use, "I activate Rolf's Run's Fast Trait - there's that corner not far off, maybe he can make it there before Mack gets his gun out, or just after." But you just cannot resolve before the dice are rolled.

If you allow nested complications, the narration of the resolution neccessarily tends to somewhat resolve the complication in which the sub-complication resides. So that was a problem we just eliminated by chucking the whole concept of allowing recursion.

But that doesn't mean it's a bad idea a priori. Just that I haven't found a good way to do it yet. Shreyas reminds me that his game Torchbearer has some functional recursion in it, however. :-)

Mike

[John Kirk]

You probably got it the first time, but I wanted to be sure so you can see how simply indicating that previous contest input can be put in doesn't really cover where things come from.

Yes.  I understand what you're saying.

I think this is a case of asking a diagramming technique to illustrate something it isn't designed to show.  Every diagramming technique emphasizes some things and suppresses others.  It is good at showing the kinds of things it is designed to show and poor and showing things it isn't.  In this case, Gauge Diagrams purposefuly hide Process Flow to show Currency Flow.  I think what you need is an entirely different kind of diagram that illustrates Process Flow.

A Computer Process Flow Chart illustrates process flow.  But, they have fallen out of favor because code, or an English representation of the code (known as pseudo-code), does this more succinctly.  I don't even think the UML diagramming standard even includes a detailed process flow diagram technique.  The closest thing I can think of would be a sequence diagram.  But, that empasizes the sequence of messages that get passed between software modules to solve a problem.

If you're intent on creating a diagram to illustrate recursion, I think the best bet is a Computer Process Flow Chart.

[Mike Holmes]

I guess that the symbols involved in the diagrams seem so much like flowcharts that I've been reading them like flowcharts. But I see what you're saying.

Mike