Sneaky Fingers Project Report
1. The Concept
Sneaky Fingers is a lightweight, web-based 2D puzzle game inspired by stretchy-hand puzzle mechanics. The player controls a cartoon thief who can stretch his arm across the level to steal a target item while avoiding hazards, obstacles, guards, and other dangers.
I chose this concept for the one-day sprint because the core interaction is simple to understand but challenging to implement well. The game requires direct mouse/touch controls, collision detection, character reactions, responsive layouts, level progression, and strong visual feedback.
The main gameplay flow is:
Hold → Stretch → Avoid Hazards → Grab Target → Retract → Reaction → Result
Each mission uses the same core mechanic while introducing different victims, targets, environments, hazards, and difficulty.
2. The Stack
The Stack: HTML5, Vanilla CSS, JavaScript, and HTML5 Canvas.
The project uses PNG/WebP assets for characters, environments, targets, props, and hazards. Canvas is mainly used for the dynamic stretchy-arm mechanic, collision handling, hitboxes, and lightweight gameplay effects.
The AI Assist: ChatGPT handled concept analysis, gameplay planning, UX flow, mission structure, responsive requirements, visual direction, and technical prompts. OpenAI Codex was used for the coding and implementation phase, translating those requirements into the working HTML, CSS, JavaScript, game logic, asset integration, and responsive system.
No MVC architecture or frontend framework was required.
3. The 1 Day Sprint
Morning (Hours 1–3): We started by analyzing the core stretchy-hand puzzle mechanic and defining a simple gameplay loop. The first goal was to make one mission playable before expanding the game. We planned the thief, victim, target, stretchy arm, collision system, success/fail states, and direct hold-and-drag controls. We also established the 2D cartoon visual direction and started building Mission 1 as the reference implementation.
Afternoon (Hours 4–6): The main development and debugging phase focused heavily on gameplay presentation. The first versions had several problems: characters looked like basic stick figures, the art styles were inconsistent, the stretchy arm looked like a tube or repeated image segments, the arm connected to incorrect parts of the thief's body, targets sometimes appeared in unnatural positions, and character poses did not match their environments. We repeatedly tested and improved the arm socket, target anchors, hitboxes, grab/retract behavior, character reactions, and illustrated assets.
We then expanded the mission system so different levels could have their own victims, targets, locations, hazards, and difficulty while sharing the same core gameplay engine.
The Finish Line (Hours 7–8): The final stage focused on UI/UX, responsive behavior, mission variety, and QA. We reviewed the Home screen, Mission Select, How to Heist, gameplay HUD, Pause, Win, Lose/OOPS, Retry, Next Level, and other popup states. We also tested mobile, tablet, laptop, and desktop layouts to reduce cropping, overlap, broken scaling, and mismatches between visual sprites and collision coordinates.
The game was also expanded with multiple unique missions, character reactions, progression, scoring, sound/music support, and a more complete game flow.
4. The Roadblocks
Roadblocks: The biggest challenge was achieving consistent visual quality while keeping the gameplay system functional.
Early versions technically worked but did not look like a polished game. Characters were initially drawn using simple shapes and later became inconsistent when detailed character images were combined with primitive Canvas backgrounds. This made the game look like different art styles had been pasted together.
The stretchy-arm system was another major problem. An early implementation repeated arm-segment images along the player's path, which created visible joints and jagged edges. Later versions used a smoother Canvas arm, but the arm sometimes connected to the thief's hip, chest, or other incorrect locations instead of the shoulder/sleeve.
Character and target positioning also required significant work. Victims sometimes looked like stickers placed over backgrounds rather than characters naturally standing or sitting in the environment. Target items could float or appear in incorrect positions because the visible target and gameplay hitbox were not always using the same anchor.
Mission variety became another challenge. Reusing Mission 1's implementation caused some later missions to use placeholder-style scenery, repeated victims, incorrect character positions, or the same reaction artwork. The solution was to separate shared gameplay logic from mission-specific configuration and assets.
Responsive design was also difficult because scaling the visual scene without scaling character anchors, arm sockets, targets, and collision geometry together could make gameplay look correct while the actual interaction coordinates were wrong.
5. Key Takeaways
**What was the part that worked the best?
** The shared gameplay architecture. Once the core flow of hold, stretch, avoid, grab, retract, react, and result was clearly defined, it could be reused across multiple missions. Separating shared mechanics from mission-specific data also made it possible to create different victims, locations, targets, and hazards without rebuilding the complete game for every level.
**What was the part that worked the worst?
** Visual consistency and AI interpretation of character interaction. Broad instructions such as "make it polished" or "make the character dynamic" were not specific enough. Codex often solved only the visible symptom instead of the complete system. Better results came from defining exact requirements such as stretchArmSocket, targetAnchor, character states, hitbox synchronization, crop-safe assets, and explicit acceptance tests.
Another important lesson was that generating more artwork does not automatically improve a game. The background, characters, props, target placement, scale, perspective, animation, and interaction all need to agree with each other. A high-quality character asset can still look bad when it is positioned incorrectly or combined with a completely different environment style.
My final thought: If I had one more day, I would spend most of it on complete mission-by-mission QA rather than adding more features. I would manually review every mission's character placement, victim actions, target anchors, hazard routes, difficulty, win/lose reactions, sound effects, and responsive behavior across mobile and desktop devices.
If I could redo the project, I would first finish one complete "gold standard" mission—including gameplay, artwork, character states, sound, responsive behavior, and result screens—and only then use that architecture to build the remaining missions. This would reduce repeated fixes and make the entire game more visually and technically consistent.