Hey guys! Lead programmer Dave Ratti has put together a post for you on blueprint replication. You can view the original post over on our blog.
[HR][/HR]
Blueprint classes can replicate the same way as native C++ classes can. This is a crash course on getting started, though is not a full tutorial on networking gameplay code.
Making a blueprint replicate
A class must first be marked to replicate. Without doing this, a blueprint actor spawned on the server will not spawn on clients. This is done in the blueprint defaults, under replication:
Testing multiplayer in the UE4 Editor
The UE4 Editor provides a built in way for testing multiplayer games. To use this, simply set Number of Clients to a value greater than 1 in the Play In Editor Network settings. Then use the Play In Editor feature - by selecting the New Editor Window mode. This will launch a separate editor window for each player, and automatically connect them into a multiplayer game. This is the easiest way to test and iterate on multiplayer gameplay.
Authority checks
It will be important to only run certain parts of your blueprint logic on the server. For example, the server should be authoritative over the health value of each actor. Only the server should handle changing health. Clients should be free to run cosmetic logic, but should not run gameplay critical code on their own.
Doing this check in blueprints is simple; just use the Switch Has Authority macro:
Replicating Variables
Replicated variables are used to replicate state. Replicated variables are sent from server to client only. That is, the server’s value of a replicated property is sent down to all clients. Only the latest/current value of a property is sent. To make a property replicated, simply select the Replicated or RepNotify from the Replication drop down in the variable details panel.
‘RepNotify’ means the variable is replicated down like normal, and a notify event is called on both client and server when the variable changes. This is useful when you need to do additional work based on a replicated variable. For example, you may replicate Health down as an integer. In Health’s RepNotify event you may look at the health value and apply cosmetic damage effects (swap mesh, apply damage decals, play sounds, etc). It is more efficient to apply the cosmetic damage in a RepNotify than to replicate each cosmetic effect down individually.
If you select RepNotify, a function will automatically be added to your blueprint. It will be named OnRep_YourVariableName. Just implement a body in this function and will be called automatically.
Replicating Events (RPCs)
Events can also be replicated as RPCs (remote procedure call). An event can be called on one machine and replicate to another where it is executed. To use this feature, create a new custom event in your event graph. Click on the custom event and edit the Replication settings in the details view:
There are three types of replicating events:
Multicast events are called on the server and are executed on the server and all connected clients. These can be called on any replicating actor. Multicast events are best for replicating transient events (e.g, not state) to everybody.
The Server RPC type (‘Run On Server’) is needed for blueprints to communicate client to server. A Server RPC is only executed on the server. When the client reaches the node to call the custom event, he will send a packet to the server telling it to execute the event on the actor. The client himself will not execute the event locally.
Server RPCs can only be called by a client who owns the actor executing the event graph. For example, a PlayerPawn is owned by the client who controls it - only that client can send Server RPCs on that pawn. The pawn also may own weapons, abilities, inventory items, etc (this is game specific). This can be a hard concept to communicate directly in blueprints. It is something we will work to improve as time goes on.
A client RPC (‘Run on owning client’) is only sent from the owning client. In the same way that only the owning client can send server RPCs, only the owning client will receive Client RPCs sent by the server.
Finally, blueprint RPCs can also be checked to be reliable. By default, blueprint RPCs are unreliable and should almost always be unreliable. You should only make a function reliable if you are sure it needs to be.
Do you guys have any questions about blueprint replication? Sound off below and let us know!
