The rest of the Signalling group is more similar to the chat example; however there are still some more differences to come. First of all as before, once connected we log in with our username.
To join the game, one difference is we use Auto-join room instead of Join room. If we only used Join room, then everyone ends up in the same game. 30 players in a game which only supports 2 players isn't very useful! By using Auto-join room, once a room is full the next joining players get sent to a new room. In this case 30 joining players get assigned to 15 separate 2-player games. Locking the room when full also prevents late-joiners; it means once the room is full, even if some players quit nobody else will be added to the game. If the room stayed unlocked a newly joining peer could be sent to the same room to top it back up, but that means having to handle late-joiners, which we'll skip for simplicity.
Once joined, we establish if we are the host. We do the same as the chat example: either the Host or Peer group is activated. However we also need to handle the paddle and ball already in the layout depending on whether we became host. If we're a peer, it's easy: we just destroy the objects already in the layout. Sync object will automatically create, move and destroy any objects that are present on the host, including the object that represents our own player. The game will also start just after we join as a peer, since the host is already there, so we immediately set the game state to "getready".
However when we are the host, we adopt the existing paddle object in the layout as our own object that we control. The paddle object has a peerid instance variable. This stores the signalling-assigned peer ID, and allows us to pick any paddle instance and know which player it represents. It must be a text variable, since peer IDs are short sequences of random characters. Our own peer ID is assigned to this object to indicate it represents ourselves.
The Associate object with peer action is also necessary to indicate to the multiplayer engine that this instance represents a player in the room. By default Sync object treats objects as neutral, like scenery objects or AI-controlled enemies, and simply makes sure everyone sees the same number of objects in the same places. Using Associate object means the object is not neutral and is associated with a connected peer in the same room, and allows it to do more automatically (such as destroying the object when the peer leaves). In this case we're adopting the object already in the layout, so we associate it with our own ID.
The remaining events in the Signalling group cover error handling in the same way the chat room does. However there's an extra event that simply displays some connection stats, including the number of inbound and outbound messages sent per second, the total resulting bandwidth in kilobytes per second, and the latency and PDV to the host. (These will show as 0 for the host, since they do not need to connect to themselves!)