Maze_GamePlay
Maze_LeaderBoard
Maze_Main
Maze_ChooseItem
Maze_HowToPlay

Inspiration

Most Reddit games are solo experiences: you open a post, play, and leave nothing you do touches anyone else. That felt like a waste of what makes Reddit Reddit: people drop into the same thread at completely different times, and their traces still matter to whoever shows up next (a comment, an upvote, an edit). We wanted a game where that async pattern is the hook, not an afterthought.

We considered a few other concepts a daily "verdict" voting game, a community garden, a word-chain relay, a Hot & Cold guessing game but all of them either leaned on plain Reddit-native features (votes/comments) without adding much of our own, or risked feeling too close to existing subreddit games. The maze idea won because it let us build genuine indirect interaction: you never see another player in real time, but you constantly feel them through the footprints they left, and the traps they set.

What it does

Maze Footprints is a top-down grid maze covered in fog of war. Your own screen only stays lit where you've personally walked, and that's local, client-side state, not shared with anyone. What is shared is the footprints you leave behind, though only a random subset of the tiles you walked ever get shown to later visitors, so your full path is never fully given away, only soft hints about where it goes.

Scattered across the maze are mystery boxes. You don't know if a box holds a helpful item (flashlight, shield, trap detector, or trap-install) or an environmental trap (slide, respawn, blind, or reverse) until the moment you step on it. Players can also actively install traps of their own, and anyone who isn't the installer can trigger them. Once fog reveals the tile, a trap's position is always visible as an unmarked box indistinguishable from an unopened mystery box, and a trap detector item lets you scan the tiles around you to briefly reveal what type each nearby trap actually is. Before each run, players also pick one item as a starting loadout.

Clearing the maze is scored by step count, where the fewest successful moves wins and clear time is used only as a tiebreaker. The leaderboard, footprints, traps, and mystery box spawns all reset daily at midnight. Which of our two hand-built maps shows up on a given day is picked deterministically from a hash of the date, so the whole community races the same maze on the same day.

How we built it

The stack is Devvit Web with React for the splash screen, menu, loadout picker, and leaderboard; Phaser for the actual maze gameplay screen (game.html), handling grid movement, fog rendering, and trap and item effects; and Devvit server with Redis for everything that has to be shared, such as footprints, trap boards, mystery box outcomes, and rankings, all reached through tRPC and Hono API routes.

We were a team of three with clearly split ownership across gameplay and Phaser, backend and async data, and UI, content, and integration. We spent the first two days aligning on the shared Redis data schema and shared/ types together before splitting off, and kept footprint rendering on the client and footprint storage on the server moving in lockstep throughout, since a mismatch between the two breaks the whole hook. Cross-boundary edits were allowed when someone needed to unblock themselves quickly, as long as the area's owner was looped in as a reviewer.

Challenges we ran into

The first challenge was keeping trap information fair to discover without turning the reveal mechanism into a map-scanning oracle. If players could freely query what's near them at any time, they could script a full map reveal. We settled on two separate layers: a trap's position becomes visible to everyone once fog uncovers that tile, shown as the same unmarked box used for mystery boxes, while its actual type stays hidden until someone steps on it or scans it with a trap detector item, and the detector itself is only allowed to scan off an event the server already validates for position, such as a real movement or a real pickup, rather than a free-standing scan endpoint. We arrived at this split only after playtesting exposed real frustration from players getting hit by installed traps whose positions were never shown at all; the design started out with trap positions fully hidden and opened up to always-visible positions, with types still hidden, in response.

The second was a same-day merge collision between two branches that had redesigned the same system differently. One branch reworked random spawns into mystery boxes with a new response contract, while another branch redesigned the map layout with new coordinates. Reconciling meant picking the validated post-redesign coordinates and patching the client to the new contract, verified by the full regression suite before merging.

The third was a TOCTOU race in the trap detector's charge counter, found during our own PR self-review. Two near-simultaneous detector uses could both pass a "do I have a charge" check before either decrement landed, letting one charge power two reveals. We fixed it by making the decrement atomic first and rolling back on failure, with dedicated regression tests that reproduced the race against the old code.

The fourth was fog of war that behaved like a flashlight. The vision radius itself was correct, but distance was computed as straight-line Chebyshev distance, so light leaked through walls into adjacent corridors. Swapping to a wall-aware BFS made the fog respect the maze's actual walls.

The fifth was a leaderboard-forging bug found one day before the deadline. While self-grading against the judging criteria, we noticed the finish-line endpoint never actually validated that a player's reported position matched a real exit tile, meaning a crafted request could claim any step count. Fixing it correctly, and then discovering our first fix accidentally rejected every legitimate finish, was a scramble we caught only because we reviewed our own pull request before merging it.

Accomplishments that we're proud of

We're proud of building a real, working example of async-first design, where footprints and traps let players who are never online at the same time genuinely affect each other's runs, which is the exact hook we set out to build. We're also proud of the deterministic daily map rotation, a small piece of infrastructure that hashes the KST date to pick between two maps and makes sure the whole subreddit is racing the same maze on the same day, every day. We're proud that we were willing to redesign the trap-detection system several times mid-hackathon based on real playtesting feedback rather than shipping the first version that technically worked. And we're proud of catching a leaderboard-forgery vulnerability the day before submission through our own review process, instead of after launch.

What we learned

We learned that async social mechanics demand a very deliberate line between shared server state, such as footprints, trap boards, and mystery box outcomes, and personal client state, such as your own fog of war. Blurring that line either breaks privacy expectations or breaks the hook itself. We also learned that letting teammates cross into each other's owned code when blocked, with a mandatory reviewer from that area, kept us moving fast without losing accountability. And we learned that reviewing our own pull requests before merging, rather than relying solely on the other reviewer, caught two of our most serious bugs, the detector race condition and the leaderboard-forgery gap, that automated tests alone hadn't surfaced yet.

What's next for Maze FootPrints

Next up is a user map editor so players can design and share their own mazes as new posts, which was deliberately scoped out of the MVP and is our top candidate for a post-hackathon stretch. We also want wider playtesting to tune the remaining assumed balance numbers, such as trap detector radius and duration, per-trap install caps, and mystery box outcome odds. Finally, we're interested in exploring lightweight social features, such as inviting a friend or simple team runs, if daily-reset retention data after launch suggests players want more direct connection on top of the async hook.