[Design Patterns of RPGs] What's in a Diagram?

[Roger]

The value I see in these two particular diagrams is that it makes obvious the symmetries and asymmetries between Elms and Maples.

They are clearly very symmetrical, with the glaring exception of how Elms interact with GM Fiat.

This isn't necessarily a bad thing, of course, but it would lead me to carefully examine why that assymetry exists, and whether there should be an analogous process with Maples.

From an software "object-oriented" viewpoint, it also leads me to think that Elms and Maples should perhaps have a parent-child relationship, or a sibling relationship to some higher parent class.  Or there may be some value in removing the distinction entirely and lumping the gauges together into one set.


Cheers,
Roger

[John Kirk]

Hello!
I am new to the Forge but you have enthralled me with these Design Patterns topics. I have to answer! *laughs*

I guess I missed the fact that you were new here in previous posts.  Welcome to the Forge!

Before I say more, I have a few questions:

• Why exactly are Means and Ends conflicted? Is this because they increase Stake, but decrease Plot Points?
• 4th proposal - page 2: Is the first relation of each type ambiguous because it is not specified whether the originating gauge can incrase / decrease the target gauge or not?

I would say that you are correct about why Means and Ends are conflicted.  You are also correct about the relationships being ambiguous because they don't specify clearly how they affect the target.

The element symbol is nice and simple. The gauge next to the set is arbitrarily chosen (from the set's elements), isn't it? But if the choice was not random, moving a specific (=named) gauge out of set and giving it special relations would kick it out of the set anyway. Hence the element symbol would not be appropriate in this case. q.e.d (right?)

Correct.

I have one idea: I see a lot of "resource" relationships in WhiteRat's diagrams. There are two gauges, one solid arrow forth, one dashed arrow back. I think this clutters the diagrams. But this can be solved with an inverse relationship! You just take the third inverse relationship. So the target can only be increased and hence the origin can only be decreased by this relationship. This would make the Means and Ends diagrams a lot simpler!

That is an excellent observation!  I overlooked that fact.  I'm now wondering if the new solid/dashed arrow definitions changed things enough that the two-arrow representation of resources is now actually wrong.

There is only one point that I don't like. At the moment, you introduce more symbols, arrows and all that stuff to the diagrams. But.. which program is able to draw these diagrams? Somebody around here mentioned AutoRealm, right? I know this program, but is it really capable of doing these things?
Anyway, which program do you use to draw your diagrams?

I've been using Microsoft Word to create all of my diagrams.  Now, before anyone asks the question, let me provide a pre-emptive answer:  Yes, it is a pain in the ass.  All I can say is that the diagrams in the book grew way beyond what I thought they would when I started this whole thing.

I am currently working on a game (pen & paper) and I want to design it using your patterns, gauge diagrams and component diagrams. Let's see how far I get. If I have some useful pictures, I'll post them here.

I look forward to seeing them.

[RenjiKage]

I'm now wondering if the new solid/dashed arrow definitions changed things enough that the two-arrow representation of resources is now actually wrong.

I think the old notation is wrong.

The new notation implies that a decrease of the resource "flows" to the target and increases it in some way. This is exactly what you describe as a "resource". Of course, it can also be that the original gauge increases when it's decreasing the target (if lower values are better).

The old notation means, that the target gets a higher value if you increase the resource. Then the target can again decrease the resource. Besides this ugly explanation it is not said when the "feedback" of the loop happens... and it's ambiguous, because the resource can decrease and hence decrease the target...
So I think the diagrams shoud be changed.

I think you should use your new relationships to remove any ambiguity from your loops in the proposal. For example, a reinforcing loop of filled circles which increase each other is good. The opposite (filled circles decrease each other) is a "death spiral". You can do the same for balancing loops, I think, but I am not so familiar with these...

[Adam Cerling]

RenjiKage --

Welcome to the Forge! I'm Adam. (I just haven't got around to having them change my handle yet.)

Why exactly are Means and Ends conflicted? Is this because they increase Stake, but decrease Plot Points?

