DEV Community: Arjen

Delta encoding multiplayer game state

Arjen — Sun, 30 Aug 2026 09:49:49 +0000

Old Light is a browser strategy game where a tab can stay open for days. The client holds a full copy of the galaxy state it is allowed to see, and the server keeps that copy honest by sending patches: every change arrives as a world.delta message the client merges into what it already has. Sending changes instead of resending state is textbook delta encoding. What that leaves open is what a game state patch actually holds, and why the patch a rival receives is not the one you receive.

I covered how the stream starts (one snapshot on connect, then deltas) and the time-math traps inside it in the networking post. This post is about the delta itself.

What goes in a game state patch

When people say delta encoding they usually mean byte diffs: compare two versions of a blob, ship the difference. That requires the sender to know which version the receiver holds. A game server broadcasting to thousands of sockets can't afford that; tracking a per-client "last known state" and diffing against it on every change would be more expensive than the update.

So an Old Light delta states facts about players and sectors instead:

interface WorldDelta {
    added?: { players?: Player[] };
    removed?: { playerIds?: string[] };
    updated?: {
        players?: Player[];
        sectors?: Sector[];
        dirtySectors?: SectorCoord[]; // map data here went stale, refetch it
        tradeBoard?: TradeBoardDelta; // the market board moved
        deals?: DealsDelta; // a negotiation moved; only its two parties get this
    };
    serverNow: number;
}

A delta says a player joined, an id is gone, a player's row changed, or a sector's public map data went stale. The last two fields carry no payload. They say a surface moved, a client with that surface open goes and reads it, which keeps a busy marketplace off every socket that isn't looking at one. The server can emit the identical message to every socket without knowing what any of them currently holds, and the client can apply it to whatever it has. It also tells the renderer exactly what to repaint: a players update touches the roster and HUD, a dirtySectors entry touches the hexes in the named sectors. Nothing else on screen is redrawn.

Absolute values, never increments

Every value in a delta is the new total, and the client assigns it, with no arithmetic against the value it already holds. When your empire's score moves, the payload contains the score, and the merge is a replace keyed by id:

const incoming = new Map(delta.updated.players.map((p) => [p.id, p]));
this.players = this.players.map((p) => incoming.get(p.id) ?? p);

(Simplified; the per-field rules come next.) Absolute values make the patch idempotent. A message delivered twice lands on the same state. A message that never arrives leaves the client stale but not corrupted, and the next update of the same entity repairs it completely, because that update is also the full truth rather than a step in a sequence. Increments would need exactly-once, in-order delivery to stay correct, and a browser tab that sleeps for hours and reconnects on a different network is the wrong place to bet on that.

The same event is a different delta for every viewer

Delta encoding collides with information hiding here. In Old Light, who owns which star is public, but what's inside an empire is not: building composition, income, fleet stacks, and treasury are visible only to the owner (until a rival scouts them). A change to your empire therefore produces two different patches from one event.

The public version goes to the galaxy-wide room that every socket joins, including anonymous spectators, and it passes through a scrub function first:

function scrubForBroadcast(player) {
    const out = {
        id: player.id,
        name: player.name,
        kind: player.kind,
        spawn: player.spawn,
        score: player.score,
        owned: player.owned.map(publicHex), // coord, name, score, buildings: []
        // anything not listed is not sent: credits, transits, unread counts...
    };
    // promoted to public by an explicit decision, and carried only when set
    if (player.protectedUntil) out.protectedUntil = player.protectedUntil;
    if (player.banner) out.banner = player.banner;
    return out;
}

The scrub is an allowlist. Every public field is listed explicitly and anything unlisted is dropped by default, so a field added to the player type six months from now stays private until someone consciously promotes it. The two conditional lines were each promoted on purpose. A rival sees the beginner-protection countdown because otherwise a refused attack looks like a bug, and the crest is cosmetic.

