Comment puis-je créer une partie multijoueur poste à poste? [fermé]

Comment créer un jeu multijoueur P2P? J'aimerais avoir un jeu multijoueur sans serveur. Mais alors, comment tous les clients se connaissent?

Pourquoi le protocole p2p est-il si célèbre dans le transfert de fichiers mais pas dans les jeux multijoueurs?

Les jeux entre pairs ont généralement toujours un hôte de jeu. C'est l'hôte du jeu qui poste le jeu sur la liste des jeux maîtres et accepte de nouvelles connexions. Chaque fois que l'hôte du jeu accepte un nouveau client, il informe tous les clients existants du nouveau client afin qu'ils puissent s'assurer qu'ils se connectent au nouveau client.

Le moyen le plus simple d'implémenter p2p est d'utiliser un lobby. Tous les clients se connectent à l'hôte dans un hall (ou une salle de discussion). Lorsque l'hôte est prêt, le joueur appuie sur Démarrer et tous entrent dans le jeu en même temps (couramment utilisés dans les jeux de stratégie). Une approche plus complexe consiste à utiliser un «système d’abandon immédiat» permettant aux joueurs de rejoindre et de quitter le jeu, mais il est beaucoup plus complexe à mettre en œuvre dans un jeu de p2p et nécessite une fonctionnalité appelée migration d’hôte.

Un bon nombre de jeux utilisent le réseau peer to peer, y compris la plupart des titres de stratégie, de sport et de conduite. À peu près tous les jeux Xbox360 et PS3 utilisent le réseau p2p. L'architecture client-serveur est principalement utilisée dans les jeux de tir à la première personne ou les jeux MMO.

Client-Server est généralement plus facile à mettre en œuvre car une seule machine ne connaît pas tout l'état du jeu. Les clients ne sont en fait que des moteurs de rendu avec des prédictions pour rendre les choses plus fluides.

Lorsque vous construisez un moteur p2p, tous les clients ont besoin d'un état complet du monde du jeu et sont tenus de rester synchronisés.

Pour plus de détails sur les architectures p2p et client-serveur, je vous suggère de lire l'article suivant: Ce que chaque programmeur doit savoir sur la mise en réseau de jeux .

Et si vous débutez dans le réseautage en général, consultez les autres excellents articles de ce site. Glenn est un génie des réseaux.

Il y a beaucoup de raisons pour lesquelles P2P n'est pas populaire dans les jeux, principalement en raison du décalage. Tout le monde est aussi lent que le joueur le plus lent. Nous ne parlons pas de bande passante ici, mais de temps de ping.

P2p peut transférer des tonnes de données, mais avec un ping assez élevé, les jeux doivent transmettre de très petites quantités de données, avec un temps de ping minimal.

Il y a des aspects intéressants sur les systèmes peer-to-peer et les jeux d'action. J'ai essayé de les poster en tant que commentaire sur le blog de Glenn Fiedler, mais apparemment, il n'aime pas se tromper et a tiré l'article complet à la place. C'est sur Internet Archive, au cas où vous voudriez le lire.

Il n'a pas laissé le commentaire être mis en ligne, je vais donc le citer ici:

La suggestion poste à poste du premier message est en fait un point de départ intéressant, même si elle est parfois un peu naïve: la première possibilité serait de combiner le système avec un modèle client / serveur standard avec une prédiction, comme indiqué dans votre message. sur le jeu en réseau. Le ping P2P inférieur réduirait considérablement le décalage de prédiction entre les joueurs en fonction de leur emplacement: cet effet ne serait probablement pas visible pour la plupart des joueurs américains, mais ici, en Europe, des pings de plus de 200 sont normaux sur la plupart des serveurs et une connexion directe réduirait la retard de prédiction à celui d’un serveur européen.

Une véritable approche P2P sans serveur est un peu plus complexe: une des préoccupations majeures des réseaux décentralisés est d'assurer la cohérence, en particulier si la simulation peut avoir des effets papillon en raison du timing légèrement différent des commandes envoyées sur le réseau ou des problèmes de virgule flottante. Cela est possible en mettant en réseau l'état de chaque objet (joueurs, NPC, ...) au moins périodiquement. Il ne serait même pas nécessaire de le faire pour tous les objets en même temps, et chaque client pourrait prendre possession de certains objets. La mise en réseau d’un nombre suffisant d’objets dans un certain temps devrait atténuer la différence qui se crée entre chaque synchronisation d’un objet de manière à devenir non pertinente même pour des intervalles de synchronisation d’une seconde ou plus.

Le deuxième problème des systèmes P2P est la sécurité, mais cela peut être résolu avec un correctif relativement petit: les clients peuvent utiliser leurs simulations physiques pour collecter des informations sur le niveau d'erreur de chaque objet physique. La physique manipulée entraîne toujours une erreur plus importante, de sorte que les clients «votent» simplement pour se déconnecter de l'homologue qui contrôle un objet suspect. De plus, les messages de contrôle pour les objets non physiques sont transférés entre les clients en fonction de leur importance: les mises à jour du joueur peuvent être transmises de manière aléatoire, les mises à jour importantes et peu fréquentes doivent toujours être envoyées, mais toujours à un joueur aléatoire. De cette façon, un joueur devrait contrôler une grande partie des clients connectés pour pouvoir tricher de manière visible.

