Multiplayer

Bolt's classes are network replicated. Bolt uses the Model-View-Controller (MVC) paradigm for handling multiplayer:

• Model: Inventory components and item stack objects.
• View: UI widgets which the player interacts with.
• Controller: Inventory controller component(s).

Controllers

To make using inventories as easy as possible, most of this happens behind the scenes. The controller component(s) handle sending these requests and broadcasting the server's approve/deny response when received. When a player wants to manipulate an inventory, you only need to call one of the Request functions. These will handle all of the prediction, sending RPCs, syncing, etc. for you. If you're interested in seeing their process, see Advanced.

Extensions

You may override these functions to customize the request behavior:

1. Can: used to check what the result of the request would be. E.g., "Can I deposit items from one slot to another?"
   • This check is the same regardless of which player requests it.
2. Verify: Check player-specific conditions for each request; has context of the requesting player.
   • While this may seem similar to the Can function, Verify is meant to check player-specific conditions. E.g., "Is the player's pawn close enough to the chest actor to open it?".
3. GetDropTransform: Get the transform where dropped items should be spawned. Called from Request_DropWorldItemFromSlot.
   • By default, this will spawn at the attached player's pawn location.
4. GetDropInstigator: Get the pawn that acts as the Instigator for the dropped item.
   • By default, uses the attached player's pawn.

Implementors

Currently there are two implementors for inventory controllers:

1. BLInventoryControllerComponent, a simple and lightweight inventory controller for those who are not using GAS.
2. BLInventoryAbilitySystemComponent, an inventory controller for those who want to use gameplay abilities to handle inventory requests. See ability system integration for more info.
   • Note that this component doesn't have Verify functions; you can implement this in each ability.

Advanced

For reference, this is the flow for Request functions:

Request Flow

Guide

See the guide to set up world items and to see configuration options. Although, in most cases the example project's configuration will be sufficient.

Client-Side Prediction

Client-side prediction improves players' experience with inventories by reducing their perceived latency. This works out of the box in Bolt, but here is an explanation if you want to know more:

Each time the player wants to manipulate inventories, they must send a request to the server. If it fails, the server explicitly responds with 'Deny', otherwise inventories must wait until the results are replicated. While waiting for the server to respond, inventories will predict the results locally. This way using inventories appears seamless to players, even if their latency is high. Players may chain multiple actions (even dependent ones) without waiting for the server's response. When the client receives the server's response, the client syncs its state from the server's (if success) or rolls back the prediction (if failure). A more in-depth description of the prediction system can be found in the BLPredictionSubsystem.h file.

Predictive Actors

Bolt has support for predictively spawned and destroyed World Items. To enable predictively spawning and destroying actors, attach a BLPredictiveActorControllerComponent to the player controller.

Predictively spawning and destroying world items are handled by their respective requests:

• If a World Item's slot becomes empty while predicting for a request, the world item will predictively destroy itself.
• The request for dropping items will handle predictively spawning the world item.

As of the current version, Bolt doesn't support predictively spawning/destroying other actors, although this may be added in the future.