Why Separate Author Solutions, Player Content, and Production Notes into Three Layers?

When puzzle solutions and player hints are mixed together, separate them by purpose into three layers: author solutions, player content, and production notes. Specify the recipients and delivery scope for each layer. The aim is to give the person handling publication exactly what can be published, without making them guess which sentences to remove at the last minute.

Author solutions explain why a puzzle works; player content provides the clues and feedback currently visible to the player; production notes explain how that text is incorporated into the work. All three can refer to the same node ID, but they should not be delivered together by default. In particular, an “internal” label is only a reminder: it cannot stop someone who has the complete document from copying, forwarding, or exporting it.

The example below uses The Empty Station Locker. This is a fictional teaching example, not a real user case or a tested result, and it does not represent any product features. The document separation, handoff, and checking procedures described here are all manual working methods.

In this scenario, the player must open a locker with a three-digit code. There are three train tickets dated June 12, 13, and 14, with train numbers ending in four, seven, and two respectively. The locker door is engraved with “Follow the dates, earliest to latest. Take only the last digit of each train number.” The intended solution is 472.

A mixed draft might read: “The locker door is engraved with ‘Follow the dates, earliest to latest. Take only the last digit of each train number.’ Entering 472 correctly opens the door; an incorrect entry leaves it closed. Do not crop the dates off the tickets here.” This passage combines a visible clue, the correct solution, interaction rules, and visual requirements. Copying the entire passage, or relying on memory to remove parenthetical material, can easily leave content that should not appear.

Once separated, the author solutions should record the reasoning: sort the tickets by date, then take the last digit of each train number to get 472. They should also state that all three tickets have different dates, ensuring a unique order. Player content should retain only the door inscription, the complete faces of all three tickets, and feedback such as “The locker door opened” and “The locker door is still closed.” Production notes should specify: keep the input field at three digits; route a correct answer to the door-opening passage and keep an incorrect answer in the current scene; ensure that ticket dates and train numbers are legible.

The easiest item to misclassify here is “route a correct answer to the door-opening passage.” Although it contains no solution, it is still a production instruction and should not appear as narration. Conversely, although the numbers on the tickets relate to solving the puzzle, they are evidence the player must receive. They cannot all be removed out of fear of spoilers.

Create a handoff card for each puzzle, linking the three layers with a shared ID. The card itself is an internal index and is not published with player content. It records file locations and who may receive each layer; there is no need to copy the solution into it again.

The card should also include the node ID, versions of all three layers, each layer’s owner, recipients, delivery checklist, publication destination, and unresolved issues. Blank fields must not be interpreted as “handle however you like.” For example, if the publication destination is undecided, you cannot yet determine which text will appear before the player.

For this example, the card could read: node “Locker 01”; all three layers at version two; publication destination: locker scene; player-content delivery checklist: door inscription, all three ticket faces, input instructions, and two feedback messages; unresolved issues: none. The author owns the solution, the editor owns player content, and the implementer owns production notes. Each confirms the corresponding version before handoff.

There is no need to limit each person to receiving just one layer. If the person implementing input validation does need 472, list that node’s correct code as an additional deliverable; they may not need the complete truth behind every other puzzle. The person drawing the tickets needs complete dates and train numbers, but may not need an explanation of the ending. Scope should follow the task rather than a rigid division by job title.

First, label each sentence by purpose, then split mixed sentences into separate entries. Do not simply move whole paragraphs: “After the correct entry of 472, display ‘The locker door opened’” must be split into an input-validation condition and display text. Otherwise, the solution remains bundled with player content.

Next, number the entries. In this example, the door inscription is Player Content 1, the three ticket faces are Player Content 2–4, and success and failure feedback are Player Content 5 and 6. Production notes reference these IDs and specify when each entry appears. References reduce repeated copying; they do not imply that any tool will automatically keep the content synchronized.

Then prepare delivery copies according to each recipient’s task. Publishing staff receive Player Content 1–6 and input instructions; visual production staff receive ticket content and legibility requirements; the person implementing input validation receives this node’s solution, feedback IDs, and transition requirements. You can retain an internal master draft, but “find the parts you need yourself” is no substitute for a handoff.

Finally, handle revisions. Suppose the last digit on the second ticket changes from seven to eight: the solution must then change to 482. Those responsible need to cross-check the ticket, author solution, and input-validation notes, and reconfirm the versions. Replacing only the image without updating input validation will give players incorrect feedback despite their following the correct clues. Separating the layers reduces mixing but adds work to keep related content consistent. Someone must take responsibility for that work.

Before publication, open the copies prepared for delivery and check them item by item, rather than looking only at the neatly organized master draft.

• Compare them against the delivery checklist to confirm there are no solution pages, internal indexes, or extra attachments.
• Check titles, filenames, comments, tracked changes, and link destinations to rule out solutions leaking from outside the player content itself.
• Search for internal wording such as “correct answer,” “input validation,” and “needs revision,” then judge each sentence by its purpose. Finding none of these terms does not prove that nothing has leaked.
• Read everything in the order the player encounters it. Confirm that all three tickets and the door inscription remain present, and that feedback appears only under the agreed conditions.

In this example, four, seven, and two appearing on the respective tickets are necessary clues. “Enter 472” appearing beside the locker door, however, performs the deduction for the player. The check must therefore consider how information is combined, where it appears, and under what conditions. It cannot treat every number related to the solution as a forbidden term.

A small solo project can retain three clearly marked sections in a master draft, but should still generate delivery copies containing only the required content. When multiple people revise the work continually, three separate documents plus a handoff card can be used. Collapsed paragraphs, hidden columns, and text colors help organize documents for reading; they should not be treated as recipient access controls.

If the work includes an explanation after completion, author solutions still cannot be published unchanged. They may contain discarded ideas and production instructions, so a separate player-facing explanation that reviews the puzzle needs to be written. The three layers address information ownership and delivery scope in collaboration. How much a hint should reveal and whether a puzzle is fair still require separate judgments.