Le plugin multijoueur de Construct 2
La conception générale d'une partie multijoueur dans Construct 2 ressemble à ceci.
Déroulement d'un jeu multijoueur
Le cycle de vie d'un jeu multijoueur se déroule comme suit :
1. Se connecter au serveur de signalisation et se connecter
2. Rejoindre une salle
3. D'autres pairs peuvent rejoindre et quitter la partie pendant qu'elle se déroule
4. Les données des objets et d'autres messages comme le chat sont échangés avec les autres pairs connectés.
5. Finalement, le jeu se termine, tout le monde quitte la pièce, et peut éventuellement chercher une nouvelle pièce (retour à l'étape 2).
Notez que le jeu se termine si l'hôte se déconnecte. Il joue le rôle de serveur pour le jeu, donc s'il se déconnecte, le jeu n'est plus en cours. C'est une raison d'envisager l'utilisation d'un hôte dédié sur un serveur central, en particulier pour les jeux plus importants avec plus de joueurs. Cependant, cela ne fait aucune différence pour les jeux à deux joueurs - le jeu se termine de toute façon si l'autre joueur se déconnecte.
Le plugin Multiplayer possède des fonctionnalités couvrant la phase de signalisation (étapes 1-2), ainsi que des fonctionnalités de "salle" couvrant le jeu lui-même, telles que des déclencheurs pour le moment où les pairs rejoignent et quittent, les messages sont reçus, etc.
Aperçu de la conception
Les jeux sont conçus avec un seul type d'objet représentant à la fois les objets contrôlés par le joueur et tous les autres joueurs du jeu. Le même objet est alors utilisé de manière égale pour tous les participants au jeu, y compris vous-même (et même lorsque l'hôte). Il est judicieux de nommer cet objet Client, puisque c'est ce qu'il représente. Si vous avez des joueurs composés de plusieurs objets, comme une arme et un corps séparés, ayez un objet Client de base et placez-le dans un conteneur avec les autres objets. Cela permet de s'assurer que les joueurs sont créés et détruits dans leur ensemble et que leurs objets connexes sont sélectionnés automatiquement dans les événements avec l'objet de base, de sorte que vous pouvez largement considérer l'objet de base comme représentant l'ensemble du joueur.
L'hôte et les pairs exécutent le même projet. Cela signifie que votre projet doit être capable de gérer les événements à la fois pour l'hôte, qui a la version du jeu qui fait autorité, et pour les pairs, qui voient une version retardée et n'envoient que leurs entrées. La façon la plus pratique de gérer cela est d'avoir deux groupes d'événements dédiés à l'hôte et au pair, et d'activer uniquement le groupe approprié après avoir rejoint une salle et déterminé si vous êtes devenu hôte.
L'action Sync de l'objet Multiplayer est le moyen fondamental d'indiquer que vous souhaitez envoyer des données sur les objets via le réseau. Elle indique à l'hôte d'envoyer des informations sur ces objets aux pairs, et indique aux pairs d'attendre de recevoir des informations sur ces objets. Le moteur multijoueur crée et détruit automatiquement les objets qui représentent les pairs lorsqu'ils se joignent à lui ou le quittent. (Le Sync object action peut également être utilisée pour d'autres objets qui ne représentent pas des Clients, mais elle est le plus souvent utilisée pour les Clients).
Chaque Client a un ID Client attribué par le serveur de signalisation. Il s'agit d'une chaîne de caractères contenant une courte séquence de caractères aléatoires pour les identifier de manière unique. Les Peer ID sont généralement utilisés pour pouvoir se référer de manière cohérente au même joueur même si son alias change. Le Peer ID doit être stocké dans une variable d'instance afin de savoir quel Peer un objet donné représente. Lorsqu'un objet pour un pair est créé par le moteur multijoueur, l'expression Multiplayer.PeerID est définie sur l'ID du pair, de sorte qu'elle peut être stockée dans sa variable d'instance. Puisque vous avez le contrôle de votre propre objet peer, vous pouvez facilement le choisir en testant si sa variable d'instance est égale à Multiplayer.MyID, puis modifier uniquement cette instance.
Modes de fiabilité
La dernière chose à mentionner est qu'il existe 3 modes de transmission des données. Ils permettent d'échanger la fiabilité contre les performances.
Le mode le plus fiable est Fiable ordonné (Reliable ordered). Il envoie un message qui est suivi : s'il est abandonné par le réseau, il le renverra jusqu'à ce qu'il vérifie qu'il arrive à destination. Il ordonne également les messages, de sorte qu'il est garanti qu'ils arrivent dans le même ordre qu'ils ont été envoyés. C'est utile, mais ce n'est pas le plus rapide : si un message est abandonné et retenu, tous les messages suivants seront retenus jusqu'à ce que ce message arrive. Cela signifie également que les messages individuels peuvent prendre plusieurs fois le temps de latence pour arriver, car il faut attendre au moins le temps d'aller-retour pour savoir si le message est arrivé. Cette méthode ne convient généralement qu'aux messages importants et peu fréquents, comme les messages de discussion.
L'option suivante, la plus rapide, est Fiable non ordonné (Reliable unordered). Elle envoie un message qui est suivi et le renvoie jusqu'à ce qu'elle vérifie qu'il est arrivé à destination. Cependant, les messages peuvent arriver dans n'importe quel ordre. Cela permet d'éviter qu'un seul message retardé bloque tous les messages suivants - il peut simplement arriver en retard, après d'autres messages qui ont été initialement envoyés après lui. Cependant, les messages individuels peuvent toujours prendre un multiple de la latence pour arriver. Ce mode convient aux événements de jeu qui doivent arriver mais qui ne sont pas liés les uns aux autres, comme l'ouverture d'une porte ou une explosion.
Le mode le plus rapide est Non Fiable (Unreliable). Il envoie un seul message et l'oublie. S'il est abandonné, le message n'arrivera tout simplement jamais à destination. Il peut également arriver dans un ordre différent de celui dans lequel il a été envoyé à l'origine, et même éventuellement en double. En général, cela convient aux messages réguliers, pour lesquels il est plus important que le message arrive le plus rapidement possible que de savoir s'il arrive tout court. S'il est abandonné, il est probable qu'il sera suivi rapidement par le message suivant avec des données plus récentes, donc cela n'a pas d'importance. Notez que le moteur utilise ce mode en interne pour les objets synchronisés avec des fonctions d'interpolation et de compensation intégrées, donc n'essayez pas de reproduire cette fonctionnalité avec ce mode.
Prêt à coder !
Bien que le plugin Multiplayer de Construct 2 gère de nombreux détails techniques pour vous, tels que la prédiction d'entrée et la connectivité, il est toujours très important de connaître la théorie pour être en mesure de faire les choix appropriés concernant les données qui sont envoyées où, avec quelle précision et quel mode de fiabilité. Nous espérons que ce tutoriel vous a donné une vue d'ensemble suffisante pour commencer à concevoir votre premier jeu multijoueur avec une bonne compréhension de ce qui se passe dans les coulisses et de ce que vous devez faire dans Construct 2 pour utiliser au mieux les fonctionnalités. Alors que ce tutoriel s'est concentré sur la théorie, les tutoriels suivants traiteront de la manière de résoudre des problèmes tels que la prédiction de l'entrée et la compensation du décalage dans la pratique en utilisant des fonctionnalités spécifiques du plugin Multiplayer.
Si vous êtes prêt à en apprendre davantage, passez au tutoriel Multiplayer 2 : chat room !