For gamers who use flow charts, process models and diagramming in their game what set of graphical representations work best at representing story components. I'm looking for what set of notations can best be used to represent gaming bits and why. I've seen a lot used (most misused) and I'm looking for a set of notations to roleplaying.
I.e. Use gateways to represent X, with an Exclusive decision/merge (XOR) representing moments when...; and a Complex decision/merge representing....
I've found several different modes for flow charts in games...
Mode 1: standard Information Processing
Rectangle: Do something. 1 step per box.
Diamond: make a decision
Circle: Start, end, and goto circles
This mode is excellent for combat flowcharts, especially when the dice pools are detailed in the rectangles.
Not so good for adventures
Mode 2: decisions only
typically, ovals or rectangles
Each location is a chunk ending in a decision point.
I've seen this used for good effect in Digest Group Productions Cinematic Nugget adventure format. That format shows the overall flow as a chart connected by by arrows, with each box being a chapter of the adventure. Each chapter likewise has a flowchart of it's encounters, and then each encounter has a large bold headline.
It also is how I tend to write adventures, when I bother to write adventures.
Mode 3: actions only
Typically, one action per rectangle, no decision blocks.
This mode has been used in several games, as a shortcut on the standard information processing model. Rather than have separate decision triangles, boxes with rolls or comparisons have multiple outputs, with the line annotated for the value ranges. Steps with no decision simply have a single line out.
This mode works rather well for process charts, especially encounter trees for an adventure, but it's less clear about where decisions occur. It's very similar to decisions only, but in the scenario case, there are often lots of decisions with no long term impact, and so the flowhchart shows only the one line out for many encounters; overcome them, by any means, and go on to the next. I've not seen it used in about 10 years; it was very easy to draw with 1996 word processors, unlike the traditional diamonds, circles, and rectangles.
Variations
I've seen combat encounters marked with lines rayonny, dancety, or even embattled, with non-combat using a line simple, in both modes 2 and 3.
I've seen process charts which used different shading for who was doing that step; these were usually after-market free fan clarifications, usually combat process.
Commentary All of them work. The question becomes, which can you draw and use most effectively?
The decisions only mode is often too terse for many people; it's a map to a text. It doesn't stand alone, and there is a tendency to overlook planned encounters which don't affect the overall flow. Sometimes with drastic consequences; in one adventure, the flow-map didn't show a particular encounter which provided the hook for an entire branch of the adventure; the branch point is several encounters later, and was on the chart.
The boxes-only version is easily doable in most current word processors; it was even doable in old-times with formatted monospaced text. It's simple to draw, and readily followed. It can be cluttered, however.
I find using author/scriptwriter tools to keep track of a novel's plot, npcs, and locations works better than flow or process control charts. The main difference is that an author will be using that to develop a story from while for a RPG referee it is a bag of stuff to use to adjudicate the results of players actions. The initial plot is what would happen if the characters didn't exists and it is a more of a plan that changes as result of the players actions than a fixed script. The organization tools of author/script software are ideally suited for this type of work.
There are also wiki software with their ability to incorporate text and images and most important their ability to crosslink. This is a good alternative to using script information.
Check out Page 2
There is Tiddlywiki which can be carried around on a USB stick.
I use a variety of tools, most often finding myself using a simplified version of Business Process Model and Notation (BPMN). Here are the major elements I use.
I am a huge fan of John Kirk's Design Patterns of Successful Role-Playing Games (available at no cost as a ZIPped file at the bottom of this page). His Design Patterns book describes a notation for RPG components and techniques. The notation uses what John calls "gauge diagrams" to indicate how information flows between different mechanical constructs within the game. You could repurpose these and add a time component to record a lot of information about an instance of play.
Another obvious choice for representing story (and its essential time component) is a UML sequence diagram, which can record information flow, transfer of control, and even simultaneous action (say, several players doing something at the same time).
To avoid railroading, I recommend only include main plot points essential that your PC's must hit. The connecting lines should signify the order in which they can be achieved. Using this method, you can be careful to not force them into nearly anything, and you can keep organized those crucial points in the campaign, this way, no matter what path they choose to arrive at your destinations, you wont be caught off guard.
As far as the information to put in the bubbles, I recommend listing some relevant NPC names(so you don't have to make them up on the fly), a brief summary(maybe one sentence) of what will happen, and what players should be present. Beyond this might stifle creativity on your part.
I have had good luck with this schema. As far as how to prepare them, I just draw them, or if I want to get fancy I use inkscape.
I think what you're looking for here is Robin Law's "Hamlet's Hit Points", a book about deconstructing and diagramming fundamental narrative and pacing structures to the ends of building better stories in RPGs. He invented a diagrammatic format and everything.
EPC is a relatively simple notation that you might find useful if you're not comfortable with an idiosyncratic notation.
http://en.wikipedia.org/wiki/Event-driven_process_chain
Most modeling notations are built for software design or business process design. Of the two, the business process languages tend to be a little more useful for RPGs.
I find this kind of notation most useful for modeling long-term NPC decision chains. You could chart out the villain's overall plan with some basic contingencies already built in. I would combine it with a simple work breakdown structure for maximum effectiveness, in that case.
In my current campaign, I drew a digital circuit design with AND and OR gates to represent the entire adventure. Actions of the players and of the bad guys can change whether input lines to these gates change from Low to High or vica versa.
In my design, there are many inputs lines and only one output. The final output starts out as a Low. If it ever becomes a High, the adventure is over.
To mix things up, it is the bad guy who is trying to make the final output go High, not the PC's. The PC's goal is to prevent the final output from going high.
Let me give an example of OR's and AND's in this circuit design. The bad guy needs to find one descendant from each of four long-ago heroes and have them help him with his quest, whether willing participants or not.
Because some of those heroes have multiple descendants, and he need find only one, OR gates are involved. But since he needs at least one descendant for each of the four, an AND gate is also involved. So there are four OR gates feeding into one AND gate.
If even one descendant is found for one of the four heroes, then the output of the corresponding OR gate goes High. If the outputs of all four OR gates go high, then the output of the AND gate goes High and the bad guy wins.
At first, the PC's were trying to find and warn all of the descendants to be wary. But then they realized that they need only stop one of the OR gates from going high to prevent the AND gate from going high.
You can read about it at Quest of Zorgon
