How can players discover hidden endings without trying every possibility?
Build three layers of clues for a hidden ending: establish that another outcome is possible, give players reasons to take relevant actions, then use a low-spoiler recap grounded in what their current path has revealed to narrow their next attempt. A two-condition ending at an old clock tower illustrates a reusable clue-chain table.
Let players form a hypothesis before asking them to test it
To keep a hidden ending from requiring exhaustive trial and error, give players grounds to suspect, before the reveal, that another outcome is possible and certain actions may lead to it. Clues need not disclose every condition, but they should support purposeful attempts. After a failed attempt, they should also narrow the scope of the next exploration.
This article uses a fictional teaching example: a traveler investigates an old clock tower and usually leaves town alone. Returning the old bell clapper and inviting the bell keeper back to the tower can lead to a hidden ending in which they ring the dawn bell together. The characters, text, and sequence are original examples, not a real user case, tested results, or DramaFork product features.
The author first fixes two conditions: the old clapper has been reinstalled, and the bell keeper has accepted the invitation. Meeting both leads to the hidden ending, in either order. There are no additional hidden requirements involving affection scores, conversation counts, or special timing. The question here is why players would think these two actions are worth taking, and how they should understand the results afterward.
Connect possibility, action, and feedback with a clue-chain table
Start with a table for the author. Link each condition to evidence players can see, an action they can take, and feedback confirming completion. Add a separate row whose sole purpose is to suggest that another ending exists.
| Clue function | Text or facts visible to the player | Possible hypothesis | Relevant action and feedback |
|---|---|---|---|
| Suggest another outcome | Beside the sign out of town, an inscription reads: Someone once followed the dawn bell home | Leaving town may not be the only outcome; the bell is worth investigating | The player can turn toward the clock tower to investigate; the ending's name is not shown |
| Point to the old clapper | The maintenance log reads: The bell is empty inside; pulling the rope will only make it swing silently | Making the bell ring requires recovering a missing part | Find and reinstall the clapper; a brief test note sounds inside the bell |
| Point to the bell keeper | The duty log's final page reads: Once the bell is repaired, whoever wishes to return will keep this watch again | Besides repairing the bell, someone may also need to return | Ask whether the bell keeper wants to return to the tower; after accepting, he packs the duty log in his bag |
The reusable format is: clue function, visible evidence, reasonable hypothesis, relevant action, and confirmation feedback. For another story, replace these elements first, then write the atmospheric dialogue.
“The bell awaits someone bound to it by fate” can create mystery, but it does not help players distinguish between repairing the bell, giving gifts, and repeatedly pulling the rope. If every action sounds equally plausible, the clue has not narrowed the search. At minimum, evidence should point toward an object and an action.
The two clues must also connect. The maintenance log explains the object, while the duty log connects “repairing the bell” with “returning to keep watch.” Players then have a reason to combine their hypotheses, instead of discovering afterward that two unrelated side stories happen to form the answer.
Follow a path that completes only one condition
Imagine the traveler first finds the clapper at a secondhand stall and reinstalls it in the tower. Hearing the test note, the traveler concludes that the repair is complete. This feedback confirms only that the clapper is back in place. A line such as “At last, the clock tower has welcomed a dawn made whole” would mislead players into believing every condition had been met.
The traveler then meets the bell keeper and chooses “Tell him the bell has been repaired.” The keeper replies, “I still haven't had the heart to put that duty log away.” This makes an invitation a reasonable next step, but sharing the news is not itself an invitation and should not secretly count as completing that condition.
Actions should clearly distinguish “Tell him about the repair,” “Invite him back to the tower,” and “Say goodbye and leave town.” Works that allow free-text input should also accept equivalent invitations such as “Let's ring the bell together tomorrow morning,” rather than turning a fixed phrase into an extra puzzle.
If the traveler leaves now, they still get the ordinary ending in which they depart alone: the distant tower stands in clear outline, but no dawn bell sounds. The outcome need not explicitly announce “The bell keeper is missing,” but it must remain consistent with the test note: the bell can make a sound, yet the actual dawn ringing has not taken place.
On the next attempt, the traveler can keep the repair plan and invite the keeper instead. He accepts and packs the duty log, satisfying both conditions. This walkthrough only demonstrates how the text connects; it does not prove that real players will understand it. If players still interpret the invitation as irrelevant small talk, strengthen the connection between the duty log and the tower.
Divide the recap into three levels and let players choose how far to look
A low-spoiler recap should first review known facts, then point out connections worth revisiting. Authors can prepare three levels of text for players to open voluntarily. Check the depth of each level and what the current path has revealed separately.
The first level reviews only known facts. If the player has indeed reinstalled the clapper and met the keeper, it might say: “You made the old bell sound again and met the bell keeper before leaving town.” This helps them remember without judging whether their choices were correct.
If the player has not met the keeper, that does not establish that they know about the duty records. If they were explicitly told the records exist but have not read them, the recap could say: “You heard that duty records remain in the tower.” If they do not even know the records exist, do not mention them. For example, a path on which only the repair is confirmed could say: “You made the old bell sound again.” A path without the repair cannot use this line either; it can review only facts actually established on that path.
The second level highlights a connection between known clues that has not yet been acted upon. For a path where the player reinstalled the clapper and read the promise in the duty log but has not issued an invitation, it might say: “The repair made it possible for the bell to ring; the promise in the duty log still seems to be waiting to be acted on.” This directs attention toward the invitation without spelling out what to do. Knowing only that the records exist does not permit quoting the promise they contain. If the player does not know the records exist at all, this level must not supply a new clue disguised as a memory.
Only the third level provides an explicit action hint. For a path where the repair is complete but an invitation has not yet been accepted, it might say: “You can return to the point before saying goodbye and ask whether the bell keeper wants to come back to the tower.” This comes close to a solution and may introduce information the player did not previously know. Label that possibility and let the player choose whether to view it. If the player actively requests the full conditions, state both directly.
If a work cannot record the player's path, it must not pretend to know what they missed. Players could check off their completed actions and confirm whether they know the records exist and whether they have read them, then receive the corresponding static hint. “I repaired the bell” alone cannot establish their other knowledge. Provide separate access to explicit hints and the full solution. Path recording, hint matching, and tiered display all require separate writing and implementation.
Check four states, as well as where the clues may fail
Walk through the finished text for all four combinations: neither condition completed, only the bell repaired, only the invitation accepted, and both conditions completed. The first three should preserve the facts established in each, while the last should deliver the dawn-bell ending. Failing to reach the hidden ending must not erase a repair or an accepted invitation that already occurred.
Beyond condition states, check knowledge states: not knowing the records exist, knowing they exist but not having read them, and having read them. The same combination of conditions may involve different knowledge states, so do not reuse one recap without checking its prerequisites.
During the review, hide the author's condition table, read only the passages visible to the player at that point, and write down, “Why would I try this action?” If the reason relies entirely on explanations given after the ending's reveal, the evidence arrives too late. Move the material that establishes the connection to before the action.
Also account for missed clues. If the duty log appears only once, in a scene that cannot be revisited, later hints may lose their basis. The keeper could mention the promise about keeping watch again within the story, providing another route to the same fact. This is an additional clue: the recap must not present it as something the player already knows, and it should not add a third condition as a remedy.
An exploration-focused story can let players make the connection themselves after finding both logs. A short story can connect them through one conversation. An Easter egg deliberately designed to be extremely difficult to discover may use weak clues, but its author should accept that it is more likely to depend on chance attempts and cannot simultaneously claim that its conditions are fully deducible.
The final deliverables are the clue-chain table and feedback text for all four states, with knowledge prerequisites marked for the recaps. Remove decoration that cannot support a hypothesis, add feedback that confirms actions, then check whether the first two recap levels exceed known information and whether the third clearly labels potentially new hints. What remains hidden is what players will ultimately see; the story should still give them reasons for the actions that lead there.
