HeroQuest

The Question

HeroQuest was my favourite game as a child. The 1989 one — the plastic furniture, the quest book, one player behind the screen as Zargon and everyone else around the board. Plenty of digital adaptations of board games exist, and most of them make the same trade: they take the rules and quietly discard the table. The camera goes free, the dice become a number in a log, and what you end up with is a small video game wearing a board game's licence.

I wondered whether I could go the other way. Keep the board, the visible dice, the cards, the turn order — everything that makes it legible as a game happening on a table — and rebuild the table itself in 3D. Not HeroQuest-inspired. The original board, the original quests, the original dice.

The Problem

The practical problem is the obvious one: the physical game needs four or five people in the same room for an evening, which is a resource I had considerably more of in 1992.

The interesting problem is fidelity. HeroQuest's character lives in specific mechanical details. The combat die is not a d6 with numbers on it; it has three skull faces, two white shields and one black shield, and heroes defend on white while monsters defend on black — which is the entire balance of the game hiding in the print on a die. The board is 26 by 19 squares with letter-and-number coordinates. Opening a door reveals a room and everything in it at once. If a digital version gets these details approximately right, it is not the same game, and anyone who played the original will feel it even if they cannot name it.

The other half of the problem was assets. A faithful recreation needs four heroes, a bestiary of monsters, doors, furniture, and the table itself, in 3D. I am one person and I am not a 3D modeller.

The Hypothesis

Two bets, really.

The first was that if I encoded the rules as a pure, deterministic engine — no rendering, no Unity scene, just actions going in and events coming out — then the 3D tabletop becomes a presentation layer over a board game rather than the game itself. Fidelity would live in tested code, and everything visual could be wrong, ugly or missing without the game being wrong.

The second was that AI-generated 3D assets could make the modelling problem tractable for one person. I used Meshy to generate the heroes, monsters and props from prompts, on the theory that a board game viewed from above is forgiving of imperfect models in a way a first-person game is not.

The Approach

The rules engine came first and stayed first. Every player intention — move, attack, open door, search, cast spell, end turn — is a typed action that goes through validation and then application, and application emits events. The UI, the animations, the log and the network layer all subscribe to those events; none of them are allowed to change game state. The dice roller takes a seed, so a test can replay an exact sequence of rolls, and the die faces are the real distribution: three skulls, two white shields, one black.

The board is the physical board. Coordinates are letter-and-number, matching the notation in the original quest book, so transcribing a quest is a copying job rather than a translation job. Rooms only connect to the corridor through doors, movement is orthogonal, and opening a door reveals the room the way lifting the Zargon screen never quite managed to.

Content is data rather than code: the board layout and the quests are JSON, and heroes, monsters, cards and spells are ScriptableObjects. About fourteen quests from the original book are transcribed. Somewhere along the way I built a quest editor with drag-and-drop and undo/redo, which was a detour by any measure, but transcribing quest three by hand in a text editor is the sort of experience that makes you build tools.

The 3D layer came last, and it is deliberately a table. The models include the dungeon furniture but also the table the board sits on, the floor the table stands on, and a Zargon screen — because the thing being recreated is not a dungeon, it is the experience of a dungeon on a table.

Architecture

The project is organised as separable engines, and the separation is real rather than aspirational — each one has its own folder, its own tests and a documented contract.

1. Rules engine. Validates and applies every action, host-authoritative in multiplayer. The only code allowed to mutate game state.
2. Turn engine. Hero phase, monster phase, end of round. Fixed hero order, as per the original rules.
3. Board engine. A sparse dictionary of tiles over the 26×19 grid, A* pathfinding, line of sight and fog of war.
4. Combat and dice. Seedable rolls, skulls against shields, with the presentation choreographed by a separate state machine so the maths never waits for an animation.
5. Controllers. An abstraction over who is playing: human, AI, hybrid or remote, for both the heroes and Zargon. Solo play, co-op and an AI overlord are configurations rather than separate modes.
6. Persistence, networking and tools. Save/load, campaign progress, a lobby-and-relay multiplayer layer that reuses the same action pipeline, and the quest editor.

The rendering is genuinely dual: the same game state can draw as a flat 2D board or as the 3D table, which fell out of building the rules first and turned out to be the most useful debugging tool in the project.

Trade-offs

