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.

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

Mike wrote:
Your example is nifty.

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.

Mike wrote:
Your example is nifty.

John wrote:
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[sub]1[/sub] or Hate[sub]2[/sub]).  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[sub]1[/sub] lie on the left side of the contest icon and gauges for character[sub]2[/sub] 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.

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

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

John wrote:
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.

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.)

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.

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

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

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

Mike wrote:
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.

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