The Emberbound warband stands against an army beneath the eclipsed Ashen Vale

Development record · Human direction + Codex execution

One prompt lit the forge.

What began as the same test task for three coding agents became a week-long creative sprint, an epic cooperative game, and one pivotal decision: build a foundation strong enough to carry worlds beyond Emberbound.

Exact first prompt · reproduced verbatim
Build a video game, multiplayer, based on golden axe, but multiplayer, cool ass characters with similar graphics
Read the record

Not a victory lap. A build record.

The direction changed because the prompts did.

Jeff J Hunter supplied the taste, references, corrections, priorities, and final calls. Codex App turned that direction into code, tests, art workflows, documentation, and deployments. Every frustrating playtest note became design pressure.

Editorial note: The opening prompt is reproduced exactly as submitted. Later prompt fragments are lightly condensed for readability. This is a curated public history, not a raw transcript. It publishes no private conversation, credentials, task identifiers, or local development details. Historical game references describe creative touchstones only; Emberbound’s world, heroes, artwork, code, and identity are original.

Three agents · One test task

The benchmark refused to end.

Jeff gave the same opening prompt to Claude Code, Grok Build, and Codex to see which coding agent could turn a loose idea into something playable. In that test, Codex was the clear winner.

The comparison should have ended with a result. Instead, the Codex build had enough spark to demand another prompt, then another. What began as a test task between three coding agents became an original, epic game—and a week-long coding session shaped by direct playtests, ambitious new ideas, blunt corrections, and hundreds of deliberate decisions.

01
Starting ideaA browser-based four-player fantasy arcade brawler.
12
Campaign stagesBosses, cinematics, co-op trials, bonus rounds, and persistent progression.
05
Engine packagesReusable authority, protocol, content, deterministic core, and test infrastructure.
Possible worldsEmberbound is the first realm this foundation is intended to power.

The record of the forge

The prompts that changed the product.

