The Daily Zomble

A one-control zombie survival game where each day's winners rewrite tomorrow's rules for everyone.

Comment

The Daily Zomble

A one-control zombie survival game where everyone plays the same run each day and the winners rewrite tomorrow's game for the whole subreddit.

Inspiration

This game is a mash-up of three games I love:

  • Realm of the Mad God — the top-down, dodge-and-survive feel where movement is everything. I grew up playing this, probably my favorite game of all time.
  • Call of Duty Zombies — seeing how long I could last against an endless, growing horde.
  • Wordle — everyone gets the same puzzle each day, and half the fun is comparing results with everyone else.

I wanted to blend the tension of a "one shared challenge a day" ritual with a survival game and then push it one step further: instead of just comparing results, the people who win get to reshape the game everyone plays next. That felt like a hook that only really works on a platform like Reddit, where a whole community shows up to the same post. I wanted this to have as little friction as possible: one control, works on all devices, no popups or menus, jump in and play right away.

What I learned

I did not come into this with a lot of game-development experience, so almost all of it was new. I have a math and software background, but really wanted to challenge myself and build a fun game. Watching a pile of static sprites turn into a living game as I connected the pieces was incredibly fun. Here are some of the specific things I learned:

  • Sprites & animation — spritesheets, frame animations, and little tricks like starting each zombie on a random animation frame so the horde doesn't move in lockstep.
  • Sound — wiring sound effects to gameplay moments (fire, hits, explosions, death) and realizing how much audio does for feel long before the visuals are finished. I had way to much fun listening to "zombie sound effects" that people posted online and used some of the ones (under CC0) that made me laugh the most.
  • Game feel — camera shake on death, a "stomp" animation on the title and score, pulsing buttons. These tiny touches I didn't realize I needed until I was playing other games for inspiration.
  • The loop — how the update loop, input, physics, spawning, and UI all have to cooperate every single frame.

Alongside the game itself, I learned Reddit's Devvit platform: running a real-time game inside a post's web view, backing it with a server and a database, posting comments (as the player), and scheduling background jobs. I also talked to a lot of users to understand how they play and what could be improved: it was through this I settled in on things like the spawn rate, gun damage, weather conditions, and found a lot of hitbox bugs. I learned a lot of valuable communication skills through this. I had a lot of fun and will be creating more games in the future.

How I built it

The game runs on Phaser in the post's web view, backed by a small Hono server and Redis on Reddit's Devvit platform. A few design choices I'm happy with:

  • One control, and that's the whole game. You point; your survivor runs toward the cursor and fires automatically. The player's facing angle is just

$$\theta = \operatorname{atan2}(\Delta y,\ \Delta x)$$

and everything else, weaving through the horde, lining up shots, falls out of that single input. No buttons, no menus.

  • The same run for everyone, generated from the date. Rather than store a "map of the day," the entire day's configuration is produced by a seeded pseudo-random generator keyed to the date. Every player on a given day gets the identical map and settings, Wordle-style, with zero luck of the draw. I also wanted to hide the daily high score, the daily modifiers, and map layout so that everyone coming in has the same information. You can also practice, but you must complete your daily ranked run first!

  • The server is the referee. The leaderboard is a Redis sorted set, each player gets one ranked run per day, and no score is trusted from the browser, it's re-checked on the server (more on that below).

  • The hook, as a daily pipeline. When you beat the high score, the server hands you one of tomorrow's four still-open settings; you lock in a value, and a background job finalizes anything nobody claimed. Tomorrow's world is then the seeded config, overridden by yesterday's winners' picks. Nobody sees it until it goes live.

  • Clean scene flow. Boot → Preloader → Title → Tutorial → Game → Game Over, with a separate Practice mode that never touches the leaderboard, so the ranked run always stays "one shot, everyone blind."

Challenges I ran into

Teaching a horde to chase you well. This was my favorite problem. A swarm that just walks straight at you looks terrible, everyone clumps into a single-file line and piles up against the first crate. I ended up with a flow field: the map is a grid where I compute (from the player outward) the direction each cell should push toward, rebuilt on the fly as moving hazards like fire appear, and each zombie simply steps "downhill" toward you while routing around obstacles.

The magic ingredient was controlled randomness. Each zombie carries its own weave, an oscillating offset is added to its heading. They all still reach you, but they spread across angles and arrive from every direction instead of a neat conga line. I also gave each one a staggered re-route timer so it commits to a heading and only re-decides on its own schedule; without that, zombies jittering across a grid boundary would flip direction every frame and vibrate in place. I learned that the hard way after lots of testing.

Race conditions in the server logic. Two features had classic concurrency traps. The "one ranked run per day" and "the first players to beat the record claim tomorrow's settings." I used atomic Redis operations (hSetNX, "set only if absent"), so of any two racing requests exactly one wins the slot and the other is cleanly turned away, no double-writes. Although this is extremely unlikely to happen in a small game, I wanted to design with best practices in mind.

Anti-cheat for a game that runs in the browser. Since the simulation lives on the client, a tampered browser could just claim a huge score. So the server bounds every claim against physical reality: survival time is server-stamped with a run token and kills can't exceed how many zombies could even have spawned by then. There is a lot of room for improvement with this anti-cheat, but I'm satisfied with this solution for now as I was more interested in making the game fun for the Hackathon.

Learning as I went. And underneath all of it, this was my first real game, so a lot of the challenge was simply figuring out how the parts fit together: getting sprites, sounds, physics, and UI to cooperate into something that feels good to play.

Notes & extras

Built with: TypeScript · Phaser 4 · Devvit (Reddit Developer Platform) · Reddit API · Redis · Hono · Vite · Node.js.

  • Fresh every day at midnight Pacific. A brand-new map, a clean leaderboard, and whatever twist yesterday's winners left behind.
  • The four daily settings winners can set: weapon (Pistol / Machine Gun / Shotgun / Railgun), weather (Clear / Rain / Fog), fire direction, and starting health: each guns/weathers changes how the whole run feels.
  • Share your run with one tap: copy your result, or post it straight into the comments as you (the comment is built from your verified leaderboard standing on the server, so it can't be faked).
  • Recognition: each day's winners are credited on the next day's twist, and the current #1 is shown on the home screen.
  • Runs everywhere the same — phone, tablet, or desktop, and you're in a game within a couple of seconds.
  • Credits: map/tileset by ittaimanero (personal and commercial License), sound effects from various Freesound creators under CC0, plus custom-made art. Full attribution is on the in-game Credits screen.

I hope you enjoy playing it as much as I enjoyed building it.

Share this project:

Updates

Submission history