The Alexandrian

Go to Part 1

Something I touched on lightly when discussing the organization of your nodes was the difficulty of working with large networks of nodes.

This ties into Delta’s “Magic Number Seven”, which I’ve talked about before. To sum it up:

  1. Working memory capacity for most adults is in the range of 7 +/- 2 objects. Short-term memory capacity is also 7 +/- 2 when memorizing strings of random digits.
  2. Beyond these limits, mental functioning drops off rapidly.

In other words, we are generally pretty good at holding somewhere between 5 and 9 objects in our mind at a given time. Any more than that and it becomes increasingly difficult (or impossible).

So if you start trying to tackle large networks of nodes, you can quickly reach a point at which you can’t keep the whole network “in your head” at the same time. At this point, the network becomes difficult to design and manage (particularly in real-time at a game table).

Properly organizing your network can make it easier to manage, of course. (The Act I structure I posted, for example, took 15 difficult-to-manage nodes and broke them down into 6 major nodes with a varying number of sub-nodes. I could easily grasp the structure of the 6 major nodes and then “zoom in” to focus on the sub-nodes as necessary.)

But this principle also offers us an opportunity as designers: A quick and easy way to add complexity to a node-based scenario is to simply add a second set of nodes that are largely or entirely disconnected from the first set.

I call this technique the Second Track.

In my experience, it’s particularly easy to run a second track if the tracks use different methods of linking their nodes. For example, you might create a timeline of “backdrop events” combined with a primary network of clue-linked nodes. But this division of methods isn’t strictly necessary.

The reason this works well is that, from your perspective behind the screen, there are just two “chunks” of 4-6 nodes each: Easy to keep track of. Easy to understand. Easy to design. Easy to run.

But for the players – who aren’t privy to that structure – there are 10-12 nodes. This pushes it past the Magic Number Seven and presents them with enough complexity to become enigmatic.

(To put it a different way: The GM can easily handle the reactions of Conspiracy 1 independently from the reactions of Conspiracy 2. Until the players figure out that there are two different conspiracies, however, they can’t even start to unravel what’s happening to them.)

Go to Part 5: The Two Prongs of Mystery Design

Share on TumblrTweet about this on TwitterShare on StumbleUponShare on FacebookShare on RedditShare on Google+Digg this

4 Responses to “Advanced Node-Based Design – Part 4: The Second Track”

  1. Crabus says:

    I very enjoy your Node-Based Design serie but what about “Mind Map” Desgin ? Do you have any knowledge about using mind mapping in order to design a scenario ? It can be a complementary approach.

  2. Dan Dare says:

    Crabus, node based design is about the structure of the game world. Mind mapping is a system of recording the information. I find it very useful myself, although I don’t use strict mind mapping. I combine a network with mind maps flowering from various points.

  3. Dan Dare says:

    Justin have you ever specifically looked at nodes that are especially intended for players to return to? For example they find the entrance to the secret lair and then decide to head off and follow up something else and come back here later to follow on with it.

  4. Justin Alexander says:

    I tend not to design nodes specifically to be returned to, because I don’t really know what the PCs will necessarily do or accomplish at any given node. (The exception would be, say, including a clue in a later node that reveals something previously unknown about a previous node — whether that’s the entrance to a secret lair or the fact that Monica was Raymond’s secret lover.)

    This does come up organically through play all the time, though.

    My primary method of handling this is the Campaign Status Sheet, which is something I’m probably going to write a lengthy essay about at some point in the future, but which I currently discuss briefly over here.

    That link also briefly talks about designing from the status quo, which I discuss at greater length in Don’t Prep Plots: Prepping Scenario Timelines.

    The key thing is that, if the PCs go to visit a node, that node will usually end up getting altered in some way — like a planet getting perturbed out of its orbit. So if the PCs go back to that node, they should see the consequences of their actions. Eventually the node, like a perturbed planet, will settle back into a new status quo (although probably one different from the previous status quo).

    A few examples from my own campaigns:

    – The PCs remove the evil idol that’s sustaining the living flesh which has grown over the walls of the dungeon. They return several weeks later to see if the bad guy (who has escaped) has returned to his former lair and discover that the living flesh is now dead, rotting, and being feasted upon by giant maggots.

    – The PCs attack a slavers compound and return to discover that the slavers have hired mercenaries to beef up their security.

    – The PCs unwittingly take an action which politically damages a minor lord they were previously on good terms with. When they go back to chat with him, they find him cold and distant.

    And so forth.

Leave a Reply

Archives

Twitter

Recent Posts


Recent Comments