You are correct that they are conflicted that way. But they are also conflicted in another way that my diagram doesn't show.

In a conflict of Stakes, the higher Stake wins.
But if the player with the lower Stake chooses to pay a certain cost in Plot Points, the lower Stake wins.
But if the player with the lower Stake tries that, the other player can cancel it if his Stake is twice as large and he is willing to pay a cost in Plot Points instead.
All costs paid go to the loser of the conflict.

In any given conflict it's not clear at first whether you want the higher number or the lower number. It all depends on who's willing to pay what costs in Plot Points. So I call the gauges conflicted.

Roger --

This isn't necessarily a bad thing, of course, but it would lead me to carefully examine why that assymetry exists, and whether there should be an analogous process with Maples.

From an software "object-oriented" viewpoint, it also leads me to think that Elms and Maples should perhaps have a parent-child relationship, or a sibling relationship to some higher parent class.  Or there may be some value in removing the distinction entirely and lumping the gauges together into one set.

Thanks for the analysis!

The asymmetry exists for conceptual reasons, hidden by my fake terms. The real term for "Elms" is "Ends," and the real term for "Maples" is "Means." In a conflict, each participant chooses what they're fighting for (Ends) and how they're doing it (Means). They also have other subtle differences that would require procedural diagrams to illustrate.

From an object-oriented viewpoint, Ends and Means would have a sibling relationship to a parent class of "Ranked Trait."

And John --

The last round of revisions leave me scratching my head.

I understand how the win/lose coloration of the conflict symbol (><) would benefit my diagram, but what if the sides were not symmetrical? I think I would need one diagram to show what happens when side A wins, and another to show what happens when side B wins. A single diagram would make it look like one particular side would always win or lose.

The decorations on the arrows are counterintuitive to me. My eye can parse the meaning of a two-way arrowhead on the line easily enough, but put a single arrowhead on the line and I have to refer back to the examples. Right, left, up and down have no meaning, so I have to not whether it's going with the flow of the parent arrow or against it -- and by the time I determine that, I've forgotten what each way means! The meaning doesn't follow naturally from the decorations.

I don't think I could confidently chart Ends and Means with the new arrows. Maybe I need to see a real game example before I get it.

[John Kirk]

I understand how the win/lose coloration of the conflict symbol (><) would benefit my diagram, but what if the sides were not symmetrical? I think I would need one diagram to show what happens when side A wins, and another to show what happens when side B wins. A single diagram would make it look like one particular side would always win or lose.

It is not required to fill in one side of the contest symbol.  It is merely an option if the diagrammer feels that doing so would provide a better illustration of what's going on.  If two diagrams are needed to convey some important point, then I don't see a problem with that.  I also think that it is fairly obvious that even if you fill one side, then readers will understand that the diagram shows the currency flow when one side wins, not that one of the two sides will always win.  After all, it wouldn't really be a contest if one of the two sides always won.

The decorations on the arrows are counterintuitive to me. My eye can parse the meaning of a two-way arrowhead on the line easily enough, but put a single arrowhead on the line and I have to refer back to the examples. Right, left, up and down have no meaning, so I have to not whether it's going with the flow of the parent arrow or against it -- and by the time I determine that, I've forgotten what each way means! The meaning doesn't follow naturally from the decorations.

The triangles are placed on the lines so that you can read the diagram without referring to the examples.  Just remember these simple rules:

1) If the base (big end) of a triangle points toward the target, the relationship increases the target.
2) If the tip (little end) of a triangle points toward the target, the relationship decreases the target.

So, as you travel from the origin to the target, if the triangle gets wider, the relationship can make the target larger.  If it gets narrower, the relationship can make the target smaller.  Does that help any?  Do you have any other suggestions to improve this notation?

I don't think I could confidently chart Ends and Means with the new arrows. Maybe I need to see a real game example before I get it.

Fair enough.  I diagrammed out Legendary Quest using the new notation.  You can download the gauge diagrams here.  If you are unfamiliar with LQ, you can download the game from legendaryquest.com.  I hope that helps.