• Rules first versus looking like a game early. For months the game was coloured primitives sliding around a grid, and parts of it still are — there is a factory whose entire job is producing placeholder capsules for monsters without models. The trade paid for itself in the test suite: the fiddly rules (line of sight through doorways, trap reveals, treasure deck composition) are covered by unit tests that never open a scene.
• AI-generated assets versus commissioning or learning to model. Meshy got me a full cast — four heroes, orcs, goblins, skeletons, zombies, mummies, a gargoyle — for the cost of prompting and patience. What it did not get me is consistency. Every model arrived at its own idea of scale and orientation, and the clean-up work is real. It moved the effort; it did not remove it.
• Faithful rules versus quality-of-life. I chose the classic rules with no redesign, deferring house rules and variants. This is the right first move for a fidelity project and it means some genuinely dated mechanics are reproduced with loving accuracy.
• The quest editor versus more game. Building an editor with undo/redo for a game with fourteen quests is hard to defend on arithmetic. I defend it on morale: the editor made content a thing I could touch, and the project has outlived several of my others partly because adding a quest is pleasant.

What Went Wrong

Every Meshy model is its own universe. The models arrive at wildly inconsistent scales — the furniture renderer has an inspector header that reads "Meshy models are often tiny - use large values like 100-500", which is the sound of a lesson being learned and then written down where I would see it next time. Orientation, pivot points and rig naming all needed per-model fixing, and there is a setup guide in the repository that exists purely because I kept re-deriving the same import steps. The asset folders also contain wizzard and wepons_rack, misspellings I have chosen to keep as an honest record of how iteratively that pipeline was thrown together.

The documentation describes a project slightly better than this one. The README says the project targets Unity 2023; it runs on Unity 6, and there is a separate upgrade-notes file that knows this. The README also marks three development phases as complete, which is true of the engines and untrue of the experience — "complete" phases coexist with cube furniture and silent audio. I have seen this failure in my own projects before: the documentation records the moment of intention, and nothing forces it to record the erosion.

Zargon is not clever. The AI overlord moves each monster towards the nearest hero and attacks when adjacent. That is the whole strategy. The real game's tension comes from a human Zargon holding monsters back, blocking corridors and spending the dread the players build up for themselves — none of which a nearest-hero-and-swing policy can produce. The plans folder contains notes on hallway-blocking and focus-fire behaviour, which is to say the problem is understood and unstarted.

The polish phase keeps not arriving. Camera follow was stubbed out, the audio mixer sliders are wired to a TODO, and combat is still missing small planned touches. The engine-first approach has a shadow side: the satisfying work of making rules pass tests crowds out the unglamorous work of making the game feel finished, because there is always one more rule.

Lessons

• Encoding rules as a pure engine with an event stream is the single decision everything good in this project traces back to. Tests, the dual renderer and multiplayer all fell out of it at a fraction of their usual cost.
• AI asset generation changes the shape of the work rather than the amount. I spent no hours modelling and many hours importing, scaling and rigging. For a solo project that is still an excellent trade — the hours I spent were ones I was capable of.
• Fidelity lives in small numbers. Three skulls, two white shields, one black; 26 by 19; letter-and-number coordinates. Getting those exactly right did more for the feel of the thing than any model.
• A README is a claim about the present written in the past. Mine drifted within months, and the fix is either ruthless maintenance or writing less that can go stale.
• Build the content tool early if content is the point. The quest editor was a detour that became the reason adding content stays fun.

Current State

Work in progress, honestly. The repository holds 120 commits between November 2025 and July 2026, and the core loop is playable end to end: pick a party, load a quest from the original book, move, open doors, fight with the real dice, search for treasure and traps, cast spells, finish the quest, visit the shop, carry the campaign forward. The 3D table works, with Meshy-generated heroes and monsters standing on it.

Around that core, the edges are visibly unfinished. Some furniture is coloured boxes, audio is unwired, Zargon plays like a toddler with a grudge, and the multiplayer layer is plumbed through but barely lived in. The engines have a solid unit test suite; the experience has not had its polish pass.

The repository is private. I do not own HeroQuest, and a faithful recreation of someone else's game is a thing I am comfortable building for my own table and not comfortable distributing.

Next Questions

• What does a good digital Zargon actually do? Blocking corridors and focusing fire is the mechanical answer; the interesting question is whether an AI overlord can pace a dungeon the way a human does, holding back the reveal until it hurts.
• Do the placeholder assets need replacing, or embracing? A deliberately stylised set of pieces might be more honest than AI-generated models that are each 80% right in different directions.
• Is the multiplayer layer real? It reuses the validated action pipeline, which should make it robust, but "should" is a hypothesis and I have not tested it against actual latency and actual disagreement.
• What does finished mean here? My current answer is all fourteen transcribed quests playable end to end with sound and finished furniture — a definition chosen because it is checkable, which is a property my definitions of done have historically lacked.