Conception du moteur de jeu: serveurs multijoueurs et écouteurs [fermé]

Mon moteur de jeu se compose actuellement d'une partie solo qui fonctionne. Je commence maintenant à réfléchir à la façon de faire la partie multijoueur.

J'ai découvert que de nombreux jeux n'ont en fait pas de véritable mode solo, mais lorsque vous jouez seul, vous hébergez également un serveur local, et presque tout fonctionne comme si vous étiez en multijoueur (sauf que les paquets de données peuvent être transmis sur un itinéraire alternatif pour de meilleures performances)

Mon moteur aurait besoin d'un refactoring majeur pour s'adapter à ce modèle. Il y aurait trois modes possibles: client dédié, serveur dédié et client-serveur (mode d'écoute)

• À quelle fréquence le modèle de serveur d'écoute est-il utilisé dans l'industrie du jeu?
• Quels en sont les (dés) avantages?
• Quelles autres options ai-je?

Je vais voir si je peux y répondre du mieux que je peux:

À quelle fréquence le modèle de serveur d'écoute est-il utilisé dans l'industrie du jeu?

En ce qui concerne la plupart des jeux en ligne, vous constaterez qu'une grande majorité de jeux utilisent une architecture client-serveur, mais pas toujours comme vous le pensez. Prenez n'importe quel jeu Source, par exemple. La plupart utiliseront un client-serveur standard avec une architecture de serveur maître (pour répertorier les jeux disponibles), dans la mesure où une personne hébergera un serveur dédié et toute personne ayant un client pourra le rejoindre.

Cependant, vous avez certains jeux et services, par exemple Left 4 Dead, League of Legends et certains jeux XBox Live, qui adoptent une approche légèrement différente. Ils utilisent tous une architecture client-serveur avec un serveur de contrôle. L'idée principale ici est que quelqu'un crée un serveur dédié qui ne "lance" aucun jeu. Le serveur de contrôle créera une sorte de "lobby", et lorsque le jeu démarrera, le serveur de contrôle les ajoutera à une file d'attente, et quand ce sera le tour de ce lobby, il sélectionnera un serveur dédié correspondant (en termes d'emplacement / vitesse, disponibilité, nombreux facteurs) et affectez les joueurs à ce serveur. Ce n'est qu'alors que le serveur "exécutera" réellement le jeu. C'est la même idée, mais un peu simplifiée, car le client n'a pas besoin de "choisir" un serveur,

Bien sûr, le plus grand modèle client-serveur est le modèle MMO, où un ou plusieurs serveurs exécutent un monde persistant qui gère presque toutes les données et la logique. Certains des jeux les plus célèbres utilisant ce modèle sont World of Warcraft, Everquest, quelque chose comme ça.

Alors, où se situe un serveur d'écoute ici? Pour être honnête, pas vraiment bien, cependant, vous trouverez toujours de nombreux jeux qui l'utilisent. Par exemple, la plupart des jeux Source permettent de créer des serveurs d'écoute, et de nombreux jeux XBox Live le font (cela fait longtemps, mais je pense que Counter Strike l'a fait, ainsi que Quake 4 et bien d'autres). En général cependant, ils semblent être désapprouvés en raison des avantages du modèle client-serveur, ce qui nous amène à notre prochain point.

Quels en sont les (dés) avantages?

