Skip to main content

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.

info

It is generally not recommended to add multiplayer to your first project. Most developers, including myself, ignore this.

So what is there to know?

  1. It is complex and takes much time.
  2. 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

A quick read.

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

Increase network latency

Other resources

What are your thoughts?