[...]

Vous pouvez trouver le fil que je référence à l' adresse http://www.devmaster.net/forums/showthread.php?t=14640 .

Je pense que quelqu'un a mentionné les problèmes de pare-feu que peer-to-peer a dans l'un des fils de l'article. Une solution possible serait un NAT-Punchthrough:
- Vue d'ensemble du Punchthrough NAT
- Communication entre homologues entre traducteurs d'adresses réseau

Il n'y a pas de taux de réussite de 100%, vous devriez donc toujours dire aux joueurs d'ouvrir un port.

Un bon exemple de gameplay "peer-to-peer" serait un jeu de stratégie en temps réel tel que Starcraft.

Dans un jeu avec des centaines d'unités / projectiles en mouvement, il n'est pas pratique d'envoyer de manière répétée les positions / états d'unités sur le réseau à tous les autres joueurs. Une solution consiste donc pour tous les joueurs à exécuter la simulation (exactement) en synchronisation.

Lorsqu'un joueur exécute une action, la commande / ordre ('move zergling to X, Y') peut être envoyé à tous les autres joueurs pour être exécuté par toutes les instances de la simulation une fraction de seconde plus tard.

Dans cette situation, si un joueur se déconnecte, le jeu peut continuer - car aucun serveur / hôte n'est nécessaire pour exécuter le jeu, les joueurs restants peuvent continuer.

Cependant, la synchronisation des jeux n’est pas anodine, vous devez utiliser un pas de temps fixe pour les mises à jour de la logique du jeu et faire très attention à l’utilisation et à l’amorçage des générateurs de nombres aléatoires, afin d’assurer que les simulations ne divergent pas!

Il serait un peu trompeur de prétendre que ce n'est pas célèbre pour les jeux quand la plupart des jeux de stratégie en temps réel (séries Star Craft, Command and Conquer) et de nombreux jeux FPS (Call of Duty: Modern Warfare 2) l'utilisent.

Cela dit, la façon dont on apprend le jeu dépend du service de jumelage / lobbying que vous utilisez ou créez. Mais même une fois que l’on a appris le jeu, il peut toujours y avoir un ou plusieurs pairs plus égaux que d’autres. Prenons le cas de 3 clients souhaitant jouer, un derrière un nat ouvert, deux derrière des nats stricts (fermés). L'homologue open nat peut établir des connexions entre les deux autres. Mais les 2 strictes ne peuvent pas se connecter directement les unes aux autres, elles nécessiteront l’ouverture de nat pour relayer les paquets. Si l'homologue open nat quitte le jeu, un autre relais devra être trouvé ou le jeu sera perturbé.

Vous pouvez également consulter Badumna (www.badumna.com), qui prétend être une solution de réseautage entre homologues pour les jeux en ligne. Il semble que la synchronisation de l'état du jeu soit distribuée et, selon leur site Web, une version Flash est à venir.

Vous voulez probablement courir avec un joueur (nous l'appellerons "hôte") en tant que serveur ne faisant pas autorité. Vous aurez tous les autres joueurs communiquer ce qu'ils font de leur côté avec notre hôte, et l'hôte transmettra les messages aux autres joueurs.

Vous voudrez probablement aussi transmettre une liste des ordinateurs connectés au lecteur hébergeur afin de pouvoir choisir un nouvel hôte et de commencer à communiquer avec les lecteurs restants.

La documentation de smartfoxserver peut vous aider et / ou vous voudrez peut-être aussi l’utiliser pour votre jeu. Vous venez de l'intégrer dans votre jeu client au lieu d'avoir un programme client et serveur séparé.

Je suis un peu intéressé par cette question. Vous dites qu'il y a beaucoup de problèmes à créer un jeu p2p au lieu d'un modèle client-serveur classique. Mais je suis à peu près sûr que P2P est comme un client-serveur, mais chaque pair a la chance de devenir un serveur. À propos du LAG, si vous ajoutez une machine supplémentaire en tant que serveur, il est plus probable que de nombreux clients soient plus éloignés du serveur. Toutefois, en utilisant p2p, il n’existe aucune machine supplémentaire dans le lobby. Vous pouvez gérer les tests de latence et créer des groupes avec un ping minimal. À propos du trafic générant, comme je l’ai appris, vous devez demander aux clients de transmettre moins que moins, ce qui signifie que les clients doivent comprendre que tous les autres clients sont prêts à vouloir dire.

Si vous créez un mmorpg d'aspect relativement simple avec une configuration système minimale, je suggérerais de créer un programme interne qui crée une "fréquence" en fonction du contenu du dossier du jeu et de la composition des fichiers. Cela permettra aux personnes ayant la même "fréquence" de jouer sur les mêmes canaux. Les clients modifiés, manipulés ou normaux seront séparés. Cela ne fonctionnera que pour les hacks ou les mods natifs, mais je suis sûr que cela couvre tous les tricheurs "stupides". Combiné à la méthode de vérification des erreurs mentionnée par une personne, la modération n’est pas nécessaire. En ce qui concerne les ports, il suffit de le couvrir du port 52225 avec un processus d'arrière-plan qui le garde branché sur les routeurs sans ports de déclenchement.