Network Contexts

Overview

The multiplayer experience in Core is achieved by sharing information back and forth between a server, and the computers of each connected player. Because that process takes time, Core has different contexts that you can use to specify code that should run just on the server, or just on individual computers, clients.

Many functions in the Core API will only work on a script in a Client or Server Context.

How Networking Works

When a Core game starts, a version of it begins on a server. Each player that connects creates a local version of the game, with the default and client information copied to it. To create a multiplayer experience, players need information about their actions passed through the server to the other players, to be copied into their local versions of the game.

Creating a Context

To make it easy to manage contexts inside of the Core Editor, contexts are treated like folders. Any object or script that is inside of these context folders will have that context.

Contexts are created in the Hierarchy window.

1. Right click inside the Hierarchy window to open the menu.
2. Mouseover Create Network Context….
3. Select New Client Context, New Server Context, New Static Context, or Local Context.

Alternatively, you can select a group of objects to be moved to a context, and choose New Client Context Containing These or New Server Context Containing These.

Contexts

Default Context

All Core content starts out in this context unless they are moved into a new one. Objects in the default context can have collision, and are visible to both the server and the client.

Example Uses of the Default Context

• Walls and terrain
• Trees and scenery objects
• Platforms that do not move
• Signs that never change

Objects in the Default Context are all the objects that need collision. If you want to move one of this object from a script, you have to enable the networking for this object. For example, if you have 3 platforms with one in the middle that is rotating, you need to enable the networking for this object and use the method RotateCotinuous. Networked objects have this “(networked)” prefix in the Hierarchy.

Client Context

The client context can be different on each player’s individual instance of the game. It is efficient to put as much as possible in this context, because it requires no confirmation from the server, and is runs locally.

Objects in a client context cannot have collision.

Example Uses of Client Context

• Object pickups that are always available to the player.
• Visual Effects

Server Context

The server context is used for scripts that don’t need access to the client side. Scripts in other contexts also run on the server, but in the server context they cannot be accessed by the client.

Example Uses of Server Context

• Scripts that handle gameplay logic
• Rounds and timers

Diagrams of the different contexts

Using the different contexts with Triggers

In this example, the player equips a Gameplay Object of type Equipment that shows a barrel in front of the player. The barrel is placed in the Client Context with Can Overlap Triggers turned on. Only the client will render the barrel so you can’t detect if the barrel enters a specific zone using a Trigger (Default Context).

The Barrel is not detected and only the player overlapping with the trigger is printed in the Event Log tab.

If the barrel is at the root of the Equipment, it is now Networked and it can interact with the Default Context.

The Barrel is detected (Event Log).

Sending Events between contexts

As previously discussed in the previous lesson, you can send Events. Following the diagrams, you can send data and information between the Server Context and the Client Context. Events sent with Events.Broadcast are staying in the current context, either server or client.

When receiving events from the Client Context to the Server Context, you can use Events.Connect or Events.ConnectForPlayer to also get the information of who sent the event.

-- Client context
Events.BroadcastToServer("HP", 75)

-- Server context
Events.Connect("HP", function(hp)
  print(hp)
end

-- or if you want to know who sent it
Events.ConnectForPlayer(function(player, hp)
  if not player:IsValid() return end
  print(player.name..": "..hp)
end)Code language: Lua (lua)