Inspiration
The original Flappy Bird has been gone a long time. Removed by its own creator… Plenty of people have thrown out their own spins since - websites, apps, you name it - but none ever quite matched its charm.
When someone new gets into game dev, the first advice they hear is "start with a Flappy Bird clone!" It's basically a rite of passage - which is exactly why your feeds fill up with people showing off their version, usually with some ridiculous sprite or mechanic swapped in. I saw some really funny ones posted as memes online - and that's the bit that stuck with me.
Everybody makes a fun clone. So I thought... what if, instead of adding one more to the pile, I built the machine that makes all of them? One to rule them all. Whether you want to make a meme, a challenge, news, culture, fan-art - whatever it is.
The idea sat in my head gathering dust for months, and the thing holding it back was never the code - it was distribution. Release it as a .io game maybe... but for games to be saved and shared, people have to sign up first - and who signs up for a .io game? How do I build a social layer into it? This is turning from a fun game into a massive project quickly…
Suddenly - Reddit has games! A Reddit post is the save file, the share button and the comment section, all in one. Add Reddit's meme culture on top and it's basically perfect for this type of UGC game. Perhaps I am building the first playable meme format?
A little while later a Devvit Hackathon appears. Since all the stars aligned - I simply had to do it!
What it does
Simple. Mess around and build your own flappy styled game. Upload art for the bird, pillars and background - or just one of them. Want to just play with the gravity? Go for it. No requirements!
A little wizard walks you through it step by step (bird → pillars → sky → tune) and gently stops you posting until nothing's missing - so your own custom game is only about 10 clicks away (but you can also dig deep and make something truly unique and special).
The asset pipeline is where the real magic lives. Upload any image, or even an animated GIF, and it stays animated in-game - your bird, your pillars, even the background can be a living, looping GIF. A little masking tool auto-crops your upload (you can still set the crop and collisions manually), then lets you rotate, flip, zoom and drag it without wrecking the quality (auto-crop works on GIFs as well - with collisions!).
Then tweak whatever you like! Shove the pillars close together. Make your bird absolutely massive. And for the tinkerers, there's a whole extra layer hiding underneath: two pillar sprites that alternate as you fly, proportional or stretched pillars, Tap (classic flap) vs Hold (jetpack-style thrust) controls, full physics sliders, one-click random world-colours, a Randomize button for happy accidents.
And the best part? Post it! Every game goes up as a proper Reddit post from your own account - its own top-3 leaderboard, a real unique-player count, playable right there in the feed or fullscreen, on any device. Which means every player is one "pfft, I could make a better one" away from becoming a creator - and every creator drops a brand-new game into everyone else's feed. The content never runs out, because the community is the content.
How we built it
Being most at home with web tools, I took the "demo website" route first: a rough NextJS version just to see if the mechanics were even feasible - specifically the customization side, which was the scary part. Collision and cropping on unpredictable, user-uploaded art is a whole different beast from a fixed sprite! The plan was to de-risk: prove the hard thing works in a stack I already know, so porting it later would be a translation job, not a design job. Once I was happy, I committed to porting it over to Devvit and tailoring it properly for Reddit.
Under the hood, the stack itself is in the tags - what matters is how it's put together. Client and server share the same request/response types end-to-end, so the API can't silently drift out of sync. The game itself is a hand-written Canvas 2D engine - no game framework. The loop is delta-time scaled (and clamped, so a random lag spike can't teleport your bird straight into a pillar), which keeps it feeling identical across refresh rates and devices. All in, it's roughly 6,600 lines of TypeScript across the engine, the editors, the optimizer and the server. Even the little stuff is handmade - procedurally textured ground, and random world palettes generated in HSL with hue/lightness separation rules so a "random" world never comes out unreadable.
Naturally, AI was part of the workflow - mostly for prototyping concepts and debugging (lots of it…). The initial UI sketch came out of v0 by Vercel, and from there I moved into Cursor where I do the majority of my development. Learning the Devvit ecosystem was really fun.
Challenges I ran into
1. Simplicity or features? A game this customizable can go two ways - a simple, fun toy for the average Redditor, or a fully fledged game design tool. I decided to balance this very carefully, so that everybody can have some fun. Sensible defaults, auto-crop and a Randomize button mean a 3-asset game takes about 10 clicks - yet every advanced setting sits one layer deeper, out of the way, until a determined player wants to make something truly unique.
2. Collision collision collisions. How do we make them accurate - especially with totally unpredictable, user-uploaded assets? The answer: every asset gets a real polygon hitbox, tested with the Separating Axis Theorem rather than a lazy bounding box. Players can even draw the outline themselves, and I auto-simplify it with the Douglas–Peucker algorithm, so a shaky hand-drawn scribble becomes a clean, fast hitbox - even on mobile.
The real hero here is auto-crop. Do users really want to manage their own collision boxes? Probably not. It's secretly a little computer-vision engine running right in the browser: transparent PNGs take a fast path straight off their alpha channel, while opaque photos get the full treatment - sample the border pixels, run a tiny 2-means colour clustering so two-tone backgrounds (sky above, ground below) are both recognised, flood-fill the background away, keep the largest blob, trace its outline with Moore-neighbour contour tracing, then simplify it into a polygon. And if it guesses wrong? Press Auto Crop again - it cycles through three tolerance presets instead of giving up. Still not good?? Just draw the collision yourself in a few seconds :)
3. Speed, speed, speed. Users can upload their own images and GIFs and draw their own collision shapes - so how do we keep this buttery smooth, no matter what? GIFs were the villain of this story. Decompressing every frame at once OOM-crashes the tab on long GIFs, so I stream-decode one frame at a time. Then came the ghost bug: a tiny stutter exactly where the GIF looped. Turned out separate per-frame canvases were getting evicted from the GPU, so wrapping back to frame 0 hit a cold texture every single loop! The fix was to pack every frame onto one spritesheet - one warm texture that never gets kicked out - while staying under iOS Safari's ~16.7-million-pixel canvas ceiling. GIFs had one last trick, too: you can't re-encode them in the browser. So when someone rotates or flips an animated sprite, I don't bake it into the pixels - I store the transform and apply it algebraically at decode time. Lossless, and it feels identical to the still-image path.
4. The 4 MB tightrope. Devvit actually gives you a 20 MB media pool - and I deliberately didn't touch it. I wanted every game to be fully self-contained in its own 4 MB post: one payload, nothing external to fetch, so a game loads instantly for someone mid-scroll on mobile data and can never half-load with missing art. Simplicity and speed, over raw headroom. Of course, users can still upload whatever chunky art they like! So there's a payload optimizer that hands each asset its own byte budget - the background gets the biggest slice (large, always on screen), while the bird and pillars get squeezed harder (small, moving, nobody notices) - then compresses in priority order until the whole thing fits.
5. The "impossible game" problem. With proportional pillars, a weirdly-shaped upload could technically grow wide enough to seal off the passage entirely - an unbeatable game. So the geometry floors the horizontal spacing based on the widest a pillar could ever get. Roughly:
$$ \text{spacing} \ge w_{\text{max}} + g_{\min} $$
where $w_{\text{max}}$ is the worst-case pillar width for the current world and $g_{\min}$ is a guaranteed clear gap. The result? Every posted game is mathematically guaranteed to be solvable. Total creative freedom for the player, with guardrails quietly enforced by maths.
6. And the smaller ones. Two players setting a high score in the same instant? Handled with optimistic Redis transactions and a retry loop. Reddit user-lookups randomly throwing a 403 mid-playtest? Caught and handled gracefully instead of crashing the post. Had some issues early on sizing the game correctly for all the screen sizes and viewports - but honestly, thanks to how flexible Devvit turned out to be, I never really struggled to find an elegant solution to any of it.
Accomplishments that we're proud of
The custom collision workflow is the thing I'd show off first. Anyone can hand-draw a hitbox around their own upload, right on their phone, and get accuracy that actually holds up in play - the scribble becomes a clean polygon, tested properly with SAT, so when your bird clips past a pillar by a pixel, it feels fair. And most people never even need to touch it, because auto-crop quietly does the whole job for them. Getting that level of accuracy without asking the user to care about it took the most iteration of anything in the project, and it's the part I'm proudest of.
But the accomplishment that surprised me? The community out-imagined me. People started posting games I never saw coming - jets and planes gliding through low gravity, things that weren't really "flappy" at all. That's actually where the Tap vs Hold controls came from: watching people bend the physics toward jetpack-style flight and realising the game wanted a thrust mode. When your users start designing your feature roadmap for you by playing, you know the UGC loop is genuinely working.
Simplicity and speed stayed sacred the whole way through. A complete custom game is still only about 10 clicks, and every post loads instantly in the feed - self-contained, no waiting, smooth on a phone in a Reddit webview even with someone's monstrous GIF as the bird. It would have been so easy to let features pile up and bury that. They didn't.
FlappyLab also hit the first Reddit Developer Funds tier - real players, organically, from the feed. Genuinely surreal to watch a months-old shower thought cross an actual milestone with actual numbers behind it.
And honestly? The accomplishment that felt the best: my friends laughing at the ridiculous games we made of each other (most were not posted). That was the whole thesis - the playable meme format - working exactly as intended, in person, before a single stranger ever played it.
What I learned
Reddit is a seriously powerful platform for games, especially UGC ones. I honestly can't think of anywhere else that intertwines so nicely with this concept - because on Reddit, the post is the distribution unit. Every game someone makes arrives into the world already carrying a comment thread, a share button, an author and a moderation system, all for free. It's just perfect. Cross-posting is also a strong asset!
I also learned to love constraints. The 4 MB payload budget, the serverless Redis quotas, the webview performance ceiling - each one annoyed me for an afternoon and then forced a better design than I'd have reached with no limits at all. Building for a UGC platform rewired how I think, too: you don't engineer for the average input, you engineer for the worst one. Every feature had to survive some absolute legend uploading a 450-frame, 4096px GIF as their bird.
And along the way I picked up a whole pile of browser internals I never expected to learn from a bird game - GIF disposal modes, GPU texture eviction, iOS canvas-area limits. The social side really opened my eyes to what's possible here, and this definitely isn't my last game on the platform. There is so much untapped potential combining a forum styled social media platform with playable games - I have some more ideas up my sleeve!
What's next for FlappyLab
I've had many requests for new features - custom SFX, a level editor where hitting a certain score unlocks a whole new environment, and so on. Next on the list: the ability to remix other people's games. This was actually requested by a user. How did I not think of this?? Maybe you love someone's environment but just want to see how a different bird looks - and every remix is another post, another leaderboard, another thread. It's really great getting feedback from people, and as the community grows I'll start running polls on what to build next - then build it.
A Daily Challenges pipeline is also in the works. I love that anybody can make and post their own games, but a set of highly tailored, quality Daily Games would give the community something to come back for every single morning - perhaps in collaboration with other subreddits to feature them and their community.
As far as a path to growth, I believe short-form content is our strongest ally (hence the persistent r/FlappyLab watermark in the ground). A humorous game such as this has great potential to bring new players onto Reddit from other platforms. I've already had comments on TikTok asking: "Where can I download this game?" - little did they know, you can simply play it on Reddit, as well as play other people's versions and even make your own!
Built With
- devvit
- express.js
- html5
- javascript
- node.js
- react
- redis
- tailwindcss
- typescript
- vite
Log in or sign up for Devpost to join the conversation.