[RenjiKage]

Hello John and Adam!

My real name is Stefan. Nice to meet you!

Now I fully understand your diagrams, Adam. Your game idea sounds very interesting to me. I want to have a closer look at it. :-) After having played S-games for years, I think that I should try an N-game now. Your idea that some of your most important gauges are conflicted is especially fascinating. What settings can be played with your game? (I know this is a little OT, but a short answer is enough for me. ;-) )

The triangles are placed on the lines so that you can read the diagram without referring to the examples.  Just remember these simple rules:

1) If the base (big end) of a triangle points toward the target, the relationship increases the target.
2) If the tip (little end) of a triangle points toward the target, the relationship decreases the target.

Oh! Now I understand. I must admit that I had Adam's problem, too. But I thought that I was missing something quite obvious (I always think that if I don't understand "simple" things right away). Now the notation makes sense to me. Before, I tried to apply some ideas of flow to the arrows, but if you do that, the arrow tips point to the wrong direction (do they?... ahh... my brain refuses to think more about that).
The way you explain it makes it clear. Please remember to add this explanation to your book!

[Adam Cerling]

John --

Ah, it clicks now. It was this piece of text that did it for me:

So, as you travel from the origin to the target, if the triangle gets wider, the relationship can make the target larger.  If it gets narrower, the relationship can make the target smaller.  Does that help any?  Do you have any other suggestions to improve this notation?

Now I can think of them not as arrowheads in the middle of the line, but as vectors of change.

Yet if you could explore other ideas for decorations on the line, I think it would still help. Just as parsing gauges becomes more difficult if filled or empty circles decorate the line (as was suggested at the start of the thread), parsing the direction of currency flow becomes more difficult if extra "arrowheads" are scattered all about.

Perhaps you could shade the terminal arrowheads you already have. A solid terminal arrowhead means "only increases," an empty terminal arrowhead means "only decreases," and an arrowhead-within-an-arrowhead means "increases or decreases." That arrangement would mirror your gauges' meaning (although it becomes even more difficult to draw in Word!).

Stefan --

I'm glad you find Ends and Means intriguing from just its diagrams! You can learn more from these threads: Debut, Werewolves in L.A., Memorial Day Playtest, and King Lothian's Court. I'm writing the game for large group LARP play, and as these threads attest, the game will support many settings.

The setting for my next playtest is titled Steel Pit Fight Night![/i] and draws its inspiration from those most venerable of dramas, Capcom's Street Fighter video game series.

[RenjiKage]

John --

Currently I was skimming through your list of patterns and thinking about which I want to have in my game and which not. Now I am trying to draw my first gauge diagrams, but I have a problem. I have traits in my game. They can be bought during character creation using some kind of resource (Character Points or something like that...). How can I draw this, since traits are not gauges. I want a "CP create trait and are decreased during this process"-relation - how can I do this?


Adam --

Oh... I totally forgot that your game was for LARP. I have never played a LARP, but it interests me what kind of rules exist for them. So I'll take a look at your game anyway. I also interests me how this "Ends and Means"-principle can be transferred to P&P. The idea of some primary gauges to be conflicted is very promising... I just got an idea for a simple P&P game... *laughs* but first, I will read the topics you pointed me to!

[Adam Cerling]

Stefan --

I'll jump in for John here: the daigram you want is like the relationship I have between Weight Reserve and Ends (or Means). Using John's new arrows, that'd mean drawing a dashed arrow from the Resource to the set of Traits, with a "can only increase the target" decoration.

Traits are Gauges -- they're just binary gauges. You have them or you don't.

As far as LARPs go, my previous experience is mostly with White Wolf's Mind's Eye Theater system, which is pretty much the same as any pen and paper system -- you're just standing around and dressed up. In my opinion, LARP and PnP differ only in Techniques, Ephemera, and the unusual task of distributing the SIS.

[RenjiKage]

Adam --

But my traits don't mean necessarily good things. One trait can be an advantage, a disadvantage, or it can depend on the situation. So how do I have to draw them? Are they conflicted?