The private version of the same event, with the economy, build queue, fleet, and credits populated, goes only to a room containing your own connections. The server also orders the two emits, scrubbed global first and your rich view last, so the thin version can never overwrite the detailed one on your own screen. From the protocol's point of view, a rival's client is synchronised with a smaller galaxy than yours, one holding only the facts the two of you share publicly.

A missing field keeps its old value

Two versions of the same player on the same event channel create a merge problem. Your own client sits in the galaxy room like everyone else, so when the server broadcasts a scrubbed update about you, your client receives a copy of yourself with no credits field and an empty owned list. Blindly replacing your local player with that would wipe your empire off your own screen until the next rich view arrived.

The merge rule that prevents it: undefined means "not sent", never "cleared".

credits: incoming.credits !== undefined ? incoming.credits : local.credits,
owned: incoming.owned.length > 0 ? incoming.owned : local.owned,

A field the scrub stripped keeps its locally held value; an explicit value, including null, overwrites. The empty-owned rule exists because a public broadcast carries owned: [] by design (rival hex lists travel through the map data channel, not the roster), so an empty list must never be read as "this empire lost everything".

There's a second merge subtlety on captures. When a star changes hands, the delta names the new owner with the hex now in their list, but the previous owner isn't in the payload at all. The client walks every other player it knows and strips any hex the freshly delivered player now claims: last writer wins, keyed by coordinate. Without that pass, both empires would render as owning the same star until the next full snapshot.

Ship the fact, derive the rest

A lot of what the player sees is never on the wire. Territory is the clearest example: every occupied star projects an empire's borders a fixed radius outward, and where two empires overlap, the older claim wins. The server could ship the resulting shapes, hundreds of hexes for a large empire, on every change. Instead the delta carries only the occupied stars, and the client recomputes the projection from them. Client and server run one rule over one set of inputs, so they can't disagree. The patch stays a few hundred bytes however large the borders it implies.

dirtySectors goes further and ships an invalidation instead of data. An early version of the client refetched the whole visible map region after every delta, which at scale meant every economy tick anywhere triggered viewport-sized fetches everywhere. Now a delta that changes star ownership names the map sectors that went stale, and the client refetches only those, through the same public request any client could make anyway. Deltas that change no geometry, which is most of them, trigger no fetch at all.

When a client misses one

There is no delta journal and no sequence numbering. If a client disconnects, it doesn't ask for the deltas it missed; on reconnect the server sends a fresh snapshot and the client throws its incremental state away, because every missed change is already baked into the new snapshot. The dormant star cache deliberately survives that reset. It holds the unclaimed stars the snapshot never carries, and dropping them would blank most of the map until the first region fetch came back, which looks like a bug.

I could have kept a journal and replayed it. The snapshot code has to exist anyway, since every fresh connect needs one, and it is already scrubbed per viewer. A retained event log would need the same per-viewer filtering applied retroactively to every reconnecting client, over a gap of unknown length.

The game this comes out of is Old Light, a strategy game across a galaxy that runs in a browser tab.

Paw & Order: upload your dog, and defend them against evidence generated from their own photo

Arjen — Sun, 16 Aug 2026 12:56:15 +0000

This is a submission for the DEV Weekend Challenge: Dog Days Edition.

Upload a photo of your dog. An AI accuses them of a crime. You're their defense attorney.

What I Built

Paw & Order is a browser game where your own dog is the defendant.

You upload one photo and a few seconds later your dog has been arrested:

The People vs. Biscuit
Docket #PAW-042
DEFENDANT: Biscuit
CHARGE: Grand Theft Sausage
COUNSEL: You
STATUS: Extremely suspicious

Then the trial starts. The prosecutor puts a question to you, you pick a response, and the case branches from there. Three exhibits go into evidence: generated images of your dog, at the scene, with the frosting still on their muzzle. Two witnesses give statements, and at least one of them is usually lying.

A trial runs a few minutes. At the end you get one of four verdicts:

