Gameplay
Playing animations
Fruitss
Big wave incoming
Perfect wave!
Powerups and bombs
Introduction Screen
Come play
Leaderboard!
Menu

Slicer - Devpost submission text

Tagline: Slice fruit with your bare hand: your webcam is the controller and your fingertips are the blades.

Inspiration

We wanted a game anyone can play with nothing but a laptop and a hand - no controller, no headset - and bright enough that a kid and a grandparent would both want a turn. Fruit-slicing is the perfect fit: the gesture is obvious, but making a camera feel as responsive as a touchscreen is a real engineering puzzle.

What it does

Slicer is a webcam fruit-slicing game. MediaPipe tracks your hand and every fingertip becomes a glowing blade: touch a fruit with the blade and it is cut. There are 15 fruit (each with its own art, cut face and juice), 7 power-ups (Freeze, Frenzy, Double Points, Big Blade, Shield, Extra Heart, Bomb Clear), 3 kinds of bomb (plain, fast, and cluster bombs that split into small bombs), combos, streaks and "perfect wave" bonuses, three solo modes, three difficulties and a 2-player split-screen duel. A pineapple mascot named Pip reacts to everything. Menus work by hovering a fingertip on a button, and the mouse works too.

How we built it

Python with OpenCV (capture, drawing, window), MediaPipe Tasks HandLandmarker (21 hand landmarks), NumPy (procedural art and audio synthesis), Pillow (text) and pygame's mixer (sound). A camera thread runs capture and tracking so a slow detection never stalls the game; fingertips go through a One Euro filter with teleport rejection and prediction through short dropouts; the game runs on fixed 120 Hz physics. Every fruit, the mascot, the UI, the leafy border, all sound effects and the adaptive music are generated by code - the only bundled asset is one font. A difficulty director and 11 wave patterns drive the pace, and a human-like bot plays thousands of simulated seconds headless to balance it.

Challenges we ran into

MediaPipe removed mp.solutions, so we moved to the Tasks API and a downloaded model, with a mouse-mode fallback.
Camera plus detection adds ~70 ms, so "is the blade on the fruit now?" missed fast swipes. We test each blade segment against the fruit rewound to the moment the camera saw the finger, and also test the whole drawn trail, so what is drawn is what cuts.
Smoothing vs. lag: in simulation our first filter trailed a fast swipe by up to 31 px; retuning cut that to 7 px.
Tracking drops when the hand blurs. Prediction through dropouts raised the share of fruit cut in simulated fast swipes with dropouts from 80-96% to 95-100%.
A soak test found a memory leak (caches bounded by count, not bytes) that unit tests could not.
Balancing a game with waves of 3-5 objects every second took hundreds of bot games.

Accomplishments that we're proud of

633 automated tests and a 32-game-minute soak test that passes with flat memory (189 screens, 20 games, no exceptions).
Fast play: about 93 FPS with the camera running and 113 FPS without, in a bot-played busy game on our laptop.
A game with no image or audio assets: ~22,700 lines of Python generate everything.
A fairness guarantee we can test: every fruit always has a cut that stays clear of every bomb.
Hover menus that cannot double-press, a restart screen instead of a vanishing window, and a rotating log for diagnosing problems.

What we learned

Measure before tuning (simulate the filter, the dropouts, whole games). Use one source of truth for what is drawn and what is hit. Bound caches by memory, not entry count. Long soak tests find what unit tests miss.

What's next

More webcams and lighting conditions, testing the duel with two real players (so far validated with bots and mouse input), online play or a shared high-score board, more modes such as a daily challenge, and a one-click installer.