D'abord et avant tout: la performance. Dans un modèle client-serveur, le client gérera les changements locaux (tels que l'entrée, les graphiques, les sons, etc.) à chaque cycle du jeu. À la fin du cycle, il regroupera les données pertinentes (telles que le joueur s'est-il déplacé? Si oui, où? Où regarde-t-il maintenant? Vélocité? Ont-ils tiré? Si oui, des informations sur la balle. Etc) et l'envoyer au serveur pour traitement. Le serveur prendra ces données et déterminera si tout est valide tel que, l'utilisateur se déplace-t-il d'une manière qui indique le piratage (plus de détails plus tard), le mouvement est-il valide (quoi que ce soit sur le chemin?), A fait la balle du joueur 1 hit player 2 ?, et plus. Ensuite, le serveur empaquette cela et l'envoie aux clients, qui mettent ensuite à jour tout ce qui est nécessaire, comme ajuster la santé si le joueur a été abattu, donner un coup de pied au joueur s'il est déterminé qu'ils piratent, etc.

Un serveur d'écoute, cependant, doit gérer tout cela en même temps. Étant donné que je suppose que vous connaissez la programmation, vous vous rendez probablement compte de la puissance qu'un jeu peut voler à un ordinateur, en particulier un jeu mal conçu. En ajoutant le traitement réseau, le traitement de sécurité, etc. , ainsi que le jeu du client, vous pouvez voir où les performances prendraient un sérieux coup, du moins en ce qui concerne le traitement standard. De plus, la plupart des serveurs fonctionnent sur des réseaux rapides et sont des serveurs conçus pour supporter le trafic réseau. Si le réseau d'un serveur d'écoute est lent, l'ensemble du jeu en souffrira.

Deuxième sécurité , comme indiqué précédemment, l'une des principales choses qu'un serveur fera sera de déterminer si un joueur exploite le jeu. Vous avez peut-être vu cela comme Punkbuster, VAC, etc. Il existe un ensemble très compliqué de règles qui exécutent ces programmes, par exemple, déterminant la différence entre un pirate et juste un très bon joueur. Ce serait très mauvais pour votre jeu si vous ne pouviez pas attraper les pirates, mais pire encore si vous exécutiez une action contre un accusé faussement accusé.

Un serveur d'écoute ne sera généralement pas en mesure de gérer le jeu du client, le traitement du serveur et la détection de piratage, et dans la plupart des cas, les détecteurs comme Punkbuster sont très difficiles, voire impossibles à exécuter sur un serveur d'écoute, car il est difficile pour qu'il fonctionne correctement sans la puissance de traitement nécessaire, car généralement la logique de jeu est prioritaire sur la sécurité, et si le détecteur n'est pas autorisé à traiter pour une image, il peut perdre les données nécessaires pour condamner quelqu'un.

Enfin, le gameplay . La plus grande chose à propos des serveurs est qu'ils sont persistants, ce qui signifie que même si tout le monde part, le serveur continuera de fonctionner. Cela est utile si vous avez un serveur populaire qui n'a pas beaucoup d'activité la nuit, les gens peuvent toujours se joindre lorsqu'ils sont prêts à jouer et ne pas avoir à attendre qu'il soit remis en ligne.

Dans un serveur d'écoute, le principal inconvénient est que dès que le client hébergeant le serveur d'écoute quitte, le jeu doit soit être transféré à un autre joueur (créant un lul dans le jeu qui peut durer quelques minutes dans certains cas), soit se terminer complètement . Ce n'est pas préférable sur un grand serveur, car l'hôte doit soit rester en ligne (gaspiller un emplacement dans le serveur et la puissance de son ordinateur, ce qui pourrait également ralentir le jeu), soit terminer le jeu pour tout le monde.

Cependant, malgré ces problèmes, les serveurs d'écoute présentent quelques avantages.

Facile à configurer : la plupart des serveurs d'écoute ne sont rien d'autre que de frapper "Nouveau jeu" et de laisser les gens se joindre. C'est facile pour les personnes qui veulent simplement jouer avec leurs amis et ne souhaitent pas avoir à chercher un serveur dédié vide ou jouer avec d'autres personnes.

Bon pour les tests : si quelqu'un possède un serveur dédié et souhaite changer sa configuration, il est généralement préférable de testerla configuration en premier. L'utilisateur devra soit créer une sauvegarde du serveur dédié et entrer aveuglément dans les changements, la seule option étant de revenir en arrière en cas de problème, de créer un nouveau serveur dédié pour les tester, de simplement créer un serveur d'écoute simple pour testez-les. Et avec le point 1, ceux-ci sont généralement plus faciles à démarrer et à configurer. Cela est particulièrement vrai, car la plupart des serveurs dédiés ne sont pas dans l'accès immédiat des administrateurs (la plupart des serveurs dédiés sont loués à distance). Il faut beaucoup plus de temps pour pousser les modifications de configuration, ainsi que les commandes de redémarrage, etc., vers un emplacement distant qu'une machine sur laquelle l'administrateur est actuellement.

Moins de ressources : dans la plupart des serveurs dédiés, un utilisateur avec la même IP ne peut pas se connecter au serveur dédié (ce qui signifie que le client doit soit héberger le serveur, soit jouer, il ne peut pas faire les deux). Si le client souhaite jouer sur son propre serveur, il aura généralement besoin d'une deuxième machine pour héberger le serveur, ou acheter ou louer un serveur dédié pour pouvoir jouer sur celui-ci. Un serveur d'écoute ne nécessite qu'une seule machine, ce qui peut être la seule chose que le client peut utiliser.

Dans les deux cas, les deux présentent des avantages et des inconvénients, et vous devez les peser avec ce que vous êtes prêt à concevoir et à mettre en œuvre. D'après mon expérience, je crois que si vous implémentiez un serveur d'écoute, il serait utilisé, ne serait-ce que pour quelques utilisateurs souhaitant jouer avec des amis ou tester les paramètres.

Enfin:

Quelles autres options ai-je?

Il s'agit d'une boîte industrielle de vers. En réalité, tout type d'architecture de réseau peut être appliqué aux jeux vidéo. Cependant, d'après ce que j'ai vu, comme la plupart des communications Internet, la plupart se résument à une certaine forme de modèle client-serveur.

Veuillez me faire savoir si je n'ai pas répondu à votre question, ou si vous avez besoin de quelque chose de plus, et je verrai ce que je peux faire.