Understanding Multiplayer

Multiplayer Experiences have some special requirements to consider.

Multiplayer supports greater synchronisation for Behaviours and Components that control and change the ‘position’ or ‘state’ of objects and the environment.

This means when objects move, or a change to the environment occurs, every player can see those changes simultaneously.

A great example of this is the use of the Door Behaviour.

Actors equipped with this Behaviour are triggerable by ALL players, and its collision will change for ALL players as well: When a door opens, it’ll open for all players. When it closes, it will close for ALL players.

Another example is the Basic Platform Behaviour.

When actors with this Behaviour move from one location to another, the movement will be synchronized for ALL players.

Using moving platforms and doors synchronized for all players is a great way to set challenges and provide access to different areas of an experience.

SINGLE-PLAYER VS MULTIPLAYER

Multiplayer functionality is an exciting part of building an experience, but it does come with an added layer of complexity.

As soon as more participants are involved, it introduces extra ‘layers’ to consider when deciding how players interact, what those interactions trigger, and who can see the outcomes of those interactions.

This is because 'Synchronized' Behaviours and Components can’t send messages to, or receive messages from, Behaviours and Components that aren’t 'Synchronized'.

Not ALL Behaviours, Components, and Tools can function with synchronization.

For example, Quests created in the Rules tab aren’t synchronized and can only be triggered by ‘Client Only’ messages and completed ‘locally’ by individual players.

To address this, the recent 0.8 update introduced a Client Only [SP] and Synchronized [MP] split for Behaviours and Components.

LEFT: Client-Only Behaviours RIGHT: Syncronized Behaviours

Client Only [SP] Behaviors and Components are the ones that work ‘locally’, meaning messages sent and received by them will only be received from or sent to other ‘local’ Behaviours and Components. These messages and changes in the experience, such as Quest progression, will only occur for an individual player, even in a multiplayer experience.

Synchronized [MP] Behaviors and Components are the ones that work ‘globally’, meaning every message exchanged between actors happens for ALL players, and ALL players will be able to see the state changes that come as a result of those messages.

Take the Collectable Component, for example.

This Component can be selected as either ‘Client Only’ OR ‘Synchronized’.

If an Object with [SP] Collectible is collected, it will disappear from the individual player's experience but remain for others in the experience. This is because the actors' ‘state' change only occurs for an individual player.

If an Object with [MP] Collectible is collected, it will disappear from the experience for ALL players, essentially making it only collectable by one player. This is because the 'actors' state change occurs for ALL players.

BEHAVIOURS & COMPONENTS LIST

With the [SP] / [MP] split almost doubling the options to consider when applying a Behaviour or Component, it may feel a little daunting.

To help get a lock on exactly which ones have changed and where they can be used, take a look at the chart below.

A list of the ported, new, and legacy Behaviours and Components.

The legacy Behaviours and Components in the table above have been marked in grey and labelled NOT compatible with MP Experiences. These should not be used in Multiplayer experiences.

Using non-ported, ‘client only’, Behaviors and Components in a Multiplayer experience can cause desynchronization between players.

You may notice that some items are labelled as 'Synchronized, but NOT ‘Client Only’.

This doesn't mean those Behaviours and Components can’t be used in Solo-Experiences, it means there is no longer a version that will be experienced uniquely by individual players.

For example, the Basic Platform is NOT available as 'Client-Only' and can only be accessed through the ‘Synchronized’ filter in the Behaviour window. It can still be used in a Single-Player experience, it just can’t be used in a multiplayer experience without its movement and collision being available for ALL other players.

As a general guide, ‘Client Only’ use cases that CAN be implemented in a Multiplayer experience include:

Dialogue with the Asker Behaviour, notifications with the Speaker and Indicator Components, responses to actions using the Animated Decoration Behaviour, and Quest objectives activated by Behaviours like the Message Broadcaster.

SELECTING [SP] OR [MP] BEHAVIOURS AND COMPONENTS

To apply a Behaviour or Component, first, select an actor and click on the Behaviour or Component field in the Properties Panel.

When the pop-up window opens, the default view will display the ‘Client Only’ variants first, which can be identified by their green text and the prefix [SP].

Behaviours and Components with grey text will be visible in the default view but aren’t compatible with multiplayer experiences and should only be used in single-player experiences.

To access the ‘Synchronized’ versions of Behaviours or Components, click the drop-down menu labelled ‘Type’ in the top right-hand corner of the pop-up and select ‘Synchronized’. This will refresh the window with a list of items in yellow text with the prefix [MP].

Once you’ve found the right version for your needs, simply click on it, and it will be added to the selected actor.

The colour coding used to identify [MP] and [SP] Behaviours and Components will be removed once they have all been ported to multiplayer compatibility in future updates.

There are no visual indicators in the scene to show if an Object is set as ‘Client Only’ or ‘Synchronized.

One final point to make here is that [MP] and [SP] variants of Behaviours and Components can’t exist on the same actor. So an Entity with the [MP] Asker Behaviour can’t have an [SP] Indicator Component.

Trying to select a Behaviour or Component from an alternate network will result in the message:

"BLOCKED BY Network policy incompatible with another behaviour/component assigned to the actor/s."

The message received when trying to add a [SP] Component to an actor with a [MP] Behaviour.

Again, this is because each version is designed to interface with either a ‘client’ environment or a ‘synchronized’ environment, and having both would create a conflict in environments.

MULTIPLAYER CONSISTENCY

To reduce the potential for faults and inconsistencies, it is important to make sure that an actor’s 'Type' is consistent.

This means ALL Components and Behaviors on a single actor must be EITHER ‘Client Only’ or ‘Synchronized.’

1️⃣ Consistent Type

If a Behaviour or Component of a specific ‘Type’ has already been added to an actor, then the Game Maker will automatically restrict access to conflicting settings by making the alternate ‘Type’ un-clickable in the Behaviour or Component window.

2️⃣ Consistent Messages

It’s also important that an actor’s communication stays consistent, keeping in mind that actors set to ‘Client Only’ cannot send messages to ‘Synchronized’ actors set to and vice versa.

3️⃣ Consistent Hierarchy

An actor’s parent-child relationships must also be consistent. If an actor is set to ‘Client Only’, it cannot be a child or parent of an actor set to ‘Synchronized’, and vice versa.

4️⃣ Consistent Spawn

An actor ‘spawned’ during an experience via an Asset Spawner Behaviour, Replace Asset Behaviour, or Drop Component must maintain the same 'Type' as the ‘spawner’.

This means that a 'Synchronized' Behaviour can’t spawn by a 'Client Only' actor, and vice versa.