Common group
The Common group has events that are used for both the host and peers.
When peers connect and disconnect, we add a log just like in the chat tutorial.
Our own peer is also updated so its lookatx and lookaty variables are set to the mouse position. For peers, these values are sent as client input values to the host; on the host we update it anyway so we can treat all players consistently.
Every tick, we need to update a few things. First of all every peer is made to point towards its look position, and their associated AimSpot placed at the same position. The PeerName labels are positioned above each peer with some stats including the player name, health, kills and deaths. Finally, we always move objects to the appropriate layer. The reason for this is Sync object does not transmit which layer an object is on to save bandwidth, since for most games objects remain on the same layers. As a result Sync object might create objects on the wrong layer for peers, so we make sure everything is moved to the correct layer.
We also display which peers are firing. This event is purely cosmetic: the actual hit testing happens only on the host, and has already been covered. However it would look strange if damage was being dealt but nobody appeared to be firing. So when a peer is firing (remember this is indicated by bit 4 of inputs), their PeerLaser is made visible and positioned from their gun to their aim position.
The last events deal with the chat room functionality, covered in the previous tutorial. Finally the last event unfocuses the chat controls when we click in the game, otherwise our keyboard controls would go to the text box after sending a chat message. This way the user can click back in the game to restore keyboard control to the game, not the chat.
Conclusion
Designing multiplayer games can be challenging. These three tutorials have covered everything from the architecture of the Internet to how to perform lag-compensated hit-testing on the host, so hopefully now you are in a much better position to take on the challenge!
To learn even more, refer to the manual entry for the Multiplayer object. These tutorials have offered a practical guide to putting together each part of the Multiplayer object to produce a game, but the manual will go into more depth on each specific feature.
Designing multiplayer games requires a close awareness of where data is travelling, such as that Sync object only sends from the host to the peer, and client input values only go from the peers to the host. It is also important to remain aware that both the host and the peers are running the same Construct project, which requires being able to consider your one project from two points of view. The technique of activating the correct event group makes this a lot easier to think about in the event sheet, but you must also remember this when adding the objects and setting their properties. With practice and experimentation this should become easier and you'll be able to design the multiplayer game you've been planning!