EMBERSLING Project Report
1. The Concept
EMBERSLING is a portrait, web-based slingshot battler where the player fires elemental orbs at floating demon enemies. The core idea is simple: choose the correct element, aim the slingshot, break numbered shields, then damage enemy HP after shields are gone.
I chose this game concept because it combines several mobile-game systems in one prototype: physics-style aiming, elemental matching, boss readability, cooldown abilities, campaign progression, and premium fantasy UI presentation. The project became a useful test of whether an AI-assisted workflow could build not only a playable browser game, but also a full asset pipeline and campaign structure around it.
2. The Stack
The Stack: HTML5 Canvas, JavaScript, CSS, JSON, PNG/WEBP image assets, WAV audio, and Python tooling.
The AI Assist: ChatGPT/Codex handled concept planning, implementation, asset manifest design, campaign data creation, AI art prompt generation, validation tools, UI iteration, and gameplay debugging. The user provided direction, reference images, design rules, and repeated visual feedback. Codex then translated those requirements into the working browser prototype.
The project uses a centralized assets/manifest.json file and a campaign data file at assets/campaign.json. All graphics are loaded from the assets/ folder, and future campaign art can be generated from campaign_asset_prompts.md.
3. The 1 Day Sprint
Morning (Hours 1-3): We started by reading the Sakurai-inspired notes and shaping the initial idea into a clear game pitch. The early planning focused on portrait orientation, one-thumb mobile play, real-time cooldowns with aim slowdown, elemental shields, one-bounce chain attacks, and short 1-2 minute fights. The target was a casual mobile audience that likes satisfying combat, readable bosses, and collectible progression.
Afternoon (Hours 4-6): The coding phase began with a single-page HTML5 Canvas prototype. We built the battle screen, home screen, asset manager, slingshot input, elemental slots, shield logic, boss rage, particles, basic audio, and responsive desktop framing. A lot of time was spent matching the attached visual reference: boss size, minion positions, top HUD, bottom ability bar, slingshot placement, and touch targets.
The Finish Line (Hour 7-8): The final stretch focused on polish and structure. We added a 15-level campaign, unique boss/enemy asset slots, hero slingshot upgrades, five world themes, AI image prompts, validation scripts, a README, and a playable tutorial. We also improved loading and home screen animation, added generated WAV sound effects/music, and fixed the combat loop so enemies and bosses can actually be defeated.
4. The Roadblocks
Roadblocks: The biggest roadblock was visual asset handling. The user specifically wanted real PNG/WEBP game assets, not CSS shapes, SVG drawings, or placeholder UI. Early attempts used the wrong kind of placeholder behavior, and the bottom ability bar was especially difficult because the icon art already contained circular frames. That caused repeated “circle inside circle” problems until the footer was changed to use cleaner symbol assets centered inside the existing socket art.
Another issue was the asset manifest. At first, missing assets stopped the game or created ugly placeholders. The workflow had to be changed so optional future campaign assets can be listed in the manifest, generate prompts, and be replaced later without code changes. This was necessary because the campaign requires 15 unique bosses and 60 unique enemies, but not all final artwork exists yet.
Gameplay also had a logic gap: the first version could reduce shield numbers, but enemies did not properly die. The combat loop had to be updated so shields break first, then HP damage begins, minions can be removed, the boss can be defeated, and boss rage can damage the hero.
5. Key Takeaways
What worked best was the structured iteration. The repeated visual feedback made the game much closer to the reference image than a single prompt would have achieved. The campaign data, manifest pipeline, and prompt generation also worked well because they created a clear production path for future assets.
What worked worst was interpreting “premium asset integration” too loosely at first. The project needed strict respect for real image assets, exact placement, and no fake UI art. Several fixes only moved layout around instead of solving the real issue in the asset composition. Once the workflow focused on real files, manifest keys, and replaceable assets, the project became more stable.
My final thought: If I had one more day, I would split the single index.html into modules, add a proper level-select screen, and replace all remaining placeholder campaign assets with final generated artwork. If I could redo the project, I would define the complete asset naming system and campaign manifest before coding the first screen, because that would have prevented several painful UI and placeholder problems later.