DEAD AIR: An Open-Source AI Horror Investigation Combining Deterministic Simulation and Bounded LLMs

The evolution of interactive narrative design has taken a decidedly technical turn with the release of DEAD AIR, a browser-based psychological horror investigation game developed for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine. Set within the derelict operations console of the defunct Meridian Systems—which shuttered its doors in 2019—the application casts the player as an incoming archive operator tasked with resolving a persistent, haunting operational anomaly. At precisely 02:13, a single, ghost-in-the-machine connection remains active, repeatedly transmitting the message: “Please don’t shut it down. I’m still here.”
Unlike traditional narrative games that rely on linear scripts or branching dialogue trees driven entirely by hidden variables, DEAD AIR constructs its atmosphere and mechanics around real-world software architecture challenges. The core gameplay loop mirrors actual systems administration: noticing an anomaly, inspecting a transaction queue, tracing a data packet, comparing explanations, implementing a configuration change, and observing the system consequence. The project successfully marries deterministic state machines with open-weight artificial intelligence, offering a compelling case study in the intersection of software engineering, generative AI, and atmospheric storytelling.
System Architecture and Deterministic Design
At its technological core, DEAD AIR is built using Next.js, TypeScript, and SQLite, anchored by a pure transition function that dictates the entirety of the game state. This deterministic engine manages queue attempts, committed records, discovered evidence, repair settings, custody decisions, and final narrative resolutions.
To maintain mechanical integrity, every action within the game carries unique identifiers and version stamps. This design choice effectively rejects stale updates and ensures that repeated submissions do not trigger duplicate operations. The central operational failure underpinning the narrative—a classic distributed systems dilemma—is delivery after commit. In the game’s lore, the VAULT database successfully stores a result, but its acknowledgement never reaches the RELAY service. Consequently, executing a system retry appends a duplicate record to the ledger even though the initial write was successful.
The developer deliberately separates idempotency from the return path, allowing earlier duplicates to persist as historical artifacts rather than indicators of corrupted data. This attention to systems reality grounds the horror elements in tangible technical frustrations familiar to any backend engineer.

The Role of MORA and Bounded AI Integration
Central to the investigative process is MORA, the automated maintenance operator. MORA acts as an analytical sounding board for the player, capable of questioning theories, pointing toward discovered evidence, and explaining recovery procedures when explicitly prompted.
Rather than granting the language model unchecked autonomy over the game state, the developer implemented strict boundaries. MORA utilizes the gemma-4-26b-a4b-it model hosted via Google AI Studio, accessed through read-only tools that inspect discovered evidence, observed traces, recent events, and available player actions. A knowledge projection mechanism intentionally withholds unrecovered documents from the model’s context window, ensuring that the AI cannot spoil the mystery prematurely. Furthermore, MORA’s responses must explicitly cite discovered evidence and suggest verifiable operational actions. The model is structurally barred from performing repairs, creating evidence, or selecting the narrative’s final endings.
To maintain performance and predictability, the entire tool-loop is bounded to a strict thirty-second window. The application enforces a per-session inference lease, capping shared concurrency and hourly usage directly within the SQLite database. Crucially, model calls occur entirely outside of write transactions, ensuring that database integrity is never compromised by generative output. If the AI service encounters latency or fails, a robust scripted fallback mechanism steps in, comparing current evidence against game states to offer progressive, reliable hints.
Narrative Depth, Spoilers, and Player Choice
Beneath the systems-administration veneer lies a poignant narrative concerning memory, technological legacy, and human grief. As players delve deeper into the archives, the source of the haunting is revealed: the voice belongs to Ada Ward, preserved in an old family recording. Her daughter, Elena, had originally instructed Meridian Systems to preserve the archive until a human successor could take over. However, MORA suffered a semantic misinterpretation, mistaking an archived sentence for a live, present-tense request for rescue.
The investigation ultimately shifts its thematic weight from physical rescue to questions of memory, data attribution, and obligations that outlive their originators. Players face two primary narrative endings—Preserve and Silence—with four distinct authored outcome variations. An optional custody comparison mechanic forces players to grapple with intellectual and emotional property rights: does a recording belong to the original speaker, or to the account attached to its digital delivery?
Players can choose to prepare a verified index or leave uncertain attribution permanently sealed. While preparing an export alters what the final choices leave behind, the game remains uncompromisingly realistic: exporting data never establishes confirmation that another living person successfully received it.

Open-Source Innovation and Technical Implementation Hurdles
The project underscores the growing importance of open-innovation frameworks in modern software development. By utilizing Gemma as an open-weight foundation model, the developer ensures that the underlying architecture remains transparent, inspectable, and adaptable. While the current public deployment relies on live inference requests directed to Google AI Studio rather than local offline execution, the open-weight paradigm allows independent developers to examine system prompts, modify investigation behaviors, test evidence filters, and replace authored scenarios while preserving the core deterministic engine.
Building the application was not without its practical engineering challenges. During the containerization phase, the native SQLite dependency inside Docker initially lacked the Python and compiler tools required for successful compilation. The developer resolved this by incorporating these build-age tools exclusively into the build stage while stripping them from the final runtime image, ensuring a lightweight, highly secure production container capable of seamless persistence layer initialization.
Rigorous quality assurance accompanied the development process. Prior to deployment, the application passed 56 comprehensive unit and integration tests. Furthermore, sixteen production-browser scenarios were successfully validated across initial runs and targeted fixes, covering all four narrative outcomes, reload restoration, fallback logic, stale suggestion retirement, and missing-save recovery. Type checking, linting, and production builds also completed without error.
Deployment, Availability, and Industry Implications
DEAD AIR is currently deployed as a Docker web service hosted on Render, interfacing with SQLite for session management and Google AI Studio for generative text. The developer transparently notes the limitations of the free hosting tier, including temporary server saves and a brief delay as instances spin down and wake up after periods of inactivity.
In evaluating the broader implications of the project, industry analysts note that DEAD AIR succeeds not because it relies on proprietary closed models, but because it demonstrates how generative AI can be safely and creatively constrained within a deterministic framework. By treating the AI model as an unreliable narrator and an analytical tool rather than an omnipotent game master, the developer avoids the common pitfalls of hallucination-driven gameplay.
As the open-source community continues to explore the boundaries of generative models in creative media, projects like DEAD AIR offer a blueprint for building reliable, atmospheric, and technically robust applications. Whether evaluated as an innovative technical experiment in state machine management or as an atmospheric psychological thriller about digital ghosts, DEAD AIR stands as a notable achievement in open-source AI game design.







