DEV Community

Cover image for I made Snake. Then I kept going.
PRANTA Dutta
PRANTA Dutta

Posted on

I made Snake. Then I kept going.

So here's a thing that happened.

A few months ago I thought, "I should build a small Flutter game to sharpen up my custom painter / animation chops. Something simple. A weekend project." I picked Snake. The 1997 Nokia kind. Eat the dot. Don't hit the wall. Don't eat yourself. That's the entire game.

That was a few months ago. I now have:

  • A multiplayer Snake matchmaking system.
  • A tournament platform with six game modes.
  • A frame-by-frame replay viewer.
  • A push notification backend in FastAPI.
  • Sixteen achievements with a rarity system.
  • A friends list with online presence.

For Snake.

This is its story.

What it actually is

The project is called Snake Classic, and you can find the source on GitHub. It's a Flutter app targeting Android, iOS, web, and desktop. The core game is exactly what you remember — 20x20 grid, snake, food, walls, regret. 60 FPS, custom painter, smooth swipe gestures. About a weekend of work.

The other 95% of the codebase is what happened after that.

Here's a tour of the over-engineering, in roughly the order I built things.

"I should add themes"

The very first slippery slope. Snake is monochrome by tradition, but Flutter makes it so easy to swap palettes that I added a "Modern" theme alongside Classic. Then Neon, because I wanted to play with glow effects. Then Retro for the vintage vibe. Then I thought "the snake should travel through space," so Space. Then Ocean, because at that point why not.

Six themes. With a dedicated theme selector screen. With live previews. For Snake.

"I should add sound"

audioplayers package, three sound effects, done. Except now there's a crash sound, a food_eat sound, a level_up sound, a button_click sound, a high_score sound, and background music with independent volume controls. There is more audio engineering in this app than in some games I've actually paid money for.

"I should add a high score"

This is where it really started.

A local high score is just SharedPreferences. Easy. But what if you play on two devices? Need to sync. So Firebase Auth. Anonymous accounts for guests. Google Sign-In for people who want their score preserved. A migration flow to upgrade a guest account to a real one without losing data.

And if I have user accounts, I might as well have leaderboards. Global. Weekly. Friends-only with podium displays. That requires a Firestore schema, real-time listeners, pagination.

And if I have friends, I need a friends system. Search by username. Send requests. Accept/decline. Online status indicators ("playing", "online", "offline"). Username reservation logic so two people don't grab the same name.

For Snake.

"It would be cool if you could replay your best game"

Reader, this is where a normal person stops.

I built a frame-by-frame recording system that captures the full game state every tick. Compresses it. Uploads it to Firebase. There's a replay browser organized by "Recent", "Best Performances", and "Crash Analysis". You can scrub the timeline. You can change playback speed. You can analyze why you crashed — wall collision vs. self-collision, with visual indicators.

Imagine telling someone in 1997 that one day they'd be able to slow-mo a replay of their Snake death and study it like Zapruder film.

"Multiplayer would be fun"

Two snakes. Same board. Firebase Realtime Database for live state sync. Quick match for instant pairing. Private rooms with shareable codes. Lobby UI with player ready states. Four game modes for multiplayer specifically. Cross-device, so you can play your friend on iOS while you're on web.

I have not actually convinced anyone to play it against me yet. The matchmaking system works fine. It's just that no one has matchmade.

"What if there were tournaments?"

Daily challenges. Weekly championships. Monthly events. Six tournament game modes including "Perfect Game" (one mistake and you're out) and "Power-up Madness" (chaos). Real-time tournament leaderboards. Tournament rewards. A tournament history screen.

Yes — I implemented power-ups too. Four of them: Speed Boost, Invincibility, Score Multiplier, Slow Motion. Each with a circular progress timer in the HUD. Each rendered differently per theme.

"Achievements"

Sixteen of them. Four rarity tiers from Common to Legendary. Categories for Score, Games Played, Survival, and Special Feats. Animated unlock notifications with particle effects. A browser screen with filtering. Progress bars on locked ones.

Achievement Unlocked: Scope Creep Survivor (Legendary)
Build a side project that grew 50x larger than you planned and still ship it.

(That one's not in the game. Yet.)

"Push notifications"

This is where I crossed a real line.

I wrote a separate Python backend. FastAPI. APScheduler for scheduled notifications. Firebase Admin SDK on the server side. Pydantic for validation. A whole notification service running independently so the game can ping you about "tournament starting in 1 hour," "your friend challenged you," "you haven't played in 3 days, here's a comeback bonus."

The notification_backend/ folder has its own README. Its own requirements.txt. Its own test suite. It is, by any reasonable definition, a microservice.

For a Snake game.

"I should add a statistics dashboard"

50+ tracked metrics. Games played, average score, survival rate, food consumption patterns, power-up usage breakdowns, collision analysis, streak tracking, session length distributions. Performance trend charts. AI-generated insights based on your play patterns.

I know more about how the average user plays my Snake game than most apps know about anything.

So what did I actually learn?

This sounds like a self-roast, and it kinda is, but I want to be real about why this is actually fine.

1. Snake is a perfect scaffolding for learning everything. The game loop is trivial, which means you can pour all your energy into the systems around it. Firebase auth flows, real-time multiplayer, push notification deep linking, replay encoding — every single one of these is a transferable skill I now have working production code for. Try learning Firebase Realtime Database multiplayer on a side project you also care about creatively; you'll get demoralized. On Snake, the stakes are zero. You just ship.

2. Premature features are still real practice. Did I need power-ups in Snake? No. But building the power-up timer system taught me a clean pattern for time-bound state in Flutter that I've already reused in a different app. The replay system gave me a battle-tested approach to compressing time-series state. The tournament system is just a CRUD app with extra steps, but that scheduling code is good.

3. Side projects don't need to be "minimum viable." They need to be fun to work on. The "MVP" doctrine is great when you have customers waiting. When the customer is just you trying to keep yourself engaged for six months, "Wouldn't it be funny if Snake had a tournament system" is a valid product decision.

4. The architecture got better the bigger it got. Look at the project structure — clean separation of models/, providers/, services/, screens/, widgets/. Beautiful debug logging with Talker categorized by service. Offline-first data sync with a queue. Stuff I would have hand-waved past in a weekend project, but had to do correctly once the system got big. The big system forced the discipline.

The code

It's all open source — github.com/theprantadutta/snake_classic. MIT licensed. 97.8% Dart per GitHub. Fork it, study it, laugh at it, learn from it. The README has setup instructions, screenshots, the works.

Get it on Google Play

If you've been sitting on a side project that you keep dismissing as "too simple," I'd gently suggest: build the simple thing. Then keep going. See how far it goes. The detour is the point.

I built Snake. Then I kept going. You should too.


I write about Flutter, full-stack dev, server ops, and apparently now confessional posts about over-engineering. Follow along at pranta.dev or here on Dev.to.

Top comments (0)