The Three Clue Rule
states:
For any conclusion you want the
PCs to make, include at least three clues.
The underlying theory behind the rule is that having three distinct
options provides sufficient redundancy to create a robust scenario:
Even if the PCs miss the first clue and misinterpret the second, the
third clue provides a final safety net to keep the scenario on track.
This logic, however, also leads us to the inversion of the Three Clue
Rule:
If the PCs have access to ANY
three clues, they will reach at least ONE conclusion.
In other words, if you need the PCs to reach three conclusions (A, B,
and C) and the PCs have access to three clues (each of which would
theoretically allow them to reach one of those conclusions) then it is
very likely that they will, in fact, reach at least one of those
conclusions.
And understanding this inversion of the Three Clue Rule allows us to
embrace the full flexibility of node-based design. Here’s a simple
example:
The scenario starts in the blue node, which contains three clues – one
pointing to node A, one to node B, and one to node C. Following the
inverse of the Three Clue Rule, we therefore know that the PCs will be
able to conclude that they need to go to at least one of these nodes.
Let’s assume they go to node A. Node A contains two additional clues –
one pointing to node B and the other pointing to node C.
At this point the PCs have had access to 5 different clues. One of
these has successfully led them to node A and can now be discarded. But
this leaves them with four clues (two pointing to node B and two
pointing to node C), and the inverse of the Three Clue Rule once again
shows us that they have more
than enough information to proceed on.
Let’s assume they now go to node C. Here they find clues to nodes A and
B. They now have access to a total of seven clues. Four of these clues
now point to nodes they have already visited, but that still leaves
them with three clues pointing to node B. The Three Clue Rule itself
shows that they now have access to enough information to finish the
scenario.
(Note that we’re only talking about clue access here. That doesn’t mean
that they’re guaranteed to find or correctly interpret every single
clue. In fact, we’re assuming that they don’t.)
Now, compare this node-based design to a comparable plotted approach:
Note that the plotted approach can also be broken down into distinct
nodes. And in terms of preparation, the plotted approach requires the
exact same resources: Four nodes and nine clues. But the non-plotted
design is richer, more flexible, and leaves the PCs in the driver’s
seat. In other words, even in the simplest examples, node-based design
allows you to get more mileage out of the same amount of work.
Of course, this entire discussion has been rather dry and technical. So
let’s put some flesh on these bones.
|