NOT GUILTY
NOT GUILTY, BUT SUSPICIOUS
GUILTY, BUT REASONABLE DOUBT
GUILTY

Plus a scoreline that isn't the same thing as winning:

VERDICT

NOT GUILTY

Biscuit is free to commit additional crimes.

Defense Performance: 94/100

You can lose the case and still score 96. You can win it badly.

Every case has a hidden truth, generated before the trial begins. Sometimes the dog really did it, sometimes they're innocent, sometimes the evidence just lies. The client never sees any of it, so you're not hunting for a correct answer. You're building the strongest defense the facts allow.

Choices decide the outcome. Replay the same case, answer differently, and the verdict and the score change with you.

Demo

Live: https://paw-order.pages.dev

Bring a dog photo, or don't. The home page has a public docket of cases other players entered into the public record, and you can play any of them without uploading anything.

Code

ArjenPostma / Paw-Order

dev.to weekend challenge submission

Paw & Order

Justice for every good boy.

Upload a photo of your dog. AI generates a fictional criminal case around that dog. You defend them in court.

Live: https://paw-order.pages.dev

DEV Weekend Challenge: Dog Days Edition

Built for the DEV Weekend Challenge: Dog Days Edition, start to finish inside the challenge window. Everything up to the last commit before the deadline of 2026-08-17 06:59 UTC is the submitted entry; anything after that timestamp is post-deadline work.

Submission post: SUBMISSION.md.

Local development

nvm use
npm ci
cp packages/api/.env.example packages/api/.env   # GEMINI_API_KEY is the only one needed
npm run dev:api    # :4270
npm run dev:app    # :5173, proxies /api

npm run all (format, lint, typecheck, test) must be green before a commit.

View on GitHub

How I Built It

One rule sits under everything else:

The AI creates the world. The engine runs the game.

Nothing calls a model during the trial. Generation runs once, up front, and produces the whole case: crime, hidden truth, evidence, witnesses, the branching question tree, and the verdict thresholds. After that the game is deterministic code reading structured data.

The generation pipeline

Six model calls per case, all Gemini:

Screening. Is this actually a dog, and is the frame safe to show on a public page? One gemini-3.7-flash call against the photo before any of the rest runs.
Facts. Crime, hidden truth, exactly three exhibits, exactly two witnesses, a 4-6 entry timeline. Schema-constrained JSON, with the dog photo attached.
Three exhibit images. gemini-3.1-flash-lite-image, rendered concurrently, each with the player's photo passed inline as a reference so the same dog turns up in every exhibit. Without that likeness you're looking at a stock dog and the joke dies.
The trial tree, generated last, so it can only be built out of exhibits that already exist.

Every visual claim has to be backed by the image

When the prosecutor says:

"Then perhaps you can explain the frosting on your client's muzzle."

the exhibit had better show frosting on your dog's muzzle. Otherwise it's AI noise with a caption.

So each exhibit carries visualFacts, one to four things visibly present in the rendered image, and the tree model gets those and nothing else to write from. Three levels stay separate:

Level	Example
Narrative fact (what happened)	Biscuit ate the cake
Evidence fact (what can be proven)	Biscuit has frosting on his muzzle
Visual fact (what is actually in the picture)	White frosting is visible around Biscuit's mouth

The trial can cite the third column, and can't invent a fourth.

Model output is untrusted input

A response schema is a request, not a guarantee. Every generated payload goes through a hand-written validator before anything is stored. It checks what a JSON schema structurally can't:

the trial graph is reachable from the root, acyclic, and finishable
every evidence id cited by a node, a choice or the hidden truth resolves to a real exhibit
no duplicate node, exhibit or witness ids
score effects clamped, so one choice can't blow the scale open
every string and array capped, since the case lands in one JSON column and is served under a long cache
control characters, zero-widths and bidi overrides stripped from stored text, so a charge title can't reverse the text around it on someone else's home page

When validation fails, the reasons go back into the retry prompt. tree node N4 points at unknown node N9 is something a model can act on, where a bare retry just rolls the dice again. One retry only.

