The Alexandrian

Fractal Spheres - Pete Linforth

Go to Part 1

An idea we’ve sort of been flirting with here is that node-based design is fundamentally fractal: You can “zoom in” on a node and break it apart into more nodes. Or, conversely, you can “zoom out” of the local collection of nodes you’ve been adventuring in and discover it’s all part of just ONE node in a much larger web.

For example, let’s consider the Lytekkas vampire hypercorp:

  • At the highest level, we map their activity across seven cities: Chicago, the Old Angeles arcology, Shanghai, St. Petersburg, Reykjavik, Cheltenham, and the Lytekkas-Auberjonais L1 colony.
  • Pick one of those and open it up: Now you’ve got nodes representing all of Lytekkas’ major projects in the Chicago metroplex. (These would also have connections to the other cities.)
  • One of these involves the development of experimental blood-nannies (probably derived from the vampiric virus to mass-Renfield the population; or maybe an effort to control the negative side-effects of being a vampire).
  • Look inside that node and you find the half dozen or so people and facilities involved in the program.
  • The PCs identify and target a Lytekkas warehouse. This node is a heist scenario. There are elements of a heist scenario that are node-like, but it’s really a different structure, so this is the end of the road.
  • … or is it? Part of the heist scenario is the opportunity to secure blueprints of the target. We could resolve that with a skill check, but we could also design it as a micro-node-based scenario.

But you can also flip this whole thing around and see that the Lytekkas hypercorp is just one of the immortal corporations which can track their secret history from the 22nd century back to the Dutch East India Company in the 17th century, with each one of those immortal corporations being a separate node.

This fractal quality can be seen not just in the nodes themselves, but in the connections between those nodes: There’s functionally no limit to how many leads can be placed in a single node, nor in how many leads can be created that point to a node. There is always an opportunity to increase the complexity and interconnectedness of your node map, particularly if we’re talking about an ongoing campaign which is developing over time (and, thus, features connections being formed and broken over time).

At this point the pedants may point out that this isn’t truly fractal because there is a limit to how far we can take this: At some point we’ll end up with a node which is a person; which is a sole entity that cannot be subdivided.

But it’s more true than you might think: Even individuals can be reconceptualized as a node-based scenario consisting of their job, connections, family, etc. The question is not whether you can do this, but whether it is interesting to do so.

MANIFESTING & MANAGING COMPLEXITY

This fractal nature of node-based scenario design, as we’ve seen, allows us to manifest an almost limitless amount of complexity. That can be quite daunting.

But it also allows us to manage this complexity. One of the functions of node-based design is specifically to chunk information into manageable nodes so that you don’t have to try to juggle or keep the whole thing in your head at once.

If you’re getting overwhelmed by trying to handle all seventy nodes of the Lytekkas hypercorp, figure out how to categorize those nodes into manageable groups: By city of operation. Or secret projects. Or corporate division.

The “right” division is going to depend on your own personal preferences and the details of the specific scenario. You’re looking for the clear conceptual chunks that will allow you to keep on top of incredibly complicated campaigns, while ideally only needing to think about one chunk of the scenario or campaign at a time. (I talk a bit more about what the manageable limits for this are in Advanced Node-Based Design – Part 4: The Second Track.)

For a rough-and-ready example of this, let’s consider the Bangkok node in the Eternal Lies Remix. In my prep notes, you can see that I identified five nodes:

  1. Lowman’s Townhouse
  2. Phikhat Hwan
  3. Ko Kruk Island
  4. Sirikhan Estate
  5. Savitree Hunts the Investigators

The first two nodes are pretty standard node-based design: They’re distinct locations with (at least) three clues pointing at each.

But Ko Kruk Island is then broken into three separate nodes: The island itself, the Sirikhan Estate (a mansion on the island), and Savitree hunting the investigators (on the island).

Why?

To manage the complexity.

While the Sirikhan Estate is located on Ko Kruk Island, if the PCs are exploring the island (Node 3) I don’t need to think about every individual room inside the Estate (Node 4). And vice versa: if they’re in the mansion, I generally don’t need to worry about the whole island. Just like separating the individual rooms of a dungeon into separate keyed entries, separating this information lets me clearly focus on (and find!) what’s important RIGHT NOW.

(Speaking of fractal prep, of course, the rooms of the Estate are prepped as a location-crawl. So it’s individual rooms within a node (the Estate) within another node (the Island) within another node (Bangkok). You can really see how the prep structure lets me precisely narrow my focus.)

Node 5 was actually a late addition to my prep notes. I was originally trying to include that material in Node 3 — it’s stuff that happens on the island, so logically it should be in the “Island” chunk of information.

But the complexity of that particular event sequence was bloating the material to a point where I was finding it difficult to organize and reference it. If this is happening to your prep, it’s usually a warning sign that you need to break the material apart into more discrete chunks!

On the flip side, if the players become particularly fascinated by some aspect of the scenario or game world, it becomes relatively trivial for you to zoom in on it and explore it in more detail. Keep this in mind even when running the game: Zoom in on the node and/or add connections to it in response to the PCs’ actions. Slap in a simple node-template like the 5-Node Mystery and you’re good to go following the players down their rabbit hole. Who knows where it will take you?

Go to Part 4: Nodes Aren’t Everything