Not every request added a feature. Some rejected weak work. Some exposed structural problems. The most important prompts changed what Emberbound was allowed to become.

  1. Entry001

    The spark

    The impossible arcade cabinet

    “Multiplayer online… hosted on a VPS. Four-player co-op.”

    Emberbound did not begin as a planned production. It began as the same loose challenge handed to Claude Code, Grok Build, and Codex. The first prompt supplied energy, not a specification; Codex supplied the strongest playable answer, and Jeff chose to keep pushing it. The online and VPS follow-ups immediately ruled out a disposable single-player mockup.

    The growing wish list used genre landmarks as emotional shorthand: Golden Axe for fantasy-brawler impact, Gauntlet: Dark Legacy for long-form cooperative adventure, the four-player Teenage Mutant Ninja Turtles and X-Men cabinets for shared-screen clarity, Street Fighter bonus rounds for joyful detours, and Diablo for online persistence. They defined feelings to chase—not characters, worlds, or assets to copy.

    What it became: an original browser-native realm with one authoritative Node.js simulation, private four-player rooms, and WebSocket play.

  2. Entry014

    The quality line

    “The dude’s not even holding the weapon.”

    “It’s still very amateur.”

    That blunt review established the project’s most useful rule: technically present is not visually convincing. Weapons needed to belong in hands. Feet needed to meet the floor. Walkable ground, camera movement, collisions, approach distance, and enemy entrances all had to tell the same physical story.

    What it changed: grounded presentation, stronger hero renders, authored spawn approaches, readable combat lanes, clearer hit geometry, and a much higher acceptance bar.

  3. Entry031

    Combat identity

    Every attack needed a body behind it

    “There’s no body movement… it just stands there.”

    Sable’s projectile could not simply appear at a weapon tip. Casters, archers, bruisers, and guardians needed different windups, release points, recoil, combo branches, and recovery poses. Secondary attacks grew into character-specific motions; light, heavy, ranged, and melee inputs became combo vocabulary.

    What it changed: six combat identities, visible equipped weapons, ranged casting origins, multi-hit sequences, character death performances, boss finishers, and rotating voice reactions.

  4. Entry047

    Fight as one

    Co-op became more than four people attacking nearby

    “Partner abilities… unique as to who initiates.”

    The warband needed verbs that only existed because another player was present: linked spins, throws, shared specials, rune relays, rescue pressure, and score rivalry inside cooperative bonus trials. “T for team up” eventually became both the signature partner input and the readable way to resurrect a downed ally.

    What it changed: directional team attacks, downed timers, revive signaling, full-party HUD information, cooperative challenges, and shared victory moments.

  5. Entry063

    Arcade becomes campaign

    The fight gained memory

    “Play for 20–30 minutes at a time and return together.”

    That request transformed a run-based brawler into a persistent online adventure. Accounts, heroes, campaigns, weapons, unlocks, difficulty, checkpoints, reconnect grace, and safe return points now mattered as much as moment-to-moment combat.

    What it changed: durable PostgreSQL-backed chronicles, six selectable heroes, equipment progression, Novice/Veteran/Hardcore modes, twelve stages, and resumable shared campaigns.

  6. Entry078

    A living warband

    The lobby became a social place

    “Friends… individual chat, party chat, voice.”

    Real cooperative play needed relationships outside the battlefield and coordination inside it. Authentication, email verification, friend requests, direct messaging, party chat, presence, and opt-in WebRTC voice became platform systems rather than combat shortcuts.

    What it changed: persistent identity, social rosters, private and party channels, mute/deafen controls, and TURN-ready voice architecture.

  7. Entry096

    The pivotal question

    Was this a game—or the beginning of an engine?

    “I want to create additional games like this… built solid, and replicatable.”

    The answer could not be a renamed folder full of Emberbound assumptions. The reusable pieces had to stop importing the game. Time, random state, transport, content, and game rules needed explicit boundaries. A second headless game had to install the packed packages outside the workspace and prove they worked without Emberbound.

    What it changed: five private @generated-adventures/* packages, strict dependency boundaries, a clean-room Smoke Arena consumer, and documentation for creating another game.

  8. Entry112

    The rebuild

    Reliability became a feature players should never notice

    “Back up what we have… make sure it’s reversible and test it in the new engine.”

    The migration could not gamble with a working game. Authority moved behind versioned protocols and fixed simulation steps. Reconnect behavior, deterministic state, checkpoint envelopes, recovery artifacts, journaling, storage boundaries, and rollback were tested as hostile failure surfaces—not optimistic happy paths.

    What it changed: engine-owned room authority, deterministic replay foundations, bounded recovery evidence, immutable release artifacts, automated rollback rehearsals, and canonical full-campaign raids before deployment.

  9. Entry129

    From prototype to public Alpha

    The realm acquired a front door

    “The Alpha on EmberboundGame.com… gate who gets access.”

    The game, the public story, and player acquisition became separate surfaces. The root domain could sell the dream without consuming realm resources. The play subdomain could protect accounts and campaigns. Alpha applications could enter a consent-aware recruitment workflow without exposing invitation security.

    What it changed: a cinematic marketing site, protected application intake, branded transactional mail, HighLevel automation, a locked-down VPS, verified deployments, and a private GitHub release trail.

  10. EntryNow

    The journal opens

    The build process becomes part of the game’s story

    “A ‘Codex Journal’ section… show how a simple prompt turned into this massive project.”

    The latest prompt makes the collaboration visible. Not as magic and not as a transcript dump, but as evidence that strong direction, honest testing, and the willingness to rebuild weak foundations can turn a loose idea into a serious living system.

    What it changes: players can now follow the decisions behind the Vale—and watch future entries arrive as Alpha feedback shapes what comes next.

The engine pivot

Extracted to expand. Rebuilt to survive.

The foundation is deliberately smaller than the game. It owns the reusable truths; Emberbound keeps its heroes, combat, art, progression, and world.

PromptDesign pressureImplementationPlaytestHardeningRelease
01

Engine Core

Fixed simulation steps, deterministic ordering, seeded state, canonical hashing, and checkpoint envelopes.

02

Engine Protocol

Versioned commands, events, snapshots, compatibility limits, and untrusted-payload boundaries.

03

Engine Realm

Authoritative one-to-four-player rooms, command sequencing, disconnect grace, and reconnect rotation.

04

Engine Content

Versioned manifests, namespaced identities, explicit references, and behavior registries.

05

Engine Testkit

Manual time, virtual transport, replay verification, and clean-room second-game proof.

What it is today: a reusable private foundation proven outside Emberbound. What it is not yet: a public SDK, visual editor, turnkey brawler template, or promise that every Emberbound-specific system is generic.

What the process taught us

The rules written by the work.

01

Playable beats plausible

A convincing screenshot is not proof of movement, collision, multiplayer authority, recovery, or fun.

02

Blunt feedback is useful data

“It floats.” “It’s amateur.” “I can’t read it.” Each sentence points to a broken promise the player can feel.

03

Co-op needs unique verbs

Four players on one screen are not automatically cooperating. Rescues, relays, team attacks, and shared risk create the warband.

04

Reuse must be proven elsewhere

An engine is not reusable because its folder says engine. A different game must consume it without importing the original.

05

Releases must be reversible

Backups, immutable artifacts, health-gated promotion, and rollback tests turn iteration into an operation players can trust.

06

The Journal stays unfinished

Every Alpha session can change combat, presentation, accessibility, progression, and the worlds this engine carries next.

The next entry needs players

Enter the Vale. Leave a mark on the record.

The Journal tells how Emberbound reached this gate. The Alpha warband decides what survives beyond it.