Networking
Rationale
Adding networking to a project quickly adds a lot of complexity and is non-trivial. Tutorials make it seem easy, but don't usually cover many edge cases and real world implementation problems.
It is generally not recommended to add multiplayer to your first project. Most developers, including myself, ignore this.
So what is there to know?
- It is complex and takes much time.
- When integrating multiplayer it is crucial to understand the underlying concepts that make for non-buggy multiplayer experiences. Without understanding these concepts, your networked game might open the door to cheaters or fall apart when introducing some latency.
Framework
Firstly, here are some old docs with a decent explanation of the different blueprints and their replication rationale.
You can have replication using Blueprints only (perhaps not recommended for complex games yet).
Below image, taken from Unreal Engine Framework Reference, illustrates how classes relate to each other
Authority
It's important to understand what kind of experience you're trying to create. The incentive to cheat in a friendly 4 player co-op game might be negligible. A competitive race game is a very different story.
For the co-op game you might choose to have clients make decisions that reflect the game state. This is called client-authoritative. For the competitive race game, you will need a server that confirms the data for every frame each client sends. This is called server-authoritative.
If the nature of your game allows you to implement features in a client-authoritative way, it might be legitimately valuable to choose that to keep complexity down and development speed up. For example, you might consider having clients make decisions about their characters and the game state and exchange data (perhaps directly) with other clients.
Replication
Client-side prediction - and for server authoritative games, server reconciliation - are essential for networked games.
Client-side prediction is when you don't wait for the server to accept your movement data based on previous frames, but rather already take the unconfirmed actions (i.e. movement) to conceal negative effects of network latency. This is essential in any networked game.
Server reconciliation is the process where a client's game state is updated to match the server's authoritative version to ensure consistency in multiplayer games. A client should be ready to roll back a number of framed to the last confirmed frame if necessary.
The Character Movement Component (CMC) and Vehicle Movement Component (VMC) from Chaos Vehicles-plugin have built-in support for client-side prediction and server reconciliation. They take away much of the complexity for you. However, adding custom animations quickly complicate things; you will need to extend the blueprint and might quickly also need C++ code.
Testing
Testing replication at its basis is very simple.
Use multiple clients
- Start the game using multiple clients
Simulating network latency
Simulating latency and package loss can be done in the Editor Preferences.
These settings will most likely start showing some lag-induced stutter in the movement of actors.
This is what client-side prediction is for. Currently, UE5 example projects don't have client-side prediction implemented, so you will need to implement it yourself.
Other resources
- Using steam sockets for networking