Rules Diagrams

[Shreyas Sampat]

In Game Design Methodology,

As an extension to Tony's thought about integral design:

So here's my design process: Take a few simple rules and provide a framework for them to be applied to a large and varied "problem space". Then see what patterns and behaviors emerge in the problem space as it is changed by repeated applications of the same simple rules. That means playtesting, and lots of it. Change your simple rules until you get the behaviors you're looking for. Only add new rules when there is absolutely no other option.

The trick is keeping the rules simple and few. In my opinion, if you can easily imagine a game session where the rule wouldn't be used then the rule shouldn't be in your system at all.

I find that it helps to draw out a diagram of the rules, showing how each takes input and feeds its results into the other rules. If there is a rule whose output doesn't feed into another rule, it's probably either superfluous or incomplete.

Tony Irwin suggested that I discuss this in some more detail,  so I whipped up some graphs for Refreshing Rain and Limitless (follow links to see). Matt Wilson's "Budget-Fanmail Ecosystem" diagram in Primetime Adventures is another excellent example.

I find that this helps me immensely in seeing how rules interact with one another, and finding weird gaps where there should be interactions, but they're absent!

I'm interested in discussing other visual representations of systems, and how people have found them useful. Are they useful?

[Adam Dray]

I recently stumbled across Systems Thinking, which seems like it could be useful for your analysis. It takes the graphs you already created and adds one more degree to each connection. Then, you can determine which of the cycles in the graph are balancing and which are reinforcing. Neat stuff.

[Ron Edwards]

Hello,

I do this frequently. Most recently, our role-playing group diagrammed out the rules-interactions in Nine Worlds, in order to appreciate which aspects of play and character design were most "active" in early play.

Best,
Ron

[Andy Kitkowski]

Here's two examples:

Flowchart of rules procedures for actions (translated from a steampunk-western game called Terra the Gunslinger)
http://www.tenra-rpg.com/secret-ninja-shit/terraaction1.jpg

Here's Karma rules in the game Tenra Bansho Zero. They're hard to get into by simple reading, becuase they affect other rules in sort of a flow (one thing leads to a second, which leads to a third, which leads back to the first). This diagram tries to make those rules clear, complete with cute illustrations, ect.
http://www.tenra-rpg.com/secret-ninja-shit/08-tenrakarma.jpg

-Andy

[Malckuss]

I heve a question: what layout sems to work best as a diagram? Does it depend on what the diagram is trying to explain/demonstrate? When is a diagram too complicated to do any good?

[contracycle]

I like this idea, but I think it should be more detailed.  That is, if you have a range of 1-10 results for a gioven roll, there should be an indicator where each of those results will go.

Admittedly I'm influenced by programming design diagrams, but I'm thinking of things like the exploding dice convention that can add a looping special case that must be decided before the next step of the overall mechanic can be completed.

And indeed, I think that ultimately we should be able to "map" existing mechanisms with such diagrams, and perhaps even obtain insight from comparing the maps of different games.

When is a diagram too complicated to do any good?

At the same time that a piece of striong is "too long".  Diagrams may need specialist knowledge to "read" correctly, but thats not in itself a problem.

[Shreyas Sampat]

In my specific example, the intent of the diagram was to see not how rules interrelated, but if they do, so I think that diagramming every possible case, making complicated subdiagrams for subsystems, and so forth would be less than ideally productive.