Host groupe
L'hôte est responsable de l'exécution du jeu. Sync Object fait la plupart du travail en gardant les pairs à jour. Par conséquent, les événements hôtes sont un peu plus impliqués que pour les pairs.
Tout d'abord lorsqu'un pair se connecte, l'hôte crée l'objet Peer pour eux dans un endroit aléatoire dans la mise en page (de sorte que tout le monde ne se partage pas l'un sur l'autre). Comme dans les événements Peer, nous avons également configuré leur peerid sur l'ID de l'homologue et associons l'objet avec eux. N'oubliez que l'hôte crée, déplace et détruit les objets, et Synchroniser l'objet les met à jour sur les pairs. Une fois l'objet créé, il sera prochainement créé dans tous les jeux partagés. L'événement On créé par un partenaire peut ensuite déclencher et associer l'objet nouvellement créé à un pair connecté. Gardez à l'esprit que les choses qui se produisent sur l'hôte auront souvent des conséquences pour les pairs connectés.
Comme l'hôte, il n'est pas nécessaire de s'inquiéter de la prédiction d'entrée ou des retards d'entrée. L'hôte a la version autorisée du jeu et peut simplement se déplacer directement. L'objet de synchronisation fera en sorte que la position de l'hôte soit mise à jour pour tous les pairs. La seule chose non évidente est lors de la prise de vue avec le bouton gauche de la souris, nous avons toujours réglé le même bit dans la variable inputs que les pairs définis. Ce n'est pas pour une raison particulière à faire avec le multijoueur - il permet simplement à notre groupe d'événements commun de traiter tous les mêmes quand ils tirent, car le fait de définir ce bit dans les entrées * signifie toujours que peer déclenche.
En tant qu'hôte, nous sommes également responsables de déplacer tous les pairs. Lorsque les pairs se déplacent, ils indiquent à l'hôte quelles entrées ils appuient et commencent à se déplacer de toute façon. Il est important que l'hôte les déplace exactement de la même manière en fonction de leurs entrées, de sorte que la prédiction de l'entrée du pair fonctionne.
L'expression Multiplayer.PeerState nous permet de récupérer la valeur de saisie actuelle du client envoyée par un pair. Nous ne voulons pas mettre à jour notre propre pair en fonction de ces données, alors nous exécutons une boucle for-each pour chaque pair qui n'est pas nous pour la mettre à jour. Nous mettons à jour ses variables d'instance en fonction des dernières valeurs d'entrée du client. Cela définit la position de regard correcte et les mises à jour entrées . Ensuite, dans les quatre sous-événements, à partir duquel les bits sont définis dans entrées , nous simulons également ces contrôles en cours d'exécution pour ce pair. Il en résulte que les pairs se déplacent avec les mêmes contrôles qu'ils pressent à distance.
L'hôte est responsable de la détection des pertes. C'est là que la compensation de retard devient pertinente. Nous devons dire qui se lance actuellement, et s'ils frappent quelqu'un d'autre de leur point de vue . Tout d'abord pour déterminer qui lance, nous testons chaque pair et voyons si le bit 4 est défini dans leurs entrées (ce qui signifie qu'ils maintiennent le bouton gauche de la souris pour tirer). Nous ne voulons pas infliger des dégâts à chaque tic pendant qu'ils tirent, seulement la première fois qu'ils tirent, alors nous utilisons une variable d'instance FirstShot pour agir comme un déclencheur par instance une fois . FirstShot est toujours vrai, sauf lorsqu'il déclenche lorsqu'il est défini sur false. Si nous tirons et FirstShot est vrai, c'est la première tic de tir.
Pour la détection des pertes, nous devons tester le chevauchement entre le AimSpot du Peer (déjà choisi parce qu'il se trouve dans un conteneur) et tout autre pair. Le système d'événements Here Construct 2 rend cela un peu gênant. (Ce n'est pas spécifique au moteur multijoueur, cela s'applique à tous les tests de chevauchement entre le même type d'objet.) Nous ne pouvons pas facilement tester un chevauchement dans cet événement, car nous avons déjà choisi un objet Peer en utilisant le pour - chaque boucle. La façon la plus simple de gérer cela est d'appeler une fonction pour effectuer la détection de succès réelle. Dans un appel de fonction, les objets sélectionnés sont réinitialisés, de sorte que nous avons une ardoise propre pour réussir à tester. Cependant, nous passons l'UID du AimSpot * pour tester la collision avec, et l'identification du joueur qui déclenche.
Maintenant, nous atteignons la fonction qui fait le test de succès réel. Puisque le AimSpot est dans une famille avec Peer , il est encore difficile d'éviter de choisir le même pair. Pour contourner cela, nous avons une famille distincte avec juste AimSpot . Les familles choisissent leurs propres objets séparément et ne choisissent pas automatiquement des instances contenues, alors se référant à AimSpotFamily nous permet de choisir le AimSpot indépendamment de tout le reste. Nous copérons également l'ID de démarrage du paramètre 1 dans une variable locale pour la lisibilité. Dans un sous-ensemble, nous répétons pour chaque pair autre que l'homologue qui lance le feu. (Il est inutile de vérifier si un homologue s'est suicidé lui-même!)
La façon dont les retards de compensation fonctionne est que nous savons que le groupe de tir voit le jeu sur un délai, alors, en vérifiant si ils frappent n'importe quoi, nous déplaçons les objets qu'ils visent à l'endroit où ils auraient été lors de leur tir à l'origine. Les étapes à suivre pour ce faire sont:
1. Enregistrez la position actuelle et l'angle du pair pour tester.
2. Déplacez-les à l'endroit où l'homologue les aurait vu.
3. Testez un chevauchement.
4. Déplacez le partenaire à leur position et angle d'origine.
L'étape 2 est gérée automatiquement par les expressions Multijoueur.LagCompensateX / Y / Angle . Ceux-ci calculent la position passée et l'angle pour l'objet étant donné le délai que le homologue voit le jeu. Cela garantit qu'ils peuvent toucher des cibles mobiles en les visant directement. L'événement 60 enregistre la position actuelle sur les variables locales OldX , OldY et OldAngle afin que nous puissions le remettre après, la position actuelle du pair actuel pour lequel nous testons un succès avec sa position compensée . Ensuite, l'événement 61 teste un succès en utilisant un ordinaire se chevauche *. Enfin, l'événement 62 le ramène à l'endroit où il se trouvait.
Notez si un coup a été enregistré, nous vous enlevons un peu de santé et sauvons également l'ID du dernier correspondant qui les a frappés. Cela signifie que si elles meurent, nous pouvons en ajouter un au nombre tue * du joueur correct.
Quand un joueur décède (sa santé atteint 0), nous les repositionnons quelque part dans la mise en page avec une nouvelle santé et ajoutons à leur décès. Pour ajouter au nombre de morts, nous faisons face au même problème d'avoir à choisir des pairs différents à celui déjà choisi, alors nous appelons à nouveau une fonction pour réinitialiser les objets sélectionnés. Dans la fonction, nous trouvons quel pair correspond à la variable lasthitbypeerid et ajoute à ses morts.
L'événement 66 est le relais de chat de l'hôte, abordé dans le didacticiel précédent. Cela conclut les événements hôtes! Le test de succès compensé par le décalage est probablement la partie la plus compliquée, puisque la façon dont fonctionne le système d'événements Construct 2 signifie que nous devons utiliser des fonctions et une famille afin que nous puissions choisir les objets corrects. Cependant, j'espère que ce système est quelque chose que vous pouvez transférer à vos propres jeux.