The verdict thresholds are derived, not generated

Asked to set its own thresholds, the model has to guess blind, before it knows what totals its own choice effects add up to. Measured over a batch of generated cases that came out at roughly 80% acquittals, with the tainted-acquittal ending unreachable in every case sampled.

So the engine works them out instead. It walks every run the finished tree can be played to and places the lines by quantile inside that real spread: the top 30% of endings acquit, the bottom 30% convict outright, the middle band convicts with reasonable doubt, and half the acquittals come out tainted. The same quantiles hold whatever numeric scale the model wrote its effects on.

Two edge cases needed handling. A plain quantile over endings like 0, 0, 10, 20, 30 lands on the minimum, so every run sits above the line and the verdict below it becomes unreachable. And two independent quantiles over one list can land on the same value, emptying the middle band while both lines still look correctly placed. Both are now drawn from the values strictly above the floor. A tree where every run ends on the same doubt total is rejected: if no choice decides anything, it's a cutscene rather than a trial.

The score is calculated the same way, weighted towards doubt and normalised against what that particular tree made possible. That's what lets a loss read as an excellent defense. The ceiling is usually below 100, because the run that maximises doubt and the run that argues best are rarely the same run.

The hidden truth never reaches the client

The api serves the case minus truth, minus each exhibit's image prompt, minus whether a witness is reliable. Those stripping functions list every field by hand instead of spreading and deleting, so a field added to the type later can't ride out onto the wire without someone deciding it should. The verdict function never reads truth at all, only player state and the derived thresholds.

Everything is hostile

An anonymous upload endpoint in front of image generation needs bounds:

uploads capped at 20MB, one file, image mime types only, with part and field counts capped too, because busboy defaults both to Infinity
per-IP rate limit keyed on the IPv6 /64 rather than the address. Keyed on the full address, one host rotates through 2^64 of them and every ceiling becomes decoration.
a global daily generation ceiling, charged only once a generation is actually going to happen. It used to share a middleware with the per-IP check, which let malformed requests that generated nothing burn the day's headroom and lock real players out.
bounded concurrency on the screening call, since each one in flight holds the uploaded photo and its base64 copy in memory, and it runs before the generation slot counter ever sees the request
the screening gate fails open on isDog and closed on safeForPublic. A model outage shouldn't tell someone holding a real dog that it isn't a dog, but an unscreened photo must never reach the public docket.

Stack

Vue 3 + Vite as a static SPA on Cloudflare Pages, Express + TypeORM on Railway with Postgres, images in Cloudflare R2. The shared types and the trial engine live in one workspace package, so the api is the authority on the verdict while the app renders a score from the exact same code. 167 tests, plus a CI job that dumps the production schema into a throwaway Postgres to prove the committed migrations still describe it.

Prize Categories

Best use of Google AI. Gemini does four separate jobs here:

gemini-3.7-flash writes the case as schema-constrained JSON, so what comes back is a structured world rather than prose
the same model, with vision, gates the upload: dog or not, safe for public or not
gemini-3.1-flash-lite-image renders the exhibits with the player's own photo as a reference, which keeps one specific dog recognisable across three separately generated images
the same model writes the branching trial tree, constrained to the visual facts of images it has already produced

Then it stops. Gemini builds the world, and the verdict belongs to code that never saw the truth.

Justice for every good boy.

Game networking for a slow strategy game

Arjen — Thu, 23 Jul 2026 05:31:37 +0000

Almost everything written about game networking is about fast games. The classic material covers UDP and client-side prediction, in service of squeezing sixty snapshots per second through a home connection. Very little of it applies to the game I'm building.

Old Light is a multiplayer browser strategy game. A fleet takes hours to cross the galaxy and your economy keeps growing while the tab is closed. If a click takes 300ms to round-trip, nothing in the game can tell. The hard part is different: staying correct over long stretches of time, for thousands of empires at once.

