When to Pause Auto-Advance: Set Three Human Review Questions for a DramaFork Project

Auto-advance is good for quickly laying out the parts you have already thought through; pause only where "the cost of rework will spill over into many downstream steps." For a two-person small team, it is recommended to set only three checkpoints: before the plan is finalized, before the script is converted to storyboards, and before high-cost video batch generation. Each checkpoint answers only one question; once answered, either release or return it, without requiring confirmation at every step.

The following uses a fictional teaching example throughout: the two-person team "Gray Lantern Group" is making the interactive film-game Mist Harbor Courier, and the members are screenwriter A Lan and artist Lao Zhou. The dialogue, numbers, and conclusions in the example are made up to illustrate the method, not actual test data.

The planning stage produces character identity, goals, needs, secrets, initial relationships, arcs, and boundaries. The first three are usually written quickly; what is easy to miss is boundaries: what this character will absolutely never do, will never know, and will never change their stance because of. If boundaries are not locked down, the later script will constantly find reasons for them.

In Gray Lantern Group's plan, the protagonist, the courier A Xu, has the goal of "delivering the last letter into the recipient's hands," the need of "being acknowledged as someone who is not dispensable," and the secret that "he privately opened a dead letter." A Lan initially wrote only one boundary line: "will not harm innocents." During review, Lao Zhou asked: if the recipient is the sender of that dead letter from back then, would A Xu open the letter again? A Lan said yes, but that is the climax of the plot, not everyday behavior.

So the boundary was changed to two lines: in daily life, he will not open letters; only when it is confirmed that the recipient is directly related to the dead letter will he open it, and after opening it, the player must see the cost. This change took only ten minutes, but if it had been left until the script stage, every scene involving A Xu would have to be rewritten.

Release condition: every major character's boundary can be written in the sentence pattern "will not... unless..." Return condition: the boundary has only adjectives, no specific behavior. One line is enough for the objection record, for example, "Lao Zhou believes A Xu's motivation for opening the letter is insufficient; A Lan keeps it and will verify at the script stage."

When the script enters storyboarding, it means the text must become shootable images and interactive nodes. In DramaFork, nodes are organized in tables, not drag-and-drop diagrams, so each choice should ideally correspond to a state change; otherwise the storyboards will shoot a bunch of beautiful shots that do not affect what follows. This article is compiled by DramaFork and explains according to the current project implementation: changing the script affects storyboards, style, characters, nodes, video, preview, and export; completed steps will be marked as needing updates, and old data is retained, but the system will not judge for you whether the expression of the old assets still holds.

In Act Three of Mist Harbor Courier, Gray Lantern Group set three choices: hand the letter to the dock manager, burn the letter, or open it yourself. A Lan initially wrote different dialogue for all three choices, but the only state change was "whether the letter is opened." Lao Zhou pointed out that handing it to the manager and burning it made no difference in the later storyboards, which meant two choices were wasted.

The fix was to have the three choices change different states: handing it to the manager changes "A Xu's relationship with the port forces," burning it changes "A Xu's attitude toward the dead letter," and opening it changes "whether the secret is exposed." Only then do the storyboards have three sets of shootable visual differences.

Release condition: each key choice changes at least one state that will be referenced later. Return condition: the choice changes only dialogue, not state. This step does not require line-by-line review; review only the nodes that will enter storyboarding.

Video generation is usually more expensive than text, so the pause goes before batch submission. The criterion is not "does the image look good," but "will the character settings and style that this batch of videos depends on still change?" If character boundaries or style are still being changed, make one or two test clips first; do not lay out everything at once.

Gray Lantern Group wants to generate three videos: a dock panorama, the courier running, and a close-up of opening the letter. A Lan had just changed A Xu's boundary, and Lao Zhou's style draft had also shifted from "cold gray" to "cold gray plus warm yellow streetlights." The two decided to generate only the close-up of opening the letter first, because this segment depends on both character expression and style. After the test clip came out, Lao Zhou found that the warm yellow streetlights stole attention from the face in the close-up, so he changed the style back to mainly cold gray. If all three had been generated together, the dock panorama and the running scene would both have to be redone.

Release condition: the characters, style, and nodes that this batch of videos depends on are all finalized, and the test clip confirms the direction of expression. Return condition: any dependency is still being changed, or the test clip differs greatly from expectations. Failed asset tasks can be retried individually; there is no need to redo the whole batch.

The objection record is recommended to have only three columns: who raised it, which step it targets, and whether it is kept or pending verification. In Gray Lantern Group's record there is one line: "Lao Zhou: A Xu's motivation for opening the letter is insufficient; A Lan keeps it and will verify at the script stage." If it still does not hold at the script stage, go back to Checkpoint One and change the boundary, rather than patching it forcefully in the storyboards.

The completion check can ask: Did all three checkpoints ask only one question? Does each return condition directly point to the material that needs to be changed? Are there still "pending verification" items in the objection record that were not handled in the next stage? If all three answers are yes, auto-advance can continue running; if one is no, stop at that step first, and do not use downstream assets to patch upstream ambiguity.

Small action: open your current project's plan or script, pick one major character, write one boundary using "will not... unless...," and see whether it can directly determine whether a certain choice should exist.