We wanted a 2D strategy game where you could gather wood, stone, gold, and food, build a settlement, recruit soldiers, upgrade structures, and eventually lead an army into battle.
The inspiration was the settlement-building loop of classic RTS games, with direct control of a hero. The world and characters would be original. The game had to run in a browser, and all its illustrated assets had to come from SpriteShip.
The result is Emberhold: The Last Hearth, a Godot game with a story campaign, a peaceful sandbox, and a public web build.
Codex handled the coding and tool-driven implementation. SpriteShip supplied the illustrated assets and their export data. Godot brought the systems together.
Here's what that process actually looked like—including the parts that still need work.
Start with a game vision, not an asset list
Our initial request described a genre and a visual ambition. It did not specify every building, character, quest, or balance value.
We asked Codex to turn that into a product requirements document before implementation. A cleaned-up version of the brief would look like this:
Build an original 2D settlement strategy game in Godot for the web.
The player gathers resources, constructs and upgrades buildings,
recruits soldiers, explores the map, and fights enemies.
Use SpriteShip for every illustrated game asset.
Define the story and campaign objectives before implementation.
Keep SpriteShip production within a 30,000-credit ceiling.
Validate the game in the engine and in a real browser.
That planning step gave the art and mechanics a shared direction.
Captain Elara arrives in a ruined valley with survivors and a coal from the last living hearth. Rebuilding the settlement lets her recruit an army, rekindle three beacons, and confront Veyr, the Ash Regent.
The campaign has five chapters. Its progression moves from gathering and construction to recruitment, exploration, beacon liberation, and the final battle.
The PRD is in the repository, alongside the implementation.
Give Codex tools and an explicit workflow
For this build, Codex could inspect and edit the repository, run commands, call SpriteShip's API/MCP tools, download exports, and examine the resulting game.
We also supplied SpriteShip's current agent instructions. Those instructions covered generation, export contracts, synchronization, collision metadata, quality review, and spending controls.
There are two useful layers here: tools expose operations, while a skill explains the workflow around them. That's also the distinction described in the official OpenAI documentation on skills.
In our production scripts, the loop became:
Define the asset and its role
→ obtain a generation quote
→ check it against the authorized budget
→ submit and wait for the job
→ download the native export
→ integrate, inspect, and test
The scripts retained request state and used idempotency keys for paid operations. They also needed file locking when multiple production operations updated shared state.
The point was to make the agent's work inspectable: which assets were requested, which jobs finished, what was imported, and what actually cost credits.
Build a coherent art pack
We chose an angled top-down, painted fantasy style: mossy greens, ivory stone, copper roofs, warm settlement lighting, and ember-red enemy accents.
The SpriteShip project supplied the illustrated menu scene, terrain, nature props, resource deposits, structures, fortified building variants, landmarks, characters, icons, and ornamental UI.
The character lineup includes Elara, settlers, guards, rangers, knights, raiders, and armored brutes. The final boss uses the brute artwork at a different scale.
Godot code supplies lighting, particles, text, interface layout, and gameplay. Music and sound effects are synthesized at runtime rather than imported as generated audio files. Fonts arrived through SpriteShip with their license notices.
We later changed the account's watermark setting and downloaded every selected asset again, including the whole-character, map, and UI bundles. We did not paint over watermarks locally.
That refresh also reinforced a useful production rule: store local asset bytes and stable identifiers, not expiring download URLs.
Native exports make integration concrete
SpriteShip's Godot character bundles include native .tres animation resources, spritesheets, manifests, and integration instructions. Its Codex integration guide describes these self-describing exports.
Codex read the delivered animation names, frame order, and playback data rather than inventing a spritesheet layout.
Our project keeps an asset lock file and a local runtime manifest. The lock records imported entities and versions; the runtime manifest routes game archetypes to their local art and animation resources.
The final synchronization check covered 18 entries, all matching the downloaded versions.
The surprisingly tricky part: feet
A character can look great in an individual frame and still look wrong when it switches animations.
Different clips had different amounts of transparent padding. Without calibration, standing and walking could appear to change the character's size or ground contact.
We used a fixed neutral-first-frame reference for each clip to calibrate visible height and the foot anchor. This is a per-clip render adjustment, not a crop that changes on every frame.
Movement footprints were authored back into SpriteShip separately from full-body hurtbox metadata, then downloaded in fresh native exports. The full, untrimmed logical frame coordinates were retained.
For browser delivery, we applied a paired 50% scale to the character sheets and every corresponding atlas rectangle. Scaling only the image would leave the atlas pointing at the wrong pixels. Full-resolution native sources were retained locally.
These integration details were a substantial part of the work. Generating the image was only one step.
Build the game systems in Godot
The shipped game uses Godot 4.7.2 and GDScript. Node.js handles production and build tooling; it is not the gameplay engine.
The main systems include:
- Hero movement, contextual gathering, melee attacks, healing, and dashing.
- Settlers that travel to deposits and gather resources autonomously.
- Eleven structure types, construction progress, upgrades, repairs, and population limits.
- Guard, ranger, and knight recruitment, with follow, defend, rally, and assault orders.
- Research, ranged projectiles, defensive towers, enemy camps, and escalating raids.
- Three beacons, a protected citadel, a final boss, campaign progression, and save/load.
The authored valley is 4096 × 3584 pixels. Godot handles obstacle-aware navigation with AStarGrid2D, exploration, fog, interactions, and the gameplay meaning of the map data.
The source is split into recognizable responsibilities: game.gd owns simulation and saves, world.gd handles rendering and animation selection, hud.gd manages the interface, and data.gd holds unit, building, and story definitions.
You can inspect that division in the Godot project source.
Test actions, not just screenshots
We used two different kinds of validation.
First, native Godot acceptance scenarios exercised gathering, settler travel, navigation routes, placement, upgrades, completed recruitment queues, research, repairs, projectiles, saves, beacon activation, and final victory.
Those tests use prepared resources and cleared beacon guards where appropriate. They are systems tests—not evidence of a complete human campaign playthrough or a measured campaign duration.
Second, an isolated Chromium browser used real mouse and keyboard input. It moved Elara, placed structures, waited for settlers to collect resources, recruited troops, upgraded a barracks, saved, reloaded, and continued the settlement.
The browser also led an army to the first beacon, defeated five enemies, used healing, and rekindled it. We repeated these checks against the public GitHub Pages build.
The public-site run passed with all seven character archetypes registered and zero browser console or page errors. Screenshots covered multiple desktop viewport sizes.
The browser tests inspect a read-only state snapshot; they do not use a debug API to grant resources or complete objectives.
Ship the web build through GitHub Pages
The repository already hosted another game, Last Light. We extended its Pages build so Emberhold could live alongside it:
https://spriteship.github.io/sample_games/emberhold/
We used Godot's Compatibility renderer and a single-threaded Web export. Single-threaded exports avoid the cross-origin isolation headers required by threaded builds, which makes this a practical fit for static hosting. See Godot's web export documentation.
The Linux CI build installs the pinned Godot version and matching Web templates, verifies their SHA-256 checksums, runs the tests, exports the game, and packages both games into the Pages artifact.
Generated web builds stay out of Git. The repository contains the source and illustrated assets; CI rebuilds the deployable files. Playing or deploying the game requires no SpriteShip API key.
To rebuild locally, install Godot 4.7.2 with matching Web export templates and Node.js 22+, then run:
git clone https://github.com/spriteship/sample_games.git
cd sample_games
npm ci
npm run build:emberhold
npm run dev:emberhold
The local game runs at http://localhost:4174. Saves on the public site are separate from localhost saves.
What it cost—and what still needs work
Our audited SpriteShip production spend was 14,360 credits net, against the authorized 30,000-credit ceiling. That includes generation failures and provider refunds recorded in the ledger. It is an art-production figure, not the total cost of development or a dollar-price estimate.
The original brief asked for an AAA-style 2D look. That was an ambition, not a certification of the result.
This is a playable single-player campaign and sandbox on one map. It still needs animation polish, broader hardware testing, and longer balance playtests. In particular:
- Gathering reuses strike/chopping clips rather than having distinct animations for each resource.
- Hero death currently restores health and returns Elara home immediately, which needs a clearer death-and-recovery sequence.
- Three gameplay building levels share two delivered artwork tiers; level III reuses fortified art with a crown marker.
- Some optional attack directions failed at the provider, so delivered animations serve as fallbacks. Quality-review flags remain documented.
It does not include multiplayer, voice acting, mobile touch controls, or a multi-map campaign. The QA record explains the validation and limitations.
The takeaway
Codex let us work through planning, implementation, asset orchestration, debugging, testing, and deployment in one ongoing workflow. SpriteShip gave that workflow a source of illustrated assets with native export data the agent could inspect and integrate.
The most useful combination was a clear game brief, a coherent art direction, explicit asset contracts, bounded spending, and tests that exercised actual player actions.
There is still polish to do. But the result is a public game you can play, with source you can inspect and a production process you can follow.
Try Emberhold, browse the repository, or explore SpriteShip and the game's art project.
If you play it, I'd love feedback on the settlement pacing, army controls, and what feels most important to improve next.
Top comments (0)