Mergehaven Project Report
1. The Concept
Mergehaven is a lightweight, web-based merge-kingdom game where players harvest resources, combine matching items, complete quests, and spend keys to clear fog and unlock new regions. I chose this project for a one-day sprint because it tests more than basic page generation: it requires persistent game state, drag-and-drop interactions, progression balancing, responsive UI, canvas rendering, animation, and automated regression testing.
2. The Stack
The Stack: HTML5, Vanilla CSS, JavaScript, HTML Canvas, Web Audio, WebP assets, and browser localStorage.
The AI Assist: Cursor's AI coding agent helped analyze the game loop, plan improvements, implement gameplay and UI changes, diagnose rendering and worker-animation bugs, and run the automated golden-path test. The project intentionally uses no framework, package install, or build step, so the AI-generated work had to fit the existing vanilla JavaScript architecture.
3. The 1 Day Sprint
Morning (Hours 1–3): We established the core merge-game loop: harvest generators, merge three or more matching items, collect resources, complete quests, and unlock fog-covered land. We reviewed the existing architecture and focused on stabilizing save/load behavior, board state, camera framing, tutorial guidance, and progression. We also expanded the land, quest, shop, and reward systems so player levels and keys had clear uses.
Afternoon (Hours 4–6): The main implementation and polish phase focused on worker behavior, generators, wonders, offline energy, shop packs, responsive HUD behavior, and game feel. Workers gained a full task sequence—idle, walk, arrive, work, react, drop, celebrate, and return to idle. We added land-gated shop packs, better wonder rewards, merge-five bonuses, bubble overflow protection, objective tracking, multi-worker support from upgraded houses, and a board-tidy action.
The Finish Line (Hours 7–8): Final QA exposed several important bugs. A malformed edit in render.js stopped the entire canvas from drawing, workers could path through locked fog, and their generated walking animation still looked like a sliding image. We repaired the render syntax, replaced straight-line movement with unlocked-tile pathfinding, synchronized walk frames to tile steps, added eased movement, and kept automatic harvesting visually quiet. The final golden-path suite passed ten consecutive runs, including save repair, actor flow, fog-lock pathing, bubble control, merging, harvesting, quests, unlocking, and save/load.
4. The Roadblocks
Roadblocks: The largest challenge was keeping a growing set of game systems synchronized without a framework. A small syntax mistake in the rendering file caused the board to disappear while some UI controls still responded, which made the game state appear corrupted even though the underlying save was intact. Worker movement was another difficult area: simple coordinate interpolation looked like sliding, and direct paths allowed workers to cross locked regions. The solution required separating simulation from presentation, restricting paths to unlocked tiles, tying animation frames to each tile step, and adding regression coverage for fog boundaries.
The project also depended on static worker artwork rather than true directional animation frames. Runtime-generated six-frame walk strips improved the result, but they cannot fully reproduce natural leg and body motion. Hand-painted front-left, front-right, back-left, and back-right walk frames remain the main visual limitation.
5. Key Takeaways
**What worked best?
** The modular vanilla JavaScript structure made targeted iteration possible. Game data, simulation, rendering, sprites, audio, and UI wiring are separated into focused files. The automated golden-path test was especially valuable because it caught regressions across the complete player journey instead of testing isolated functions only.
**What worked worst?
** Visual animation created from a single static worker image. Code can add bobbing, easing, direction changes, and squash-and-stretch, but it cannot generate truly believable walking anatomy from one pose. Rapid edits across tightly connected global scripts also created a temporary render-breaking syntax error, showing the need for syntax checks after every gameplay batch.
My final thought: If I had one more day, I would replace the runtime-baked worker animation with professionally authored directional walk frames, add browser-based visual regression tests, and complete a longer mobile playtest across every region. If I could redo the sprint, I would establish render smoke tests and worker pathing tests before the polish phase so animation and canvas failures could be caught immediately.