Boardroom: Building a Meaningful Game with AI

by William

How Boardroom — a Reigns-style swipe-card game about the impossible balancing act of corporate leadership — was built end-to-end with AI as the builder and a human as the director.

Project: Boardroom — a Reigns-style swipe-card game about the impossible balancing act of corporate leadership Repo: https://github.com/PlayableStories/boardroom-game Status: Playable prototype shipped, forking system in place, reference prompt validated on real AI builders

TL;DR

I set out to test a specific question: can a genuinely meaningful game — one with a point of view, not just a tech demo — be built end-to-end with AI as the builder and a human as the director, even without a programming background? The answer so far is yes, and the more interesting result is how. The value didn't come from the AI writing code fast. It came from a disciplined loop where I framed the thing, the AI proposed, I decided, and we shipped in small reviewable pieces — with playtesting, not coding, as the human's real job. Boardroom is real and playable, but it's also meant as an example: proof that this is possible, shared openly so others can learn from it, fork it, and build their own.

1. What the game is

Boardroom is a swipe-card game in the tradition of Reigns. You play the CEO. Advisors walk in with a dilemma — a harassment complaint, a leak, a board pressure, a quarterly earnings call — and you swipe left or right to commit to one of two responses. Every choice nudges four resource meters:

  • 💰 Shareholders — investor confidence
  • 🏢 Management — executive cohesion
  • 😊 Staff — employee morale
  • 🌍 Public Image — reputation in the world

All four start at 50, and both extremes are fatal: drive any meter to 0 or 100 and the run ends with one of eight named failures (Hostile Takeover, Board Coup, Great Resignation, PR Collapse, and so on). Survive the whole deck and you earn a ninth ending — "Out of Crises." A run takes 5–10 minutes, on desktop or mobile.

What makes it meaningful rather than a toy is the design intent: it's dark satire about leadership being an impossible balancing act. The decisions feel reasonable in the moment — a quiet settlement here, a performance bonus there — and then a "bomb" card you planted ten swipes ago detonates and collapses the empire you thought you were managing well. The aim is to make the player feel clever, then guilty, then doomed. The card arcs draw on recognizable real-world scandal patterns (bro culture, fake-it-til-you-make-it valuations, safety shortcuts, the cult of growth) without ever naming a real company, and the characters are archetypes — The Chair, The HR Director, The Journalist, The CFO, The Whistleblower — rather than real people.

Under the hood, the deck mixes four card types — base character cards, delayed bomb cards, chain follow-ups, and quarterly interrupts every fourth turn — and a draw-priority system lets bombs and chains override the deck, giving the game memory.

2. How AI is used

AI did the actual building. Every part of the game — the logic, the look, the way a card responds to a swipe — was written and refined by an AI coding agent rather than by a developer. But the real story isn't "AI wrote it." It's the back-and-forth that kept the AI on track instead of letting it run off in its own direction.

We worked in small, deliberate stages. The AI built one piece, stopped, told me what it had done, and waited for me to say "carry on" before starting the next. Nothing happened in one big invisible leap, which meant I could catch a wrong turn after ten minutes instead of discovering it a day later.

The most telling moment came from a check the AI had built into the game to quietly scan the cards for inconsistencies. It found one straight away: a card was set up to trigger a delayed consequence pointing at another card that didn't actually exist. Rather than guess or ignore it, the AI flagged the gap and asked me how I wanted to handle it — write the missing card, or remove the link? We wrote it together, on the spot. That was the pattern throughout: the AI surfaces something, lays out the options, and I make the call.

So the AI generates and checks the work; I steer, decide, and approve. Neither of us is doing the other's job.

3. How the human framed the game and gave feedback

This is the part I think actually matters, because it's the transferable bit.

Start from a brief, not from a chat. Boardroom existed on paper before it existed in any editor — a design spec covering the concept, mechanics, four meters, schema, and visual direction, plus a card deck with real prose for an early prototype. Because the brief was specific, the AI could plan the build instead of inventing what the game should be. Before any code, I had the AI read the documents and produce a written implementation plan.

Resolve ambiguity early, with multiple choice. That plan surfaced four open questions the spec hadn't settled — e.g. does "left" mean yes or no (we added an explicit direction field so each card self-describes), public vs private repo, org name, build order. Rather than let the AI guess, each was a two-minute pick. Locking genuinely open questions before code lands is the cheapest design conversation you can have.

