Signaling group
Ce groupe a de nombreuses similitudes avec l'ancien exemple de pong. Cependant, il existe des différences importantes dans ce qui est synchronisé, car c'est un jeu différent.
Tout d'abord, dans Sur le début de la mise en page , nous devons configurer les objets et les données qui vont être transmis. Les premières actions créent les entrées que les pairs envoyent à l'hôte. Pour éviter de tricher, les pairs n'envoyent que leurs entrées à l'hôte, qui effectue alors le mouvement réel pour les pairs. La prédiction de l'entrée locale couvre la latence de l'envoi des entrées à l'hôte et la réception de la nouvelle position. Les entrées que nous ajoutons ressemblent à ceci:
Les entrées qui sont envoyées à l'hôte sont appelées les valeurs d'entrée du client . Pour ce jeu, nous avons trois: les coordonnées X et Y du but, que nous appelons lookx et looky , et le bouton indique que le joueur appuie, que nous appelons entrées . Le look X et Y sont des valeurs int16, puisqu'ils n'ont pas besoin de précision de sous-pixel et que la disposition est bien inférieure à 32767, la valeur maximale pouvant être envoyée avec cette précision. Entrées est une valeur de 8 bits que nous avons définie des bits individuels pour chaque contrôle. Ce jeu comporte cinq contrôles: quatre directions et bouton gauche de la souris pour tirer avec trois autres bits de rechange, donc nous n'avons pas besoin d'utiliser une précision plus élevée. Plus tard, dans le didacticiel, nous nous occupons de la mise à jour de ces valeurs pour que l'information correcte soit envoyée à l'hôte.
Les valeurs X et Y du regard utilisent l'interpolation linéaire . Cela signifie que si les mises à jour ne sont pas fréquentes, le moteur multijoueur conçoit les valeurs intermédiaires en les déplaçant en ligne droite entre les valeurs connues. Cela garantit que le mouvement de la position du look se déplace en douceur. Cependant, il est très important qu'aucune interpolation ne soit utilisée pour les entrées , donc Aucun est choisi pour l'interpolation. Il n'y a pas d'états intermédiaires pour ces entrées et l'interpolation pour cette valeur entraînera simplement des résultats incorrects sur l'hôte.
La partie suivante de l'événement définit les objets et lesquels de leurs variables d'instance vont être synchronisés. Ce sont les actions pertinentes:
La première action utilise l'action Action Sync de l'objet multijoueur. C'est l'action clé pour indiquer quels objets doivent être envoyés sur le réseau. La synchronisation d'un objet est à sens unique: cela signifie que l'hôte indique aux pairs combien de ces objets existent et où ils se trouvent. Les pairs ne reçoivent que ces données et les modifications apportées par les pairs à ces objets seront ignorées et remplacées. Les valeurs d'entrée du client sont les seules manières dont les pairs ont d'affecter le jeu. L'hôte a la version autorisée du jeu, et les pairs font de leur mieux pour afficher ce que l'hôte a eu. L'hôte est seul responsable de créer, déplacer et détruire ces objets; Comme il le fait, Synchroniser l'objet provoquera la création, le déplacement et la destruction d'objets sur les pairs connectés. Tout cela se produit en interne dans le moteur multijoueur en conséquence de cette action.
Il est important de sauvegarder la bande passante en synchronisant uniquement des objets qui doivent absolument être transmis. Dans ce cas, l'objet Peer représente un joueur et doit être transmis. Il est généralement redondant de synchroniser des choses comme le terrain, les décors et les accessoires - c'est un gaspillage de bande passante pour les synchroniser, surtout s'ils ne changent jamais. Même si elles changent, si les résultats sont sans importance pour le jeu réel (par exemple, des trous de balle cosmétiques ou des cratères qui n'affectent pas les collisions), il est judicieux pour les pairs locaux de gérer cela par eux-mêmes. Il n'est pas non plus nécessaire de synchroniser les objets AimSpot, PeerLaser ou PeerName dans le conteneur avec Peer: le conteneur assure qu'ils sont créés et détruits en même temps, et les événements ultérieurs les positionneront en fonction de l'objet Peer uniquement, donc il n'y a pas besoin Pour envoyer des données supplémentaires pour eux.
Synchroniser l'objet peut mettre à jour la position ou l'angle de l'objet, ou les deux, ni l'un ni l'autre. Dans ce cas, nous ne sommes intéressés que par la position, puisque l'angle de référence est toujours défini sur la position de l'objectif. La précision int16 convient aux positions. (L'interpolation Linear est automatiquement utilisée ici pour la position de l'objet et l'interpolation Angular utilisée pour l'angle si elle est activée.) Le paramètre Bandwidth * permet de réduire le taux maximal de mises à jour de l'hôte. Ceci n'est normalement pas nécessaire - reportez-vous à l'entrée manuelle pour en savoir plus sur l'option.
L'objet Sync object par défaut ne transmet pas d'autres données, et les variables d'instance ne seraient pas mises à jour. Il serait inutile de mettre à jour automatiquement chaque variable d'instance, car certaines d'entre elles ne peuvent être utilisées que localement. Après l'action Sync , nous pouvons éventuellement utiliser n'importe quel nombre d'actions Sync instance variable pour ajouter des variables d'instance pour que l'hôte envoie également aux pairs (et comme avec Sync object , les variables d'instance sont mises à jour automatiquement). Les variables ajoutées dans ce cas sont les variables lookatx et lookaty (afin que nous puissions voir où les autres joueurs visent), les entrées (afin que nous puissions indiquer les boutons qu'ils pressent) et que le joueur joue le rôle Santé , tue et décès variables. Rappelez-vous que, comme avec Sync object , ces variables ne sont envoyées que de l'hôte aux pairs pour indiquer quel est l'état du jeu. Notez également que, bien que les pairs reçoivent les boutons de direction sur lesquels chaque joueur appuie sur la variable entrées , ces informations sont ignorées: L'objet de synchronisation met déjà à jour les positions des objets, il n'est donc pas important de prendre en compte leurs contrôles. Cependant, nous sommes intéressés par le fait qu'ils tirent ou non, ce qui est juste l'un des bits de cette valeur, de sorte que nous synchronisons toute la variable de toute façon. (Un autre jeu pourrait également trouver les états d'entrée utiles pour définir les animations.) Les positions de look utilisent également l'interpolation linéaire, et les autres n'utilisent aucune interpolation car elles devraient simplement être mises à jour par étapes.
La balise de valeur du client est utilisée si la variable d'instance correspond également à une valeur de saisie du client . En d'autres termes, si la valeur d'entrée d'un client de pair est définie à partir de cette variable d'instance, le réglage de la balise correspondante ici permet au moteur multijoueur de savoir s'ils sont liés. L'hôte peut utiliser cette information pour réduire la latence lors du relais des entrées vers d'autres pairs.
Maintenant que toutes les entrées du client et les objets synchronisés sont configurés, la dernière action dans On start of layout se connecte au serveur de signalisation.