Orvyn Living

Journal · 2026-05-14 · 8 min

Dev log — shipping 15 browser games.

This is a candid log of how the first 15 Orvyn Living games came together: time spent, what was hard, what was easy, and what I'd do differently. If you're working on a similar collection, hopefully some of this is useful.

The plan and the cut list

The original sketch had 22 games on it. After the first round of "would I actually play this for two minutes" review, half were gone. After the second round ("can I make this in a weekend?"), it was down to 15.

What got cut: a tower defense (too much state, too many balance levers); a multi-screen dungeon crawler (way out of scope); a typing-based platformer (cute idea, awful controls); two music-creator sandboxes (without a clear win/lose, they're just instruments). What survived was anything I could play in three minutes and feel like I'd done a thing.

Time per game

Roughly, in build order. "Hours" includes design, code, tuning, and the page copy.

  • Drift — 8 hours. The river generation went through three rewrites; row-based scrolling won out over segment lists.
  • Bloom — 4 hours. The whack-a-mole pattern is well-trodden; the watercolour visual sold it.
  • Lanterns — 4 hours. Easier than expected. The combo and gold-lantern variant landed quickly.
  • Stargaze — 5 hours. Procedural constellation generation needed two passes to avoid stars overlapping.
  • Wind Chimes — 6 hours. The Simon-Says input loop is finicky to get right with audio cues plus visuals.
  • Tide — 6 hours. Stone-stack physics were the third try; the trick is freezing the camera until you actually need to scroll.
  • Pulse — 3 hours. Rhythm timing is mostly tuning the perfect/good/ok windows.
  • Kintsugi — 5 hours. Crack generation is generative-art adjacent; a lot of small tweaks for the gold lines to look right.
  • Snake Garden — 3 hours. A solved problem, basically. Made the food look like flowers.
  • Hop — 7 hours. Frogger-style means lane management — water lanes carry you, road lanes kill you, the bank in the middle is safety. A lot of lane-state code.
  • Type Storm — 5 hours. Mostly word-list curation and the lock-target system that prevents accidental switches.
  • Match Pair — 4 hours. A flip-animation took longer than the game logic.
  • Color Run — 3 hours. Auto-runners are short on logic, long on feel.
  • Aim — 5 hours. The trajectory preview made it twice as good as the version without one.
  • Last Light — 3 hours. The simplest reflex-defence loop in the collection. Sometimes that's the right move.

Total: about 71 hours of game-build time. Plus another ~15 hours on the shared site (CSS, copy, legal pages, sitemaps, ad wrapper, etc.). Call it two solid weeks of focused work, or two months of evenings.

What was harder than expected

  • Touch input. Mouse and keyboard were trivial. Touch pulled in three subtle bugs across the collection — passive listeners not preventing default, touchstart-without-touchend leaving "held" state, and the fact that e.touches is empty inside touchend (use e.changedTouches).
  • HiDPI canvases. The high-DPI setup function in the engine was wrong for the first three games; everything was blurry on iPhones. The fix was setting both the canvas pixel dimensions and the CSS dimensions, then scaling the context by devicePixelRatio.
  • Audio autoplay policy. Web Audio context can't start without a user gesture. Every game had to delay new AudioContext() until the first tap, which meant moving sound from "preloaded" to "lazily initialised."
  • Time-based gameplay. Using setInterval for game loops is doomed; the ticks drift. requestAnimationFrame with a delta-time argument is the only clean way. We had to refactor the early games when frame rates dropped on mid-tier phones.

What was easier than expected

  • The visual style. A consistent palette and a single display font (Space Grotesk) tied everything together with no per-game art direction. Each game has one accent colour and one or two shapes drawn live. No assets to manage.
  • Local high scores. Five lines of localStorage. No accounts, no servers, no backend.
  • Mobile-first sizing. Designing for phone-portrait first, then desktop, meant nothing felt awkward at small sizes. Doing it the other way around always punishes you later.

What I'd do differently

  • Build the shared engine before the first game, not in parallel with it. Drift's first version had a bunch of inline boilerplate that should have been factored out of game logic from the start.
  • Pick the input model per game earlier. Some games are touch-first (Bloom, Lanterns), others are keyboard-first (Type Storm). Mixing both well takes per-game thought, not a generic input wrapper.
  • Write the page copy before the game is "done." Writing the rules clearly often surfaces mechanics that don't actually make sense.
  • Keep an "ad break point" comment near every game-over hook, so the H5 Games Ads integration is unambiguous later.

What's next

The site is at 15 games. We'll add ~one new game every 2–3 weeks, plus a couple of journal posts. Goals for the next batch: a real platformer (yes, with physics), a word-puzzle daily, and maybe a small two-player shared-screen game for laptops.

If any of these look like fun puzzles to solve along with us, the contact page is open.

← All notes Play a game