Meilleure architecture de jeu peer-to-peer


10

Envisagez une configuration où les clients de jeux:

  1. ont des ressources informatiques assez petites (appareils mobiles, smartphones)
  2. sont tous connectés à un routeur commun (LAN, hotspot, etc.)

Les utilisateurs veulent jouer à un jeu multijoueur, sans serveur externe.

Une solution consiste à héberger un serveur faisant autorité sur un seul téléphone, qui dans ce cas serait également un client. Compte tenu du point 1, cette solution n'est pas acceptable, car les ressources informatiques du téléphone ne sont pas suffisantes.

Donc, je veux concevoir une architecture peer-to-peer qui répartira la charge de simulation du jeu entre les clients. En raison du point 2, le système n'a pas besoin d'être complexe en ce qui concerne l'optimisation; la latence sera très faible. Chaque client peut être une source de données faisant autorité sur lui-même et son environnement immédiat (par exemple des balles).

Quelle serait la meilleure approche pour concevoir une telle architecture? Existe-t-il des exemples connus d'un tel protocole peer-to-peer de niveau LAN?

Remarques:

Certains des problèmes sont abordés ici , mais les concepts qui y sont énumérés sont trop élevés pour moi.

Sécurité

Je sais que ne pas avoir de serveur faisant autorité est un problème de sécurité, mais ce n'est pas pertinent dans ce cas car je suis prêt à faire confiance aux clients.

Éditer:

J'ai oublié de mentionner: ce sera un jeu assez rapide (un jeu de tir).

De plus, j'ai déjà lu sur les architectures de mise en réseau chez Gaffer on Games .

Réponses:


10

Jetez un œil à cet article sur l'architecture de mise en réseau d'Age of Empires II.

Ils ont réussi à créer un jeu multijoueur qui fonctionnait très bien sur un Pentium 90 avec 16 Mo de RAM et une connexion par modem à 28,8 kB / s. Pour ce faire, chaque joueur exécutait sa propre simulation, mais synchronisait ses commandes.

Ils ont des astuces intelligentes là-dedans, je le recommande fortement.


5

Je l'ai fait pour un jeu de course PSP commercial, qui fonctionnait à la fois sur un réseau ad hoc et via un point d'accès sans fil. (Ou vers un serveur statique sur Internet, si vous le souhaitez)

En raison du point 2, le système n'a pas besoin d'être complexe en ce qui concerne l'optimisation

D'après mon expérience, ce n'est pas vrai. Les appareils sans fil (en particulier les petits appareils portables) ne sont pas comme des ordinateurs avec des connexions réseau filaires - les smartphones et les consoles de jeux sans fil ont tendance à avoir des interfaces réseau lentes pour les jeux.

Ne vous méprenez pas - leur débit est généralement bon (c'est-à-dire la quantité de données par seconde; idéal pour les films en streaming ou etc.), mais la latence à la livraison d'un paquet particulier peut être extrêmement mauvaise, et peut l'être très variable qu'il est difficile d'estimer même combien de temps un paquet individuel prendra pour livrer. Cette variation devient encore pire lorsque de plus en plus d'appareils sans fil sont regroupés dans une zone générale, car leurs signaux commencent à interférer les uns avec les autres. À la suite de cela, j'ai passé beaucoup de temps à réduire le nombre de paquets à envoyer, nous aurions donc moins de collisions de paquets. (Notez que c'est un peu moins un problème dans le cas où un point d'accès réseau alimenté est impliqué, plutôt que d'avoir les appareils qui se parlent directement sur un réseau ad hoc)

Comme exemple de ce type d'optimisation, notre jeu de course s'est déroulé dans un monde qui avait des feux de circulation. Des milliers d'entre eux. Et nous devions nous assurer que leurs signaux étaient synchronisés entre tous les joueurs d'une session réseau. Plutôt que d'essayer d'envoyer des paquets pour dire à tout le monde quels feux étaient dans quel état, nous avons défini un calendrier statique pour tous les feux de circulation, puis nous nous sommes juste assurés que tous les clients étaient d'accord sur le "temps de jeu" actuel. Puisqu'ils connaissaient tous l'heure du jeu et que tous les états des feux de signalisation pouvaient être déterminés à partir de l'heure du jeu, nous avons synchronisé toutes ces données d'état sans envoyer de données spéciales. Ce seul changement a fait une énorme différence pour nos performances réseau.

