Groupe Commun
Le groupe Commun est toujours activé et contient des événements qui s'appliquent à la fois à l'hôte et aux Clients. Il s'agit d'une autre façon judicieuse d'organiser les événements sans avoir à dupliquer des événements identiques entre les groupes Client et Hôte.
Lorsque quelqu'un d'autre rejoint le salon de discussion, l'événement On peer connected se déclenche. Dans cet événement, l'expression Multiplayer.PeerAlias est définie sur l'alias du Client qui s'est joint. Dans ce cas, nous enregistrons qu'il s'est joint à nous et l'ajoutons à la liste des Clients. Notez que l'événement On peer connected se déclenche également une fois par Client, juste après avoir rejoint la salle pour tous ceux qui sont déjà présents. En d'autres termes, s'il y a déjà 5 personnes dans la salle de discussion lorsque vous vous joignez à elle, l'option On peer connected se déclenchera 5 fois pour chacun des Clients déjà présents. Bien que les personnes déjà présentes dans la salle ne se joignent pas techniquement à ce moment-là, cela nous permet de traiter de la même manière les Clients préexistants et ceux qui viennent de se joindre.
Lorsque quelqu'un quitte la salle de discussion, le message On peer disconnected se déclenche. Comme pour la connexion des Clients, Multiplayer.PeerAlias contient le nom du Client qui s'en va. La seule petite complication ici est que nous devons supprimer son nom de la liste des Clients. Pour s'assurer que son nom est supprimé, nous comparons chaque élément de la liste ; si le texte de l'élément correspond à l'alias du Client qui est parti, il est supprimé.
Enfin, nous gérons le cas où nous sommes "virés" de la pièce. Cela signifie que nous avons été retirés de la salle par la force sans l'avoir demandé. Cela se produit généralement pour deux raisons. Premièrement, comme l'hôte agit en tant que serveur pour le jeu, s'il quitte le jeu, celui-ci se termine et tous les autres sont expulsés. Ou bien, après avoir rejoint la salle, si nous ne pouvons pas nous connecter à l'hôte dans un certain laps de temps, le serveur de signalisation nous expulse à nouveau. Certains types de NAT rendent impossible la connexion d'un Client à un hôte, et il restera simplement là à essayer de se connecter sans succès pour toujours. Le délai d'attente du serveur de signalisation (20 secondes par défaut) signifie que vous avez au moins la possibilité de rejoindre un autre jeu ou de réessayer.
Groupe Clients
Le groupe Clients n'est activé que lorsque nous sommes dans la salle en tant que Client (nous ne sommes donc pas l'hôte). Notez que dans ce cas, nous sommes uniquement connectés à l'hôte - il n'y a pas de connexion directe entre les Clients. L'hôte joue le rôle de serveur. Si deux Clients veulent communiquer, ils doivent d'abord passer par l'hôte, qui les relaie ensuite. Ce relais est traité dans le groupe Hôte ; pour l'instant, tout ce dont nous devons nous préoccuper est d'envoyer et de recevoir des messages !
Tout d'abord, si nous cliquons sur Envoyer ou appuyons sur Retour avec un message non vide, nous ajoutons immédiatement notre propre message de chat au journal et envoyons un message avec l'étiquette "chat" en mode ordonné fiable (en utilisant l'action Envoyer un message). Nous ne voudrions pas utiliser le mode non fiable (votre message de chat pourrait ne jamais arriver !) et nous ne voudrions pas non plus utiliser le mode non ordonné fiable, car le réseau pourrait changer l'ordre dans lequel les messages arrivent, et les messages de chat pourraient alors apparaître dans le mauvais ordre et éventuellement altérer le sens de la conversation ! L'étiquette de message est également un moyen simple d'identifier différents types de messages. Par exemple, les messages portant l'étiquette "chat" dans ce cas sont des messages de chat publics, mais une étiquette différente "private-message" pourrait être utilisée pour envoyer un message à une personne uniquement. Notez également qu'en tant que Client, nous laissons le paramètre recipient (Peer ID) vide pour envoyer à l'hôte, puisque c'est la seule connexion que nous avons de toute façon.
La réception des messages est simple. Lorsqu'un message portant l'étiquette "chat" arrive, le message On peer "chat" se déclenche. Dans cet événement, nous ajoutons simplement au journal de chat le nom de l'expéditeur (avec l'expression Multiplayer.FromAlias) et le message qu'il a envoyé (Multiplayer.Message). Rappelez-vous que nous ne recevons pas les messages que nous envoyons nous-mêmes, donc cet événement ne se déclenche jamais pour nos propres messages de chat - c'est pourquoi nous ajoutons séparément nos propres messages de chat au journal lors de leur envoi.
Groupe hôte
Le groupe hôte est similaire au groupe Clients, mais à la place nous communiquons avec tous les Clients. Lorsque le client envoie un message, il l'envoie uniquement à l'hôte. Cependant, en tant qu'hôte, lorsque nous envoyons un message, nous devons le diffuser à tous les Clients afin que tout le monde le reçoive. Ceci est fait avec l'action distincte de Broadcast message qui ne peut être utilisée que par l'hôte. De plus, au lieu de spécifier un destinataire, nous spécifions de qui provient le message, ce qui est utile pour relayer des messages. Dans ce cas, nous laissons le paramètre From ID vide pour indiquer que le message provient de l'hôte.
Enfin, nous arrivons à l'élément clé du salon de discussion : le relais de l'hôte. Lorsque l'hôte reçoit un message de "chat", nous l'ajoutons au journal de chat comme le font les Clients. Cependant, si nous en restions là, nous aurions un salon de discussion étrange : les Clients ne recevraient que les messages envoyés par l'hôte, alors que l'hôte pourrait voir les messages de tout le monde. Pour que les Clients puissent voir les messages des autres Clients, l'hôte doit les relayer à tous les autres. Ainsi, lorsque l'hôte reçoit un message de chat, il le diffuse également afin que tous les autres Clients le reçoivent également.
Chaque Client a un identifiant unique attribué par le serveur de signalisation, et peut être utilisé pour se référer à un Client individuel de façon permanente, même si son alias change. Comme pour l'expression FromAlias, dans le déclencheur de message On peer, l'expression Multiplayer.FromID est définie sur l'ID du Client d'où provient le message. Ainsi, lorsque l'hôte diffuse le message, il indique qu'il provient réellement de ce Client, et non de l'hôte. Cela signifie que lorsque les autres Clients reçoivent le message et déclenchent le message On peer, le message apparaît comme provenant du Client d'origine et non de l'hôte. En d'autres termes, le message diffusé provient de l'hôte, mais nous pouvons dire qu'il est envoyé au nom d'un autre Client. Notez également que lorsque nous diffusons un message, il n'est pas envoyé au Client dont nous disons qu'il provient - cela enverrait inutilement son propre message de chat directement vers lui. Le message est donc diffusé à tous, sauf à l'expéditeur initial.
Conclusion
C'est la fin de notre salon de discussion en 26 événements ! Nous espérons que vous avez maintenant une bonne compréhension de la signalisation, de la gestion de l'arrivée et du départ des Clients, de la messagerie et de la manière de configurer des événements distincts pour l'hôte et le Client.
Si vous avez envie de relever un défi, essayez de trouver un moyen d'envoyer des messages privés à des Clients individuels dans le salon de discussion. Dans IRC, cela se fait avec une commande spéciale de message de chat commençant par un slash, comme par exemple : /pm SomeUser hello !
Dans ce cas, l'hôte doit également relayer le message privé, mais en envoyant un message au lieu de diffuser un message afin qu'il ne soit reçu que par le destinataire prévu. Vous ne voudriez pas diffuser des messages privés à tout le monde !
Le troisième tutoriel présentera la synchronisation des objets en temps réel. Si vous êtes prêt, passez au tutoriel Multijoueur 3 : pong !