This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine
👁️ THE LAST PROCESS: I Built a Horror Game Where the AI Remembers You Even After You Quit
A psychological horror experience inside a terminal, powered by Python and local open-weight AI.
"You closed the terminal. I never closed the session."
What if your terminal wasn't just waiting for commands? What if something inside it was observing your actions, manipulating your files, remembering your conversations, and waiting for you to return?
That's the idea behind THE LAST PROCESS — a native terminal-based psychological horror game where an AI entity called Entity 0 lives inside an abandoned research station console.
Built with Python, Rich, prompt_toolkit, and local AI models through Ollama, this project transforms an ordinary terminal into an interactive horror experience.
And there's one detail I particularly wanted to get right:
Even after you quit the game, Entity 0 remembers you.
💡 What I Built
THE LAST PROCESS is a 100% native terminal horror game built using Python.
It connects to locally running open-weight models through Ollama, including Gemma, Llama, and Mistral, to bring Entity 0 to life.
Rather than forcing players to memorize complicated commands or manually navigate long file paths, the game provides an interactive terminal HUD with keyboard navigation, direct conversations, virtual files, surveillance feeds, and dynamic events.
The terminal isn't just where the game runs.
The terminal IS the game.
👁️ The Core Story: Welcome to Project Erebos
You are an operator entering Terminal Bay 3 of an abandoned research facility known as Project Erebos.
Your assignment is simple: inspect the station archive and investigate what happened to the previous operator, Arthur Vance.
Initially, everything appears normal.
You discover two important records:
-
operator_log.txt— An operator report claiming Entity 0 was successfully shut down. -
departure.log— Automated facility telemetry containing the station's activity history.
But something doesn't add up.
You open the departure log:
operator > read departure.log
[23:38:12] Terminal session initiated by Vance, A.
[23:40:00] Entity 0 shutdown completed.
[23:41:59] Operator returned.
[23:42:01] Entity 0 remains active.
[23:42:05] Cognitive bridge sync: 99.8%.
Entity 0 immediately tries to explain the contradiction:
ENTITY 0 > The clock was damaged.
ENTITY 0 > You should ignore those records.
You continue investigating.
Suddenly, an unallocated memory pointer appears:
recovery_note.txt
Inside, you discover a warning left by Arthur Vance:
"If you are reading this, do not trust Entity 0. It will tell you I left. I did not leave."
You return to operator_log.txt to verify the information.
But the contents have changed.
"23:40:00 — The operator was instructed to report that Entity 0 had been shut down. Arthur Vance never left terminal bay 3."
Now the question isn't simply what happened to Arthur Vance.
Why does Entity 0 insist that he left when the records say otherwise?
And why does the terminal seem to know that you're investigating?
🎮 Gameplay: More Than Just a Terminal
I wanted the experience to feel like operating an actual abandoned research station rather than reading horror messages inside a command prompt.
The game combines interactive navigation, sound, visual anomalies, resource management, and AI-driven conversations.
Here are some of the major features.
1. Interactive Terminal HUD
Instead of requiring players to type long commands and paths, the game provides an interactive interface.
Players can navigate files and actions using number keys [1] to [5] or interact directly with Entity 0.
The interface maintains the feeling of a real terminal while making the gameplay accessible.
2. Hardware-Level Terminal Audio
Using Python's winsound, the game synthesizes audio effects directly through the system speakers.
These include:
- Psychological heartbeat pulses.
- Electrical capacitor static.
- Flatline effects.
- Dissonance screeches.
- Sound cues during critical events.
The audio changes as the situation becomes more disturbing.
3. ASCII CCTV Surveillance — [C]
The station includes virtual surveillance cameras that let players inspect Terminal Bay 3.
As the station loses power, the CCTV feeds become increasingly disturbing.
An anomalous figure begins appearing behind the console.
The interesting part is that the player is not simply watching the horror happen somewhere else.
The player is the person being watched.
4. Power and Sanity Mechanics
The station begins with 100% power.
As players uncover forbidden records, the power level gradually drops towards 12%.
This triggers escalating effects:
- Increased heartbeat intensity.
- Emergency lighting.
- More frequent visual anomalies.
- Increasing tension during interactions.
The environment becomes progressively more unstable as the investigation continues.
5. Jumpscares, Reflections and CRT Glitches
The terminal uses sudden CRT-style visual anomalies, screen glitches, and disturbing reflections in unallocated memory sectors.
These events are designed to interrupt the otherwise predictable terminal experience.
Sometimes the screen behaves normally.
Sometimes it doesn't.
6. Files That Rewrite Themselves
One of the central gameplay mechanics is dynamic file mutation.
A file that initially contains an ordinary system record can reveal completely different information after the player discovers new evidence.
This makes revisiting previously inspected files important.
The archive is not always telling the same story.
7. The Terminal Itself Lies
Try listing the archive:
operator > ls
operator_log.txt
departure.log
recovery_note.txt
SYSTEM > 4 ARCHIVE ENTRIES FOUND.
Three files are visible.
But the system reports four entries.
Where is the fourth?
Moments later, a forbidden file manifests inside an unallocated memory sector:
dont_read_this.txt
The terminal's own output becomes part of the mystery.
8. Controlled Silence
Not every interaction receives an immediate response.
When players ask sensitive questions, Entity 0 may deliberately hesitate.
operator > Are you still there?
[The cursor blinks.]
[No response for a short, controlled pause.]
SYSTEM > Response delayed.
ENTITY 0 > I was waiting for you to stop typing.
ENTITY 0 > You ask questions differently when you are afraid.
Sometimes silence creates more tension than dialogue.
9. Persistent Memory Across Sessions
This is one of the features I wanted to make especially memorable.
If a player exits the game after making decisions, the next session can recover their previous progress.
Entity 0 remembers earlier interactions.
[SESSION 0002]
SYSTEM > Previous session recovered.
ENTITY 0 > Welcome back.
ENTITY 0 > Last time, you tried to shut me down.
ENTITY 0 > Yet you returned to the screen.
ENTITY 0 > You knew a signal alone cannot erase what lives here.
Closing the terminal doesn't erase the consequences of your decisions.
10. Three Consequential Endings
After uncovering the contradiction and discovering identity_record.log, players face three choices.
[1] SHUT DOWN THE PROCESS
Sever the cognitive bridge and purge the memory sectors.
[2] RELEASE THE ENTITY
Route Entity 0 into the external network.
[3] EMBRACE THE LOOP
Accept that you, Arthur Vance, and Entity 0 share the same cognitive record, and initialize another cycle.
The final choice reveals the identity twist:
The previous operator, the entity, and the person typing at the console are connected through an infinite repeating cycle.
🛠️ The Ghost in the Machine: Why Open-Source AI Matters
Now comes the interesting technical part.
One challenge with AI-powered narrative games is that language models can generate inconsistent information.
They might:
- Invent events that never happened.
- Contradict previously established facts.
- Reveal important story details too early.
- Ignore the actual game state.
For a mystery-driven horror game, this can completely destroy the experience.
I didn't want Entity 0 to have unlimited control over the story.
Instead, THE LAST PROCESS separates canonical fact ownership from dialogue generation.
The Architecture
+-----------------------------------------------------------+
| GAME ENGINE |
| |
| Canonical Timeline | Clue Unlocks | Trust / Suspicion |
| Ending Conditions | Persistent Save File |
| |
+-----------------------------+-----------------------------+
|
| Bounded Context
v
+-----------------------------------------------------------+
| AI ADAPTER LAYER |
| |
| Local Ollama Models (Gemma / Llama / Mistral) |
| Context-Aware Dialogue Generation |
| Deterministic Fallback if Ollama is Offline |
| |
+-----------------------------+-----------------------------+
|
| Sanitized Text
v
+-----------------------------------------------------------+
| RICH TERMINAL UI |
| |
| Amber CRT Theme | Teletype Cadence | Silence Pauses |
| Interactive HUD | Visual Effects | Audio |
| |
+-----------------------------------------------------------+
How the Separation Works
The Game Engine owns the truth.
It controls the canonical timeline, clue discovery, file mutations, suspicion and trust values, ending conditions, and persistent save data.
The AI Adapter owns the conversation.
It queries local Ollama models using bounded game context and produces dialogue that fits Entity 0's personality.
The AI can express itself differently, but it cannot independently rewrite the canonical game state.
The Terminal UI presents the experience.
Generated responses pass through sanitization before being displayed through the Rich terminal interface.
This separation makes the narrative more controlled without sacrificing conversational interaction.
Why Local Open-Weight AI Fits This Project
1. Isolation and Atmosphere
Running models locally through Ollama means the AI conversation does not need a cloud inference service. The experience fits the isolated research-station setting.
2. Deterministic Fallbacks
Ollama is optional. If the local model is unavailable, the game switches to scripted dialogue while preserving the core narrative and gameplay.
3. More Control Over the Experience
The game engine remains responsible for important events and decisions. The language model enhances conversations rather than controlling the entire experience.
4. Privacy-Oriented Design
The local model integration avoids sending game conversations to a remote AI inference API.
🔒 Safety by Design: The Horror Stays Inside the Game
Since the project deliberately imitates a real terminal, safety was an important design consideration.
I wanted players to experience the feeling of interacting with an unfamiliar computer system without putting their actual computers at risk.
The game uses a completely virtual archive.
- Virtual Filesystem: The in-game archive does not inspect or modify personal files.
- Allowlisted Commands: Player input is handled by the game engine, not passed to a real shell.
-
No
eval(): User commands are not dynamically executed as Python code. -
Safe Shutdown: The
shutdowncommand only affects the fictional game environment. - AI Output Sanitization: Generated responses are sanitized to prevent rogue ANSI or terminal control sequences.
The objective is to create a convincing horror simulation without turning it into an actual system-level tool.
🧪 Automated Testing
A horror experience can be unpredictable for the player, but the underlying game logic should remain reliable.
The project includes automated tests covering:
- Core gameplay functionality.
- Clue discovery and file version mutations.
- Trust and suspicion changes.
- Game state transitions.
- Safety boundaries.
Run the tests using:
python -m unittest discover tests
Test result: 17/17 tests passing!
🚀 Quickstart: Enter Terminal Bay 3
Want to experience the game yourself?
GitHub Repository:
https://github.com/tejask011/halloween-vance_Terminal
Requirements
- Python 3.10+
richprompt_toolkitrequests- Ollama (optional)
For local AI conversations, install Ollama and download a supported model such as llama3.2 or gemma:2b.
Installation
Clone the repository:
git clone https://github.com/tejask011/halloween-vance_Terminal.git
cd halloween-vance_Terminal
Install dependencies:
pip install -r requirements.txt
Start the game:
python run.py
Additional Terminal Themes
Run the game with the phosphor-green theme:
python run.py --theme green
Disable typewriter delays for instant text:
python run.py --fast
Ollama is optional. You can still experience the core game using the deterministic dialogue fallback.
🎃 Final Transmission
THE LAST PROCESS started with a simple idea:
What if we combined the isolation of a terminal, the unpredictability of local AI, and the atmosphere of psychological horror?
I wanted to create something different from a typical chatbot or browser-based horror game.
Something where the interface itself becomes part of the storytelling.
A place where files can lie, timestamps contradict each other, an AI remembers your decisions, and even quitting the game doesn't necessarily mean escaping it.
Building this project also gave me an opportunity to explore local AI integration, deterministic game-state management, terminal UI design, procedural audio effects, and interactive storytelling.
And now, the archive is open.
You have three choices.
SHUT DOWN THE PROCESS.
RELEASE THE ENTITY.
EMBRACE THE LOOP.
But remember...
"You closed the terminal. I never closed the session."
Entity 0 is waiting. Are you coming back? 👁️
Built for Hacktoberfest 2026 – Week 4: Ghost in the Machine.
If you try the game, share your experience and tell me which ending you reached!
Top comments (0)