Ce qui a dit, établir une synchronisation d'horloge fiable entre plusieurs appareils sans fil (avec des temps de ping très variables dus en grande partie à la perte de paquets) a été un énorme défi. Heureux d'en parler davantage si vous avez un intérêt.

Chaque client peut être une source de données faisant autorité sur lui-même et son environnement immédiat (par exemple des balles).

C'est ce que nous avons fait, et cela a bien fonctionné pour nous dans notre situation (voitures). La partie problématique, bien sûr, est lorsqu'un objet cesse d'être plus proche du joueur «a» que du joueur «b», et sa propriété est donc transférée d'un joueur à un autre.

Il s'agit en fait d'une négociation étonnamment complexe entre les joueurs, où le jeu 'a' propose le jeu 'b': "Je pense que cet objet est plus proche de vous. Vous devriez en prendre le contrôle." Et puis le jeu «b» peut soit accepter, soit décliner, selon sa propre vision de la situation. Les différences dans l'état de jeu perçu entre «a» et «b», et le changement de temps entre le moment où la demande et la réponse sont envoyées et reçues en font une petite négociation particulièrement désagréable pour devenir fiable, et il peut facilement dégénérer en un jeu de "patate chaude", avec la propriété d'objets rebondissant continuellement entre plusieurs joueurs. Et même quand cela fonctionne correctement, vu du point de vue du jeu «c», il »

Mon intuition est que ce type d'approche de «propriété d'objet» risque d'être trop lourd pour les petits objets à courte durée de vie comme les balles. Nous l'avons utilisé pour les voitures de circulation et les coureurs IA, qui ont tendance à vivre dans la simulation pendant une période relativement longue. Il semble qu'une approche plus performante, si vous êtes prêt à faire confiance aux clients, serait que le jeu de chaque joueur soit propriétaire de sa position et de ses projectiles, et de déclarer quand ce joueur a été touché par le projectile de quelqu'un d'autre. (Donc, en tant que "jeu A", je suis responsable de dire où sont les projectiles du joueur A et du joueur A, mais le joueur B est responsable de dire si j'ai touché le joueur B). Avec une bonne estimation, vous devriez pouvoir obtenir un comportement assez raisonnable d'un système comme celui-ci.


1

Je vous recommande d'utiliser une architecture de pair à pair de l'étape de verrouillage.

Vous commencez par compter vos cadres de jeu après le début du jeu. Un client restitue la 1ère trame puis envoie le message prêt aux autres clients et attend de recevoir le message prêt des autres clients.

Maintenant, tous les clients peuvent opter pour la 2ème image. Rendez le cadre, envoyez et recevez des commandes, mettez à jour le monde, mettez à jour la physique et ... après cela, envoyez-vous un message prêt.

Cette solution est très bonne pour les jeux LAN et tous vos clients seront synchronisés.

avec ce type de mise en réseau, vous pouvez être sûr que tous vos clients sont synchronisés afin que vous puissiez tester la meilleure façon qui convient à vos besoins.

La première façon est d'envoyer uniquement les entrées aux autres et chaque client simule le fonctionnement, le tir, la détection de collision, etc. La deuxième façon est que chaque client envoie les informations sur son personnage à d'autres comme la position, la rotation, l'état, le cadre d'animation, etc. calcule leurs affaires et les envoie sur le réseau mais la première façon est plus sécurisée.


1
Cette réponse semble concerner la boucle du jeu. Je pense que le PO pose des questions sur le système de répartition de la charge; plus précisément, qui simule quoi et comment les clients communiquent. Pourriez-vous entrer dans les détails? Je m'intéresse également à ce problème.
Wackidev

@Wackidev avec ce type de mise en réseau, vous pouvez être sûr que tous vos clients sont synchronisés afin que vous puissiez tester la meilleure façon qui convient à vos besoins. La première façon est d'envoyer uniquement les entrées aux autres et chaque client simule le fonctionnement, le tir, la détection de collision, etc. calcule leurs affaires et les envoie sur le réseau mais la première façon est plus sécurisée.
kochol

Veuillez donc l'indiquer dans votre réponse. Pour l'instant, je ne pense pas que cela réponde à la question. Veuillez également supprimer le premier commentaire en double. Merci. Quant à l'idée elle-même, la première option que vous avez énumérée ne requiert-elle pas que la simulation soit déterministe?
Wackidev
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.