Relevant VE2 documentation is linked at the bottom of this page

<aside> 🎓 If you’re attending this course through the Graduate school, this page contains the contents of the second in-person lesson. It could act as a useful reference for you after the session, but please don’t go through the material before the session or you’ll be bored!

</aside>

Networking

VE2’s networking system

Before we write our own networking code, we must first understand how VE2’s (largely automatic) networking systems operate. Consider a scenario: Two players are together in multiplayer, and both try to grab a grabbable ball at exactly the same time. A key factor to consider in networking is always the latency - it takes time for information to get from one machine to another! Player One, picks up the ball, and their machine sends a message to Player Two, telling them they’ve picked up the ball. However, at exactly the same time, Player Two also picks up the ball, and sends a message to Player One. Which player is correct? Only one player can hold the ball at once, and yet both players think they got there first!

For this reason, it is essential to have a “true” copy of the world, that has priority over all the others. In VE2, this “true” copy of the world is run on the machine of the first player to enter the scene, known as the “host”. All other players are known as “non-hosts”, and the state of their world can be overridden and reverted by the host.

When a non-host wants to change the state of the world in a way that other players can see, a message containing information about the change must be sent to the host. The host then sends that information to all of the other non-hosts, and all of the non-hosts’ world-states will change according to that information.

The host is constantly broadcasting information about the state of the world to all non-hosts. VE2 handles this automatically. The information that VE2 handles itself includes:

• The current activation state of all activatables (on/off)
• The current value of all adjustables (float)
• The grab state of all grabbables (which player is grabbing)
• The positions, rotations, and velocity of all Rigidbodies with a V_RigidbodySyncable
• The positions and rotations of all transforms with a V_TransformSyncable
• The positions and rotations of all the players
• The sync data of V_NetworkObjects (more on this later!)

This all means that most of the syncing work is already done for you, but not all! VE2 only syncs the current state of these components; all information about previous states is not synced - this is really important!

V_NetworkObjects and previous states

To understand the implications of VE2 networking model for historical states, let’s look at an example from the game you’ve been building during this course. The target’s movement is determined by the activation state of the left and right buttons. While the right button is activated, its activation syncs to all players, and all players currently in the scene see the target moving right.

Now imagine that a Player 1 is in the scene on their own, and they press the move right button. The target moves all the way to the end, and Player 1 releases the button. Then Player 2 joins the scene. Player 2 sees the target at the starting position, rather than at Player 1’s “correct” position to the right, because the information that the right button was activated is in the past and has been lost.

In the case of the current positions and rotations of gameobjects, these can be synced by adding a V_TransformSyncable to those GameObjects. In the case of gameobjects with Rigidbodies, a V_RigidbodySyncable can be used to sync position, rotation, and velocity/angular velocity.

For any other data held within our scripts that isn’t part of a VE2 component, such as game time remaining and score, we have to write some code to sync these explicitly. For this, VE2 provides a tool called a V_NetworkObject