Groupe de signalisation
Ce groupe est similaire à l'exemple de chat précédent dans la mesure où il traite de la connexion au serveur de signalisation, de l'ouverture de session, de l'entrée dans une salle et de la détermination de l'identité de l'hôte. Cependant, il y a quelques différences importantes maintenant que nous traitons des objets et de la synchronisation en temps réel.
Tout d'abord, au début du layout, nous devons configurer les objets et les données qui vont être transmis. La première action configure les entrées que les clients envoient à l'hôte. Pour éviter la tricherie, les clients n'envoient leurs entrées qu'à l'hôte, qui effectue les tests de collision réels avec les palettes et la balle. La seule entrée dont dispose le client est la position verticale (Y) de sa palette.
Les entrées que les clients envoient à l'hôte sont appelées les valeurs d'entrée du client. Dans ce cas, nous utilisons une entrée que nous appelons "y", pour la position Y de la raquette. Elle utilise un entier de 16 bits, car elle n'utilise que deux octets et les positions intermédiaires n'ont pas d'importance. La valeur d'entrée utilise également l'interpolation linéaire. Cela signifie que même si les mises à jour ne sont pas fréquentes pour l'hôte, le moteur multijoueur devine les valeurs intermédiaires en supposant que la raquette se déplace de façon linéaire. Cela garantit la fluidité du mouvement de la raquette. Si nous avions choisi None pour l'interpolation, le mouvement de la raquette pourrait souvent sembler saccadé.
La partie suivante de l'événement définit quels objets et quelles variables d'instance sont synchronisés.
La première action utilise l'action Sync object de l'objet Multiplayer. Il s'agit de l'action clé pour indiquer quels objets doivent être envoyés sur le réseau. La synchronisation d'un objet est unidirectionnelle : l'hôte indique aux clients combien d'objets existent et où ils se trouvent. Les clients ne reçoivent que ces données et toute modification apportée par les clients à ces objets sera ignorée et remplacée ! Les valeurs d'entrée du client sont les seuls moyens que les clients ont d'affecter le jeu, et les seules données de jeu qui sont envoyées du client à l'hôte.
L'hôte possède la version du jeu qui fait autorité, et les clients font de leur mieux pour afficher ce que l'hôte possède. L'hôte est le seul responsable de la création, du déplacement et de la destruction de ces objets. Ce faisant, l'objet Sync entraîne également la création, le déplacement et la destruction d'objets sur les clients connectés. Tout cela se produit en interne dans le moteur multijoueur en conséquence de cette action.
Puisque l'objet Sync déplace les objets par lui-même et que seul l'hôte exécute "réellement" le jeu, les pairs désactivent également tous les comportements des objets. Par exemple, la balle a le comportement Bullet. Seul l'hôte doit avoir ce comportement activé. Le comportement Bullet doit être désactivé lorsque vous agissez en tant que client, car l'objet Sync le déplacera déjà lorsqu'il se déplacera sur l'hôte, et si le comportement est activé sur le client, il pourrait entrer en conflit avec l'endroit où l'objet Sync essaie de le déplacer. Dans cet exemple, le comportement Bullet est initialement désactivé, mais il est activé dans les événements lorsque l'objet est l'hôte.
L'objet Sync peut mettre à jour la position ou l'angle de l'objet, ou les deux, ou aucun. Dans ce cas, seule la position nous intéresse, car l'angle des objets n'est pas important pour le gameplay et l'envoi de données sur les angles des objets serait un gaspillage de bande passante. Le paramètre Bandwidth permet de réduire le taux maximal de mises à jour en provenance de l'hôte. Cela n'est normalement pas nécessaire - reportez-vous à l'entrée du manuel pour en savoir plus sur cette option.
Par défaut, l'objet Sync ne transmet aucune autre donnée, et les variables d'instance ne sont pas mises à jour. Il serait inutile de mettre automatiquement à jour chaque variable d'instance, car certaines d'entre elles peuvent n'être utilisées que localement. Après l'action Sync object, nous pouvons éventuellement utiliser un nombre quelconque d'actions Sync instance variable pour ajouter des variables d'instance que l'hôte enverra également à ses clients (et comme avec Sync object, les variables d'instance sont mises à jour automatiquement). Il est important de noter que l'action Sync instance variable ne peut être utilisée qu'après Sync Object. En soi, elle ne fait rien ; l'action signifie "synchroniser également cette variable avec un objet déjà synchronisé".
La seule variable que nous synchronisons dans ce cas est la variable des points de l'objet Raquette. C'est un moyen simple pour tout le monde de connaître le score de chaque joueur.
La balise de valeur client est utilisée si la variable d'instance correspond également à une valeur d'entrée client. Cela n'est pas nécessaire dans cet exemple, mais sera abordé dans le prochain tutoriel.
L'objet balle doit également être synchronisé, afin que le client puisse voir où il se trouve ! Cependant, il n'est pas nécessaire de synchroniser autre chose que sa position.
Maintenant que toutes les entrées du client et les objets synchronisés sont mis en place, la dernière action dans On start of layout se connecte au serveur de signalisation.