One snapshot, then deltas

The client opens a WebSocket. The server answers with one message, world.init: everything this player is allowed to see, plus the server's current clock. After that, every change arrives as a world.delta, a small patch the client merges in.

socket.on("world.init", (payload) => {
    state = new GameState(payload.world);
    clockOffset = payload.serverNow - Date.now();
});
socket.on("world.delta", (delta) => state.applyDelta(delta));

Those two handlers are the whole protocol. Nothing needs sequence numbers or an interpolation buffer.

The fiddly part is the boundary between the two. A delta can fire while the snapshot is still being built. The server handles its side by building world.init before joining the socket to any broadcast room, so a mid-build delta never reaches the new socket, and the snapshot already includes that change. The client handles its side by buffering deltas that arrive before its state exists and draining them after boot. Skip either half and a player who connects at the wrong millisecond sees a world that disagrees with the server.

One more thing in that snippet: clockOffset. The server stamps its clock into every payload, and the client measures the difference once at boot. Everything time-based runs on server time from then on, because the player's machine might be minutes off.

The bug where both sides do time math

Resources in Old Light aren't ticked by a timer. As covered in the backend post, the server computes them on demand: last saved balance, plus rate times elapsed time. The client runs the same formula so your counter ticks up smoothly between messages.

So a resource value on the wire carries a number plus an anchor timestamp to project it forward from. The trap sits in the timestamp. When the server answers a request, it projects the stored balance to now. But the database row still carries the timestamp from the last actual save, maybe hours ago. Send the fresh number with the stale anchor and the client projects again on top:

// wrong: fresh balance, stale anchor
return { balance: projectedToNow, settledAt: row.settledAt };

// client side, moments later:
display = balance + rate * minutesSince(settledAt); // re-adds hours of income

The same hours of income get counted twice. Nothing errors out. The counter runs ahead of the truth and snaps back whenever a real server value arrives. The fix is a blunt rule: a projected value's anchor is the moment of projection, never the row's timestamp. A regression test pins it down with settledAt === now.

In a shooter, this bug would be visible within a frame. Here it only shows up if you compare the counter against a hand calculation across hours, so it ships unnoticed and gets reported as "my resources jumped".

The server plays on without you

A common shortcut in this genre is to let your building "finish" whenever some request happens to arrive after its timer expired, usually your own next login. Old Light finishes the build at the second it's due, whether or not anyone is connected.

Queue a build and the server sets an in-memory timer. When it fires, the outcome is written to the database and broadcast to your socket room. If you're offline the broadcast lands in an empty room and evaporates. The database write still happened, though, so a rival probing your system an hour later sees the upgraded reality.

In-memory timers die with the process, so every boot re-arms the pending ones and settles any job that completed while the server was down, as of its original completion moment. The main read path also settles overdue work before answering. Even a missed timer can't serve stale state.

What a broadcast is allowed to cost

With no tick rate, nearly all network cost is broadcasts, so each one has a budget: one emit per player action. When someone signs up, the server spawns their empire plus two AI empires around them. All three announcements travel as one delta, not three fanouts.

Rooms do the scoping. Public changes, like a star changing owner, go to a galaxy-wide room every socket joins. Private state, like your income and build queue, goes only to player:<id>.

Building that private view is the expensive part, so the server checks the room first and skips the work when nobody is connected. The AI empires complete builds constantly and never have anyone connected, so without the check most of the enrichment work would be for empty rooms.

The netcode I never wrote

Old Light has no client-side prediction and no reconciliation. The client is a viewer. Every mutation is a request the server may refuse, and the client waits the round trip to see the result. An action's real feedback loop is minutes or hours, so an extra 300ms before the queue entry appears is invisible.

That deletes the hardest problems in the genre's literature. There's no state to roll back, since the client never speculated, and nothing is aimed, so lag compensation has no job to do. Plain TCP WebSockets, socket.io in our case, are fine; a delayed packet delays a UI update instead of a dodge.

