The first description of Haunted Blueprint already had a memorable screen: a building seen only as a floor plan that could change while the player was inside it. I still asked where the horror was. If a blueprint merely hid rooms, the concept risked becoming a puzzle with spooky graphics. I pushed sound to the center, so the player would hear what the plan could not safely show.
That changed how the rules fitted together. A door could vanish from the document, an annotation could become suspicious, and an unseen movement could force the player to decide whether the floor plan was lying. Godot implementation reports followed the design work, but I also called out gaps in movement and assets. The project history here is the search for a playable fear loop, along with the unfinished production work that would have to support it.
The player is inside the plan
The player is trapped in the building, not observing it safely from an office. Moving room to room means committing their body to a place represented by incomplete data. The proposed loop was to read the blueprint, interpret a threat, choose a route, annotate hazards, respond to corruption, and try to reach the exit.
The assistant’s revised premise made the map hostile in specific ways. A room marked safe could become occupied. A door could remain on the drawing after disappearing from the route. Notes could be erased or rewritten. A second occupant marker could appear in the player’s current room.
One proposed log sequence shows the tone:
PLAYER MARKED ROOM 204 UNSAFE
ROOM 204 REMOVED FROM PLAN
ROOM 204 NOW ADJACENT TO PLAYERThe design rule was that corruption should remain interpretable. If everything became arbitrary, there would be nothing for the player to reason about.
Sound as the missing view
I wanted sound to do a large part of the work because there would be no conventional view down a corridor. The proposed layers included building ambience, tactile interface sounds, directional cues, entity sounds, false cues, and deliberate silence.
| Layer | Examples from the design |
|---|---|
| Building | HVAC, fluorescent hum, pipe creaks, elevator machinery |
| Interface | Pencil scratches, paper movement, stamps, scanner beeps |
| Threat | Latches, footsteps, breathing, scratching, whispered room numbers |
| Contradiction | Knocking from a room the plan labels empty |
Listening before moving was a proposed action. Sensors could add information but could also be wrong, displaced, or destroyed. The intended tension came from a progression of quiet, a small sound, doubt, contradiction, and panic—not a constant stream of jump scares.
A compact but expressive ruleset
The draft GDD proposed room knowledge states such as unknown, known, recently verified, corrupted, unsafe, and detected entity activity. Doors could be open, closed, locked, fake, removed, or entity-controlled. Annotation tools included a pencil, danger marker, circle, sensor, warning stamp, and eraser.
The wider level ideas used the language of drawings: duplicate rooms, bad revisions, broken matchlines, field verification, and an “As-Built” finale. Narrative would arrive through logs, revision notes, emergency notices, metadata, and redlined comments.
For the first prototype, the scope was one floor, one entity, one corruption mechanic, one escape objective, and a win and fail state. A ten-minute experience would be enough to test whether uncertainty felt frightening rather than merely confusing.
The implementation was less tidy
The Godot work produced concrete errors. One pasted run could not resolve custom types including BlueprintUI, RoomGraph, and FogOfWar. A later report showed foundation and project-structure messages after a fix removing unresolved custom type hints from stubs. Another run failed because the requested movement-validation script was missing.
When the discussion moved from a phase-six approval toward testing, I pointed out that assets had not been covered. That is a practical gap in a game whose readability depends on distinguishing rooms, doors, threat states, annotations, and corruption.
I had the central view and the reason it could frighten someone: sound and movement could disagree with the plan in the player’s hands. The reported Godot work still had movement and asset gaps. Those gaps mattered because the horror only works when the player can act on what they think the building is doing.