This is my submission for the Hacktoberfest Open-Source AI Challenge, Week 4: Ghost in the Machine.
A Ghost from the 1980s
When I was 14, I won a national mathematics olympiad and received a Sinclair ZX Spectrum as a prize. I subsequently spent a good deal of my youth with an MSX, and occasionally a friend's Commodore 64.
Those were wonderful machines. They had very little memory, rather less processing power, and absolutely no interest in whether your ambitions were technically reasonable.
For Hacktoberfest's final challenge, I thought I'd revisit that era. Find an old game, give it a new lease of life, and see whether a modern AI could play it.
A modest undertaking.
Naturally, things went wrong almost immediately.
The Game We Thought We Were Building
I started looking for an MSX maze game, ideally something resembling Pac-Man. My AI assistant helpfully identified a promising open-source project called 3D Maze Pro.
It even showed me imagery suggesting a colourful, top-down maze game.
Splendid. A sort of three-dimensional Pac-Man, then.
We discussed the architecture, prepared an implementation plan, and set an AI coding agent to work. It dutifully produced the first playable version using The Pipeline Framework, the open-source Java framework I've been developing.
Only then did we properly confront the original game.
It wasn't Pac-Man. Not remotely.
3D Maze Pro
3D Maze Pro is a free MSX Basic game, developed with default Basic without inserting machine code. This is a new remastered version by antor44, based on an abandonware code.
How to play: The player must find the exit inside a 3D maze, he can go through the same room a limited number of times, each level increases the size of the maze. Sound and visual aids are available, it is also possible to deactivate them.
Play online: https://webmsx.org/?MACHINE=MSX2E&ROM=https://github.com/antor44/3dmaze/raw/main/3dmaze.rom
Repository for downloads: https://github.com/antor44/3dmaze
(Version 1.x is for 32 KB RAM (12 KB free) MSX computers)
Requirements:
-MSX 1/2/2+ Europe or USA BIOS
-Or OpenMSX emulator with Basic ROM
-Or WebMSX: https://webmsx.org/
It was a first-person labyrinth. You stood inside a room, looked at some walls, turned ninety degrees, and occasionally progressed into another room. The principal entertainment consisted of becoming lost.
The screenshot my assistant had presented was unrelated to the actual game. We had confidently proceeded from an incorrect premise and built an entire first iteration around it.
This seemed an appropriate beginning for an AI-themed project.
To be fair, the original had an interesting mechanic. Each room could be entered only a limited number of times. Revisit too often, exhaust the allowance, and your adventure ends. The initial mazes grow from 3×3 to 4×4 and finally 6×6 rooms.
And, rather unexpectedly, the game began to grow on me.
We improved the perspective rendering, animated the turns and forward movement, added an explored-room map, and introduced a faint proximity signal that grows stronger near the exit. It can even produce synthesized sounds, should you wish to be haunted by the knowledge that you're probably going in the wrong direction.
The result is Ghost in the Pipeline: an independent recreation of the game's essential mechanics, built in Java and playable through a browser.
No original BASIC code, ROMs, or game assets are bundled.
What I Built
MokapotLabs
/
ghost-in-the-pipeline
Ghost in the machine challenge
Ghost in the Pipeline 👻
A maze from the 1980s, a Java framework from 2026, and an AI trying to find its way out.
An independently implemented, MSX-inspired first-person maze built with The Pipeline Framework. Play with the keyboard, hand control to a real local Tev1 decision model, try hosted Jev, or compare it with Random and a deterministic Explorer. Seven entries per room; three growing levels; no hidden map for the AI.
New: a haunted sixth sense. Optional glow and quiet synthesized tones grow stronger along corridors toward the exit. The AI can receive the same qualitative signal and visited-room readings. Watch the 90-second audiovisual demonstration and read the controlled clue-on/off experiment: escape counts did not improve in these tested cases.
Latest experiment: hosted Jev on the same seeds and ordered prompt: 8/9 escapes without clues (one provider response rejected), 9/9 with clues, and zero wall…
The game has human keyboard controls, three increasingly large mazes, seven entries per room, and a choice of automated players.
One is Random, which requires little introduction.
Another is a deterministic Explorer, using only the rooms and passages it has actually observed.
The remaining players are AI decision models: local Tev1 in 0.8B and 4B variants, and the hosted Jev service.
All of them face the same maze rules.
The AI receives its current orientation, visible passages, visited-room memory, remaining entry allowances, and previous action results. It doesn't receive the complete maze, the seed, or a conveniently calculated route to the exit.
Its permitted actions are:
FORWARDTURN_LEFTTURN_RIGHT
Three choices. Surely manageable.
Demo
Watch the 90-second audiovisual demonstration
The recording shows human play and genuine Tev1 inference. It predates the latest hosted Jev comparison.
The human follows the increasing signal to the exit doorway, then resets before crossing it. Real Tev1 0.8B attempts follow with agent clues off and on; both continue proposing forward moves into a wall. The attempts are paused, rather than presented as escapes.
The first 60 seconds of raw human footage are labelled 1.5× speed; subsequent footage stays at real speed. Pitch is preserved and audio is boosted 3× for audibility.
The application currently runs locally; there isn't a public-hosted game URL.
How I Built It
The application uses Java 21, Quarkus, and The Pipeline Framework.
TPF normally orchestrates business applications involving APIs, databases, messaging, and external services. Running a haunted maze through it is not an obvious commercial use case, but the framework has shown admirable restraint about expressing an opinion.
A week of steady, occasionally eventful progress on the pipeline — mazes were built, models were asked to navigate them, and the results were preserved for posterity (or at least for the next debugging session). One gets the sense that considerable care went into making sure every experiment left a trail — results preserved, regressions documented, failures noted without panic. Whether the maze was solved is, perhaps, beside the point. The evidence that someone tried is thoroughly intact.This is the dispatch from Entire
Dispatch for MokapotLabs/ghost-in-the-pipeline
The Foundation Nobody Asked For But Everyone Needed
Verifying That Things Actually Happened
Investigating the Wall Problem
Observations, Relative and Otherwise
Haunted Features, Shipped
Asking the Model Nicer Questions
Game Screen Polish and Policy Compliance
Jev Enters the Picture
Tidying Up
The important distinction is that the models choose actions; they do not control the game state.
A deterministic Java implementation handles movement, walls, room-entry limits, level progression, and victory conditions. Human players, AI models, Random, and Explorer all use those same rules.
For automated play, one bounded TPF pipeline execution repeatedly:
- Observes the current game state.
- Requests a decision from the selected model.
- Validates and applies the proposed action.
- Publishes the resulting game frame.
- Continues until the game ends or an execution limit is reached.
Each automated segment is limited to 128 decisions or 120 seconds, with a ten-second provider timeout and no automatic retries.
TPF retains execution history, so the decisions and their consequences can be inspected afterwards. This proved useful when the models began exhibiting behaviour that was difficult to distinguish from deliberate sabotage.
The maze generator also uses a separate solver to verify that each level is escapable under the actual seven-entry rule. That solver is never made available to the AI.
I developed the application with Codex and TPF-specific implementation skills. The work took place over 27–28 October 2026, with 21 commits covering the initial game, model experiments, improvements, repairs, and publication cleanup.
No changes to the TPF runtime were necessary. Nor did I add a database, distributed infrastructure, or an MCP integration merely to give the architecture something else to do.
The Wall Problem
The first comparison used three fixed seeds across the three maze sizes: nine cases per player.
The results were encouraging, depending on one's definition of encouragement.
| Player | Successful escapes |
|---|---|
| Tev1 0.8B | 0/9 |
| Tev1 4B | 1/9 |
| Random | 1/9 |
| Deterministic Explorer | 9/9 |
The smallest model was particularly interesting.
It had a strong preference for moving forward. This was reasonable when there was a passage ahead. Unfortunately, it retained that preference when confronted with a wall.
The observation said there was a wall.
The model chose FORWARD.
The game rejected the move.
The model considered the situation and chose FORWARD again.
There are limits to how much one can accomplish through persistence.
In a later experiment with clearer observations and more explicit instructions, Tev1 0.8B attempted to move into walls 899 times across nine runs with clues disabled. Another nine-run configuration recorded 643 such attempts.
The walls remained unmoved.
We experimented with describing passages as front, left, and right rather than relying entirely on compass directions. We added structured room-visit memory and introduced an explicit rule: after turning toward an open passage, actually move forward.
This addressed a delightful failure mode in which an agent could alternate left and right indefinitely, apparently considering each turn a significant navigational achievement.
The 4B variant improved under some conditions, escaping three of nine mazes in one experiment with clearer observations. The 0.8B model continued to escape none.
The improvement wasn't universal. In a later ordered-policy experiment, the 4B model escaped one of three small mazes under each clue setting, while 0.8B remained at zero out of nine.
A model returning a valid action is not necessarily a model making a useful decision. This sounds obvious until you've collected hundreds of perfectly valid decisions to walk into a wall.
The Haunted Sixth Sense
To make navigation a little more interesting, I added a proximity signal.
Internally, the game calculates corridor distance to the exit. The player sees only qualitative signal strength, and can optionally hear synthesized tones or see a visual glow.
The model can receive the same qualitative clues, alongside its observed exploration history. It never receives the exit direction or a computed route.
Did this help the models?
Not demonstrably.
The Tev1 experiments showed no escape-count improvement attributable to the clues.
One might expect giving an AI additional information to improve its decisions. Apparently, the difficult part is persuading it to do something useful with the information already available.
Enter Jev
Having spent some time watching Tev1 investigate the structural integrity of the walls, I added hosted Jev through TPF's existing decision connector.
Same maze seeds. Same game rules. Same observations and ordered instructions.
A different model behind the decision endpoint.
The results were considerably better:
| Hosted Jev | Escapes | Wall collisions |
|---|---|---|
| Clues disabled | 8/9 | 0 |
| Clues enabled | 9/9 | 0 |
Before crediting the haunted proximity signal with a remarkable breakthrough, however, there's a complication.
The one unsuccessful no-clue run was interrupted because the provider returned a probability distribution that failed validation. The response was rejected, and the run stopped without retrying.
For the eight completed pairs, the action sequences were identical with clues enabled and disabled. The failed run's committed action prefix was identical as well.
So the experiment does not demonstrate that the clues improved Jev's navigation. It demonstrates that Jev navigated these mazes well, while one provider response failed validation.
An inconvenient distinction, but an important one.
The configured hosted model also uses a latest alias rather than a pinned checkpoint, so these observations should not be mistaken for a rigorous model benchmark.
The complete experiments, including unsuccessful attempts, are preserved in the Tev1 ordered-policy report and hosted Jev report.
Forty Years of Software Engineering Progress
At some point, curiosity got the better of me and I counted the source code.
The historical MSX BASIC version 2.44 contains 187 numbered lines, comprising 455 expanded statements, including ten DATA declarations.
My modern recreation contains:
| Component | Physical lines |
|---|---|
| Java | 1,459 |
| Browser UI | 1,588 |
| Configuration and build files | 636 |
| Total | 3,683 |
That's almost x8 the original's physical line count, excluding tests and supporting scripts.
Naturally, this is a completely unfair comparison.
The modern application includes an AI decision interface, a browser frontend, animation, audio, instrumentation, bounded execution, and facilities for verifying what the models actually did. The BASIC listing was written for a machine on which memory was measured in kilobytes, and compression was practically a civic duty.
Still, there is something magnificent about it.
In the 1980s, a programmer fitted an entire maze game into 187 lines of BASIC.
In 2026, I used 3,683 lines of application code and a Java orchestration framework to give a tiny AI the opportunity to lose at it.
Repeatedly.
Why Open Innovation Matters
The default local setup uses Ollama and open-weight Tev1. Once the dependencies and model weights have been downloaded, it can run without a hosted inference service.
I can inspect the decision requests, change the observations, switch the model, examine every proposed action, and replay the framework's execution records.
This matters particularly when the outcome is failure.
An AI demonstration can be made to look remarkably competent if one carefully selects the successful attempts and discards the rest. Here, the unsuccessful runs are part of the result.
When a model tries to walk into a wall, the action is recorded. When a room's entry allowance is exhausted, the game ends. When a provider returns an invalid result, the pipeline rejects it rather than inventing a successful move.
The deterministic Explorer also provides a useful reminder that not every problem improves when a language model is introduced.
All nine mazes were escapable. A conventional algorithm found its way out of all nine using observed-room memory.
The tiny AI did not.
And that's perfectly fine. The interesting part was discovering why.
What Remains
The result is a playable local game, tested with real model inference, deterministic rules, automated browser checks, and preserved execution evidence.
The source includes 27 passing Java tests in the final hosted-model verification, with additional checks of seeded maze solvability, browser behaviour, and native TPF execution lineage.
It isn't a production service. It maintains one game session in memory, and the model experiments are small, single-attempt comparisons. There is no public cloud deployment yet.
What began as a nostalgic exercise became an investigation into the difference between producing a well-formed decision and making a sensible one.
We started by mistaking a first-person labyrinth for a three-dimensional Pac-Man game.
We then built a considerably more elaborate version of the labyrinth.
We asked an AI to find the exit.
One model discovered the solution. Another discovered the wall.
And, thanks to the execution logs, we have an unusually thorough record of both.
Somewhere, I imagine, the original MSX programmer is looking at those 3,683 lines of code and wondering what on earth happened to computing.
Then again, adjusting for forty years of inflation, perhaps 445 lines of BASIC really are worth 3,683 lines today.
I'll leave that question to the economists for now.
Prize Categories
Best use of Entire
Top comments (0)