INTERCHANGE.GG

Build log · Dispatch 001

Building interchange.gg in public

A starting signal for the project: why the railway is shared, why the simulation advances in fixed ticks, and what we hope to learn by showing the work before it is polished.

There is a particular moment in every interchange.gg match when the map stops looking empty. One company lays a short line. Another meets it from the opposite direction. A third notices that the connection is useful and builds into it. What began as a handful of private plans becomes one shared railway.

That moment is the reason we are making this game—and the reason for this journal.

The interchange.gg board, showing railways crossing between colorful cities

FIG. 01 — An early vision of the shared Midlands network.

A game about shared infrastructure

interchange.gg is a short-session multiplayer strategy game for one to one hundred players. Every company is trying to control 80% of the transport market, but no company can build in isolation. Track is permanent. Any train can route across connected rail, regardless of who paid to place it. When that train earns money, the companies whose infrastructure helped it get there receive a share.

That creates the tension we want: your best route can strengthen a rival, and a rival's expansion can quietly become the missing link in your network. The map is competitive, but the infrastructure is communal.

The central design question is not “where can I build?” It is “what will everyone do with the thing I build?”

The rules are deliberately legible. Stations claim space. Rails occupy edges. Cities show their market share directly on the map. We want a player to understand the state of the network by looking at it, without opening a stack of reports.

The simulation needs a metronome

The promise of a shared network only works if every player sees the same network. Underneath the illustrated map, interchange.gg runs a deterministic simulation: the browser clients start with the same seed, apply the same ordered commands, and advance through the same fixed ticks.

At normal speed, the clock advances at ten ticks per second. A command is not merely “build this now”; it is assigned a precise execution tick and sequence by the server. Every client then applies that command in the same place in the timeline.

export const TICKS_PER_SECOND = 10;

commands.sort(
  (a, b) =>
    a.executeAtTick - b.executeAtTick ||
    (a.sequence ?? 0) - (b.sequence ?? 0),
);

The simulation uses integers for money, market share, and grid positions. Every 50 ticks, clients report a compact checksum of their state. If one has drifted, the server can send a known-good snapshot and pull it back onto the rails.

This is more work than treating the server as a stream of constantly updated objects. It is also what lets a dense, fast-moving match remain predictable enough to reason about—and lets the speed control move from 1× to 100× without giving each player a different version of the future.

Showing the unfinished work

interchange.gg Dispatch is where we will document decisions like that one. Some entries will be deep technical notes about the Rust game server, the TypeScript simulation worker, or the WebGL renderer. Others will be about quieter design problems: how long an opening should last, how much information belongs on the map, or why a button felt wrong for three builds before it felt obvious.

We also want to record the paths that do not survive. Finished games tend to hide their discarded rules, awkward prototypes, and false starts. Those are often the most useful parts of the process.

The journal will follow three kinds of dispatch:

  • Build logs for milestones and the shape of the current game.
  • Systems notes for focused explanations of simulation, networking, and rendering.
  • Postmortems for experiments that failed, changed direction, or taught us something.

The next station

The playable slice already contains the core loop: place a station, build permanent shared rail, run trains, collect infrastructure fees, market into ten cities, and race for control. The work ahead is about pressure-testing that loop with more people and making every action clear at a glance.

Next, we will take apart the lockstep model in more detail—what the Rust server owns, what the browser simulates, and what happens when two clients disagree.

Until then: build carefully. Someone else will use your line.