RollbackSynchronizer

Manages state during the network rollback loop by hooking into NetworkRollback events. Simulates nodes as required during rollback.

Configuring state and input

To use RollbackSynchronizer, add it as a child to the target node, specify the root node, and configure which properties to manage:

Root specifies the root node for resolving state and input properties. Best practice dictates to add RollbackSynchronizer under its target, so Root will most often be the RollbackSynchronizer's parent node.

State properties are recorded for each tick and restored during rollback. For state, the server is the ultimate authority. Make sure that nodes containing state properties are owned by the server.

Input properties are gathered for each player and sent to the server to use for simulation. Make sure that nodes containing input properties are owned by their respective players.

See Property paths on how to specify properties.

Note that it is not recommended to have both state and input properties on the same node. Since nodes with state belong to the server, and nodes with input belong to the player, it is difficult to separate ownership on the same node.

Writing rollback-aware scripts

During setup, RollbackSynchronizer finds all the rollback-aware nodes under the specified root. During rollback, it will call all the rollback-aware nodes to simulate new state.

To learn about rollback-awareness, see NetworkRollback.

In short, implement _rollback_tick in your scripts:

extends CharacterBody3D

@export var speed = 4.0
@export var input: PlayerInput

func _rollback_tick(delta, tick, is_fresh):
  velocity = input.movement.normalized() * speed
  velocity *= NetworkTime.physics_factor

  move_and_slide()

Changing configuration

RollbackSynchronizer has to do some setup work whenever the state or the input properties change.

By default, this work is done upon instantiation. If you need to change state or input properties during runtime, make sure to call process_settings(), otherwise RollbackSynchronizer won't apply the changes.

While changing configuration after instantiation is possible, it is not recommended. You may get away with it if the configuration change happens in a few ticks after instantiation. For longer periods, experiment at your own risk.

Changing ownership

The setup work above is also needed whenever the multiplayer authority changes of any of the nodes that have a state- or input property.

Changing authority during gameplay is supported. Make sure to call process_authority() on all peers at the same time, to ensure they're on sync about ownership.

This method is called automatically during instantiation and whenever process_settings() is called.

---

When only multiplayer authority changes, call process_authority(). When the configured state- or input properties change ( i.e. different properties need to be synced ), call process_settings().