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.
Regardless of if we are the host or the peer, we always show our own paddle by our own mouse.
Sync object does not transmit which layers objects are on, to save bandwidth. It never changes in this game anyway, but this event makes sure they always appear on the correct layer.
The host and peers update their GameState variables differently, but we can handle its value the same: if we're in "getready" or "go" state, display some text in the score display.
Finally when the game is in "started" state, we display the score held in the points variable of each paddle. Both players see the host score on the left and the peer score on the right, corresponding to the position of the paddles. The host paddle can be picked by matching its peer ID to the host ID, and the peer paddle can be picked by checking its peer ID is not the host ID.
Conclusion
The general model of a multiplayer real-time game is:
- The host has behaviors enabled and actually runs the game logic.
- Peers have behaviors disabled and just uses "sync object" to passively watch what happens. However they can influence the game from their client input values, which the host reads and uses to influence the gameplay.
Pong is a simple example, but still involved 40 events. This example has also not covered local input prediction or lag compensation. Designing multiplayer games can be challenging and can take some time to learn. To move on to the final concepts in a slightly more complex game, move on to Multiplayer tutorial 4: real-time game.