Fruits Sort Puzzle

Fruits Sort Puzzle Project Report

1. The Concept

Fruits Sort Puzzle is a calm, tap-based sorting puzzle. Cute fruit characters sit on wooden tree branches. The player’s job is simple to explain and hard to master:

Tap a branch, then another — move matching fruits until every branch holds one complete set (or is empty).

It borrows the clarity of classic water-sort / bird-sort games, but reframes the fantasy around a sunny orchard: sky gradients, clouds, twin trunks, and expressive SVG fruits with eyes. The unique hook is branch sort — left/right wooden arms instead of tubes or perches — so the board reads as a tree, not a lab.

Design goals:

• Instant rules (one hint: “Tap a branch, then another”)
• Soft difficulty ramp across 100 levels
• Beginner-friendly feel with enough mix depth for longer sessions
• One clear win loop: sort → celebrate → next level

2. The Stack

Built as a zero-build, zero-dependency product so it can ship and play the same day.

Layer Choice ----------- ---------------------------------------------------------------- Structure Single index.html UI Vanilla HTML + CSS (mobile-first, safe-area aware) Logic Vanilla JavaScript (IIFE, "use strict") Art Inline SVG fruit sprites + CSS atmosphere Audio Web Audio API (procedural SFX + loop BGM) Progress localStorage (unlocked level + mute preference) Target Phone browser / PWA-style viewport (max-width ~480px)

No framework, no bundler, no asset pipeline — one file you can open and play.

3. The 1 Day Sprint (+ polish pass)

The day was treated as a full vertical slice: concept → playable core → polish → shippable demo. Scope stayed tight: one mechanic, one visual world, one progression path. Anything that did not serve “sort fruits on branches and feel good doing it” was cut.

Morning (Hours 1–3):

• Locked the fantasy: orchard sky, wood branches, cute fruits — not tubes (adapted from a bird-sort board reference).
• Built the app shell: title screen, game HUD, playfield with dual trunks.
• Defined core constants: capacity 4, fruit types pool, 100 levels.
• Implemented selection → move rules (topRun, canMove) and branch rendering.
• Got a first playable loop on device: tap source, tap target, fruits move.

Outcome: A clickable prototype that already felt like the game, not a wireframe.

Afternoon (Hours 4–6):

• Added procedural level generation with seeded RNG (stable levels per number).
• Enforced solvability checks so random boards would not soft-lock players.
• Tuned difficulty curve (colors, empty branches) as levels climb; mixed fruits per branch for real puzzle depth.
• Wired progress: Play / Continue, unlock persistence, restart, pause / home.
• Started juice: lift animation, land feedback, complete-branch highlight, win overlay with stars and confetti.
• Added Web Audio SFX + first BGM pass; mute preference on title and game screens.

Outcome: A real campaign, not a single hand-made puzzle.

The Finish Line (Hour 7-8):

• Finished move feedback, win / retry / next flow through all 100 levels, and final clear messaging.
• Responsive fruit scaling when branch count grows; touch-friendly controls.
• Title screen fruit lineup aligned with in-game sprites (five fruits).
• Pass for readability, safe areas, and “open file → play” confidence.

Outcome: A self-contained demo ready to show, share, or iterate.

Polish (Aug 10):

• Smoothed fruit travel so pieces no longer “vanish then reappear” mid-move.
• Iterated BGM several times until the loop felt inviting — bright, playful, “want to tap again.”
• Copy tweak: win banner CLEAR! → NICE!
• README for open / play / stack / layout so anyone can run the file without guessing.
• Design reference notes kept under sakurai/ and rules/ for follow-up UI and content work.

4. The Roadblocks

1. Solvable randomness — Pure shuffle looks mixed but can be unwinnable. Needed a generator + search (isSolvable) and

fallbacks when no good board appeared.

1. Readability on small screens — Many branches + large fruits = cramped UI. Solved with dynamic --fruit-size and compact HUD.
2. Audio without assets — No sound pack in a 1-day sprint. Web Audio synthesis had to carry SFX and BGM;

finding a BGM that felt “nice” and inviting took multiple rewrite passes.

1. Motion clarity — Early moves popped fruit in/out instead of reading as a pour. Needed clearer lift / travel / land timing.
2. Scope pressure — Undo, ads, themes, and meta-progression were tempting. Staying on one file and one mechanic kept the day finishable.

5. Key Takeaways

• One sentence concept + one HTML file is enough to ship a complete 100-level loop in a day.
• Familiar rules (sort) + a warmer fantasy (orchard branches) beats inventing a new mechanic under time pressure.
• Procedural levels only work if solvability is part of the generator, not an afterthought.
• Feel is product: smooth moves and the right BGM mattered as much as the rules for “this is fun.”
• Cut features early; polish the core loop instead of spreading thin across meta systems.

My final thought:

A one-day game only works when the concept is a single sentence and the stack stays out of the way. Fruits Sort Puzzle proves that: familiar sort rules, a warmer branch-and-orchard identity, and a full 100-level loop inside one HTML file. The next steps are optional — undo, handcrafted early levels, richer art — but the core already delivers what mattered most: tap, sort, smile, next.