Rollback Netcode Example

Rollback netcode is a technique used in online games to keep clients in sync by simulating remote input and correcting discrepancies after the fact. One example is handling local animations. When an animation is played locally for an entity that isn’t your character, it doesn’t replicate to others. A common solution is sending a RemoteEvent to all clients and waiting for them to respond. This creates dependency on each client’s network delay — a method known as delay-based netcode. However, this approach depends on varying client speeds. To address this variability, rollback netcode comes into play.

Rollback netcode eliminates delay for the initiating client while ensuring all other clients remain synchronized. This ensures smoother gameplay experiences.

For a deeper understanding, watch this video on Why Rollback Netcode Is Better.

Here’s a conceptual analogy using animation to illustrate how rollback-style compensation could look in a simplified form:

Example Implementation:

local Delta = (os.clock() - LastTime)
local Animation = AnimationController.LoadedAnimations[AnimationName]

if Delta > Animation.Length then
    return
end

-- Set Time Position to Match Delta
Animation:Play()
Animation.TimePosition = Delta

This simplified example isn’t a real rollback implementation, but it gives a sense of how a game might compensate for delay using rollback-style logic.

Extreme Case Example:

In scenarios with extreme latency (e.g., a 500ms delay), the result can look visually strange or jittery.

Conceptual Rollback Netcode Example

While such high delays are uncommon in most games, it’s important to note that rollback netcode is designed to handle moderate latency effectively — often making the delay nearly imperceptible to players.

Keep in mind, this is just a conceptual example, not a full implementation of rollback netcode.

A true rollback netcode system typically includes:

  • Input prediction
  • State saving
  • Re-simulation
  • Deterministic behavior across clients

This example simply illustrates the core idea behind how rollback can help correct for delay.

For smoother networking experiences in Roblox, consider using a performance-optimized module like ByteNet by ffrostfall

25 Likes

Not to mislead anyone, the example that I used was a quick and very simplified demonstration of a rollback style implementation. I would say the example I used would be more closer to a latency compensation implementation.

4 Likes

Genuinely curious, this probably means that you have to set up your own replication system right? And if I’m understanding the concept correctly, here would be an example of rollback netcode:

  • Player A idles for a while
  • Player A then punches, playing a punching animation
  • Player A sends a packet telling Player B that its playing a punching animation, this packet takes 45 ms
  • As Player A first punched, Player B is assuming it’s previous input of idling
  • When Player B receives the packet 45 ms later, it rolls back to Player A punching

The predicting is the hard bit, so for example:

  • If Player A was doing y and suddenly did x at z position, and Player B receives that x packet 45 ms later, Player B would have to predict the current position of Player A with its already outdated x and z.

Just a very interesting topic, nice post.

Yes you will have to create you own replication system since you have to record and restore past states.

Each client has to predict the other players input for an immediate feel. When the real input arrives in your case 45 ms later it will then as you said roll back and apply the actual input.

The predicting is a little more tougher since you dont want to just guess, but guess accurately. Thats why determinism and efficiently handling rollbacks matters heavily so different clients dont have different results.

2 Likes

take this with a grain of salt as i have not implemented rollback myself, but i distinctly remember from the linked video by Core-A Gaming that the solution that the programmer interviewed in the video used was just using the same input as the last frame. the timestamp for that exact point should be 2:40. (not sure if you were already aware of this but hey if you were its at least good to write down for others in the audience)

1 Like

Yeah I know, I’m talking about what happens when the packet is actually received, because (assuming the packet sends you Player A’s position and other data) the other player’s position will have already changed from when the packet was sent.

1 Like