How I built the core loop of a browser multiplayer game

Why an async, queued action loop can still feel as immediate as a real-time game — and what it took to get there

I’m kicking off a series about HiddenWars, a personal project I’ve been building with Golang and Svelte. It’s a persistent browser-based hacking game with mostly PvE gameplay, some PvP tension, and an evolving lore where players build botnets, upgrade their systems, hack targets, and uncover secrets while pushing back against powerful mega-corporations.

Introduction

Every game has a core loop. In a shooter it's: see → aim → shoot → reload. In an idle game it’s: click → earn → upgrade. The loop is the heartbeat of the design: the smaller it is and the better it feels, the more the rest of the game can hang off it.

For a browser-based multiplayer game, the core loop is harder than it looks. Browsers are not a great real-time runtime. Players come and go. Tabs sleep. WebSocket disconnect on Wi-Fi handovers. You cannot rely on every player being online at the same time, and you definitely cannot rely on a 60Hz tick.

So you have two choices: pretend the browser is a real-time engine and fight it, or accept that your loop is fundamentally async and design around that.

I went with the second option. Here is what I learned.