In Game Design Methodology,

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

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

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.

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

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

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?

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?

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.