How to Group Issues in a DramaFork Playable Preview: Which Step Should Story, Interaction, and Assets Each Go Back To for Fixes?

When issues appear in a playable preview, don't rush to change nodes. Use a one-sentence symptom record to clearly write down "who saw what at what moment," then determine whether it belongs to story, interaction, or assets. Story issues go back to planning or script, interaction issues go back to interaction nodes, and asset issues go back to storyboard, style, character assets, or video; after changes, only recheck the affected downstream steps, and do not treat a preview that runs successfully as passing release testing.

The following uses a fictional teaching example throughout: the interactive film game Night Shift at Fog Harbor, whose protagonist is night-shift lighthouse keeper Lin Che, whose goal is to survive until dawn and find out where the missing crew member went, whose secret is that he once abandoned ship and escaped in the same waters, and whose initial relationship with dispatcher Shen Lan is one of mutual distrust. The following characters, numbers, and dialogue are all fictional and do not correspond to any real project.

A symptom record should include four items: when it occurs, what the player sees, expected content, and the shortest reproducible path. The timing should be written to a specific node, for example "when the options are first displayed after entering node N-07." Do not write "that middle part feels weird," because that cannot be located.

The three records for Night Shift at Fog Harbor can be filled in like this:

The basis for grouping is "is the error in the text, in the visuals, or in the order of events." The option text in S1 is carried by the node, so it belongs to interaction; the visuals in S2 come from video assets, so they belong to assets; S3 is a missing event, so it belongs to story.

The root cause of S1 is the node copy. Nodes are organized in a table, with one row corresponding to one occurrence position, not a drag-and-drop graph. When modifying, first confirm that the video and conditions attached to that node have not changed, and only change the option text.

Original options:

• Ask him why he came to the lighthouse
• Ask him about tonight's tide level
• Ask nothing

Change to:

• Ask him why he came to the lighthouse
• Ask him about tonight's tide level, and incidentally probe whether he knows the White Gull
• Ask nothing, turn around, and go check the cables

The second option turns Lin Che's secret into a direction that can be probed, and the third option gives an evasive posture. After the change, only recheck the preview segment after N-03, checking whether all three options can enter their respective follow-ups, and do not recheck the entire line.

In S2, the expression conflicts with the line. First determine whether the input required this expression. The storyboard determines the action and emotional intent in the shot, the style constrains the visual texture, the character assets provide character references, and the video is the actual generated result. In this example, the storyboard already clearly states "serious interrogation," and the reference also has no smiling requirement, but the generated clip is still smiling. You can start by checking this video task first, and you cannot infer from the image alone which frame the model selected internally.

The handling method is to check the corresponding storyboard and reference, clarify the action description if necessary, and then retry this video task separately. If the character reference itself carries an inapplicable expression, go back to the character asset step to modify it, and check other clips that use that reference. After retrying, you still need to look at the actual output; the troubleshooting here does not include timeline or frame-by-frame expression replacement functions.

S3 is missing the ship-search process, which belongs to event structure. First go back to the script and add a search scene between N-05 and N-06: Lin Che checks the cargo hold, discovers the cut cable, and hears footsteps above. After adding it, the goal in planning to "find out where the missing crew member went" has a corresponding passage.

Changing the script will affect storyboard, style, character, nodes, video, preview, and export downstream. In actual operation, only mark the relevant and already completed steps as needing updates, and keep the old data. There is no semantically precise automatic diff, and no one-click confirmation reuse, so manual checking is required: whether the newly added search passage still makes the old storyboard and video expressions valid.

After the three symptoms are fixed respectively, the recheck scope is determined by the layer changed:

1. Only node copy changed: recheck the preview segment of that node and its direct successors.
2. Only video assets changed: recheck the playback effect of the node to which that video is attached.
3. Script changed with a new passage: recheck the storyboard, video, and nodes corresponding to the new passage, as well as its connection with the preceding and following nodes.
4. Character assets changed: recheck all videos and preview segments that use that character.

When rechecking, use the same symptom record to fill in the results, for example S1 is recorded as "changed, the three options have distinguishable tones," S2 is recorded as "the corresponding video has been retried, and the actual expression matches the interrogation," and S3 is recorded as "the search segment has been added, and the connection from N-05 to N-06 is complete." These are still fictional filling examples, and actual projects should record according to observed results.

• Each symptom has when it occurs, what is seen, expected content, and the shortest reproduction path.
• The grouping conclusion points to a specific step, and does not say "adjust the whole thing again."
• Changing nodes only touches nodes, changing video only touches video, and unrelated steps are not affected.
• After upstream changes, only mark the relevant completed steps as needing updates, and keep the old data.
• The recheck scope corresponds to the changed layer, and rerunning the entire line is not treated as the only method.
• A preview that can play continuously does not mean release testing has passed; after export, it still needs to be checked according to the asset package instructions.

This article was organized by DramaFork and is explained according to the current project implementation. The playable preview is used to check the connection between nodes and assets, and does not replace playability verification after export. A successful ZIP does not mean playability verification has passed; localhost on someone else's computer points to their local machine and cannot be used as a universally accessible domain.

Next step: pick a preview symptom you recently encountered, fill in one row according to the table above, write down when it occurs and the shortest reproduction path, and then decide whether it goes back to story, interaction, or assets.