A visual novel can contain five ending labels and still leave an important question unanswered: can a player reach each one through the intended clues and choices? In Room 404, the source includes both a branching story and a flowchart that tracks five ending keys. Those are useful pieces of the experience, but they prove different things.

Room 404 is a private Ren’Py narrative-game prototype. I reviewed the evidence modal, climax choices, ending labels and flowchart source. I have not verified a clean launch or completed every route, so this article describes the implementation structure rather than claiming that all branches have passed a playthrough.

ROOM 404 / NARRATIVE STATE
SOURCE REVIEW / NO PLAYTHROUGH

01 / EVIDENCE CONFRONTATION

  1. INPUTUnlocked clueclue.unlockedThe modal lists evidence already collected.
  2. CHECKRequired clueactive_required_clueThe selected clue ID is compared with the active target.
  3. BRANCHStory label
    MATCH successOTHER fail

02 / ENDING MENU → COMPLETION FLAGS

CLIMAXFive player choicesEach menu option jumps to an ending label.
SELECTED ROUTEOne ending labelunlock_ending_record(key)
VISIBLE STATEBoolean flagThe flowchart marks the recorded key.
  • 01 Accomplice ending_accomplice
  • 02 Blackmailer ending_blackmailer
  • 03 Whistleblower ending_whistleblower
  • 04 404 Phantom ending_phantom
  • 05 Clean Slate ending_clean_slate
RECORDS

A selected ending label called the function that marks its key.

DOES NOT PROVE

That every clue gate and ending route is reachable in a clean playthrough.

The diagram separates clue branching from the ending progress display. It describes reviewed source structure; it is not a capture of a completed playthrough.

Separate the clue gate from the ending record

The investigation screen presents the player with unlocked clues. When a confrontation starts, the script stores a required clue and the labels to jump to on success or failure. Choosing a clue compares its ID with that active requirement. A match follows the success path; another unlocked clue follows the failure path.

That is a clear, inspectable rule for one interaction. It also gives a tester a concrete pair of cases: present the required clue, then present a different clue and confirm that the two paths diverge as intended. The source describes those branches, but that alone does not show that the player can collect each required clue in the right sequence during a clean playthrough.

Five labels become five booleans

At the climax, the player sees five choices. Each choice jumps to its own ending label. Those labels call a shared function with a key such as ending_accomplice or ending_clean_slate. The function marks that key in an unlocked_endings dictionary, and the flowchart reads those values to show which endings have been recorded.

This division is useful: the story labels own the narrative outcome, while the flowchart presents progress. It also sets a precise limit on what that display can say. A marked flag shows that the corresponding code path reached its recording call. It does not establish that the path is reachable from a fresh game, that its clue prerequisites are correct, or that a full playthrough reaches the expected ending without a softlock.

The distinction matters because a progress screen can look authoritative. Five visible ending names make a strong promise to a player, but the state variables are only one part of that promise. Route reachability depends on the transitions that lead to them; the flag does not exercise those transitions by itself.

What the current checks cover

The repository’s CI workflow checks that the project structure is present. It does not launch Ren’Py, compile the story, or play through narrative paths. The project identifies Ren’Py 8.5.3 in its configuration, but a version string and a list of ending labels are not a clean-run result. The repository also states that a complete playthrough of every branch has not been independently verified.

I would keep those boundaries visible in the portfolio. The source review supports claims about the clue modal, the five choices and the ending flags. It does not support claims that all endings are reachable, that every choice has been tested, or that the save and load behavior preserves route progress correctly.

Turn the flowchart into a test plan

The next useful step is a route matrix, not another layer of UI. For each ending, record the starting state, clues that must be available, choices made, expected story label and expected ending key. Then test the evidence modal separately with one correct and one incorrect clue.

After a clean launch from source, I would verify that each planned route reaches its ending, that the expected key is marked, and that the flowchart reflects that state. I would also check the intended save and load behavior once the baseline paths work. Until those checks are automated or recorded as a reproducible manual run, the map should remain a progress display rather than a completion certificate.

The source repository is private, and this page does not reproduce its code or claim a completed playthrough. The diagram above is a source-based explanation of the boundaries that still need runtime evidence.

← All notes