Dread Engine: A Horror Game Where AI Can Haunt You, But Can't Rewrite Reality

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What if an AI could make you question everything you see in a horror game, without being allowed to change what is actually happening?

That question became the foundation of Dread Engine, an open-source, AI-powered, terminal-based horror adventure where reality and perception are deliberately separated.

Most AI-generated games have a fundamental problem: the language model is responsible for both storytelling and maintaining the game world. As a result, items can appear from nowhere, locked doors mysteriously become accessible, and characters can forget decisions made just a few turns earlier.

I wanted to approach this differently.

What if the game engine controlled the truth, while the AI controlled how the player experienced it?

That is the idea behind Dread Engine.

What I Built

Dread Engine is a local-first, single-player horror adventure powered by an open-weight language model and a deterministic Python game engine.

Players explore unsettling environments, uncover clues, solve puzzles, manage resources, and make decisions through natural-language commands.

Instead of selecting predefined dialogue options, you can describe what you want to do:

• Examine an unfamiliar object.
• Search a room for hidden clues.
• Pick up and use items.
• Move between connected locations.
• Investigate mysterious events.
• Make decisions that influence the story's ending.

The AI interprets your intentions and narrates the consequences, but it cannot independently modify the game's underlying state.

The most important design principle is simple: the AI narrates reality; it does not create reality.

An AI That Can Distort Your Perception

One of Dread Engine's central mechanics is psychological sanity.

The engine tracks three important player attributes:

• Health: The character's physical condition.
• Sanity: Their psychological stability and perception.
• Dread: The increasing pressure and tension of the environment.

As sanity changes, the narrator can alter how the same environment feels to the player.

A quiet corridor might initially seem ordinary. Later, the narrator might describe the uncomfortable feeling of being watched.

The crucial distinction is that the underlying environment remains controlled by the engine. The narrator can create uncertainty, but cannot invent a collectible object, introduce an inaccessible location, or silently change a puzzle's outcome.

This creates an interesting kind of horror: the player must distinguish between what is happening and what the character believes is happening.

Three Different Horror Experiences

Dread Engine's repository includes three scenario concepts designed around different interpretations of fear and mystery.

1. The Last Ofrenda — Remembrance, Loss, and Día de los Muertos

This is the featured scenario.

Set in an ancestral Mexican hacienda, the story takes inspiration from Día de los Muertos, emphasizing remembrance rather than portraying the departed as monsters.

The player must gather meaningful offerings, including a photograph, a candle, marigolds, traditional bread, and water, before speaking words of remembrance.

The experience is designed around memory, unfinished goodbyes, and the importance of preserving the stories of those who came before us.

I wanted this scenario to feel warm and melancholic rather than relying entirely on jump scares.

2. Signal Lost — Isolation and Psychological Horror

An Antarctic research station has lost contact with the outside world.

The player must investigate the station, restore critical systems, and understand mysterious signals emerging from beneath the ice.

Here, the horror comes from isolation, uncertainty, and the possibility that something is terribly wrong.

3. Night Shift — A Museum After Midnight

A night-shift worker becomes trapped inside a museum when its security systems malfunction.

As the building becomes increasingly unsettling, the player must investigate unusual events and find a way through the night.

This scenario focuses on environmental storytelling, exploration, and suspense.

Together, the three settings demonstrate how the same game engine can support different narrative styles without changing its fundamental rules.

Demo

Dread Engine runs inside a terminal-based interface, with a narrative display and a status panel showing the player's current condition.

A typical interaction begins with a player command such as:

> examine altar

The parser converts the request into a structured action. The rules engine checks the current location, available objects, and relevant conditions.

Only after the action has been resolved does the narrator generate its atmospheric description.

The interface is designed to display the current location, health, sanity, dread, and the evolving story.

Try the project locally:

git clone https://github.com/AntKss07/Dread-Engine-Game.git
cd Dread-Engine-Game
pip install -e .

With Ollama installed, download the project's configured model:

ollama pull qwen2.5:7b-instruct

Then start the game:

dread play

You can also explore the game using its mock model implementation:

dread play --mock

This mode is particularly useful for exploring the deterministic engine and testing without running a language model.

Code

Dread Engine is available on GitHub:

GitHub Repository: https://github.com/AntKss07/Dread-Engine-Game

The project is published under the MIT License.

The repository contains the game engine, AI integration, scenario definitions, configuration, tests, and documentation.

The project is intended to be accessible to developers who want to experiment with local AI storytelling or create additional scenarios.

How I Built It

Dread Engine combines Python, local language-model inference, structured action parsing, deterministic game rules, and narration validation.

The architecture separates the system into independent responsibilities.

1. Natural-Language Action Parser

The first challenge was turning unrestricted player input into actions the game could safely understand.

The parser receives the player's command together with relevant information about the current environment.

Using a locally running language model, it maps natural language into a structured action containing fields such as:

• Verb
• Target
• Instrument
• Confidence

For example, a request to pick up a candle can be interpreted as a TAKE action targeting the candle.

The parser is constrained to supported actions rather than being allowed to invent new game mechanics.

When an instruction is unclear, the system is designed to request clarification or use a deterministic fallback parser.

2. Deterministic Rules Engine

This is the foundation of the project.

The Python engine maintains the authoritative game state, including:

• Player location
• Inventory
• Health and sanity
• Dread levels
• Accessible locations
• Puzzle conditions
• Story events
• Ending conditions

The language model cannot directly change these values.

