Introduction to Morpheus Networking

What is Morpheus Networking?

In MSquared, we replace Unreal's standard networking with our own custom implementation, called Morpheus.

Morpheus is the technology that enables thousands of players and objects to be networked together in the same space, in real time, whilst using the bandwidth of a standard battle royale game.

The fundamental concepts of Morpheus networking are the same as in Unreal:

• A single server coordinates multiple clients

• The basic unit of networking is the actor

• Actors are synchronised ("replicated") between server and client using two mechanisms:

  • Variable replication

  • RPCs

This document assumes a rough familiarity with these concepts, and focuses on Morpheus's essential differences from Unreal.

Morpheus Actors

In a Morpheus game, only actors that inherit from AMorpheusActor are networked. All other actor types are local-only. If you spawn an AMorpheusActor on the server, it will be replicated to all clients immediately. AMorpheusActors should only be destroyed on the server, and the actor's destruction will also be replicated to all clients immediately.

Each client sees every AMorpheusActor in the world; there is no concept of 'net relevancy' or 'checking in and out' an actor.

Changes to Core Unreal Classes

Since only Morpheus Actors are networked, a number of the core Unreal classes behave slightly differently when using Morpheus networking:

• GameMode - Functionally the same as native Unreal, except that it adds a default Morpheus Actor class, similar to the Default Pawn Class, and it replaces the normal GameState with a MorpheusGameState.

  • 
  • Note that the GameMode is also created on the local client, rather than exclusively existing on the server, since a client using Morpheus networking is configured to be a "standalone" game, rather than a "client", since it does not use native Unreal networking.

• GameInstance - same as in native Unreal networking. It exists on all machines, but is not networked.

• GameState - Not used in Morpheus networking. Replaced with a replicated MorpheusGameState (a Morpheus Actor that is replicated, and can be used functionally like a GameState.)

• GameSession - Not used in Morpheus networking. We handle online services and player connection separately.

• PlayerController - This is only present on the local client's machine. It is not replicated, and does not exist on the server.

• PlayerState - This is not networked. It is largely unused and untested with Morpheus networking - if you want replicated player data, you can use the Morpheus Actor.

• Pawn/Character - This is not networked. For the local player, this works the same as native local-only games. For other players, their in-game representation is determined by their morpheus actor's render target. (See Morpheus Render Targets).

  • If other players' characters are represented with actors, they are also subject to pooling (see Actor Pooling)

Replication

Network Levels

Although every client sees every AMorpheusActor in the world, it may not hold the full state for all of them. On each client, each AMorpheusActor is present at one of three network levels:

• Background

• Midground

• Foreground

Only actors in the foreground are fully replicated.

For a detailed description of how network levels work, see Network Levels.

Authority

Unlike in standard Unreal, a AMorpheusActor may have an authoritative client. This is an immutable property assigned when the actor is spawned. An actor's client authority affects both variable replication and RPCs.

(For how to assign a client authority to an actor, see "Spawning and Destroying" below.)

Variable Replication

In Morpheus, you can mark blueprint variables for replication the same way you would in Unreal. However, existing Unreal replication features such as RepNotify behave differently in Morpheus. For more information on how these features work and how to apply them in your variable definitions, see Replicated Properties.

RPCs

Morpheus supports the three main types of Unreal RPC: Server, Client and NetMulticast. However, the semantics of these differ from standard Unreal networking. For further information, see RPCs.

Morpheus Actor Components

In order to be networked, a component must:

• Inherit from UMorpheusActorComponent

• Belong to an AMorpheusActor

• Be created in its owning actor's constructor, using CreateDefaultSubobject. Components added to existing actors won't be replicated.

Authority and network level are delegated to the component's owning actor.

Variable replication and RPCs work the same way as for AMorpheusActor.

Spawning and Destroying

Spawning an AMorpheusActor

Only the server can spawn replicated AMorpheusActors. You can spawn them from server blueprints, using Unreal's standard SpawnActor functions. In addition, Net Startup Actors that are AMorpheusActors will be automatically spawned and replicated when their level starts up or their sublevel streams in.

By default, an AMorpheusActor has server authority. To spawn an AMorpheusActor with client authority, you must call SpawnMorpheusActorWithClientAuthority on the server. You identify the authoritative client by passing in an AMorpheusClientConnection; this is typically obtained by calling the AMorpheusActor function ServerGetRpcCallerConnection from within the handler for a Server RPC.

Morpheus does not support authority transfer. If a client disconnects, the server destroys any AMorpheusActors which that client had authority over.

Destroying an AMorpheusActor

Only the server can destroy replicated AMorpheusActors, using the standard Unreal Destroy functions.

Lifecycle Events

For AMorpheusActors and UMorpheusActorComponents, there's a single change to the standard Unreal actor life cycle. Instead of the standard BeginPlay event, you need to use MorpheusBeginPlay. (BeginPlay still exists, but shouldn't be used - it will print warnings in the blueprint compiler if you do use it.)

The call to MorpheusBeginPlay marks the point at which networking functionality becomes available. RPCs sent from within MorpheusBeginPlay are queued up and sent later, once the actor has completed initialization.