I have PMed you about my idea, because I don't want to hijack the thread.

[John Kirk]

Yet if you could explore other ideas for decorations on the line, I think it would still help. Just as parsing gauges becomes more difficult if filled or empty circles decorate the line (as was suggested at the start of the thread), parsing the direction of currency flow becomes more difficult if extra "arrowheads" are scattered all about.

Perhaps you could shade the terminal arrowheads you already have. A solid terminal arrowhead means "only increases," an empty terminal arrowhead means "only decreases," and an arrowhead-within-an-arrowhead means "increases or decreases." That arrangement would mirror your gauges' meaning (although it becomes even more difficult to draw in Word!).

I'm still willing to explore alternatives.  I tried out a number of things before proposing the triangle notation.  I agree that they disrupt the visual flow, but I haven't come up with anything better.  I'm afraid I don't much like the arrowhead-within-an-arrowhead idea, though.  I think the arrowheads would become too large and would crowd the gauges when several arrows point to a single gauge.  Also, I want a diagrammer to be able to remain ambiguous about exactly how a relationship affects the target while he ponders his game design.  And, yes, they would be a bitch to draw in Word (or most other drawing packages).  The triangles are no picnic either, though.

I'll jump in for John here: the daigram you want is like the relationship I have between Weight Reserve and Ends (or Means). Using John's new arrows, that'd mean drawing a dashed arrow from the Resource to the set of Traits, with a "can only increase the target" decoration.

I concur.

But my traits don't mean necessarily good things. One trait can be an advantage, a disadvantage, or it can depend on the situation. So how do I have to draw them? Are they conflicted?

Well, you are right in that an unranked trait is not really a gauge, since a gauge must have a graduated value of some sort and "exists" or "doesn't exist" isn't really graduated.  But, in such cases, I have always just used a filled circle anyway, since there didn't seem much point in coming up with a different symbol to represent a gift or unranked trait.  I suppose if you wanted to represent a Flaw or unranked trait that is a disadvantage, you could use an empty circle.  After all, a Handicap would be represented as an empty circle, since low ranks would be good.  You shouldn't represent a trait with the "conflicted gauge" icon unless a single trait is both good and bad at times.

[Stefan / 1of3]

I think somewhere I suggested to use squares, instead of circles, for Traits and other binary stuff.

Filled square = You want it.
Empty square = You don't.
Square in square = Conflicted trait.

That wouldn't make the diagrams more complicated, but adds useful information.

[RenjiKage]

John, Adam --

Thank you for your help! I try to draw some diagrams in the next few days. But... I still have some problems with the notation. What do I do if the player can choose "good" and "bad" traits? Can I draw a set with filled and empty circles to represent this (just to simplify notation)?

Stefan / 1of3 --

Ach, sieh an, ein FERAner. ;-) Ich war bisher noch nicht aktiv dabei, bin aber ambitionierter Lurker im FERA!

I don't know if "binary" gauges are something that special. Let's see how my diagrams look loke when I use squares... :-)

[Adam Cerling]

Stefan, I think it'd be perfectly understandable if you put both filled and empty circles in the set. Alternatively, you sould create two sets, one for each type -- even if they fall under the same heading in the rules, their design is still different.

Thank you all for a fun and educational discussion of John's diagramming techniques! I consider my purpose in this thread fulfilled.

John -- I'm greatly looking forward to the next draft of your book. The last word in this thread goes to you if you like.

[John Kirk]

I think somewhere I suggested to use squares, instead of circles, for Traits and other binary stuff.

That's a pretty decent idea, actually.  I don't know why I didn't pick up on it before.

I'm greatly looking forward to the next draft of your book. The last word in this thread goes to you if you like.

I appreciate that, but don't hold your breath.  It will be a while before I get the next draft out.  The changes due to this thread alone are going to take me quite a while to implement.  :-)

Thank you all for your suggestions.  I think our gauge diagramming technique is much improved over what I originally presented due to the wonderful feedback I have received here.