Light is fast.
It is not instant.

A request crosses the planet as light in a glass fibre. Light in vacuum travels at 299,792.458 km/s, exactly: the metre is defined by that number. In glass it is slower by the fibre's group index of refraction. For standard single-mode fibre at 1550 nm that index is 1.4682.

v = c / n = 299,792.458 / 1.4682 = 204,190 km/s

That is 68% of the speed of light, or about 4.9 microseconds for every kilometre. A request has to get there and the answer has to come back, so the time a user waits is twice the one-way trip.

round trip (ms) = 2 × distance (km) / 204,190 × 1000

The game asks for an answer in under 100 ms. Turn the formula around and that buys 10,210 km of fibre, no more. The Earth is 40,030 km around, so one data centre can reach a little over a quarter of the way round the planet, and the far side (20,015 km away, 196 ms) is out of reach from anywhere. That single fact is the whole game.

Cables in the game follow great circles: the shortest path between two points on a sphere. Distances use the haversine formula on a sphere with the Earth's mean radius, 6,371.0088 km. City positions and populations come from GeoNames, and the land on the globe is drawn from Natural Earth.

The orange rows miss the limit however good the engineering is. Those cities need a data centre closer to home.

What you build is a graph. Cities are nodes, cables are edges, and the weight of an edge is its length. Each city is served by whichever working data centre is nearest along your cables, which is not always the nearest on the map.

The game finds those paths with one multi-source run of Dijkstra's algorithm: every working data centre starts at distance zero, and the search spreads outwards over the working cables. It runs again whenever something is built, breaks or is repaired. A city's latency is the round trip over its shortest path. The ring you see around a selected city is what is left of its 100 ms: any city inside it can be linked and still be answered in time.

The signals moving along the cables are drawn at the speed of light in fibre divided by 20, so a 100 ms round trip takes 2 seconds on screen.

A map has 36 cities, drawn from a list of 86. A round lasts 180 seconds and covers three days: the sun goes round once every 60 seconds. Its position is computed, not painted: it sits over the Greenwich meridian at 12:00 UTC, moves 15 degrees west every hour, and its height north or south of the equator follows the date of the map, using the usual approximation for solar declination with an axial tilt of 23.44 degrees.

A city's peak demand is the square root of its population in millions, in points per second. Through the day it follows a cosine of local solar time, peaking at 15:00 and falling to 20% of the peak twelve hours later. This curve is a design choice, not a traffic measurement. It is there so that the busy part of the world moves, and a failure costs more when it lands in someone's afternoon.

Day one is quiet. From day two cables are cut, and from the middle of day two data centres go down. You get 3 seconds of warning. A cut cable is dark for 24 seconds and a failed data centre for 15.

The times of the failures are fixed by the map. What they hit depends on what you built. A cable fault is a hazard per kilometre: each one lands at a random point on a line 60,000 km long (or as long as your whole network, if that is longer), with your cables laid end to end along it. A small network is usually missed. A long cable is hit more often than a short one. Data centre outages work the same way, picking one of at least 3 slots.

Real submarine cables do break: the industry records roughly 150 to 200 faults a year worldwide, most of them from fishing gear and ships' anchors. The game's fault rate is compressed to fit three minutes and is not calibrated to that figure. The lesson carries over anyway: a tree has no spare path, a ring does.

These prices are game balance, not market prices. The score is the demand you answered in under 100 ms, added up over the round and multiplied by 10. The percentage on the result is the share of all demand that was answered in time. The simulation advances in fixed steps of 100 ms and uses no randomness of its own, so a round is fully decided by the map and your moves.

The daily map is seeded with the UTC date. Everyone who plays on the same day gets the same cities, in the same order, with failures at the same moments.

The latency in the game is a floor. A real network is slower than this, for reasons the model leaves out on purpose:

• Real cables do not follow great circles. They go round continents, along coasts and through a handful of landing stations.
• Routers, switches and servers add processing and queueing time. Here they add none.
• The last few kilometres to a person's device are often the slowest. Here a city is a single point.
• A connection usually needs several round trips before it carries data. Here one round trip is an answer.
• The Earth is treated as a sphere and the sun's equation of time is ignored.

None of that changes the lesson. No amount of engineering buys back the time light needs to cross the distance. The only fix is to be closer.

• Speed of light in vacuum, 299,792,458 m/s exactly: BIPM, The International System of Units (SI Brochure), 9th edition.
• Group index of refraction of single-mode fibre, 1.4682 at 1550 nm: Corning SMF-28 Ultra optical fiber, product information sheet PI 1424.
• Mean radius of the Earth, 6,371,008.7714 m: H. Moritz, Geodetic Reference System 1980, Journal of Geodesy 74 (2000).
• Solar declination approximation and subsolar point: Position of the Sun, with an obliquity of 23.44 degrees.
• Shortest paths: E. W. Dijkstra, A note on two problems in connexion with graphs, Numerische Mathematik 1 (1959).
• Submarine cable faults per year and their causes: International Cable Protection Committee and TeleGeography.
• City names, coordinates and populations: GeoNames, CC BY 4.0.
• Land outline: Natural Earth, 1:50m land, public domain.