Bolt Use Cases

The following are some of the major Bolt use cases that describe different approaches. Keep in mind that most AAA games use hybrid approaches (usually movement and shooting being client authoritative with server side sanity checks and the rest being server authoritative). You are free to implement any apprach you want or choose a mix of approaches.

Note: in cases where is mentioned root motion is possible please understand that syncing root motion to proxies, it would likely require more than simple transform syncs and rather likely some special cased handling.

In general these are listed from easiest to most difficult to implement.

Completely client authoritative (no Commands)

Clients create their own Bolt entities. I.e. they create their own player and any objects their player is responsible for. They can simply move their own objects like it is a single player game, and they will sync with other players via Bolt state. The client can freely use rigid body controllers or root motion in this case. The host still can maintain some authority over some aspects. Commands are not used.

Pros:

• Easiest implementation. This is as close to writing a single player game as possible;
• No commands. Commands are complex;
• Client predicted movement. Movement is instant. No round trip time for locally controlled players;
• You can use rigidbody controllers and root motion;
• Each client handles his own simulations for his entities so the CPU work is essentially distributed rather than focused on the server.

Cons:

• Completely client authoritative. Clients can trivially hack and even the host has no way of sanity checking by intercepting and changing client requests since the sync is occuring completely through bolt state syncs. The server can, however, monitor what the client is doing and kick the player. However, interception is not possible;
• The host has no way of controlling the creation of Bolt Entities that clients are allowed to spawn. The client can simply create as many entities as he wishes. If the client wishes to create a car, it is trivially to hack this to happen;
• Multiple sources of truth. This can be a hard problem (as opposed to a single one with complete server authority).

Examples:

• The Forest;
• Rust;
• The Division.

Non-predicted, server authoritative movement via Commands

This use case describes a way of controlling something that is server authoritative but in a non-predicted way. I.e. it will take a server round trip before you will see your input reflected on your own entity. In this case commands are used solely for input, and there are no command results. The input is collected on the client, but no prediction occurs. This means the client does not apply his own input to his own entity. The server receives the input and applies the input to the server side entity. The entity then replicates the transform sync back to everyone - including the controller!

Example: you want players to control cars in your game, but you do not want them to be completely client auth like the example above since you want the server to control their instantiation. However, since cars are rigidbodies, you cannot predict them. So the server creates the car and delegates control to the player when the player enters the car. The player sends his input to the server and the server processes it and applies it to the simulation. The server then syncs back the transform information back to proxies and the controlling player via Bolt state.

Pros:

• Server still owns entities, so the client has no way of instantiating or controlling anything without server approval;
• Server authoritativ;
• Allows controlling rigidbodies within the simulation;
• Single source of truth;
• Easy to implement;
• Not hackable;
• Uses relatively low Command bandwidth compared to other approaches (here).

Cons:

• Not predicted. Requires a round trip from the server before input is reflected on the controller. This is a pretty bad negative in most cases as players expect to see the results of their input immediately. For fast moving entites this can be frustrating as you often have little time to adjust and if you have to wait for a RTT before you see your inputs it can be annoying;
• Simulation is run on the server. This can add up to significant CPU costs on the server;
• Uses a simple implementation of commands, but commands always add complexity.

Examples:

• World of Tanks
• Dota 2
• League of Legends

Client auth, predicted movement with server side sanity checks with Commands

This case is a hybrid of fully client predicted, server authoritative and client auth. The server still owns entities, but the client essentially moves his entity in a client auth fashion and simply sends the final result to the server as command input. The Command inputs do not contain traditional inputs but rather the result of the client movement (position, rotation, etc). The server then receives this input and moves the player to the position / rotation / etc requested in the command input. The server has a chance here to look at the player’s movement request and decide if it is valid or not. If not, the server does not have to apply the same result to proxies. In this case the server will violently correct the controlling player by sending back an event to the player with his new position which will be an obvious visual artifact. This does not use Command results for corrections. The Command result will be empty.

Pros:

• Client predicted;
• Rigid body controllers and root motion should be possible;
• Server has a chance to at least sanity check client movement, compared to this one where the server has no way of doing so.
• Server still owns entities, so the client has no way of instantiating or controlling anything without server approval;
• Uses relatively low Command bandwidth compared to other approaches;
• Simulation is not run on the server (i.e. the server does not run inputs), so the CPU costs are much lower for this use case;
• Single source of truth.

Cons:

• Not fully authoritative. If the server implements no sanity checks this is essentially completely client authoritative when it comes to movement and thus completely hackable.
• With server side sanity checks you can only broadly validate the client’s requests without potentially culling valid requests from clients.
• When the server does correct the client it will be violent (as opposed to somewhat more subtle corrections with true client predicted/server auth described in here).
• Uses a simple implementation of commands, but commands always add complexity.

Examples:

• Most MMO’s like World of Warcraft
• Most AAA networked games you have played

Completely client predicted, server authoritative using Commands

This use case and by far the most difficult to implement. This is client predicted but fully authoritative and is the classic use case described in the Valve paper. This requires the client and server simulations be identical and requires a bunch of tricky code for dealing with rewinds and replays especially as you branch out from movement.

With commands the locally predicted entity (usually the player) uses the command system to move on his local machine, instantly (i.e. the “prediction” part). Instant response to movement is critical for players. The player’s inputs are sent to the server as part of the command. The server plays these same inputs as well, hopefully resulting in the same exact simulation that the client already predicted. The server then returns the result (the final position, speed, etc) back to the player for a certain frame, who then essentially resets his position and other state back in time to the server’s on that frame (the “correction” in the command result) and then he replays his inputs from that point back to the present to hopefully be back where he predicted he would be. If the server’s simulation was different, the player will end up at a different position. This is the server authoritative part, because the simulation is authoritatively running on the server and the player simply tries to predict what that simulation will be. If the player sets his speed to a very high speed, the server doesn’t care, because the client simulation has no bearing at all on the server.

Pros:

• Completely server authoritative. The client is essentially a dumb terminal and the server completely simulates the world;
• Single source of truth;
• Client predicte;
• Not hackable;

Cons:

• Very complex to implement. E.g. with a shooter once you are past movement, dealing with weapon switching, firing, ammo, reloads all cascade, and you have to correct them all (or implement some of them as client authoritative) or else the simulation falls apart;
• Cannot use rigid bodies. Root motion is generally not possible for most (root motion is actually predictable and possible but the non-trivial technical constraints are outside the scope of this document);
• Uses bandwidth / CPU for Command inputs / results which can be non-trivial on the server for a large number of controlled entities;
• Simulation is run on the server. E.g. for a shooter this means the server has to simulate inputs for every controlled entity. For one hundred players that would require one hundred character character motors to run (including CC.Move () method calls) per fixed update tick on average. And that is just for movement let alone anything else being simulated! This can add up to significant CPU costs on the server;

Examples:

• Counter-Strike
• Fortnite
• Overwatch
• Ark