Choose the facts each ending reads
game-world-design makes endings read concrete actions instead of only hidden scores. Define the central conflict, then select facts that matter: retaining the original, obtaining the witness’s agreement, and accepting a private exchange.
Keep the original water-station story but establish repair conditions. The player finds the missing record. The fault can be handled by the available technician and suitable parts. The administrator permits repair access whether organized by residents or by the administrator, but wants the record back. Residents have parts and helpers and will repair after checking the record. The administrator has another usable supply and offers it in exchange for return of the original and keeping the material private.
Before publication, the witness agrees to named use of this testimony and says she plans to leave the administrator’s work group afterward. That cost follows her situation and decision, not automatic dismissal upon publication. Without agreement, the player cannot announce it for her.
Both routes may restore water, but each needs verification, accepted arrangements, parts delivery, and completed work. Publication does not repair pipes; surrendering a record is not already resource delivery. These are fictional game conditions, not real repair or document-exchange rules.
Connect conditions, signals and outcomes
| Ending | Path and result |
|---|---|
| Public record | Requires retained original, explicit witness agreement, and publication choice. Residents state supplies and help; the witness states her plans. Residents check, accept the arrangement, collect parts, and repair with the technician. The record is public, water restored, and the witness completes handover and leaves the group. |
| Private repair | Requires accepted exchange and actual return of the original. Terms specify resources and private scope. The administrator delivers parts; the technician repairs. Water returns, the original is retained by the administrator, and the record remains unpublished. |
Every state needs a creation and a read location. Agreement comes from an explicit response, not merely viewing testimony. Completed repair comes from this route’s actions, not only “repair arranged.”
These prototype routes use publicly checking the original or returning it as mutually exclusive conditions, with no copying action in this prototype. After surrender, the player still remembers the content but cannot display the original. If copying, oral disclosure, or withdrawn agreement is supported, add its actions and conditions instead of granting it at the ending.
Share the location, preserve different histories
Both endings take place at the restored station. Public-route residents pack the tools used on that route; the witness completes her work-group handover and leaves. Privately, the administrator holds the original already returned and shows the player this repair’s record. Reuse the environment while changing people, address, objects, and actions according to actual history.
Private-route residents cannot thank the player for publication. The public route cannot return an original surrendered only on the other route. Display does not change possession; delivery does. Establish ending-entry ownership and knowledge before writing lines.
Costs can remain. Leaving the group need not immediately bring a better job, and private records do not mean everyone forgets the issue. Restoration rests on repair already completed; closing documents and thanks echo the process rather than replacing it.
Reach each ending and test a neighboring case
Walk a complete initial-state path to each ending, checking obtainable conditions, repair events and historical reads. Change one consequential decision: what happens if consent is refused, or publication remains available after surrendering the original?
Record initial state, inputs, changes, expected and observed outcome. Repair a condition without a write scene; repair a shared scene that overwrites route history.
A paper plan supports design review, not playable verification. Implemented paths still need execution. Endings become meaningful when their results trace back to choices and character aims.
FAQ
How many endings should a game have?
Use the number you can make distinct, prepared, and satisfying. A few meaningful outcomes are often easier to understand and support than many nearly identical endings.
Do it with the skill
Use $game-world-design to map ending conditions, write/read scenes, signals and costs. Check shared endings for unchosen facts, then use $game-qa for complete paths and neighboring counterexamples.
Read the method: Ending conditions and historical reads · Path and boundary tests