When Plot Clues Are Written on a Phone Screen, How Do You Avoid Relying on a Single Image for Key Text?

The author should maintain a separate "required reading text list" that fully records each key text's exact wording, presentation medium, trigger conditions, and how players can verify it; in the visuals, treat that text as only one form of presentation, and provide subtitles or independent body text as well. If numbers, times, locations, or forms of address do not match, stop and revise the text rather than continuing to work on later shots.

Below, we walk through a fictional teaching example, the "ferry schedule change text message." The characters, numbers, and times in the example are fabricated and do not correspond to any real product output.

Not all words on the screen are equally important. It is recommended to divide text into three categories and write them in the same table.

Must-read text should be finalized word by word. Auxiliary text can be adjusted with the visuals. Decorative text does not enter the verification scope, avoiding spending energy on battery percentage.

Suppose the plot is: the character Lin Wan is waiting for a ferry at the old pier and receives a text message saying the ferry has changed to another pier and will depart later. The player then must choose between "rush to the new pier" and "stay where they are and wait." The time and location in the text message are the must-read text.

First write the list, not the shots.

Required Reading Text List (First Draft)

• Text ID: SMS-01
• Exact wording: "Lin Wan, today's 16:40 ferry has changed to North Embankment Pier, departing at 17:10. Don't go to the old pier."
• Sender display name: Ferry Dispatch
• Sender number: Do not display the full number, only show "Unknown Number"
• Presentation medium: Close-up of phone screen
• Trigger condition: The 2nd shot after Lin Wan arrives at the old pier
• How players verify: The next shot's subtitle repeats the time and pier name

There is an easily overlooked point here: the "16:40" in the text message is the originally scheduled time, and "17:10" is the new departure time. Both times must be clearly marked with their meanings in the list; otherwise, the person doing storyboards later might treat one of them as the departure time.

"Close-up of phone screen" is too vague. It is recommended to add recheckable conditions:

1. The screen content occupies a sufficiently large proportion of the frame, and key text is not blocked by fingers, reflections, or notification banners.
2. The full text message body appears and is not cropped so that the second half of the sentence is lost due to camera movement.
3. If the image has blur, the blur does not fall on the time and pier name.
4. Do not overlay a second notification within the same shot, avoiding two texts interfering with each other.

These conditions are not shooting parameters, but checklist items that can be ticked off one by one during acceptance. If any one is not satisfied, return to the text or storyboard for revision, rather than relying on players to guess.

Outside the visuals, leave at least one independent channel to carry the same must-read text. There are two common approaches.

Subtitle supplementation: After the text message shot, use one line of subtitle to repeat the key information, for example, "New pier: North Embankment. Departs at 17:10." The subtitle is independent text and does not depend on whether the phone screen is clear.

Independent body text supplementation: At an interaction node or in a log, make the text message content a reviewable text entry. Even if players did not see the screen clearly, they can read the exact wording in the text area.

The text in the two channels must be consistent. If the subtitle says "North Embankment Pier" and the body text says "North Shore Pier," players will get two locations, and subsequent choices will lose their basis. When inconsistency is found, stop first, unify to one version, then continue.

Suppose the visual draft arbitrarily adds a complete sender number, and later storyboards also say "Lin Wan calls this number back." Both violate the list's agreement to "only show Unknown Number." An unknown number has no selectable callback target, and one cannot凭空 write out a successful dial or an empty-number prompt.

The fix in this example is to delete the complete number from the draft and return to the list to add two lines:

• Callback operation: Unavailable; the sender did not provide a callback number
• Result text: "This text message does not show a number. Lin Wan turns to the ferry bulletin board to verify the ferry schedule."

If a callback is indeed needed later, first modify the setting, define a fictional callback target and result, then synchronize the list, visuals, and dialogue. You cannot keep "no number" while having the character dial a number that never appeared. In this way, display rules and executable actions are determined at the text layer, and the visuals do not temporarily add plot facts.

After completing the above preparation, check in order:

1. Open the required reading text list, read each exact wording aloud, and confirm there are no typos, wrong times, or wrong locations.
2. Compare each presentation medium and confirm that the text in the list matches the actual visuals, subtitles, and body text.
3. Check trigger conditions: it appears when it should appear, and does not leak early when it should not appear.
4. Check how players verify: there is at least one text channel that does not depend on the visuals.
5. If any item is inconsistent, stop and correct the text, then recheck the affected shots and nodes.

The completion standard can be set as: any person who did not participate in writing can, by looking only at the subtitles or independent body text, state the new pier name and new departure time; by looking only at the visuals, they can also find the same information. Only when both channels pass is this clue qualified.

Text in AI-generated visuals may be wrong; this is an output limitation and does not mean all AI videos cannot generate text. The safe approach is still to place must-read text in an editable, verifiable text layer, with the visuals carrying only one form of presentation.

• Text ID:
• Exact wording (word for word):
• Reason it is must-read:
• Presentation medium (visuals/subtitles/body text/log):
• Trigger condition:
• How players verify:
• Handling when inconsistent:

Fill out this table, then start working on shots. Key text will no longer rely on only one image.

Next step: pick out the most important phone text in your current plot, fill it out according to the table above, first confirm that the exact wording and time/location do not conflict, then decide how to present it visually.