network.toml
The network.toml file can be used to specify the configuration related to the network.
[network]
enableSnapshotting = false
fastEnoughMs = 60
acceptableRollbackMs = 100
coherence = 0.85
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
Because Easel uses rollback netcode, each player can choose their own input latency. However, if the input latency is set too low, the game will need to correct itself more often using a technique called a rollback, which can be disorienting for the player. The corrections will appear as jitter, teleporting and visual artifacts. Easel comes with some built-in parameters which should allow it to choose a good level of input latency for most games.
The acceptableRollbackMs parameter determines how much rollback is acceptable.
By default, this is 100ms,
which means that the input latency will be reduced by 100ms but also means
that sometimes an action may not be shown on the screen until up to 100ms after it was performed
because the input was received late.
The acceptableRollbackMs will never reduce the input latency below fastEnoughMs,
which is the point at which the input latency is considered to be low enough that the player will not notice it.
At this point, it is better to give the player a more coherent experience than to try to reduce the input latency further.
By default, this is 60ms.
If you supply the coherence parameter,
you are switching to manual control of the input latency,
and all automatic input latency adjustments will be disabled.
The coherence parameter determines what proportion of inputs should have arrived before a frame is rendered.
For example, if you set this to 0.85,
this means that the input latency will be set to a level where 85% of inputs should have arrived
by the time the frame is rendered.
coherence causes the fastEnoughMs and acceptableRollbackMs parameters to be ignored.
If you set coherence too low it may cause inputs to be received very late.
If for example, inputs are often received 10 frames late,
the game must recompute 10 frames within the time it takes to render a single frame.
Effectively, the game must run at 600 frames per second and not just 60 frames per second.
This is highly CPU intensive and could cause your game to become unplayable on lower-end devices.
If you want to accept greater rollback,
it is recommended that you modify your acceptableRollbackMs parameter instead
as that allows the automatic latency adjustment to run,
which takes into account what a player's computer can actually handle.
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.