mainmenu
game beetles
game drought
How to Play

Inspiration

Most "Reddit games" are a solo mini-game with a leaderboard bolted on — you play alone and the community is just chrome. But this hackathon is a retention contest about games that turn the comment section into the gameplay. So we inverted the usual design: instead of thousands of people each poking their own save file, what if an entire subreddit shared exactly one save file and had to defend it together, one day at a time?

That became Hive Siege — one living bee-hive per subreddit. Every day a new threat arrives, and the community collectively votes on how to respond. Your vote is one of many. What actually happens is what the swarm decides.

What it does

Open the post and you see the hive's HP, its resources and buildings, and today's threat — Wasps, Beetles, a Drought elemental, or hooded Raiders — squaring off against the Hive Queen.

Then the daily loop (the hook):

Vote on the plan. Tap Fortify / Deploy / Build / Forage / Gambit in the app, or type !vote deploy right in the comment thread — both count.
A daily tick resolves the community's top-voted action against the threat. HP and resources shift, a new threat rolls in, and the Hive Queen posts the outcome as a comment and rallies tomorrow's vote.
Come back tomorrow to steer the next decision. Threats escalate the longer you survive. When the hive finally falls, it gets a shareable post-mortem post — "The Hive Fell on Day N" — and a fresh season begins, with the all-time survival record as the new target.

The decision is genuinely collective: comment proposals + votes drive it, not a solo player nudging a shared counter. Collaboration and friendly conflict — not solo play with a social veneer.

How we built it

Built entirely on the Reddit Developer Platform (Devvit Web):

Client — Phaser 4.2 renders a framed "scene window": a per-threat sky gradient, a distant hive silhouette, honey ground, warm/threat glows, and living particle weather (drifting pollen always; embers, dust, or an angry swarm depending on the day's threat).
Server — a Hono app on Node 22 (compiled to CJS) exposes GET /api/state and POST /api/vote, parses !vote via an onCommentCreate trigger, and runs the resolution on a daily-tick scheduler cron.
State — Redis only. The vote tally is a season-namespaced sorted set with per-user dedup; casting a vote is an atomic WATCH/MULTI/EXEC transaction so concurrent voters can't corrupt the count.
Rules — the game logic is a pure, deterministic engine in src/shared with a seeded RNG, so a season is fully replayable. It's covered by 19 unit tests and is the single source of truth; the server just wires it up.
Art — the crowned Hive Queen (with per-HP wounded and critical sprites that swap as she takes damage) and every threat monster were made with PixelLab, plus a cohesive pixel icon set for resources, buildings, and actions that replaced every emoji.

Challenges we ran into

Devvit changed under us mid-build, and several assumptions were wrong:

The obvious mechanic was impossible. Our first instinct was "use Reddit upvotes as the vote." But there's no upvote trigger and vote data is private. So voting had to become fully app-owned — in-app buttons plus a !vote comment parser tallied in Redis. That constraint reshaped the whole concept.
Blocks UI was removed on June 30, 2026, mid-hackathon. Every pre-July tutorial and example we'd bookmarked was suddenly dead, and "Devvit Web" (Phaser + Hono) became the only model. We rebuilt the client layer on Phaser.
Nothing fires exactly once. Scheduler ticks and comment triggers can double-fire, so a naive tick would resolve the same day twice. We made every tick and trigger idempotent with a lastResolvedDay marker — resolving is a no-op if that day is already done.
A silent realtime bug. Live tick updates just... didn't arrive, with no error. It turned out Devvit rejects hyphens in realtime channel names — renaming hive-siege-state → hive_siege_state fixed it instantly.
Redis has no KEYS *, no plain sets/lists. We modeled everything with hashes and sorted sets, and namespaced state per season so a defeat can start a clean season while carrying the record forward.

What we learned

Designing for a shared state is a completely different discipline than single-player — the interesting bugs are all about concurrency, idempotency, and "what happens when 500 people act on the same tick."
Keeping the rules in a pure, tested engine separate from the platform glue was the best decision we made: we could iterate on balance with fast unit tests and never had to guess whether a change was engine or plumbing.
On a platform that churns weekly, the durable move is to treat every integration point as untrusted (triggers, realtime, scheduler) and prove behavior with tests and live playtests rather than docs.

What's next

Season modifiers and rarer "boss" threats to keep long streaks fresh.
Comment-authored gambits — let the community propose custom plays, not just the five preset actions.
Per-subreddit hives with a cross-community record board.