Two workflow rules, set in the first hour and held all the way through:

  • Phased work, explicit stops. Do a phase, stop, report, wait. This caught direction drift before it could accumulate. I saved this as a standing preference so future sessions inherit it.
  • Branch per task; the PR closes the task. No direct commits to main. Every meaningful change had a review surface, and main stayed merge-ready the whole time.

Playtesting matters as much as the brief. A spec can describe a game, but it can't predict how it feels to play — and that's true whether a game is built by a studio, a single developer, or with AI. The roles of game designer and playtester don't disappear when an AI does the building; if anything they become the human's main job. Once the game was playable, I kept switching between the two: designing the experience, then playing it to feel what was off. One sentence from me — "pin the card so it holds position and only leans when dragged" — was enough to reshape the core animation. And after playing it through, I told the AI the scoring felt off: players were losing control too fast, before they ever got to feel the balancing act the game is actually about. The difficulty had to let you teeter — to manage things, to almost hold it all together — before it slips away, so that the challenge carried the game's real meaning rather than working against it. Each got fixed the same way: I describe what I saw, the AI offers a couple of concrete options with trade-offs, I pick one, it ships.

A safety pattern for anything irreversible. For renames, the org transfer, and other actions visible to others, I used a strict "propose → list options and trade-offs → I confirm specifics → AI executes" loop. Those are exactly the actions where a hands-off AI can do quiet damage, so the human stays in the decision seat.

The short version of my role: I owned the brief, the open design questions, the feel, and every irreversible action. The AI owned generation, testing, and surfacing problems.

4. Community involvement through Forking

A core purpose of Boardroom is to be an example: proof that you can use AI creatively to make a real game even if you're not a programmer. If that's the point, then sharing the experience openly and giving people concrete ways to build on it isn't a nice-to-have — it's the heart of the project. That's why Boardroom is built to be forked, so the community extends it rather than just plays it. There are two deliberate levels.

Level 1 — Re-skin (no code). The load-bearing design choice is that everything a player sees lives in just two plain-text files: one holds all the words (title, meter names, characters, every card and ending), the other holds all the visuals (colors and fonts). A writer or designer can turn Boardroom into a medieval kingdom, a school-principal sim, or a starship-captain game by editing those two files — no coding required. A built-in check makes sure the two files stay in sync, so a re-skinner can't accidentally ship something broken. The formats were chosen specifically because they're already familiar to the people we want contributing — writers and designers, not programmers.

Level 2 — Rebuild from scratch with AI. For people who want the game on a different stack entirely (Next.js, Vue, Svelte, native mobile), there's a self-contained reference prompt designed to be pasted into an AI builder like Replit Agent, Bolt, Lovable, v0, Cursor, or Claude Code. I didn't just write this prompt and trust it — I tested it on real builders. Replit produced strong fidelity but only 15 cards, so the delayed-consequence mechanic barely showed; v0 produced a playable game but quietly dropped some of the core mechanics. That gap between theory and reality drove two requirements I'd never have reached from theory alone: the AI builder must show its plan to the human and wait for confirmation before writing code, and the prompt supports both a "faithful rebuild" and a "creative fork" mode.

Why this is the community engine. The two-file architecture means most contributions — new cards, new endings, new characters, visual variants — land without anyone needing to understand the game engine. Boardroom stops being just a game and becomes a template for satirical leadership simulators: a clean engine plus an editable surface, with the door open for forks I'd never have thought of. Issues and PRs are open at the upstream repo.

What's next

The focus now widens beyond Boardroom itself.

  • Put it in front of real people, at events. Boardroom becomes one of the sample games at my workshop, Playable Stories: Vibe Coding Meaningful Games (SPACE4, London, 11 June 2026) — a hands-on session for storytellers, community builders, and social-impact folks with no coding needed. Participants play and unpick games like Boardroom, then build their own short browser game with AI. The real question I want answered: does seeing a worked example like this actually make it easier for non-programmers to build something meaningful?
  • Build more game examples. One game proves it's possible; a small library proves it generalizes. More examples across different themes and emotional registers give people more starting points to learn from and fork.

The throughline: AI made building fast, but the meaning came from a human owning the brief, the feel, and the decisions — and from designing the whole thing so others can learn from it and carry it further.