How to Check DramaFork Interaction Nodes: Option Text, Exits, and Payoff Results Must Be Read as Pairs

When checking interaction nodes, treat each option as a "promise—payoff" pair: the intent the player reads on the button must receive a corresponding result in the node pointed to by the exit, and that result must be able to return to the main line or form a clear closure. Checking only the button text, or only looking at the node connections, will miss empty exits, misconnections, and duplicate intents. Below, a fictional teaching example, "Inside and Outside the Greenhouse Door," illustrates a reusable review table.

DramaFork's nodes are organized as an editing table, not a drag-and-drop branch diagram. When reviewing, it is recommended to open a separate checklist beside the current node table, with only one option per row, fixed in three columns:

1. Option text: the exact button wording the player actually sees.
2. Exit: the name of the next node that this option points to.
3. Payoff result: the first passage of narrative or state change the player reads after entering the next node.

The three columns must appear as a pair. If a row has only option text and an empty exit, it is an empty exit; if the content of the node pointed to by the exit does not match the button's intent, it is a misconnection; if two buttons have different text but their exits and payoff results are almost the same, it is a duplicate intent. The following examples are all fictional teaching materials and do not correspond to any real project.

Set up a minimal scene: the player is outside the greenhouse door and needs to decide whether to enter. The node table has three nodes: Outside the Door Choice, Push the Door Open and Enter, and Go Around to the Side Window.

The third row is a typical misconnection: the button says "Push the door open and go in," but the exit points to the side window node, and the payoff result is also entirely the side window content. The player clicks "Push the door open and go in" but reads about going around the window; the button's intent and the exit are inconsistent. The way to locate this is to first sort by the exit column; if different button texts appear under the same exit, then compare the payoff results row by row; in the table above, "Go Around to the Side Window" is shared by two different buttons, so one of them must be wrong.

Now look at how an empty exit is written: in Outside the Door Choice, add a fourth option, "Knock on the glass," leave the exit field empty, and leave the payoff result empty as well. When the player clicks it, there is no follow-up at all; this is an empty exit. When handling it, either add a node for it, such as Knock on the Glass, and write clearly, "You bend your fingers and knock twice; there is no response from inside"; or simply delete this option. If you leave it without fixing it, the player will stop at this step.

A return loop means that starting from the current node, after passing through several exits, it can return to the current node or return to a main-line node. Take Go Around to the Side Window as an example: if this node has only one option, "Go back outside the door," and the exit points back to Outside the Door Choice, the loop holds, and the player can repeatedly move between outside the door and the side window. If the side window node's option is "Continue walking inward," and the exit points to a node that does not exist, the loop is broken, and the player will get stuck. When checking a loop, start from each exit and follow the pointers until returning to an already visited node or reaching a clear ending node; if you encounter an empty exit or a pointer to a nonexistent node along the way, record that path as not looped.

Here is an easily overlooked case: if the Push the Door Open and Enter node has only one option, "Return the way you came," and the exit points back to Outside the Door Choice, the loop also holds. But if in Outside the Door Choice the exit for "Push the door open and go in" is mistakenly changed to Go Around to the Side Window, then after the player returns from Push the Door Open and Enter and clicks "Push the door open and go in" again, they arrive at the side window instead; although the loop exists, the path has already been misconnected. Therefore, loop checking must be done together with control checking; you cannot only look at "whether you can walk back."

Duplicate intent is not about similar text, but about two options whose exits and payoff results express the same result. For example:

• Option A: "Push the door open and go in" → Push the Door Open and Enter → "You step into the damp, hot air"
• Option B: "Force your way in" → Push the Door Open and Enter → "You step into the damp, hot air"

The two buttons have different text, but the exit and payoff result are the same, so the player does not get a different direction when making the choice. The handling method can be to merge them into one option, or to change the exit for one of them and add a different payoff result. If two entrances really do need to lead to the same node, it is recommended to reflect the difference in the payoff result, for example writing "The door hinge makes a dry sound" for one and "You slam the door open with force, and the hinge shakes" for the other, so the player reads a difference.

There is also a hidden kind of duplication: two options have different exits, but their payoff results differ by only one or two characters, such as "You walk into the greenhouse" and "You enter the greenhouse." This difference does not constitute an effective choice for the player and should still be regarded as duplicate intent, requiring the merging or rewriting of one of them.

After reviewing the current node, confirm item by item:

• Every option has a non-empty exit, and the exit points to a node that exists.
• The payoff result corresponding to every exit is consistent with the button text's intent.
• No two options share the same exit and have the same payoff result.
• Starting from every exit, it is possible to return to the main line or reach an ending node, with no broken links.
• After modifying a node, mark only the relevant completed steps as needing updates, keep the old data, and manually check whether the old material's expression still holds.

This article was compiled by DramaFork and explains according to the current project implementation: nodes are organized as an editing table, text and nodes can be edited, and failed material tasks can be retried individually; there is no drag-and-drop branch diagram or complex condition engine. After the check is complete, first pick an option with an empty exit or a misconnection, add the target node and write the payoff result clearly, then walk through the loop again.