L'hôte du jeu devrait-il être l'autorité ou un autre client stupide?

Lors de la conception d'un jeu multijoueur en réseau où un joueur héberge et d'autres se connectent, il y a deux stratégies que je connais:

Que le jeu du joueur hôte soit l'autorité , tous les autres joueurs en tant que clients muets essayant de rattraper l'état de jeu actuel. Dans le code, il devra y avoir beaucoup de cas particuliers, selon que le joueur actuel est l'hôte ou non.
Faites de l'hôte un client muet comme tout le monde en exécutant un serveur dédié caché sur un autre thread. Le serveur dédié sera l'autorité et l'hôte s'y connectera comme tout le monde (via localhost).

Quels sont les avantages / inconvénients de chacun d'eux? Lequel est le plus utilisé (ou varie-t-il selon le type / la taille du jeu)?

game-design networking multiplayer

— BlueRaja - Danny Pflughoeft
source

Le premier cas que vous décrivez peut être une forme de mise en réseau P2P (avec un client faisant autorité) et son généralement beaucoup plus complexe, et plus difficile à mettre en œuvre et à maintenir.

— akaltar

Réponses:

L'approche dumb-client est la meilleure d'un point de vue pur: elle limite fortement la quantité de code différent dont vous avez besoin entre l'hôte et les clients et permet au serveur de s'exécuter de manière asynchrone. L'inconvénient est que la machine de l'hôte nécessite des ressources supplémentaires, mais je suppose que c'est toujours le cas.

— DeadMG
source

Entre ces deux options, l'approche du client stupide est certainement la meilleure pour les raisons mentionnées par DeadMG.

Il existe une autre option qui fait de chaque client une autorité, elle a l'avantage du client muet que tous les pairs partagent le même code. L'autre avantage est que cela pourrait être beaucoup plus équitable si vous définissez les bonnes règles car personne n'a l'avantage de 0-lag-to-server.

Cela peut bien sûr être assez délicat à mettre en œuvre selon le type de jeu. Votre protocole devra gérer la résolution des conflits entre pairs, en utilisant probablement une sorte de schéma de propriété. Ne laissant que les conflits où 2 pairs revendiquent la propriété du même objet de jeu.

Googler les protocoles multijoueurs Peer-2-Peer pourrait vous donner plus de détails sur cette approche.

— Tinco
source

gamedev.stackexchange.com/questions/3887/… Voici quelques informations supplémentaires :)

— michael.bartnett

Intéressant. Ce post prétend que c'est ainsi que «la plupart des titres de stratégie» implémentent le réseautage. Est-ce vraiment vrai? Est-ce ainsi, par exemple. Command and Conquer et Starcraft fonctionnent-ils?

— BlueRaja - Danny Pflughoeft

@BlueRaja, c'est ainsi que fonctionne Starcraft, oui. Dans Starcraft, il n'y a aucune autorité. Warcraft III et Starcraft II ont un modèle d'échange de messages plus centralisé, un traitement des retards et des déconnexions, mais fondamentalement le même en ce que chaque client héberge son propre état de jeu.

— Rotsor

L'autre avantage de ce modèle de mise en réseau est qu'il permet de prendre en charge un grand état mondial partagé cohérent avec un trafic de synchronisation minimal.

— Rotsor

Le plus grand inconvénient de ce modèle est sa vulnérabilité inhérente au "maphacking", qui révèle certaines données sur l'état du jeu que le joueur ne peut normalement pas voir.

— Rotsor