This system is fully replicated to support multiplayer. While it will do the heavy lifting for you, you will still want to have a basic understanding of multiplayer replication to fully utilize all of the custom features of this system. If you are new to replication in Unreal Engine I highly recommend reading through Cedric Neukirchen’s Multiplayer Network Compendium a few times. This guide helped me out when I was just getting started and is still a great resource for it today.

Replication Naming Convention

I use the following naming prefixes to define events specific to replication:

S_ = Server Event

C_ = Client Event

M_ = Multicast Event

Strict Access Check

I’ve included a strict mode inside the main components which deal with data (storage, currency, crafting, vendor, and workstation). It is enabled by default, and you can disable it by setting the strictMultiplayer? boolean variable to false. When set to true (default) this will yell at you (with a print string) when you try to perform a function call from the client that you should instead be called strictly from the server. The function will also be aborted.

Unique Identification

For players, the systems that handle saving and loading data between sessions will by default use the index of the player state found in the game state’s players array to uniquely identify players.

This is typically fine during development and is a simple solution, but if you need to uniquely identify and persist your players between play sessions you will need to implement the BPI_InventoryUniqueID blueprint interface, and respond to the getUniqueIdentifier function.

This blueprint interface should be implemented on the same owner as the component. For the player this would be the player controller, for everything else it will be right on the actor.

The implemented getUniqueIdentifier function will let you return a string as your unique identifier for that player/actor, and this string will be used in the save game slot name. How you come up with this string is entirely up to you.

For uniquely identifying actors see the section in the Save System chapter.

Uniquely identifying and persisting that identification between sessions is beyond the scope of this project, and most people will use a third party like steam or epic to obtain and use a player ID. You will need to handle getting this value on your side, and then use what I’ve provided to feed that information into my system, so it knows what unique ID to use.

To get a better understanding of how this value is used see the buildSlotName function in the components doing the saving. It might also be worth taking a look at the Save System chapter, since this is where that information is used.