What's left is bookkeeping. Every value on the wire is a ledger entry, and the remaining bugs are clerical: an anchor stamped at the wrong moment, or a timer nobody re-armed after a restart. Mistakes like that never show up in the next frame. They surface ten hours later, when a player opens the tab and the number doesn't match their own arithmetic.

Deploying a real-time multiplayer game on Railway

Arjen — Thu, 09 Jul 2026 09:55:35 +0000

This post contains Railway referral links. If you sign up through one I get a bit of credit.

I build Old Light, a real-time strategy game that runs in the browser. Claim stars, grow an economy, send fleets, all while other players and NPC empires do the same. The second a build finishes or a fleet lands, the server pushes it to every connected client over a WebSocket.

That last part, a long-lived server holding an open socket, rules out most of the usual hosts. Here's what it ruled in.

Why not Vercel or Netlify

Serverless shines when your backend is stateless functions. It's the wrong shape the moment you need a socket that stays open: socket.io wants one process that lives for the whole session, and serverless boots per request and then freezes. You can bolt on a managed WebSocket service, but that's a second system to run and pay for.

Railway runs your service as a normal long-lived process, so socket.io just connects. Fly.io does this too with more knobs to turn. I wanted to ship, so Railway won.

Monorepo, two services

Old Light is an npm workspaces monorepo: a shared types package, an Express plus TypeORM plus socket.io API, and a Vite web app served by a small Express server. On Railway that's two services on the same repo, each with its own root directory and build command, shared built first.

They deploy as separate origins, so the web app reads the API's URL from VITE_API_URL. Vite bakes that in at build time, so it's a build variable, not a runtime one. Postgres is a plugin that injects DATABASE_URL, and production runs migrations rather than synchronize. WebSockets need nothing special until you run more than one instance, at which point you'd add a Redis socket.io adapter. I haven't left a single box yet.

A healthcheck that stops version skew

Two services don't go live at the same instant. Push a commit that touches both, the web finishes first, and for a minute your new frontend is calling API routes that don't exist yet. It 404s, then heals itself once the API catches up, which makes it miserable to reproduce.

The fix is to have the web service report unhealthy until the matching API is live. Both services hash their RAILWAY_GIT_COMMIT_SHA into a short build id, and the web /health fetches the API's health and compares:

const body = await fetchApiHealth(API_URL);
if (body.buildId !== EXPECTED_BUILD_ID) {
    return res.status(503).json({ ok: false, reason: "build id mismatch" });
}
res.status(200).json({ ok: true });

Point Railway's healthcheck at /health and the new web deploy waits at 503 while the old one keeps serving. When the API lands on the same build id, health flips to 200 and Railway cuts over. Not a true atomic deploy, but the frontend never serves traffic against a mismatched backend.

Things that only break in production

A few that pass every local test, because dev serves from source and prod serves from a build:

Build order. shared has to compile before the API or web, or you build against a package with no dist. Put it in the build command instead of trusting install order.
Non-TypeScript assets. tsc only emits .js, so anything you read from disk at runtime (for me, markdown that renders to pages) needs its own copy step or the container hits ENOENT on first read.
Behind the proxy. Railway terminates TLS at its edge, so set trust proxy or req.hostname reads the wrong host, and add the compression middleware yourself since the edge won't gzip your HTML.

Cost

About six dollars a month, more than the traffic needs because I keep headroom for spikes. For a stateful, real-time app it's been the least fussy host I've used: the monorepo builds without special-casing, and the commit SHA Railway exposes is what made that version-skew healthcheck possible in the first place.

The deeper backend story behind the game (no tick loop, combat as a pure function, built for scale) is its own post: Browser strategy game backend.

The game running on all this is Old Light, playable in your browser right now. Want to try Railway? Here's my referral link.

Browser strategy game backend

Arjen — Wed, 01 Jul 2026 13:00:00 +0000

