Principes de base du jeu multijoueur en ligne [fermé]

9

Je travaille actuellement sur un jeu multijoueur en ligne ac # en temps réel. L'objectif est d'avoir une connexion client / serveur utilisant le protocole UDP. Jusqu'à présent, j'ai utilisé UDP pour les mouvements des joueurs et TCP pour les événements (un joueur qui tire, un joueur qui perd la vie) parce que je dois être sûr que ces données arriveront à tous les joueurs connectés au serveur. Je sais que UDP est dit «non fiable» et certains paquets peuvent être perdus. Mais j'ai lu partout pour ne jamais mélanger TCP et UDP car cela peut affecter la connexion.

La question principale est de savoir comment dois-je organiser mon réseau?

UDP est sans connexion, comment enregistrer qui est qui? Dois-je enregistrer les adresses IP des clients dans une liste?

Dois-je utiliser TCP pour des événements importants ou utiliser UDP? Si je dois utiliser UDP, comment puis-je m'assurer que les données ne seront pas perdues?

En utilisant à la fois TCP et UDP, je dois enregistrer pour chaque joueur leur IP dans une liste (pour UDP) et le TcpClient qui est connecté dans une autre liste (pour UDP). Comment pourrais-je changer cela pour être plus efficace?

c#  networking  multiplayer  websocket 
— Lowip
source
@JoshPetrie cette question est légitime "La question principale est de savoir comment organiser mon réseau?". Il ne s'agit pas si je dois utiliser ceci ou cela. L'OP en utilise une et a besoin de conseils pour ajouter une autre technologie qu'il a déjà choisie. Il est large car la réponse ne réside pas dans la technologie à utiliser, mais dans la façon dont le logiciel peut être structuré pour éviter de gonfler les tuyaux, réduire les retards et augmenter la fiabilité indépendamment de la technologie sous-jacente.
— Coyote
C'est aussi trop large. La question doit être modifiée (n'hésitez pas à le faire, elle est assez ancienne) pour être plus sur le sujet, puis elle peut être rouverte.

Réponses:

6

UDP a moins de surcharge, mais au prix de perdre des paquets sans le savoir (une partie de la surcharge avec TCP garantit que les paquets perdus sont renvoyés).

Cependant, le gros problème avec l'utilisation d'UDP est qu'il existe de nombreux sites qui bloquent tout le trafic UDP (à l'exception du DNS) car de nombreux administrateurs pensent que c'est une bonne pratique de sécurité.

En outre, ne présumez pas que chacun de vos joueurs aura une adresse IP différente - il existe de nombreuses situations où plusieurs utilisateurs partagent la même connexion Internet, et si les écoliers deviennent accro à votre jeu, vous pouvez parier qu'ils sont probablement va comprendre comment l'installer et l'exécuter pendant les cours au lieu de faire leur travail (et ne préférez-vous pas qu'ils passent ce temps précieux sur votre jeu plutôt que sur quelqu'un d'autre?).

Une fois que votre flux TCP est ouvert, il est toujours assez efficace. La prochaine étape consiste à minimiser la quantité de données que vous envoyez / recevez, et c'est là que la conception du protocole entre en jeu. Si vous envoyez simplement quelques octets pour chaque commande (par exemple, "aller de l'avant") au lieu, par exemple, d'envelopper la même commande dans des centaines d'octets de code XML, votre consommation globale de bande passante réseau sera plus faible ET moins de cycles CPU seront être requis pour traiter les informations (quelques octets sont facilement comparables au démontage et à l'interprétation et à la vérification de la syntaxe d'un gros morceau de XML).

Vous pouvez certainement ouvrir plusieurs flux TCP et les utiliser à des fins différentes, comme un pour les commandes, un autre pour les transferts graphiques, un autre pour le chat audio, etc. De cette façon, si vous transférez un grand graphique qui prend 5 à 10 secondes à télécharger, au moins les mouvements de commande des joueurs ne seront pas en retard car ils seront sur un flux différent (et vous pouvez afficher un sprite par défaut jusqu'à ce que le nouveau sprite soit téléchargé, ce qui est toujours plus amusant que d'attendre).

— Randolf Richardson
source
1
La question d'origine mentionnait un modèle client-serveur, donc les "sites" qui bloquent tous les UDP ne sont pas pertinents; c'est le problème du client, et je doute que de nombreux clients bloquent tous les UDP. "L'utilisation de TCP est la pire erreur possible que vous pouvez faire lors du développement d'un jeu en réseau! Pour comprendre pourquoi, vous devez voir ce que TCP fait réellement au-dessus de IP pour que tout soit si simple!" Voir gafferongames.com/networking-for-game-programmers/udp-vs-tcp
— Indeed005
@ Indeed005: Il y a des avantages et des inconvénients à cela - UDP fournit certainement un avantage en termes de performances, mais au détriment de la fiabilité (c'est là que TCP a l'avantage). En ce qui concerne le blocage UDP, vous avez parfaitement raison d'être le problème du client, mais dans de nombreux environnements d'entreprise et éducatifs, j'ai rencontré UDP (à l'exception du port 53) bloqué par des administrateurs ignorants qui pensent qu'UDP est un problème de sécurité, et ainsi, l'option pour le client de recourir à TCP peut au moins signifier que le joueur peut faire l'expérience du jeu (surtout si la bande passante réseau est suffisamment rapide).
— Randolf Richardson
@ Indeed005: En outre, l'utilisation d'un mélange d'UDP et de TCP peut également être tout à fait acceptable car TCP peut être utilisé pour les transferts de données de priorité inférieure, tandis que UDP peut être utilisé pour le côté action à grande vitesse. Il est également intéressant de noter qu'avec IPv6, de nouvelles options sont disponibles (qui ne sont pas disponibles avec IPv4) qui peuvent répondre aux besoins en temps réel du jeu sans être de nature sans connexion, mais je pense qu'il faudra un certain temps avant IPv6 peut être utilisé par les jeux sans avoir à s'appuyer sur IPv4 (ce qui est regrettable, nous nous contentons donc d'IPv4 du mieux que nous pouvons pour l'instant).
— Randolf Richardson
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.