Signalling group
This group has many similarities to the previous pong example. However there are some important differences in what is synced, since it's a different kind of game.
First of all, in On start of layout we must set up the objects and data that are going to be transmitted. The first actions set up the inputs that peers send to the host. To prevent cheating, the peers only send their inputs to the host, who then does the actual movement for the peers. Local input prediction covers up the latency from sending the inputs to the host and receiving the new position back. The inputs we add look like this:
The inputs that are sent to the host are called the client input values. For this game we have three: the aim position X and Y co-ordinates, which we call lookx and looky, and the button states the player is pressing, which we call inputs. The look X and Y are int16 values, since they don't need sub-pixel precision and the layout is far smaller than 32767, the maximum value that can be sent with this precision. inputs is an 8-bit value which we set individual bits for each control. This game has five controls: four directions and left mouse button to shoot with three more spare bits, so we don't need to use any higher precision. Later on in the tutorial we'll deal with updating these values so the correct information is sent to the host.
The look X and Y values use Linear interpolation. This means if updates come in infrequently, the multiplayer engine guesses the in-between values by moving them in a straight line between known values. This ensures movement of the look position moves smoothly. However it's very important that no interpolation be used for the inputs, so None is chosen for interpolation. There are no in-between states for these inputs and using interpolation for this value will simply cause incorrect results on the host.
The next part of the event sets up which objects and which of their instance variables are going to be synced. These are the relevant actions:
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. 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 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.
It is important to save bandwidth by only syncing objects that absolutely have to be transmitted. In this case the Peer object represents a player and must be transmitted. It is usually redundant to sync things like terrain, scenery and props - it is a waste of bandwidth to sync them, especially if they never change. Even if they do change, if the results are unimportant to actual gameplay (e.g. cosmetic bullet holes or craters that don't affect collisions) then it's fine for local peers to handle that by themselves. There's also no need to sync the AimSpot, PeerLaser or PeerName objects in the container with the Peer: the container ensures they are created and destroyed at the same time, and later events will position them based on the Peer object only, so there's no need to send any extra data for them.
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 peer angle is always set towards the aim position. int16 precision is suitable for positions. (Linear interpolation is automatically used here for the object position, and Angular interpolation used for the angle if it is enabled.) 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). The variables added in this case are the lookatx and lookaty variables (so we can see where other players are aiming), inputs (so we can tell what buttons they are pressing), and the player stats with the health, kills and deaths variables. Remember that as with Sync object, these variables are only sent from the host to peers to indicate what the state of the game is. Also note that although peers are receiving which direction buttons each player is pressing in the inputs variable, this information is ignored: Sync object is already updating object positions, so it's not important to take in to account their controls. However we are interested in whether or not they are firing, which is just one of the bits in this value, so we sync the whole variable anyway. (Another game might also find the input states useful for setting animations.) The look positions also use linear interpolation, and the others don't use any interpolation since they should simply be updated in steps.
The client value tag is used if the instance variable also corresponds to a client input value. In other words if a peer's client input value is set from that instance variable, setting the corresponding tag here allows the multiplayer engine to know they are linked. The host can use this information to reduce the latency when relaying the inputs to other peers.
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.