Writing the AI Out of Barbarian Prince
I took a week off from Hexcrawl to go visit the game that started all of this, and I came back with a very specific lesson about where AI does and does not belong in a game. Short version: I set out to have an LLM run a board game for me, and I ended up writing enough code that the LLM had almost nothing left to do.
What Barbarian Prince Is
Barbarian Prince is a solitaire board game from 1981, designed by Arnold Hendrick and published by Dwarfstar Games. You play Cal Arath, whose father has been murdered and whose throne has been taken, and you have 10 weeks to obtain 500 gold pieces to raise an army and take back your kingdom.
Mechanically it is a hex crawl in the most literal sense. You move one hex a day on foot, two mounted, three by raft. Every hex you enter, you roll on a travel table for that terrain, and the table sends you to a numbered section in a 48-page event book. That section is a paragraph of prose, some choices, and often another die roll that sends you somewhere else. Two hundred and fifty-odd sections, cross-referenced into each other like a choose-your-own-adventure that also has to track your food, your wounds, your hired followers, equipment carried, etc.
Hendrick, incidentally, went on to MicroProse, where he has credits on Gunship, F-19 Stealth Fighter and Sid Meier’s Pirates!, and where he designed Darklands — the 1992 open-world RPG that Todd Howard has publicly credited as a major influence on The Elder Scrolls. Barbarian Prince definitely strikes me as one of those games that would have clearly been a video game if only it was created 5-10 years later.
BoardGameGeek has, at various points, called it the hardest solo game ever made. It won the Charles S. Roberts award for best fantasy boardgame of 1981. It kills you constantly, and the deaths are interesting, because they come out of a procedurally assembled sequence of events rather than out of a designed difficulty curve. It can feel pretty random and unforgiving, much like life itself I suppose. But the emergent story is often delightful, and the gambler instinct in my can’t resist trying just one more time to beat the thing (I have yet to ever do so).
It is also free. Reaper Miniatures owns it now, and they permit the whole thing — rules, events, travel tables, the map — to be downloaded and distributed at no charge. Not public domain, but free, which is a distinction I’ll come back to.
My History With It
I found Barbarian Prince in 2011 and it ate several months of my life. I wrote about it then — I printed the rulebooks as stapled booklets, mounted the four map sheets on poster board with sticker paper, and hunted down a 10mm Pendraken barbarian miniature that fit the hexes. I played it on my lunch break off a magnetic whiteboard. I did not win.
To speed up play, so I could try to win more frequently, I started writing some code. First I wrote a post about river crossings, where the rules genuinely contradict themselves about whether you check for a travel event after getting lost at a river, and I drew a flowchart to settle it for myself. Then there was a little Java tool to work out the odds on the opening fight with the royal guardsmen, which turned into a combat simulator I ran alongside the physical game, which turned into a whole mobile game — Road of Kings. And unsurprisingly, Road of Kings is the direct ancestor of Hexcrawl.
While I was building Road of Kings I got in touch with Arnold Hendrick himself. He was generous and encouraging to a stranger building a mobile game out of his thirty-year-old board game, which is not a given, and I’ve never forgotten it. Unfortunately he passed away in May of 2020.
I always assumed there’d be time to ask him the real questions. Not the licensing ones — the design ones. Was he happy with the balance and the reputation as one of the hardest solo games ever? And what on earth was going on with the river crossings? What would he think of my inclination to eliminate the whole “you crossed the river but you’re stuck in the original hex” concept? Sadly I never got to ask any of these questions.
This past Sunday I streamed a session of it on the Wandering DMs channel, which is what kicked all of this off again.
This Time, With an LLM
Prepping for the stream, I found myself yet again writing code for this game. But this time I had a different idea. The event book is a giant cross-referenced text corpus. Modern LLMs are supposedly excellent at navigating that. So: could I point Claude Code at it and get an AI to referee the game for me? Read me the sections, chase the cross-references, and maybe even read the text aloud to me while I move the token, make choices, and roll the dice.
That started as a couple of prompts. Then a couple of scripts. Then, somehow, a fairly complete simulator with a PDF extraction pipeline, a hand-audited map transcription, a full character sheet, and a combat engine.
It doesn’t work.
The Same Wall I Hit With Martha
Years ago on Wandering DMs I ran a series called Martha the AI Dungeon Master, trying to get an LLM to run classic D&D. I hit a wall there, and I walked straight back into the same wall here.
The model is genuinely good at cross-referencing the text and looking up a rule. What it will not reliably do is think to do so. Asked to resolve a situation, it very often just decides what happens, fluently and confidently, instead of going and reading what the book says happens. Sometimes it even hallucinates mechanics. It more than once tried to tell me to “Make an Endurance Check” – what is that? There’s no such mechanic in this game!
So I did what you do: I moved that decision into code. And then the next one. Travel became a hardcoded sequence of checks, because the order lives in prose spread across three rule sections and reassembling it is exactly where wrong rulings come from. Band sizes got rolled once by the engine and filed against the day and hex they were rolled for, so the number can’t drift. The tables got parsed into machine-readable data so the model would never have to read one aloud. Every number moved out of the model’s head and into a JSON save file.
At some point I stepped back and looked at what I’d built, and the realization was pretty stark: if I keep going down this road, I will write the AI out of the project entirely.
Because I nearly had. The design I ended up with is one routing table where the program, not the model, decides what goes to the screen, to the speaker, and to the model. The engine prints the booklet’s prose; the model never carries it. And the reason that works is precisely that it can’t fail — as I ended up writing in the README, because the model never carries the booklet’s text, it cannot fail to deliver it.
That’s not an AI game. That’s a chatbot with a rules engine behind it and an LLM sitting on top reading someone else’s words.
So What’s the Point?
Here’s the uncomfortable conclusion, and I want to state it plainly because I think it’s the most useful thing to come out of the week: AI is not good at rules automation. Deterministic procedures with a fixed order, arithmetic that has to be right, state that has to persist across an hour of play — that is what code is for, and code is better at it in every measurable way, including cost.
And when the content is all pre-written — when there are 181 event sections sitting there that just need to be delivered accurately — what is the LLM actually adding? Nothing that a print statement doesn’t do more reliably. If I wanted a good digital Barbarian Prince, the honest answer is that I should write a plain scripted chatbot with no AI in it at all, and it would be better. For the stream, I just reverted to a notepad and a pencil.
The Two Things That Were Actually Worth It
I don’t want to oversell the negative, because two pieces of this genuinely delighted me and both of them are instructive.
Text to speech. I wired up Kokoro running locally — an 82M-parameter model on my own machine, no API, no per-token cost — and had it read the event sections aloud. Playing a solo game can feel a bit isloating, and just having another voice narrate some of the content to you really improves the experience. Something about hearing “you sight a band of goblins in the distance” instead of reading it changes the register of the whole thing. And it’s local and free, which is the direction I want all of this to go anyway.
The auto-battler. Combat in this game does not have a lot of decision making and can turn into a grind - twenty minutes of dice rolling, math, and table look ups that is slow and not very entertaining. So I wrote fight auto, which rolls the entire combat, round by round, both sides, faithfully to the rules, and emits a complete log: every attack roll, every damage roll, every rout check, each one annotated with the rule that produced it. It resolves in a fraction of a second.
And then I hand that log to the LLM and ask it to tell me what happened.
That is the whole thing, right there. The dice, the arithmetic, and the rules were settled deterministically before the model ever saw them. The model’s job was to take a page of correct numbers and make it read like a fight. It cannot get the outcome wrong, because the outcome already happened. It can only make it vivid.
Back to Hexcrawl
Which is, of course, exactly the vision I wrote down for Hexcrawl before any of this: AI should expound, not invent. I went off and spent a week accidentally proving my own thesis on somebody else’s game. The engine owns the mechanics; the model works in the margins, taking hand-authored or deterministically-generated material and making it feel alive. Everywhere I violated that in the Barbarian Prince work, I got the Glimmerwings all over again. Everywhere I respected it — the combat summary especially — it was great.
It was a fun detour, and it was good to sit with the original inspiration again with fifteen more years of experience. The map’s still on the poster board. I may tinker with it some more to play some more games, but the lesson is banked and Hexcrawl deserves my energy again.
Back to work.