Skip to main content

network.toml

The network.toml file can be used to specify the configuration related to the network.

[network]
enableSnapshotting = false
maxInputDelayMs = 32

Snapshotting​

Normally when a player joins a game, they must simulate the entire game up to the present moment. If your game is quite long, this can take a while. Snapshotting allows the game to capture the current state of the game and send it to new players when they join, allowing them to join the game much faster. At present, snapshotting is done on the client-side, and so can increase the CPU usage and network requirements, so it is disabled by default.

Enable snapshotting by setting enableSnapshotting = true in network.toml:

[network]
enableSnapshotting = true

Input latency​

Easel hides latency from the player using a prediction technique called rollback netcode. Rollback netcode displays the predicted state of the game to be displayed a few frames before all inputs have been received. This prediction is normally correct, but when it is wrong, the game will need to perform a rollback to correct itself. This may appear as the player's character suddenly changing direction or a fireball suddenly appearing. Because rollbacks are so fast and often only a few frames behind, often the player does not notice them, and so this is a good way of making the game feel more responsive.

Easel only uses rollback netcode when the input latency is too high, determined by the maxInputDelayMs parameter. By default, this parameter is set to 32ms. The game will perform just enough rollback to meet this level of input latency and no more. If all the players in the game are already closer than this level of input latency, there is no need any rollback, and so the game will not perform any.

All of the above settings are just defaults. The player can choose their own input latency for themselves using the Performance Dialog, which you can make available to your users using the PerformanceDialogToggle function.

Performance limits​

Easel limits the rollback to what the player's computer can actually handle, and so if a player's computer is not fast enough to handle a lot of rollback, the input latency for that particular player will be increased to compensate.

For example, if the player's computer is predicting 4 frames ahead (approximately 67ms) ahead, then it needs to be able to compute 4 frames for every 1 frame, which is effectively running the game at 240fps and not 60fps. This can be quite demanding. This means, improving the performance of your game will allow the player to have a lower input latency.