Adventure Design about dm HOT 8 CLOSED

There need to be entrance nodes. Which means nodes need to be grouped. Then when the group is opened, it can give some general text about the group, and list the entrances.

from dm.

There are different sorts of connections, which may be handled by different attributes of the objects. You will want a parent connection to the higher level node containing this node and it's siblings. You will want connections with one or more siblings, but those connections will be one way. It should be possible to have nodes with no connections to siblings. Those will need to be detected at the parent level and shown as hidden nodes. Then we need connections down at least to the entrances of the contained nodes. But we might want sibling nodes that connect to another adventure at the same level as the parent.

from dm.

Is there a good way to abstract this so that we only need one node class? Clearly there is a way, but what is a good way to handle all of these connections?

from dm.

Nodes have three sets of other nodes: container (parent), members (children), and connections (siblings). They also have names, descriptions, tags, notes, and some sort of links to encounters and/or NPCs.

Edges have names and descriptions. The names are their hashes, so they can be used as keys in a dictionary. Edges are for connections. Members are hashed by the name of the node. Containers are singular attributes.

Containers are passed between siblings. So if you are in node B which is in container A, and you make a new node C, C's container is automatically A.

Note that containers are nodes, and can be connected to. If you have nodes A and B that are connected together, and node C is contained in node A, C can connect to B.

from dm.

Tags on nodes would take care of identifying special nodes like entrances or events. We would still need a detector for finding hidden nodes.

from dm.

Note that using names for hashes makes it a problem for changing names. I should allow for changing names, so have an underlying hash that is invisible to the user.

from dm.

There would be a separate adventure building interface, and then the Egor interface could navigate the adventure and make notes on it. The adventure interface would be accessible from Egor.

from dm.

I am closing this as it is not really part of the "running D&D" paradigm. This is prep, not running.

from dm.