When you play a fast 1v1 game against someone on the other side of the world, something quietly remarkable is happening: two computers, separated by thousands of kilometres and connected by an imperfect internet, manage to show both players the same game, at the same time, with the same result. Getting this right is one of the genuinely hard problems in game development. This is a friendly tour of how it works — and why, on a platform where matches decide real traffic, it matters more than usual.
The naive approach and why it breaks
The obvious idea is: every time something happens, send the full state of the game to the other player. Your character moved? Send the new position. Something exploded? Send everything. This works fine in a tech demo and falls apart in the real world. The internet adds delay, packets arrive out of order or not at all, and the amount of data quickly becomes enormous. Worse, if the two players' versions of the game ever disagree, you get the dreaded "but I clearly hit you!" arguments. When the outcome has real value, that disagreement is unacceptable.
Lockstep: share inputs, not outcomes
A more elegant approach is called lockstep. Instead of constantly sending the full game state, both players run the entire game simulation on their own devices, and only the inputs — "player pressed left," "player dashed" — are exchanged. As long as both simulations start identically and apply the same inputs, they produce identical results, independently, with almost no data sent. It is the difference between mailing someone a finished cake every minute versus both of you following the same recipe.
The catch: determinism
Lockstep only works if the simulation is perfectly deterministic — the same inputs must always produce exactly the same result, down to the last detail, on every device. That sounds easy and is surprisingly hard. Even tiny differences in how two computers handle decimal numbers can, over thousands of frames, snowball into two completely different games. The solution is disciplined engineering: using integer maths and carefully chosen operations that behave identically everywhere, and driving any randomness from a shared seed so both sides "roll the dice" the same way. Done right, the two simulations stay locked together for the entire match.
Hiding the delay
There is still the problem of internet lag. If you had to wait for your opponent's input to arrive before drawing the next frame, the game would feel sluggish. Real-time games hide this with techniques like input delay buffering and prediction — scheduling inputs a fraction of a second ahead and letting each device run smoothly in between, correcting course when needed. The goal is for the game to feel instant even though the network underneath is anything but.
Why a clear outcome matters here
On most platforms, a desync just causes a frustrating moment. On PlayToPromote, the match outcome decides who gets real promotional traffic, so an ambiguous result isn't just annoying — it would undermine the whole exchange. That is why the competitive games are built on deterministic, synchronised simulations: both players compute the same winner from the same inputs, independently, so the result that triggers the redirect is never in dispute. The fairness players feel is, underneath, a netcode design decision.
The takeaway
The next time a fast online match feels smooth and fair, appreciate the invisible work holding it together: two distant machines following the same recipe so precisely that they never disagree about who won. It is a quiet kind of engineering — you only notice it when it fails — and getting it right is what lets a "win a game, earn real traffic" platform exist at all.