Numbers Connect Project Report
1. The Concept
Numbers Connect is a mobile-first number-merging puzzle game. Players drag across matching tiles, combine them into larger values, reach each level goal, and unlock a collection of cosmic artwork.
The game was chosen for a one-day sprint because the core idea is easy to explain, but the systems behind it are not small: a real-time canvas board, pointer input for mouse and touch, a merge formula, special tiles, 18 levels, persistent progress, sound, and a reward loop. It was also a strong test of the Sakurai-style design notes in this repo: a unique hook, a clear game loop, beginner-to-expert depth, and as little instruction text as possible.
The unique hook is simple: connect matching numbers to build something bigger, then watch a picture reward reveal itself as you play.
2. The Stack
The Stack: HTML5, vanilla CSS, JavaScript, the Canvas API, and the Web Audio API. No React, no build step, no backend, and no package manager.
The game is split into a small set of files:
index.htmlfor screens and markupstyles.cssfor layout, animation, and visual polishgame.jsfor rules, rendering, input, audio, and save dataassets/ui/for interface artworkassets/collection/for level picture rewardssakurai/andrules/for design reference notes
Progress is stored in localStorage. Sound is generated at runtime, so the game does not need audio files.
The AI Assist: Cursor was used for planning against the Sakurai notes and UI rules, then for coding, bug fixes, and polish. Generated UI sheets were cropped into WebP assets with small Python helper scripts. The sprint stayed inside a static web project so the AI could move quickly from concept to a playable game without a framework.
3. The 1 Day Sprint:
Morning (Hours 1–3): We started with the design notes instead of jumping into code. The Sakurai files made the target clear: the game had to be a problem to solve, not a pile of features. The player action had to be obvious in 1–3 seconds. Menus had to stay simple. Parameters had to be tunable without rewriting logic.
From that, the concept became: drag matching numbers, merge them, reach a goal, unlock a picture. We locked the loop early: connect → merge → refill → reach the goal → collect the picture → retry fast. Level goals, tile colors, and special-tile rates were planned as data, not hard-coded one-off rules.
Afternoon (Hours 4–6): The playable core was built in HTML, CSS, and JavaScript. The board is a 6×7 canvas grid with pointer events for both mouse and touch. Matching tiles can connect in eight directions. Releasing a valid chain merges the tiles into a larger number, the board collapses, and new tiles fall in.
The game then grew into a full session: 18 levels from 32 to 4M, bomb tiles that blast a 3×3 area, wild tiles that can join a chain, a home screen, pause, tutorial, picture collection, score, best score, and save/resume. UI artwork was sliced from generated sheets for the background, goal frame, score frame, pause button, and result ribbon. Sound was synthesized with the Web Audio API so merges, bombs, and ambient tones could be heard without importing audio files.
The Finish Line (Hour 7-8): The last hours were spent on feel and clarity. Particles, floating score text, hit-style merge feedback, and glow on high-value tiles were added so impact would come from motion and sound, not from extra labels. The first-run tutorial was kept to three short steps with a Skip button. Idle instruction text on the board, “Connect matching numbers,” was removed because the drag action already teaches the rule. The remaining work was mobile layout, mute/unmute, collection unlocks, and a README so the project could be played from a local static server.
4. The Roadblocks
Roadblocks: The hardest conflict was the UI asset rule versus the speed of a one-day web prototype. The design rules say a commercial smartphone game should use image assets for buttons, frames, icons, and windows, not CSS shapes or emoji. Some of that was done: background, pause, goal frame, score frame, and result ribbon are images. Other parts still are not: the home Play button, Settings, Sound, tutorial copy, and several HUD labels are still HTML and CSS.
A second roadblock was input feel. Drag-to-connect looks simple, but it has many edge cases: diagonal neighbors, dragging backward to undo, starting on a wild tile, mixing bombs into a chain, and making the same code work for mouse and finger. If the chain detection is even a little too strict, the game feels broken. If it is too loose, invalid merges sneak through.
The third roadblock was information on screen. The HUD wanted to show level, goal, score, moves, collection progress, and chain preview at the same time. That fights the rule that one screen should have one job, and that explanation text should be close to zero. Cutting the idle board hint helped, but the play screen is still denser than a commercial puzzle HUD.
5. Key Takeaways
What worked best was the core loop and the parameter-driven design. Once connect, merge, refill, and goal were working, the rest of the game could be added as data: level goals, tile colors, bomb/wild chance, and collection rewards. The AI was strongest when the design notes were treated as constraints, not decoration.
What worked worst was turning those constraints into a finished commercial UI. The game became playable quickly, but replacing every CSS button and leftover instruction with image assets took more time than the sprint had left. Canvas tiles also had to be drawn in code, so readability, glow, and performance all had to be balanced by hand.
My final thought: If I had one more day, I would finish the UI asset pass first: replace remaining CSS buttons, shrink the HUD, and keep the board as the only thing the player needs to look at. If I could redo the sprint, I would ship one perfect loop—connect, merge, reach the goal—before adding collection, bombs, wilds, and extra screens.