Version 8.0 Migration Notes
SnapNet for Unreal Engine version 8.0 focuses on reducing server-side resource consumption and supporting larger numbers of clients and objects. The major developer-facing changes are as follows:
- The maximum number of supported clients has increased from 64 to 192.
- A limit can be placed on the maximum number of simultaneous unique instant replays. This can dramatically reduce server memory required for large client counts and place an upper-bound on the CPU time spent calculating these unique views for clients.
- Experimental support for multithreaded delta encoding has been added. This feature can dramatically reduce the time SnapNet servers spend on the game thread by offloading delta encoding and packet generation to another thread.
- The various implementations for all of the smoothing options available to entity renderers have been simplified and consolidated into a single pipeline for transform post-processing.
Please check out
DefaultEngine.ini in source control and boot the editor with the latest version of SnapNet to upgrade project settings. Although settings are upgraded automatically, please double-check that things are configured correctly after the upgrade.
Multithreaded Delta Encoding (Experimental)
This experimental option is disabled by default and can be found under Project Settings → SnapNet → Server → Advanced → Multithreaded Delta Encoding (Experimental).
Whether this option makes sense for a given title is mostly a business decision that comes down to cost optimization for dedicated server instances. Games with small to medium match sizes should likely leave this option disabled. In these cases, developers typically want to run multiple server instances per core, so it is more efficient to perform all computation on a single thread.
For larger games, however, using multiple cores/threads per match often makes sense as it costs a similar amount per-player (due to the increased number of players in a session). In these cases, allowing SnapNet to perform delta encoding and packet generation in parallel gives the server simulation more time on the main thread, allowing more objects and/or higher tick rates.
Note that while this feature should be considered experimental and bugs may arise, we recommend developers enable it if it makes sense for their game given the guidance above. Please reach out with any issues encountered so that they can be addressed as soon as possible.
Max Unique Instant Replays
This option can be found under Project Settings → SnapNet → Server → Advanced → Max Unique Instant Replays.
Playing back an instant replay for a client requires additional memory and can consume additional server CPU resources during playback. In previous versions of SnapNet, sufficient memory was always allocated so that the server could play back unique instant replays to every client simultaneously. In practice, usually either all clients are playing back the same instant replay (e.g. play of the game, last score/kill of the round, etc.) or a handful of clients are playing back unique instant replays (e.g. killcams). By configuring a limit on how many unique instant replays can be playing simultaneously, developers can limit the server resources required, which is especially helpful for games with large client counts.
The default value is 16. There is no need to ensure it’s configured to a value lower than Max Clients as it will automatically allocate resources for the smaller of the two at runtime. To configure no limit, as in previous versions of SnapNet, this value can be set to -1.
Min Seconds Between Baselines
This option can be found under Project Settings → SnapNet → Server → Advanced → Min Seconds Between Baselines.
While this setting existed in previous versions of SnapNet, its default value has changed from 10 to -1. It is recommended that all existing projects change their settings to this new default. If a project has not changed this setting from its previous default, its value should be updated automatically at first run of the editor as described above.
Save Prediction and Decay Error → Save Prediction
There are various places in the codebase where usage of “Save Prediction and Decay Error” has been renamed in favor of simply “Save Prediction”. This includes:
Any usage of the above will need to be updated accordingly.
Prediction Error Reduction Rate
PredictionErrorReductionRate has been moved from
Most developers have probably left this value at its default. If so, no action needs to be taken. In cases where this property has been intentionally changed for an entity, the modified value should now be set on the corresponding entity renderer instead.
Use Prediction Error Reduction For Remote Owners
USnapNetEntityComponent::bUsePredictionErrorReductionForRemoteOwners has been removed. It is no longer needed and any usage of it can be safely removed. Prediction error reduction will now automatically disable if smoothing is active.
USnapNetEntityRendererComponent::UpdateSmoothing have been superseded by
If games have implemented subclasses of
USnapNetEntityRendererComponent that override either of these functions, then they should override
PostProcessTransform instead. If any questions arise, please don’t hesitate to contact us for guidance.