Old Light is a browser strategy game: a whole galaxy you play in a tab, with star systems to claim, an economy to grow, fleets to build, and other players (plus the AI empires that live alongside them) to fight for territory. This post is about what you don't see while playing: the backend that keeps it all running.

Three things make that backend tricky, and almost every decision below comes from one of them.

It's real-time. There are no turns. Your economy keeps growing and your fleets keep moving even after you close the tab, so the server has to keep the world running on its own.
The browser is the client, and you can't trust it. Anything the browser sends could be faked, so the server, not the client, decides what is true.
It has to scale. I want it to hold around 1000 players at once. Each player is also surrounded by AI empires (roughly three per human), so 1000 players really means about 4000 active "actors" in the world. Every feature has to survive being multiplied by that number.

Here are five decisions that shaped the backend. The whole stack is TypeScript: Express, Postgres (via TypeORM) and socket.io on the server, Pixi.js on the client.

The economy has no tick loop

The obvious way to run a live economy is a timer that fires every second and adds resources to every star. That approach falls over once the world gets big: 4000 actors, each with several stars, updated every single second, forever, even for players who are offline and not looking.

So there's no timer. Instead, resources are calculated when someone asks for them. Each star saves two things: its last known balance, and the time that balance was saved. When you need the current value, the server does simple arithmetic:

current = saved balance + (rate per minute × minutes since it was saved)

capped so storage can't overflow. Stripped to its core, the function is:

project(star, now = new Date()) {
    const cap = storageCap(star);
    const ratePerMin = productionRate(star); // summed from the star's buildings

    const minutesElapsed = (now.getTime() - star.settledAt.getTime()) / 60_000;
    const balance = Math.min(cap, star.balance + ratePerMin * minutesElapsed);

    return { balance, settledAt: now };
}

No timer touches the database. We only save a new balance on the rare occasions when something actually changes the rate, like finishing a building upgrade. Reading the value never writes anything.

There's a catch hiding in that formula. "Balance plus rate times time" is only correct if the rate held steady for the whole stretch of time, and in Old Light it often doesn't. Finishing a building raises its energy upkeep, and if that tips a system into an energy deficit, its income rate drops until you build enough power to recover. So the rate can fall partway through the very window you're projecting across.

If you naively multiply the current rate across the whole gap, you paint over that slow period as if it never happened and hand the player resources they never actually earned. The fix is to never let one projection span a rate change. The moment anything changes the rate, the server first settles: it banks the accrual at the old rate, up to that exact instant, and saves it. Only then does it apply the change. Every projection after that starts fresh from the boundary, so each stretch of time is only ever multiplied by the rate that was really in effect.

The client is hostile

The frontend runs on the player's own machine, so I don't really control it. Anyone can open the browser's dev tools, read how it works, change values, and fire off whatever requests they like. The server treats every message as if it came from someone trying to cheat.

It never trusts what a request claims. A "build this on my star" message doesn't get to say who is sending it; the server takes the identity from the connection's own login, never from a field in the message:

// trusts the client to say who it is -> forgeable
const player = lookup(request.playerId);

// the player is whoever this authenticated connection belongs to
const player = connection.player;

Get that wrong and anyone can act as anyone else just by editing a number.

It also re-checks everything the client already checked, and confirms each request makes sense for the state of the game right now:

Can you afford it? The greyed-out button is a convenience, not a guard. The server works out the cost again before it builds.
Is the move even legal? You can't skip ahead and queue a jump to level 15 on a command center that's only level 10. The server accepts the next level up and nothing else.

And it decides what you're allowed to know. Public facts like who owns which star go to everyone, but your fleet size and your income are sent only to you, and to a rival only once they've scouted you. Hiding a number in the client is not hiding it: the only number a rival can't read is one the server never sent.

Combat is a pure function

When two fleets fight, the whole battle is decided by one plain function. No database, no shared state, just inputs and outputs:

function resolveBattle(input, rng) {
    /* returns who survived */
}

