How to Write an Interactive Film Prop Version Ledger: One Letter Must Not Change Silently Between Branches

A version ledger for one letter must record both “what it looks like now” and “what has happened to it.” Unopened, opened and resealed should be three separate states. Each shot then declares which state may enter, whether it changes that state, and what remains at the end. “One envelope prop” is not enough to prevent an opened letter from silently reverting to an intact version when branches merge.

The following uses Rainy-Night Handoff to demonstrate the method. It is a fictional teaching example, not a real user case, tested result or product feature. The ledger and decision rules are illustrative designs.

Lin Lan is entrusted with delivering a letter to a gatekeeper. Players can deliver it directly or open it to look inside. After reading it, they can hand it over open or reseal it. The gatekeeper checks the seal during the handoff, so the envelope’s appearance carries story evidence and cannot vary freely like an ordinary background texture.

First fix the object’s identity: an off-white envelope with a blue dot at the upper right of the front, a triangular flap on the back and one folded sheet inside. The dot identifies the same object; the flap distinguishes its state. In this example, opening leaves a tear on the right side, and resealing uses narrow paper tape while retaining that tear.

Also distinguish three questions: has the letter been opened, has Lin Lan read it, and does the gatekeeper know? They cannot share one “opened” field. Opening the letter does not mean the sheet has been read through, and the gatekeeper not yet seeing the seal does not mean the object bears no traces.

Create the variant reference table first, then have shots refer to its IDs. The ID represents narrative state; the revision represents the production specification. Changing tape width can revise the specification, but cannot rename a resealed letter as unopened.

Attach front, back and seal close-up photos for each variant, with specification revision and photo IDs. Reference images must show which side is torn and how far the tape covers. Front photos alone cannot constrain a handoff close-up.

You can prepare several physical copies of the same variant. Copy IDs track shooting consumption without changing story identity: “Letter B, copy two” is still opened. If a copy has a visibly different tear, record the difference and limit its use. Matching IDs alone do not make it suitable for adjoining close-ups.

Reusable reference-table fields are object ID, variant ID, specification revision, identifying features, contents, reference photos, physical copies and prohibited conditions. Write “to be decided” in cells lacking information; do not leave blanks that imply confirmation.

The variant table answers “which letters exist”; the shot ledger answers “which letter is needed now.” The table below records all three handoff routes together for storyboard, continuity and editing staff to cross-check.

For actual use, add asset files, actual takes, frame-entry and exit directions, and confirmation records. Route names help with lookup but cannot replace conditions. The “inspect route” uses both Letter B and Letter C, so selecting props by route alone may still produce the wrong one.

For Reseal 4, for example, first check Reseal 3’s exit record before shooting, then confirm that the sheet is back inside, the tape is on the back and the tear remains. After shooting, enter the actual copy ID and selected take in the ledger. Record any last-minute change to handing over with the left hand too, to help connect the next shot.

All three routes reach the gatekeeper, but that does not make one envelope close-up reusable across them. The differences among Letters A, B and C still matter. The merge node should retain three incoming states.

One approach is to share the gatekeeper’s reaction shot looking up, while shooting three versions of the receiving close-up. The shared shot must truly avoid exposing the seal, contents or dialogue that contradicts a state. If tape appears even at the frame’s edge, the shot can no longer be labelled usable on all three routes.

Another approach removes the visual differences in the story. The gatekeeper might open all incoming letters and spread the sheet on the table. A shared shot of the unfolded letter becomes possible only after each entry has shown the appropriate action. Even when appearances merge, whether Lin Lan read the letter beforehand must remain separate; later dialogue cannot reset that knowledge.

If the seal is not part of the suspense, you can rework the handoff framing to show only the front. This reduces that shot’s visual requirements but does not turn Letter C back into Letter A in the reference table. A later back-view shot still needs the correct variant.

First, check for invalid changes. Follow each route from a shot’s exit state to the next shot’s incoming state. If “Letter C followed by Letter A” appears, ask what justifies the change. Without a story action replacing the envelope, correct the prop assignment or asset selection. Do not hide a visual error by editing the ledger.

Second, check whether the evidence is visible. Reseal 3 may record applying tape, but if the hand covers the entire action, viewers may not understand why tape appears in the next shot. A detail pickup can explain the action. Whether it is needed depends on whether viewers must know about this change at that moment.

Third, check revision impacts. Suppose Letter C’s tape changes from horizontal to diagonal. List all shots referencing that specification first, then mark each as keep, replace or reshoot. The unopened route need not be entirely redone merely because it uses the same letter, but adjoining Letter C close-ups must be compared again.

This ledger does not prove that viewers will understand or guarantee that generated or filmed assets meet the specification. It provides traceable grounds: which state should appear, what actually appeared and which shots are affected by a mismatch. Before handoff, check each of the three routes once so every object change has an origin and every shared asset has explicit conditions.