Signalling group
This group is similar to the previous chat example in that it deals with connecting to the signalling server, logging in, joining a room and determining if we are the host. However there are some key differences now that we are dealing with objects and real-time synchronisation.
First of all, in On start of layout we must set up the objects and data that are going to be transmitted. The first action sets up the inputs that peers send to the host. To prevent cheating, the peers only send their inputs to the host, who performs the actual collision tests with the paddles and ball. The only input the peer has is the vertical (Y) position of their paddle.
The inputs that peers send to the host are called the client input values. In this case we use one input which we name "y", for the paddle Y position. It uses a 16-bit integer, since it only uses two bytes and sub-pixel positions don't matter. The input value also uses Linear interpolation. This means even if updates are coming in to the host infrequently, the multiplayer engine guesses the in-between values assuming the paddle is moving linearly. This ensures movement of the paddle is smooth. If we chose None for the interpolation, paddle movement could often look choppy.
The next part of the event sets up which objects and which of their instance variables are synced.
The first action uses the Multiplayer object's Sync object action. This is the key action to indicate which objects are to be sent over the network. Syncing an object is one-way: it means the host tells peers how many of those objects exist and where they are. Peers only receive this data and any changes that peers make to these objects will be ignored and overridden! The client input values are the only ways the peers have of affecting the game, and the only gameplay data that is sent from the peer to the host.
The host has the authoritative version of the game, and the peers are doing their best to display what the host has got. The host is solely responsible for creating, moving and destroying these objects; as it does so, Sync object will also cause objects to be created, moved and destroyed on the connected peers. All of this happens internally in the multiplayer engine as a consequence of this action.
Since Sync object will move objects by itself, and only the host is "really" running the game, the peers also disable all the behaviors on the objects. For example the ball has the Bullet behavior. Only the host should have the behavior enabled. The Bullet behavior should be disabled when acting as a peer, since Sync object will already be moving it as it moves on the host, and having the behavior enabled on the peer could cause the behavior to conflict with where Sync object is trying to move it. In this example the Bullet behavior is initially disabled, and it's enabled in the events when acting as the host.
Sync object can update the object position or angle, or both, or neither. In this case we're only interested in the position, since the angle of objects is not important to gameplay and it would be a waste of bandwidth to send data about object angles. The Bandwidth parameter allows the maximum rate of updates from the host to be reduced. This is not normally necessary - refer to the manual entry to find out more about the option.
The Sync object object by default does not transmit any other data, and instance variables would not be updated. It would be wasteful to automatically update every instance variable, since some of them might only be used locally. After the Sync object action, we can optionally use any number of Sync instance variable actions to add instance variables for the host to also send to peers (and as with Sync object, the instance variables are updated automatically). It's important to note Sync instance variable can only be used after Sync Object. By itself it does nothing; the action means "also sync this variable to an already-synced object".
The only variable we sync in this case is the points variable of the Paddle object. This is a simple way for everyone to know each player's score.
The client value tag is used if the instance variable also corresponds to a client input value. This is not necessary in this example, but is covered in the next tutorial.
The ball object must also be synced, so the peer can see where it is! However there is no need to sync anything other than its position.
Now that all the client inputs and synced objects are set up, the last action in On start of layout connects to the signalling server.