input is the ship counts on each side. rng is the function that supplies randomness. That second argument matters more than it looks: in the real game we pass in Math.random, and in tests we pass in a fake "random" that returns a fixed, known sequence.

Since randomness is the only thing coming from outside, the function is completely predictable once you control it.

That makes tests that never flake. Feed in a known sequence and the exact survivor counts come out every time, so a failing test means a real bug, not bad luck.

It also makes a balance simulator possible. I can run the same function ten thousand times with real randomness to see how often each side wins, then tune the game before shipping a change. The test suite and the simulator run the identical battle logic.

Each shot is two coin flips, did it hit, then did it win:

if (rng() >= hitChance) continue; // missed
if (rng() >= winChance) continue; // hit, but lost the exchange
target.dead = true; // hit and won

And a scouting fleet with no warships skips combat entirely:

if (!hasCombatShips(input.attackerShips)) {
    return {/* nobody fought, both sides unchanged */};
}

The AI empires are predictable on purpose

Old Light fills the galaxy with AI empires. They run through the exact same code as human players: same actions, same rules, same limits. The server never asks "is this a human or a bot?" because they are the same kind of thing.

Each AI's personality (offensive or defensive) and its speed aren't random and aren't stored in a column. They're computed from the world's seed number with a hash:

function empireIdentity(worldSeed, empireId) {
    const coin = (hash(`${worldSeed}:identity:${empireId}`) % 10_000) / 10_000; // a number 0-1
    return coin < 0.5 ? "offensive" : "defensive";
}

A hash turns text into a number that looks random but is always the same for the same input. So a given empire always lands on the same personality, with no clock, no live dice roll and no database lookup involved. Its character is fixed the moment it's born.

That same idea fixes a scaling problem. Updating every AI once a minute would mean a big spike of work all at the top of each minute. Instead, each AI is sorted into one of 60 buckets using the same hashing trick, and only one bucket runs each minute:

const thisMinutesAIs = allAIs.filter(
    (id) => hash(`${worldSeed}:bucket:${id}`) % 60 === currentBucket,
);

Every AI still gets a turn about once an hour, but the work is spread smoothly across the whole hour instead of arriving all at once.

Every code path gets multiplied by 4000

My rule of thumb: take any new piece of code, imagine ~4000 actors hitting it, plus the biggest input a player could send. If that math is scary, the code is wrong. Three rules follow from that:

Don't load a whole table and filter in code. Ask the database for only the rows you need. To find jobs that are finished, query for "finished before now," which the database has an index for and can skip the rest:

findDue(now) {
    return this.repo.find({ where: { completesAt: LessThanOrEqual(now) } });
}

Don't run a query inside a loop. To load data for 100 stars, make one query for all 100 and then look them up in memory, not 100 separate queries:

const resourcesByStar = await loadResourcesFor(starIds); // one query
return stars.map((s) => enrich(s, resourcesByStar.get(s.id))); // fast memory lookups

Don't tell everyone about everything. Sending a message to every connected player is expensive. Private updates (your money, your buildings) go only to you, and the server doesn't even build that update if you're offline:

if (playerIsOffline(player.id)) return; // nobody listening, skip the work
sendTo(player.id, buildPrivateUpdate(player));

Public news, like who now owns which star, goes out as a single shared message, never one message per tiny change. How those messages reach the browser in the first place is its own topic, covered in game networking for a slow strategy game.

What ties it together

The server owns the truth and stays cheap while thousands of actors lean on it, and it never takes the client's word for any of it. In practice that meant calculating values instead of ticking them, keeping the core logic in plain functions I could test and reuse, and treating randomness as an input rather than reaching for it mid-function.

You never see any of this while playing; it's all plumbing. The one piece you can feel is the last one: claim a star, build something, then close the tab, and your economy keeps accruing while you're gone. Come back tomorrow and the galaxy moved without you.

Play Old Light a real-time galaxy that keeps running while you're away. Claim your first system and see the backend from the player's side.