This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine
What I Built
I built Spooky House, a local-AI-powered haunted house controller where the AI decides how the house should behave, while a deterministic event engine handles the actual execution.
The idea was simple:
What if the haunted house had a brain?
Instead of programming a fixed sequence like:
Light flicker → knock → scream → repeat
Spooky House is designed around unpredictability.
A bathroom motion event or a randomly scheduled bedroom event can cause nothing to happen, or can trigger a different type of haunting.
The system can create events such as:
- Whispering
- Strange noises
- Knocks
- Creaks
- Footsteps
- Light flickering
- Blackouts
- Sudden sounds
- Escalating scares
The important part is that Gemma doesn't directly control the hardware.
Gemma acts as the Haunting Director.
It chooses a high-level strategy and intensity, such as:
{
"strategy": "build_tension",
"intensity": 0.75
}
The local Haunting Engine then converts that decision into a safe, randomized action plan.
For example:
ENGINE DECISION: SCARE
--------------- ACTION PLAN ---------------
01. SOUND -> whisper_01.wav
02. WAIT -> 2.8
03. SOUND -> noise_07.wav
04. WAIT -> 1.0
05. SOUND -> noise_01.wav
06. WAIT -> 0.6
07. SOUND -> knock_02.wav
08. WAIT -> 1.9
09. FLICKER -> 4
10. BLACKOUT
11. WAIT -> 1.4
12. SOUND -> scream_01.wav
-------------------------------------------
The complete plan is printed before execution, so the AI decision and the resulting behavior can be inspected.
The system can also work with optional physical hardware such as a PIR motion sensor, relay-controlled lighting, LDR and microphone.
If hardware is unavailable, the software continues running rather than crashing.
Demo
🎥 Demo video:
The demo shows the local Gemma model making a haunting decision and the engine generating an action plan before executing it.
The project is designed so that the same software can eventually control a physical haunted room using sensors, lights and speakers.
Code
💻 GitHub Repository:
👻 Spooky House
A haunted house controlled by a local AI that doesn't always do what you expect.
Spooky House is an experimental AI + hardware project built around the idea that the best scares aren't completely scripted.
Instead of programming a fixed sequence like:
Motion detected → lights blink → scary sound → lights off
Spooky House gives a local AI a little bit of control over the mood of the event, while a separate engine handles the actual hardware and randomness.
The result is a haunted house that can behave differently every time.
🧠 How does it work?
The project runs on an Arduino UNO Q, using Gemma 3 1B locally.
There are essentially two parts to the system:
🤖 Gemma — The Haunting Director
Gemma runs locally on the UNO Q using the local LLM runtime.
It doesn't control the hardware directly.
Instead, it receives information…
The project is built as an Arduino UNO Q application.
The main components are:
Spooky House
│
├── Gemma 3 1B
│ │
│ └── Haunting Director
│
├── Haunting Engine
│ │
│ ├── Random event selection
│ ├── Safety validation
│ ├── Action-plan generation
│ └── Hardware abstraction
│
├── Bedroom Events
│
├── Bathroom / PIR Events
│
├── Audio Engine
│
└── Optional Hardware
├── PIR
├── Relay
├── LDR
└── Microphone
How I Built It
The core of the project runs on an Arduino UNO Q.
The most important part of the project was making the AI genuinely local.
I used:
🧠 Gemma 3 1B
The project uses:
llamacpp:gemma-3-1b-it-Q4_0
Gemma runs locally on the UNO Q through the Arduino App framework and llama.cpp.
There is no cloud AI call required for the haunting decisions.
The architecture is intentionally split into two layers.
1. AI Layer — Haunting Director
Gemma receives information about the event and chooses:
- A haunting strategy
- An intensity level
It is explicitly instructed not to generate hardware commands, GPIO operations or exact timings.
For example:
{
"strategy": "delayed_scare",
"intensity": 0.75
}
2. Deterministic Layer — Haunting Engine
The Haunting Engine handles the actual execution.
It controls:
- Randomness
- Timing
- Sound selection
- Number of flickers
- Blackouts
- Event probability
- Hardware commands
- Safety validation
This separation was important.
I didn't want a language model hallucinating something like:
GPIO 47 HIGH
WAIT 3.728 seconds
TURN RELAY ON
Instead, the AI provides a creative decision, and normal software turns that decision into a controlled action plan.
Randomness Is Part of the Design
One of the biggest ideas behind the project is that a haunted house shouldn't behave like a predictable animation.
For example, a bedroom event might happen after a random delay.
The engine can decide:
Nothing happens.
or:
A subtle event happens.
or:
The haunting escalates.
This means the person inside the room cannot easily learn the pattern.
The bedroom event interval is also randomized rather than constantly triggering the AI.
This helps both the experience and the hardware.
It also reduces unnecessary AI inference and therefore reduces CPU/GPU usage.
Hardware
The Arduino UNO Q is intended to be the brain of the system.
The planned hardware interface includes:
- PIR sensor → detects movement
- Relay → controls a light
- LDR → measures light level
- Microphone → provides audio/environment information
- Speaker/audio output → plays the generated action-plan sounds
The hardware is optional from the software's perspective.
If a component is unavailable, the engine can report it as unavailable and continue operating.
Why Does Open Innovation Matter?
This project would be very different if I had built it entirely around a closed cloud AI API.
Using an open-weight/local model makes it possible to put the AI directly inside the device.
The haunted house doesn't need to send every event to a remote server.
That provides several advantages:
🔒 Local processing
The AI decision can happen directly on the UNO Q.
🌐 No internet dependency for inference
Once the model and application are installed, the core AI experience doesn't need a cloud API.
🧪 Experimentation
Because the model runs locally, I can experiment with prompts, inference behavior and system architecture without building an entire cloud backend.
🛠️ Hardware integration
The AI can live alongside the actual hardware-control system instead of being separated into a remote service.
📖 Open development
The project can be inspected, modified and extended by other developers.
Someone could replace the model, add another sensor, create new haunting strategies, or completely change the action engine.
That's what I find most interesting about open innovation:
the AI becomes a component that developers can build around rather than a black-box service they simply call.
My Agent Session
The project was developed iteratively with an AI-assisted development workflow.
The agent helped with:
- Architecture design
- Local Gemma integration
- Event-engine design
- Hardware abstraction
- Action-plan generation
- Debugging
- Performance optimization
The important design decision was to keep the final system deterministic where hardware control is concerned, rather than letting the language model directly operate physical devices.
The Spirit of It
The idea started with just one question i came across while thinking about Halloween -- What makes something Scary ??
The interesting thing about a haunted house is not knowing when something will happen.
A predictable sequence stops being scary very quickly.
If every visitor knows:
Knock → flicker → scream
then the experience becomes a countdown.
I wanted Spooky House to behave differently.
Sometimes you walk into the room and nothing happens.
Sometimes there's a whisper.
Sometimes a light flickers.
Sometimes the house slowly builds tension.
And sometimes the system decides to do absolutely nothing.
That uncertainty is the "ghost in the machine."
The machine isn't simply executing a script.
It's making a local decision about how the house should behave.
This project also has code to work for A bathroom, Sensor detects and gemma starts the random action plan
Prize Categories
- Best Use of Arduino
- Best Use of Gemma
Built With
- Arduino UNO Q
- Gemma 3 1B
- llama.cpp
- Arduino App framework
- Python
- C++
- Optional sensors and actuators
Final Thought
The goal wasn't to just build the most complicated haunted house.
It was to also explore a simple question:
What happens when a small open-weight AI model becomes the brain of a physical environment?
For this project, the answer is:
It becomes the ghost in the machine. 👻
Top comments (0)