12 Responses to “The Secret Life of Nodes – Part 3: Fractal Nodes”

  1. Toren says:

    You might like to try an organizational tool like obsidian.md
    https://obsidian.md/

    It lets you hyperlink notes to each other, like a wiki, and navigate with filters. I suspect it could do a good job of not only organizing systems of nodes, but working at different levels of node detail.

  2. Grasen J says:

    Is the example node structure in the introduction inspired by Night’s Black Agents? It sounds very similar, except leaning into cyberpunk.

  3. DanDare2050 says:

    One thing you didn’t mention is how this aids in smart prep.

    My go to example is my Traveller campaign. I have a “nation” level set, where each star nation has an overall tech level, nature, internal, high level factions and relationships. Then I do the same at lower levels: sector, sub sector, and star system (sometimes planet and planet region). Each node (a nation, faction, star system) has a generalised level of abstraction. Often that is all it has.

    I have procedural generators that make detail that conforms to the generalisation so I can create detail on the fly if required.

    As an example Traveller has a generator for making planets. However I don’t want that detail for things I don’t need to prep yet. So beyond the nearby star systems, and those that have been investigated by the players, are generalised star systems of a vague “type”: population centre, fuel stop, resource hub, science out post, military out post, mining colony and so on. The players hear about and remember those places at a distance, but not until they get closer do I want to prep them.

    My generic systems constrain the planet generation procedure to ensure that when the planet size, atmosphere and so on are finally detailed they conform to the generic description, rather than contradict it.

    Similarly factions have a general intent, scope and strength. At any given place you can see the factions that are present and can quickly build an encounter table for the likely hood of tangling with a given faction. The factions also have a high level, generalised set of current operations (consolidate, investigate, grow, attack). These ops become detailed when players encounter them and get involved. This also helps in handling the appropriate transmission of player intervention to an operations resolution at different scales.

    This all keeps campaign management very modest as broad brush strokes, while deeper and deeper detail resolves as the players get closer. My time for generating most detail is as it becomes more likely to be needed, and “moving the chess pieces” of the larger scope things ignores the details and is also pretty easy.

  4. Airlock says:

    The idea of re-conceptualizing an individual as a series of nodes is lighting my brain on fire. This would work wonders for designing and organizing a really tightly-focused scenario that mainly involves the connections between a small group of people.

    I’m imagining, like, a single hardhold in an apocalypse world game where most or all of the threats are internal, or maybe a fallout game that takes place entirely within a vault.

  5. SomeoneLivedHere says:

    Node-based prep had sorta thrown me when I first read the initial articles, but as I prep additional mysteries to run in the Styes (right now, adapting The Adventure of the Six Napoleons), I’ve found myself naturally making use of it.

    The major advantage, I’ve found, is that it forces me to avoid DM-brain – not realizing players don’t have information or priorities that I have. Developing content by following connections privileges those connections, inherently. I’m going to try to apply this to my much-less mystery based main game, and see if it livens things up. I think it will.

  6. Wyvern says:

    I, too, would like to know if you had any specific game in mind when you came up with the vampire hypercorp example. By the way, I assume you meant to write “blood-nanites rather than blood-nannies? (Though the latter is an amusing image.)

    @3: I’d be quite interested to see how you tailored the planet generation system to specific types of settlements. Have you posted your system online anywhere?

    @5: What’s the “Styes” of which you speak?

  7. Justin Alexander says:

    Lytekkas is a purely hypothetical example. (I tried pulling some actual play examples, but they were messy in the way that real world examples often are; I wanted something closer to a Platonic ideal to demonstrate the principle.) While writing it, I thought it would be fun for Technoir or as a pop-up juncture or reboot contniuity for Feng Shui (with the immortal hypercorps successfully grabbing enough chi in the 1850 juncture to shift the future). I’ve also been bouncing around ideas for a cyberpunk version of Ars Magica, but I don’t know that the immortal hypercorps quite fit with that.

    NBA’s systems for procedurally generating nodes in a conspiracy are absolutely beautiful, though. And a cyberpunk version sounds absolutely delightful.

    “Nannies” are slang from Schlock Mercenary. So both yes and no.

    I’d love to hear more about SomeoneLivedHere’s campaign, but I’m fairly certain he’s talking about a really great setting described in Dungeon #121 by Richard Pett (in the adventure “The Styes”). Very vivid and I’ve heard from a number of people who have used it as the basis for their campaigns.

    Ironically, although I didn’t mention it in Part 2, “The Styes” actually WAS one of the adventures I’d prepped for the Ptolus campaign that the PCs ended up skipping.

  8. Matthew says:

    I love thinking in terms of Nodes and node-based design. Additionally, I found this site https://kumu.io

    It may not help everyone, but I found it a useful way to organize my node based game design, and also show more relationships (having a character apply to multiple nodes, for example)

  9. DanDare2050 says:

    @7 Wyvern
    I first discussed it online here: https://strangeflight.blog/2016/11/03/low-prep-rich-traveller-campaigns/
    I made a tighter, somewhat more cut down and mechanical version here: https://www.freelancetraveller.com/features/preproom/loprep.html

  10. DanDare2050 says:

    Hey Justin,
    referring back to your work on game structures, and specifically the incomplete structure stuff where you talk about a space faring encounter structure and then a hijack structure, would it be right to think of that stuff as an instant node generator and/or template?

  11. Tom Pleasant says:

    If you have information about a node that is spread all over the place, how best do you organise that while keeping to the philosophy of keeping information where you need it? Should you religiously keep it in its relevant node and only refer to it if it is found elsewhere, duplicate it or some other combination?

    I’m experimenting with this and have the hook being the murder of a survivor of an doomed arctic expedition. Should the expedition be a node and everything to do with it and the members before, during and after the actual expedition be kept in one super node or would it be best to separate it all out if it’s just for one scenario?

  12. Justin Alexander says:

    @DanDare2050: Probably yes.

    @Tom: Sounds like this is a mystery scenario. So I would frame the question in terms of where/who/how the PCs can investigate stuff. I would probably couple that to a reference sheet on the background the expedition to keep all that continuity straight.

Leave a Reply

Archives

Recent Posts


Recent Comments

Copyright © The Alexandrian. All rights reserved.