Topic: [Design Patterns of RPGs] What's in a Diagram?
Started by: WhiteRat
Started on: 10/23/2005
Board: RPG Theory
On 10/23/2005 at 7:58pm, WhiteRat wrote:
[Design Patterns of RPGs] What's in a Diagram?
Like many, I was impressed and intruiged by John Kirk's text Design Patterns of Successful Role-Playing Games. As a software engineer myself, I found the currency flow diagrams especially thought-provoking.
In an attempt to better understand them, I attempted to diagram the game I'm working on. This got me to thinking: What can other people tell from these diagrams alone? Without any text to explain them, could you use diagrams to identify common patterns? To single out bottlenecks or lynchpins of the system? To discern strengths and weaknesses?
Hence, without any context, I'm presenting the diagrams I created. I've even changed the names of all the components just to make the diagram more generic. Based on the strengths of John's diagramming system alone, without knowing anything else about my game, what (if anything) can you learn from these pictures?
Even more than I'm curious to discover what the diagrams can say about the game, I hope that this thread will tell me something about the strengths and weaknesses of such currency flow diagrams.
Forge Reference Links:
Topic 16990
On 10/23/2005 at 10:14pm, John Kirk wrote:
Re: [Design Patterns of RPGs] What's in a Diagram?
WhiteRat wrote:
Based on the strengths of John's diagramming system alone, without knowing anything else about my game, what (if anything) can you learn from these pictures?
That is an excellent challenge. It was a good idea to change the names of the gauges so that the reader can't glean additional information just by the terms you used.
Here's what I can tell:
White Rice, White Leek, and Poplar are all attributes.
Elms and Maples are sets of conflicted gauges. Since they are conflicted, I'd guess Elms and Maples are ranked traits, skills, and/or handicaps but can't be sure which they are. (If they weren't conflicted, I couldn't be sure they weren't actually gifts and/or flaws.)
Pepper, Poplar, and White Rice are resources.
White Rice can be spent on White Leek. And, it can be spent on Maples and Elms. If Maples and/or Elms are traits, skills, or handicaps, I assume White Rice is used to buy ranks. If one or both of them were gifts or handicaps, then I'd assume it is being used to buy them outright.
Pepper can be spent on Poplar and Sage.
Poplar can be spent to buy facts (events) in the game world.
An attendance reward is given (I assume each session) in the form of White Rice. (Note that if you had renamed "Attendance" to something else, I wouldn't have a clue that this was an attendance reward.)
Based on a character's Elms, the GM decides (by fiat) how much a character can affect the game world.
Maples, Elms, and White Leek have a lowering effect on Pepper.
Elms and Maples are conflicted because they have a positive effect on Sage (which is itself conflicted), but a negative effect on Pepper.
The Conflict Resolution system is Karma-based and it contains a reinforcing loop. (A contest's winner gets Pepper, which can be spent on Sage to win future contests.) I can't be certain, but this tends to indicate the game is a narrative-style game. (None of the tactical games I've studied has reinforcing loops of this kind.) In fact, I'd say Pepper has a mechanical effect on Conflict Resolution similar to Cape's Inspirations and Universalis's Coins.
The conflict resolution system determines a winner as well as an answer to the question: Daffodil? (whatever that is).
Criticisms:
I think you have a flaw in your representation of White Leek. You represent White Leek with a filled-in circle, meaning large value are good. However, you show it as having a lowering affect on Pepper, which is also shown with high values being good. I believe you should represent White Leek with either an empty circle (in which case there are other problems with the diagram) or you should represent it as a Conflicted Gauge (in which case everything else is fine).
You show Sage as being conflicted, but I cannot see why. It has a positive effect on conflict resolution, but the diagrams don't show where Sage has a negative effect anywhere. In fact, if I had to guess, I'd say that Sage is a temporary gauge specifically calculated for each contest and that Pepper is a resource that can be spent to influence each conflict's outcome.
I am interested to hear how well this meshes with your view of the game.
On 10/24/2005 at 3:28am, WhiteRat wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
John --
I'm glad you like my challenge!
Your analysis meshes very well on the whole with the design of this game. You're correct about White Rice, White Leek and Poplar being attributes, you're close enough on what Elms and Maples are, and you can tell that Pepper, Poplar and White Rice are resources.
Poplar can indeed be spent to buy facts in the game world, modified by GM Fiat, which itself is based on the character's Elms. I was a little uncertain about putting arrows in to the fuzzy gauge of "SIS Events," but it seems to have conveyed my meaning well.
I decided not to rename Attendance because I thought it would be a non-sequitur if I did, given how it would appear nowhere else in the diagram.
Here are the places where communication gaps have yet to be crossed:
John wrote:
White Rice can be spent on White Leek. And, it can be spent on Maples and Elms. If Maples and/or Elms are traits, skills, or handicaps, I assume White Rice is used to buy ranks. If one or both of them were gifts or handicaps, then I'd assume it is being used to buy them outright.
Here was a place where I wasn't sure exactly how to represent the system. Elms and Maples are groups of Ranked Traits. White Rice can do two different things to them. Firstly, you can spend it as a resource to buy more Elms and Maples. Secondly, the higher the value of White Rice, then the higher the value of the Elms and Maples you have. Thus the player chooses between having a few high-ranked Traits, or a plethora of low-ranked Traits. Could I have chosen a better way to diagram that?
John wrote:
The Conflict Resolution system is Karma-based and it contains a reinforcing loop. (A contest's winner gets Pepper, which can be spent on Sage to win future contests.) I can't be certain, but this tends to indicate the game is a narrative-style game. (None of the tactical games I've studied has reinforcing loops of this kind.) In fact, I'd say Pepper has a mechanical effect on Conflict Resolution similar to Cape's Inspirations and Universalis's Coins.
I'm sure I could have diagrammed this one better. It's the loser of the contest, not the winner, who earns the Pepper. It's a Failure Reward. How could I have diagrammed it more accurately?
Does this knowledge change any of your conclusions? Does it say anything new about the relationship between conflict resolution and the reward system?
That you have only seen reinforcing loops in narrative-style games is fascinating. You are correct here as well. Perhaps you should include reinforcing loops as another design pattern.
John wrote:
I think you have a flaw in your representation of White Leek. You represent White Leek with a filled-in circle, meaning large value are good. However, you show it as having a lowering affect on Pepper, which is also shown with high values being good. I believe you should represent White Leek with either an empty circle (in which case there are other problems with the diagram) or you should represent it as a Conflicted Gauge (in which case everything else is fine).
White Leek has a limiting effect on Elms, Means and Pepper: it's a ceiling. And the higher it is, the more Pepper you can begin with, but you'll never begin the game with more Pepper than White Leek. The formula is basically Pepper = White Leek - Max(All Elms and Maples Traits).
I had the impression that limiting effects were represented by dashed arrows, but now that I write it out in English, I think that perhaps it should be a solid arrow from White Leek to Pepper. What do you think?
John wrote:
You show Sage as being conflicted, but I cannot see why. It has a positive effect on conflict resolution, but the diagrams don't show where Sage has a negative effect anywhere. In fact, if I had to guess, I'd say that Sage is a temporary gauge specifically calculated for each contest and that Pepper is a resource that can be spent to influence each conflict's outcome.
Your guess is correct: Sage is a temporary gauge that exists only during conflict, but it's complex enough that in my game I gave it a name of its own. I was not sure how to represent the system here. One Elm and one Maple combine to create the Sage. Then the Pepper you spend on the conflict determines whether you want a high value or a low value of Sage. If no Pepper is spent by either player, the high Sage wins. If Pepper is spent by the player with lower Sage, then the lower Sage wins. But if Pepper is spent by the player with higher Sage and his Sage is over twice the value of the lower, then the high Sage wins. It is a Karma mechanic about finding a "sweet spot" that accounts for both the amount of Pepper you are willing to spend for victory, and for your opponent's tactics.
I tried to make the diagram as simple as possible, but is there a better way to show this?
Thanks for your analysis! I hope this helps you out in some small way; I know it's helping me.
On 10/24/2005 at 6:56pm, 1of3 wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
WhiteRat wrote:
Here was a place where I wasn't sure exactly how to represent the system. Elms and Maples are groups of Ranked Traits. White Rice can do two different things to them. Firstly, you can spend it as a resource to buy more Elms and Maples. Secondly, the higher the value of White Rice, then the higher the value of the Elms and Maples you have. Thus the player chooses between having a few high-ranked Traits, or a plethora of low-ranked Traits. Could I have chosen a better way to diagram that?
I think so, but I don't have web space ready, and the board doesn't allow attachments. I'll try to describe:
You could have made a pair of two gauges, one for the existance of the Maple or Elm and one for its level. Marking them a pair can be done with a box. Then draw approriate arrows from White Rice to both gauges.
Make up another such pair including the arrows, and add dots to represent, that there may be more such pairs.
I'm sure I could have diagrammed this one better. It's the loser of the contest, not the winner, who earns the Pepper. It's a Failure Reward. How could I have diagrammed it more accurately?
I'm not sure, you could have with the available signs.
Would it be useful, if the symbol for conflicts already included a side one side for winners and one for loosers? That way symbolizing success and failure rewards could be done by simply starting the arrow on the right side.
I had the impression that limiting effects were represented by dashed arrows, but now that I write it out in English, I think that perhaps it should be a solid arrow from White Leek to Pepper. What do you think?
I think there is a substantial difference between limiting another gauge and actually reducing it, but I'm not sure either.
On 10/25/2005 at 2:35am, WhiteRat wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
Stefan --
Your suggestion about how to communicate the effect of White Rice on Elms and Maples might indeed get the point across, but I wonder why no similar structure appears in John's book. My Elms and Maples are inspired by traits in The Pool. I based my diagram on his diagram of that game.
When using an aggregate circle, the diagram simply has no way to show whether the inputs a) increase or decrease the number of gauges it contains, or b) increases the value of one or more of those gauges. Is that more information than the diagram is meant to convey? Is it worth extending the diagram language to capture that information?
In regard to making the Contest symbol have a winner's side and a loser's side, I think that might confuse other uses for the diagram. Look at my contest between Sages, for example: it answers the question Daffodil?, which actually has nothing to do with winners or losers.
Lastly, regarding limiters, John writes in his book beside the first illustration of the dashed arrow:
John Kim, in Design Patterns of Successful Role-Playing Games wrote: Here, as the value of the left gauge increases, it tends to lower the referenced gauge value or acts as a limiter (such as a maximum allowable value).
I'm pretty certain I misinterpreted his meaning there. As the filled gauge increases, the implied limit is decreasing: it's not the case that the dashed arrow itself means "limiter." In my case, as White Leek increases, the limit on Pepper increases. So I'm pretty sure I should have used a solid arrow.
On 10/25/2005 at 7:12am, John Kirk wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
WhiteRat wrote:
Your suggestion about how to communicate the effect of White Rice on Elms and Maples might indeed get the point across, but I wonder why no similar structure appears in John's book. My Elms and Maples are inspired by traits in The Pool. I based my diagram on his diagram of that game...When using an aggregate circle, the diagram simply has no way to show whether the inputs a) increase or decrease the number of gauges it contains, or b) increases the value of one or more of those gauges. Is that more information than the diagram is meant to convey? Is it worth extending the diagram language to capture that information?
I think it is worth extending for this. Just to be clear, I don't want to treat this diagramming technique as if it's in its final state yet. I'm still working on it. I made the draft version of the book available to get feedback, because I knew that anything I came up with on my own would not necessarily take everything into account. Suggestions are certainly welcome. Just keep in mind that the diagrams are intended to illustrate a game's gauges and the relationships between them (primarily currency flow). In essence, that answers the all-important first question: "What is your diagramming technique about?" :-)
You are correct in stating that there is currently no way to differentiate between buying more elements (traits, skills, handicaps, etc.) and buying ranks in them. I don't like the idea of splitting an element into two gauges representing its existence and its rank. Fundamentally, what we have here are two kinds of relationships. So, I think we need two kinds of arrows to represent that. I think a solid arrow illustrates the "increases ranks" aspect better than the "increases element count" aspect. So, let's keep the solid arrow referencing a set to mean that. What do you think about using a double lined arrow (an arrow with two parallel lines) to represent "increases element count"? A double-lined dashed arrow can similarly represent "decreases element count".
WhiteRat wrote:
In regard to making the Contest symbol have a winner's side and a loser's side, I think that might confuse other uses for the diagram. Look at my contest between Sages, for example: it answers the question Daffodil?, which actually has nothing to do with winners or losers.
Actually, as your diagram illustrates, there is no reason a contest cannot answer more than one question at a time. In this case, I would have a "Winner?" gauge coming off of the contest as well as a "Loser?" gauge. The failure rewards would come off of the "Loser?" question rather than "Winner?".
Stefan wrote:
I had the impression that limiting effects were represented by dashed arrows, but now that I write it out in English, I think that perhaps it should be a solid arrow from White Leek to Pepper. What do you think?...I think there is a substantial difference between limiting another gauge and actually reducing it, but I'm not sure either.
I've bounced back and forth on this one myself. You used the correct notation. A dashed arrow can mean a limiter (or maximum) while a solid arrow can represent a minimum (which is another kind of limiter). The point of the arrow with a limiter is that the referencing gauge has a hindering effect on the referenced gauge (in this case, it prevents it from rising above the maximum value). When I originally came up with the diagramming technique, I was wanting to abstract away all possible details while still preserving the fundamental relationship type of "aids" or "hinders". That way, games that used different mechanical techniques for "aiding" or "hindering" between gauges but otherwise had similar structures would have very similar diagrams. Keep in mind, my main goal here was to allow patterns to stand up and be recognized. It's possible I went a little too far with the abstraction in this case.
Is yet another type of arrow warranted here? Or, would that just make the diagrams too difficult to read?
WhiteRat wrote:
Does this knowledge change any of your conclusions? Does it say anything new about the relationship between conflict resolution and the reward system?
Not really. Other than the rather obvious observation that this will encourage players to fail.
WhiteRat wrote:
That you have only seen reinforcing loops in narrative-style games is fascinating. You are correct here as well. Perhaps you should include reinforcing loops as another design pattern.
I'm planning on it, along with balancing loops. Have you seen Gene Bellinger's website about Systems Thinking? It explains about reinforcing loops and balancing loops in systems. It was quite pleasantly surprised to see this since it meshes so well with how I view game design.
WhiteRat wrote:
Thanks for your analysis! I hope this helps you out in some small way; I know it's helping me.
It certainly is helpful to me as well. Thanks!
On 10/25/2005 at 7:30am, talysman wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
John wrote:
You are correct in stating that there is currently no way to differentiate between buying more elements (traits, skills, handicaps, etc.) and buying ranks in them. I don't like the idea of splitting an element into two gauges representing its existence and its rank. Fundamentally, what we have here are two kinds of relationships. So, I think we need two kinds of arrows to represent that. I think a solid arrow illustrates the "increases ranks" aspect better than the "increases element count" aspect. So, let's keep the solid arrow referencing a set to mean that. What do you think about using a double lined arrow (an arrow with two parallel lines) to represent "increases element count"? A double-lined dashed arrow can similarly represent "decreases element count".
to keep the number of lines to a minimum, how about superimposing an (unlabeled) gauge on the line? this has the added benefit that you could differentiate:
• solid line, solid circle: adds positive gauges to element count (example: Gift that adds a special Resource that fuels its power.)
• solid line, empty circle: adds negative gauges to element count (example: adding a temporary disadvantage.)
• dashed line, solid circle: removes positive gauges from element count (example: effect that removes a Strength attribute from ghost characters.)
• dashed line, empty circle: removes negative gauges from element count (example: a resource that can be spent to remove wound traits.)
I'm trying to think what superimposing a conflicted gauge would mean, to clinch the deal. =)
On 10/25/2005 at 10:28am, Shreyas Sampat wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
John wrote:Stefan wrote:
I had the impression that limiting effects were represented by dashed arrows, but now that I write it out in English, I think that perhaps it should be a solid arrow from White Leek to Pepper. What do you think?...I think there is a substantial difference between limiting another gauge and actually reducing it, but I'm not sure either.
I've bounced back and forth on this one myself. You used the correct notation. A dashed arrow can mean a limiter (or maximum) while a solid arrow can represent a minimum (which is another kind of limiter). The point of the arrow with a limiter is that the referencing gauge has a hindering effect on the referenced gauge (in this case, it prevents it from rising above the maximum value). When I originally came up with the diagramming technique, I was wanting to abstract away all possible details while still preserving the fundamental relationship type of "aids" or "hinders". That way, games that used different mechanical techniques for "aiding" or "hindering" between gauges but otherwise had similar structures would have very similar diagrams. Keep in mind, my main goal here was to allow patterns to stand up and be recognized. It's possible I went a little too far with the abstraction in this case.
Is yet another type of arrow warranted here? Or, would that just make the diagrams too difficult to read?
I'm not sure I understand the logic behind your linking solid arrows to minima and dashed arrows to maxima. I was under the impression that X ->(dashed) Y means, "Increases in X are associated with decreases in Y;" but X ->(dashed) Y, where X is a limiter (the arrow suggests it is a maximum), means "Increases in X permit increases in Y."
Meanwhile, X ->(solid) Y, where X is a limiter(the arrow suggests it is a minimum), means "Increases in X are not reliably associated with increases in Y".
So, what this suggests to me is that you do need a further graphical representation for these, because those two situations are not the only possible ones; X -> Y, "Increasing X permits decreasing Y" (i.e. X inhibits Y's minimum) and X -> Y "Increasing X is not reliably associated with decreasing Y" (i.e. X inhibits Y's maximum) are unrepresented.
Alternatively, you can avoid expanding your notation by ignoring the extreme in question; increasing an extreme makes a solid arrow, and decreasing it makes a broken arrow, regardless of whether it is a max or min; I feel this is the abstraction that fits your current schema best.
On 10/26/2005 at 1:57am, WhiteRat wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
Regarding a new type of arrow, I prefer John's proposal (a double-lined arrow) over Shreyas's (an arrow with a gauge in the middle of it). While I think Shreyas's idea is more intuitively clear on its own, I think it will clutter the diagram more: you will no longer be able to tell at a glance how many gauges are involved.
John --
John wrote:
Actually, as your diagram illustrates, there is no reason a contest cannot answer more than one question at a time. In this case, I would have a "Winner?" gauge coming off of the contest as well as a "Loser?" gauge. The failure rewards would come off of the "Loser?" question rather than "Winner?".
But wouldn't that mean that I have two gauges answering the same question? Loser? = Not Winner?, after all. Currency flows to the answer of the question, and from that answer either increases or leaves alone Pepper[sub]1[/sub] and Pepper[sub]2[/sub].
If I had labeled the gauge Wheat? instead of Winner?, you'd have no way of knowing whether I had a Success Reward pattern or a Failure Reward pattern. Shouldn't those patterns be distinguishable regardless of the labelling of the gauge? Or does that fall outside the scope of what these diagrams are about?
John wrote:
I've bounced back and forth on this one myself. You used the correct notation. A dashed arrow can mean a limiter (or maximum) while a solid arrow can represent a minimum (which is another kind of limiter). The point of the arrow with a limiter is that the referencing gauge has a hindering effect on the referenced gauge (in this case, it prevents it from rising above the maximum value). When I originally came up with the diagramming technique, I was wanting to abstract away all possible details while still preserving the fundamental relationship type of "aids" or "hinders". That way, games that used different mechanical techniques for "aiding" or "hindering" between gauges but otherwise had similar structures would have very similar diagrams. Keep in mind, my main goal here was to allow patterns to stand up and be recognized. It's possible I went a little too far with the abstraction in this case.
Is yet another type of arrow warranted here? Or, would that just make the diagrams too difficult to read?
Actually, I don't think so. I think the notation you're using now works just fine. I think I was mistaken in my understanding of what kind of relationship constitutes a limit.
I called my White Leek-Pepper relationship a "limiter" based on the idea that your starting Pepper would never go higher than White Leek. But really, that's like saying Willpower (in World of Darkness) will never go higher than Resolve + Composure. Of course it won't: that's how it is derived. It's a tautology.
Gauge (A) can only impose a maximum on Gauge (B) if there is a third gauge, (C), increasing (B). Maxima -- as dashed arrows -- never occur in the absence of solid arrows increasing the same gauge. You detected a problem with my diagram because I had three dashed arrows leading in to Pepper, and not a single solid arrow.
Does that make sense?
John wrote:
Other than the rather obvious observation that this will encourage players to fail.
What a procedural diagram would show, and a currency flow diagram does not, is that the failure reward in my game is your opponent's decision. Every contest asks the underdog, "Would victory be worth rewarding your opponent?" I'm rather pleased with that.
I had never seen the Systems Thinking site before. Your work is the first time I've encountered such ideas.
On 10/26/2005 at 2:38am, John Kirk wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
WhiteRat wrote:
Regarding a new type of arrow, I prefer John's proposal (a double-lined arrow) over Shreyas's (an arrow with a gauge in the middle of it). While I think Shreyas's idea is more intuitively clear on its own, I think it will clutter the diagram more: you will no longer be able to tell at a glance how many gauges are involved.
I agree that the idea has merit but that it would clutter diagrams as stated. However, it is an excellent suggestion that gave me an idea that I think works quite well. How about putting one or more "bubbles" on the side of a set icon representing a gauge that is "peeking out" of the set to allow arrows access to it? That way, an arrow can point to a bubble or the set, depending on the need. If it points to the bubble, it specifies that the arrow acts on the set members (say, to raise skill ranks). If it points to the set, it specifies that the arrow acts on the set itself (say, to increase the number of skills in the set).
Representing gauge minimum and maximum values could be done by placing short tangential lines next to the gauges. One line represents a minimum. Two parallel lines represents a maximum. Then, arrows could point to the minimum or maximum aspects of a gauge rather than the gauge itself.
To illustrate these proposed changes, I created a .pdf that you can download here.
What do you think?
WhiteRat wrote:
But wouldn't that mean that I have two gauges answering the same question? Loser? = Not Winner?, after all. Currency flows to the answer of the question, and from that answer either increases or leaves alone Pepper[sub]1[/sub] and Pepper[sub]2[/sub].
If I had labeled the gauge Wheat? instead of Winner?, you'd have no way of knowing whether I had a Success Reward pattern or a Failure Reward pattern. Shouldn't those patterns be distinguishable regardless of the labelling of the gauge? Or does that fall outside the scope of what these diagrams are about?
Well, I don't think it's outside the scope of the diagramming technique, but it doesn't really bother me that you have to look at the label to understand its meaning in this case. If you had named it Wheat?, then I could have told you that Pepper is increased when the answer to Wheat? is true. I couldn't have told if that was a failure or a success reward. But, I could have told you it was a reward that has a positive effect on Pepper.
WhiteRat wrote:
I had never seen the Systems Thinking site before. Your work is the first time I've encountered such ideas.
Actually, neither had I until Adam Dray pointed it out to me after he read the patterns book. But, the site certainly gave me some more ideas to think about.
On 10/26/2005 at 4:49am, WhiteRat wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
Firing off a quick reply before I disappear for a day or two:
I like the notation for maxima and minima. It's simple and clear to my eye.
I'm not so keen on the "bubble" on the side of the set -- it looks too crowded, especially with the maxima and minima squeezed in. But calling the set, well, a set made me think that maybe a little mathematical notation would fit. Put the gauge next to the set of gauges. (In my case, it'd be one "Elm" gauge next to the set of "Elms.") Link the single gauge to the set by using the "element of a set" symbol from mathematics -- [font=Symbol]Î[/font]. (Hopefully that shows up well; it's in the Symbol font face. You know the symbol: like a capital E with curves instead of corners.)
That would at least give some visual breathing room between the gauge and its set.
Of course, I don't know if these are valid criticisms. Understanding notation is one thing: discussing the aesthetics of that notation, quite another!
On 10/27/2005 at 6:34am, John Kirk wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
WhiteRat wrote:
I like the notation for maxima and minima. It's simple and clear to my eye.
I'm not so keen on the "bubble" on the side of the set -- it looks too crowded, especially with the maxima and minima squeezed in. But calling the set, well, a set made me think that maybe a little mathematical notation would fit. Put the gauge next to the set of gauges. (In my case, it'd be one "Elm" gauge next to the set of "Elms.") Link the single gauge to the set by using the "element of a set" symbol from mathematics -- [font=Symbol]Î[/font]. (Hopefully that shows up well; it's in the Symbol font face. You know the symbol: like a capital E with curves instead of corners.)
That would at least give some visual breathing room between the gauge and its set.
Well, it didn't show up in the posting as you intended. As least, not on my system. But, I'm pretty sure I got the gist of what you were saying.
I've modified the example diagrams to illustrate your suggestion here.
Personally, I like the idea. Of course, a diagrammer must be free to rotate the "element of" symbol in any direction that is convenient to a diagram's overall layout.
What are other people's opinions? Is this headed in a good direction or are we just making gauge diagrams more cryptic?
On 10/31/2005 at 4:52am, WhiteRat wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
To demonstrate what the new symbols look like when applied, I've redrawn my "Elms and Maples" picture using its real terms. Here's the Ends and Means design diagram.
I find my "At Start Of Game" diagram to be weirdly beautiful now. If nothing else had, I think that cements my geekiness.
Of course, "weirdly beautiful" isn't necessarily "clear." But it does show a few interactions now that before it did not.
If I could figure out how to show one more thing, it'd be that the Failure Reward is determined by the Plot Points (a.k.a Pepper) spent on the winning Stake (a.k.a. Sage).
Oh, and John, I saw somewhere that you were considering re-titling your book "Design Patterns of Tabletop Role-Playing Games." But this design happens to be for a LARP! Your work crosses even that gulf (if indeed there exists any gulf deeper than that of techniques and ephemera).
On 11/2/2005 at 4:22am, John Kirk wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
WhiteRat wrote:
I find my "At Start Of Game" diagram to be weirdly beautiful now.
Me too!
WhiteRat wrote:
If I could figure out how to show one more thing, it'd be that the Failure Reward is determined by the Plot Points (a.k.a Pepper) spent on the winning Stake (a.k.a. Sage).
You all really got me thinking about the diagramming technique in the last few days. I added a few things to it as a consequence, including a way to distinguish the winning side from the losing side. You can download the latest copy of the proposed changes here. I would be very interested in hearing your opinions and/or suggestions about the changes.
WhiteRat wrote:
Oh, and John, I saw somewhere that you were considering re-titling your book "Design Patterns of Tabletop Role-Playing Games." But this design happens to be for a LARP! Your work crosses even that gulf (if indeed there exists any gulf deeper than that of techniques and ephemera).
That's interesting. If so, it is purely by accident, since I have never played a LARP before, nor even read the rules to one (to my shame). I guess I always figured that LARPs would be much more free-form and use gauges to a far lesser extent than tabletop games. Your diagrams tend to indicate that to be a false assumption, though.
On 11/2/2005 at 10:22am, RenjiKage wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
Hello!
I am new to the Forge but you have enthralled me with these Design Patterns topics. I have to answer! *laughs*
What are other people's opinions? Is this headed in a good direction or are we just making gauge diagrams more cryptic?
Clearly both! The Means and Ends diagrams became more cryptic, but they can express a lot more relations than before. So IMHO you are on the right track!
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?
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?)
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!
Conclusion:
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?
Conclusion II:
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.
On 11/2/2005 at 5:41pm, Roger wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
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
On 11/3/2005 at 2:43pm, John Kirk wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
RenjiKage wrote:
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!
RenjiKage wrote:
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.
RenjiKage wrote:
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.
RenjiKage wrote:
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.
RenjiKage wrote:
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.
RenjiKage wrote:
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.
On 11/4/2005 at 9:28am, RenjiKage wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
John Kirk wrote: 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...
On 11/6/2005 at 11:12pm, WhiteRat wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
RenjiKage --
Welcome to the Forge! I'm Adam. (I just haven't got around to having them change my handle yet.)
RenjiKage wrote:
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 --
Roger wrote:
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.
On 11/7/2005 at 7:13am, John Kirk wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
WhiteRat wrote:
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.
WhiteRat wrote:
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?
WhiteRat wrote:
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.
On 11/8/2005 at 10:08am, RenjiKage wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
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. ;-) )
John Kirk wrote: 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!
On 11/9/2005 at 3:47am, WhiteRat wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
John --
Ah, it clicks now. It was this piece of text that did it for me:
John Kirk wrote: 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! and draws its inspiration from those most venerable of dramas, Capcom's Street Fighter video game series.
Forge Reference Links:
Topic 15204
Topic 15256
Topic 16707
Topic 16884
On 11/11/2005 at 2:39pm, RenjiKage wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
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!
On 11/12/2005 at 1:20am, WhiteRat wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
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.
On 11/12/2005 at 1:36am, RenjiKage wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
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.
On 11/12/2005 at 4:52am, John Kirk wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
WhiteRat wrote:
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.
WhiteRat wrote:
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.
RenjiKage wrote:
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.
On 11/12/2005 at 6:41am, 1of3 wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
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.
On 11/12/2005 at 5:05pm, RenjiKage wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
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... :-)
On 11/12/2005 at 11:59pm, WhiteRat wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
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.
On 11/17/2005 at 3:41am, John Kirk wrote:
RE: Re: [Design Patterns of RPGs] What's in a Diagram?
Stefan wrote:
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.
WhiteRat wrote:
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.