Peer groupe
Comme pour l'exemple du pong, le groupe d'événements Peer est un peu plus simple que celui de l'hôte. Rappelez-vous que Synchroniser l'objet crée, déplace et détruit les objets automatiquement pour les pairs en fonction de ce qui se passe sur l'hôte, donc nous n'avons pas à nous en préoccuper ici. Le groupe Host devra cependant faire face à la logique de la façon dont les objets se déplacent et interagissent.
Une chose que nous devons faire lors de la création d'objets en tant que pair, cependant. L'objet de synchronisation créera et détruira automatiquement des objets, mais lorsqu'ils sont créés, nous devons définir leur variable d'instance peerid afin que nous puissions savoir plus tard quel pair représente l'objet. Lorsque l'objet Sync crée un objet, les déclencheurs de l'événement activé de l'objet et l'expression Multiplayer.PeerID sont définies sur l'ID du pair pour lequel l'objet est créé. Cela nous permet de nous rappeler qui est le pair. En outre, comme pour tous les objets représentant les pairs, nous utilisons l'objet Associer avec l'action pair pour indiquer que cet objet représente un pair connecté. (Cela doit toujours être fait à la fois sur les côtés hôtes et pairs).
Vous remarquerez que l'événement 22 est un sous-événement qui vérifie si l'objet créé représente le joueur local. Si Sync object crée l'objet qui nous représente, par défaut, il est verrouillé sur les données provenant de l'hôte et tous les changements seront annulés. Cela signifierait que nos intrants seraient lâches car ils doivent être envoyés à l'hôte, puis de nouvelles données reçues en retour indiquant notre nouveau poste. Donc, lorsque notre propre objet est créé, nous utilisons l'action Activer la prédiction de l'entrée locale . Cela le libère, ce qui lui permet de se déplacer. Cependant, il se souviendra constamment des dernières secondes de mouvement et vérifie les données de l'hôte pour l'objet. Si elle commence à s'écarter de la position de l'hôte - en tenant compte du délai -, elle commencera à appliquer une correction. Par conséquent, il est important que le pair utilise exactement la même logique de mouvement que l'hôte, avec la même vitesse, l'accélération, etc.
L'événement suivant met à jour nos valeurs de saisie du client. Chaque fois que le Sur la mise à jour du client déclenche des incendies, le pair est sur le point d'envoyer ses valeurs d'entrée du client à l'hôte, il est donc temps de les mettre à jour. Notez que nous choisissons l'objet Peer représentant le joueur local dans cet événement, donc les références à Peer se rapportent à l'objet qui nous représente.
La première chose que cet événement fait est de définir les valeurs d'entrée lookx et looky sur la position de la souris. Cela signifie que l'hôte saura par où nous visons. Ceci met à jour les valeurs d'entrée du client que nous avons ajoutées dans Au début de la mise en page .
Chaque sous-élément vérifie si chacun des cinq contrôles est pressé et met à jour le bit correspondant dans la variable d'entrée entrées . Puisque la entrée la valeur d'entrée du client est un entier de 8 bits, cela ressemble à cette séquence de bits:
0 0 0 0 0 0 0 0 (= 0 en décimale)
Le Construc 2 setbit [expression du système] [4] est utile pour définir chaque bit individuellement. Les bits sont basés sur zéro et le premier bit est à droite aux fins de cet exemple. Par conséquent, le réglage du bit 4 à 1 entraînera ce numéro:
0 0 0 1 0 0 0 0 (= 16 en décimale)
Nous utilisons le bit 0 pour la gauche, 1 pour le haut, 2 pour la droite, 3 pour le bas et 4 pour la prise de vue (en maintenant le bouton gauche de la souris). Donc, si le joueur est en position debout et à droite et en tournage en même temps, le nombre finira par ressembler à ceci:
0 0 0 1 0 1 1 0 (= 22 en décimale)
L'hôte peut alors utiliser l'expression getbit pour vérifier lequel de nos contrôles est pressé. Cela utilise la bande passante très efficacement, car avec une valeur distincte pour chaque commande, nous aurions besoin d'au moins cinq octets, nécessitant cinq fois plus de bande passante pour ces données.
Notez que nous mettons à jour la variable input instance de l'objet Peer , de sorte que le dernier événement (numéro 34) copie la variable d'instance sur la valeur d'entrée du client. Nous aurons également besoin de la variable d'instance lors de l'événement suivant. Une fois l'événement de déclenchement terminé, le moteur multijoueur transmettra les valeurs d'entrée client mises à jour à l'hôte.
Enfin, nous avons permis la prédiction de l'entrée locale pour nous-mêmes, afin que nous puissions déplacer notre propre joueur avant de passer à l'hôte. Le dernier événement du groupe Peer nous déplace selon nos propres contrôles. Notez un détail important de cet événement: nous vérifions les bits définis dans la variable d'instance que nous avons mis à jour dans Sur la mise à jour du client . Comme le décrit le commentaire, c'est parce que nous ne voulons pas commencer à déménager avant d'avoir envoyé le message à l'hôte en disant que nous détenons ce contrôle. 'Sur la mise à jour du client' déclenche 30 fois par seconde par défaut, ou toute autre image dans un jeu de 60 FPS. Si nous avons commencé à nous déplacer, mais que nous envoyions la mise à jour du client à la prochaine image, nous allons faire passer un cadre hors synchronisation avec l'hôte et forcer la prédiction de l'entrée locale à effectuer une correction. Donc, si le joueur appuie sur un contrôle, nous attendons réellement la prochaine mise à jour du client avant de commencer à bouger. Cette latence d'entrée est difficile à remarquer dans la pratique et contribue à assurer le mouvement le plus près possible de la synchronisation avec l'hôte.
Notez que le comportement de direction de l'objet Peer a Les contrôles par défaut sont définis sur Non . Cela signifie que aucun des objets ne peut être contrôlé, sauf lorsque nous utilisons Simuler le contrôle . Ceci est nécessaire pour éviter le comportement en essayant de contrôler tous les pairs dans le jeu, où il serait en conflit avec ce que l'objet Sync * essaie de faire.
Cela conclut la logique spécifique aux pairs. Il y a encore les groupes Host et Common pour aller!