Rollback in RTS

Neon Marble Rust is a new Real-Time Strategy game, available now in early access.

Neon Marble Rust uses a two-state rollback system for online networking. This is used during matches to help keep latency low, and improve moderate-latency connections. It's a two-state system, which means there is a game-state that the player sees and a second state that is delayed half a second. The state the player sees is called the Display state, and the delayed state is the Rollback state.

This system is built on top of the old lock-step system, used in RTS games like StarCraft and AgeOfEmpires. With a normal lock-step system, player's inputs are delayed so that they can reach the other player's computer on time. If there is a spike in latency, and a player's inputs do not arrive on time, the game will stall and wait for those inputs.

In Neon Marble Rust, the Rollback state is the 'official' game state, which only progresses as long as both clients stay connected (each player's computer is referred to as a client). If any input comes in so late that it hasn't arrived on-time for the Rollback State, the game stalls like a normal lock-step system. But with a two-state system, the Rollback is delayed so those stalls are very rare. On top of that, the added latency is no longer needed.

The display state will show inputs on the local client right away, with minimal latency. If those inputs arrive late for the other client, then that other client does a rollback. A rollback is where the Display state is deleted, the Rollback state is copied and made to be the new Display State. Then the new Display state is updated to catch back up using the new inputs that were missed. Neon Marble Rust has its gameplay update 20 times per second, the Rollback is 10 updates behind. So during a rollback event 1 state is deleted, the other is copied and then updated 10 times, all of this happens during 1 frame on the player's screen.

Performance becomes really important with a two-state system. To maintain 60 fps during a rollback, individual gameplay updates need to be calculated in less than 1 ms (60 fps means about 16ms per frame). Small frame-rate drops during rollbacks would be somewhat hard to notice though.

Also, there are the differences between the Display state that missed that late input, and the new post-rollback Display state with that input. As long as the input wasn't too late, its likely not very noticeable either. A typical match in NMR will have a handful of rollbacks, and players tend not to notice them.

The biggest downside of this system is the limitation on how many units can be on the map at any time. Because of this limitation, the game is only 1v1. Although, this two-state system can be removed for larger games like 4v4. For now, NMR is only 1v1.

During development, rollbacks were a bit problematic. Early on, getting rollbacks to happen smoothly was a big challenge. At the time, rollbacks would cause units to jump or stutter a bit. More recently, there have been some issues with keeping the game deterministic during rollbacks. Rollbacks had potential to change the ordering of units in the Rollback state, which could eventually cause desyncs. This was a big challenge to fix.

One odd ramification of the two-state system is the potential for negative latency, which means that all inputs cause rollbacks (even on the local client). But, this isn't used in the game.

Overall the two-state rollback system has been successful, it added lots of work, but it means that even players that are on different continents can play NMR with minimal latency. It also means there is minimal difference between playing offline and online, making it easier to practice.