Even if the AI describes an impossible action, the engine's rules determine whether it can actually happen.

The engine also uses seeded randomness, allowing gameplay events and state transitions to be reproduced for debugging and testing.

3. Local AI Narrator

Once the engine resolves an action, it sends the resulting events to the narrator.

The narrator's responsibility is to transform those facts into immersive prose.

It is given only limited context, such as the current location, visible objects, permitted entities, recent narration, and relevant events.

This restricted approach reduces the risk of leaking future story information.

Different narration modes also support changes in psychological atmosphere as the player's sanity decreases.

The goal is to create a narrator that feels unpredictable without making the game itself unpredictable.

4. Hallucination Validator

This became one of the most interesting technical parts of the project.

Language models are excellent at inventing details. That is often helpful for creative writing, but it becomes a problem in a game with fixed rules.

Imagine a locked room with no visible key.

The AI might generate a dramatic description mentioning a rusty key lying nearby, even though no such object exists in the game state.

If the player tries to pick it up, the game becomes inconsistent.

Dread Engine addresses this by validating generated narration against the information the engine has authorized the narrator to use.

The validator is designed to detect:

• References to objects that should not yet be visible.
• Mentions of inaccessible locations or hidden entities.
• Inappropriate meta commentary.
• Responses that fail the expected narration constraints.

When validation fails, the narrator is given a corrective retry. If that attempt also fails, the system can use event-based fallback narration.

Instead of allowing the model to quietly corrupt the story, the system prioritizes consistency.

5. Replayability and Debugging

Dread Engine also includes a deterministic replay workflow.

A recorded session can preserve the random seed and sequence of player actions, allowing the rules engine to reconstruct and compare gameplay state.

The command interface documents replay functionality using:

dread replay saves/my_run.json

The project also provides a model-comparison script designed to evaluate different local models using consistent scripted interactions.

Its evaluation categories include parsing accuracy, narration rejection rates, response latency, and generation throughput.

These tools are important because they allow developers to evaluate actual model behavior instead of assuming that a larger model automatically produces a better game.

6. Technologies Used

The main technology choices include:

• Python: Deterministic game rules and application logic.
• Ollama: Local inference for open-weight language models.
• Qwen2.5: An example instruct model supported by the project configuration.
• Textual: Terminal user-interface framework.
• YAML: Scenario and configuration definitions.
• Pytest: Automated testing of game logic.
• Ruff: Python code linting and quality checks.

The architecture is designed to support experimentation with alternative local models while keeping the game's rules independent of the AI provider.

Why Does Open Innovation Matter?

For this project, open innovation is not simply a way to avoid API costs.

It is what makes the core design practical.

1. The game can run locally

After installing the required dependencies and downloading the model, the architecture does not require a hosted AI service for narration.

That makes offline play possible and reduces dependence on external infrastructure.

2. Player interactions can remain private

The game can process commands and generate narration on the player's own computer.

There is no inherent need to send player interactions to an external language-model API.

3. Models can be experimented with and replaced

Different open-weight models have different strengths.

Some may interpret actions more accurately, while others may produce more atmospheric writing or respond more quickly.

Local inference allows developers to compare these trade-offs and select models based on real performance.

4. Developers can inspect the entire gameplay pipeline

The parser, game engine, narrator, and validator are separate components.

That makes it possible to understand failures, improve prompts, modify the rules, and develop entirely new game scenarios.

5. The project can continue evolving without relying on a single provider

A game dependent on a proprietary hosted model is affected by that provider's pricing, availability, and API changes.

An open-source approach gives developers more control over how the project evolves.

There are trade-offs. Local models require computational resources, may respond slowly on weaker hardware, and can still produce incorrect outputs. Narration validation reduces certain classes of errors but cannot guarantee that every generated sentence is accurate.

Nevertheless, I believe local AI is particularly well suited to experimental games like this because developers can control both the underlying mechanics and the storytelling layer.

The Spirit of It

For me, the most interesting part of Ghost in the Machine is the relationship between artificial intelligence and perception.

Usually, hallucinations are something developers want to eliminate.

In Dread Engine, I explored a different question: Could the feeling of unreliable perception become a deliberate horror mechanic, while the software still maintains a consistent underlying world?

That idea shaped the entire architecture.

The player experiences the story through an AI narrator, but the rules engine maintains an independent record of what actually occurred.

It creates room for ambiguity, tension, and psychological storytelling without making progress entirely dependent on the model's imagination.

The Last Ofrenda adds another dimension to that idea.

Not every ghost story has to be about something malicious.

Sometimes, the most meaningful stories about the dead are really stories about the living: the things we remember, the traditions we preserve, and the words we never had the chance to say.

That is the direction I wanted the featured scenario to explore.

What I Learned

This project reinforced an important lesson about building applications with language models:

A language model does not need authority over an entire application to contribute something valuable.

By separating language understanding, deterministic rules, and narration, we can use AI for what it does well without giving it unrestricted control over critical application state.

There are still challenges to improve, particularly around ambiguous commands, narration consistency, local model performance, and the expressiveness of different scenarios.

But that is also what makes this project interesting to continue developing.

Dread Engine is an experiment in building AI experiences that are imaginative, locally controlled, and grounded in predictable software behavior.

The machine may tell you a ghost story. But the machine doesn't get to rewrite the truth.

---

Explore the project: https://github.com/AntKss07/Dread-Engine-Game

Built for the Hacktoberfest Open-Source AI Challenge 2026 — Week 4: Ghost in the Machine.