🎈 Whirlbird on Steroids

A first-person 3D balloon-flying game that lives inside Reddit — fly through a metallic space corridor, dodge obstacles, thread arches, rack up points, and publish your score for the whole subreddit to see.

💡 Inspiration

The original Whirlbird was a charming side-scrolling balloon game. I asked: what if we cranked it up to 11? — full 3D, first-person perspective, a deep-space corridor, and the social layer of Reddit baked right in. The result is an adrenaline-fuelled flying game you can play without ever leaving your feed.

🚀 What It Does

🛠 How I Built It

Client (Three.js + TypeScript)
  ├── game.ts        – main loop, camera, physics, score, UI overlays
  ├── obstacles.ts   – lane-based spawner, object pooling, difficulty curves
  ├── splash.ts      – leaderboard fetch, animated splash UI
  └── game.html/css  – HUD, loading screen, game-over, publish modals

Server (Hono + Devvit)
  ├── index.ts       – security middleware, error handler, 404 catch-all
  └── routes/
       ├── api.ts    – /init, /score, /leaderboard, /publish
       ├── menu.ts   – moderator menu actions
       ├── triggers.ts – onAppInstall auto-post
       └── forms.ts  – devvit form handling

Shared
  └── api.ts         – TypeScript interfaces shared between client & server

Key architecture decisions:

• Object pooling for obstacles keeps the garbage collector quiet at 60 fps
• Lane system (5 lanes, 3 units apart) guarantees playable paths exist
• normalizeModel() auto-scales any GLB to a target bounding box — no manual fiddling
• Redis sorted sets for the leaderboard — O(log N) upserts, O(N) range queries
• Security-first middleware — content-type enforcement, rate limiting, input validation, no stack-trace leaks

🧗 Challenges We Ran Into

1. GLB model sizing — models came in wildly different scales; solved with bounding-box normalisation
2. Arch collision detection — detecting whether the balloon flew through vs over/beside an arch required a two-zone box approach (ARCH_HALF_W, ARCH_OPEN_H)
3. Devvit platform constraints — no window.alert, limited DOM APIs, custom post rendering, Redis-only persistence
4. Rate-limit races — concurrent score submissions could bypass a naïve in-memory limiter; Redis timestamps solved it
5. Responsive 3D — getting FOV, touch controls, and CSS to behave across phone and desktop inside a Reddit embed

🏆 Accomplishments We're Proud Of

• Full publish-to-subreddit flow: play → score → confirm → post appears on the feed
• Chaos engineering test suite validating boundary values, malformed input, Redis failures, and rate-limit hammering
• Zero any types — every interface has readonly properties and explicit return types
• Loading screen with real progress bar tracking individual GLB asset loads
• Security hardened: OWASP-aligned headers, content-type guards, bot-proof rate limits, username sanitisation

📚 What We Learned

• Chaos engineering — hypothesis-driven fault injection catches bugs unit tests miss
• Playwright POM — page objects + role-based selectors keep E2E tests maintainable
• Three-layer API thinking — validate on both client and server, never trust the wire
• Security as a first-class feature — rate limiting, input validation, and header hardening are table stakes, not afterthoughts
• Object pooling matters at 60 fps — one stray new THREE.Mesh() in the hot loop and you feel it

What's Next

• More obstacle types — spinning blades, moving platforms, gravity wells
• Power-ups — shield, magnet, speed boost
• Multiplayer ghosts — see other players' replays in real time
• Daily challenges — curated obstacle sequences with unique leaderboards
• Sound design — spatial audio for whooshes, dings, and the satisfying arch pass chime
• Achievement badges — Reddit flair for milestones (100 arches, 1000 score, etc.)

Built With

• devvit
• eslint
• hono
• playwrite
• redis
• three.js
• typescript
• vite
• vitetest