Quelles données échanger dans des jeux multijoueurs en temps réel?

Je suis un programmeur amateur et en ce moment je suis curieux de savoir quelles données sont échangées dans une session multijoueur dans des jeux en temps réel comme Starcraft 2. J'ai fait un tas de recherches. J'ai trouvé gafferongames.com offrant un très bon aperçu des problèmes à considérer.

Glenn dans son article et ses commentaires donne un argument très solide pour utiliser UDP sur TCP, mais SC2 utilise évidemment TCP. Pour qoute Gleen,

Le problème avec l'utilisation de TCP pour les jeux est que, contrairement aux navigateurs Web, à la messagerie électronique ou à la plupart des autres applications, les jeux multijoueurs ont une exigence en temps réel sur la livraison des paquets. Pour de nombreuses parties de votre jeu, par exemple la saisie des joueurs et la position des personnages, peu importe ce qui s'est passé il y a une seconde, vous ne vous souciez que des données les plus récentes.

Donc, d'après sa déclaration, je suppose que son approche consiste à envoyer l'état de jeu complet de chaque unité sur chaque image. Si le serveur ne reçoit pas d'entrée de joueur sur la trame actuelle, alors c'est juste de la chance pour ce joueur. Pour God of War: Acension, dans lequel il est responsable du développement réseau, cela devrait très bien fonctionner, je suppose.

Pour SC2, en raison de sa capacité de relecture, mon intuition me dit que le moteur sous-jacent est une "machine de lecture d'entrée utilisateur" à pas de temps fixe déterministe, où les seules données échangées sont les entrées du joueur . Par conséquent, la déclaration de Glenn peut être totalement hors de propos pour SC2. L'entrée du joueur est importante et la séquence d'entrée est encore plus importante. Je ne pense pas qu'il soit possible pour SC2 d'envoyer un état de jeu de 200 unités et plus à 30 - 60 FPS.

Question: Je peux me tromper, mais j'ai tenté d'identifier 2 types de données possibles. Quelles sont les autres techniques? Sera bon de qoute le jeu si vous voulez.

EDIT: a trouvé ce lien sur le modèle de réseau Starcraft

Glenn dans son article et ses commentaires donne un argument très solide pour utiliser UDP sur TCP, mais SC2 utilise évidemment TCP.

Glenn parle principalement de jeux axés sur la physique, c.-à-d. jeux de tir à la première personne et jeux de conduite. Ceux-ci ont des exigences différentes des jeux de stratégie en temps réel où les positions précises des unités à chaque étape logique sont importantes. Les stratégies de communication sont donc nécessairement différentes.

"En temps réel" signifie différentes choses dans différents contextes. Les jeux ne sont pas «durs» en temps réel dans la mesure où si un message est en retard, tout se brise. (Au moins, il n'y a aucune bonne raison pour qu'un jeu soit aussi exigeant, car un système uniquement logiciel devrait pouvoir se remettre des retards de traitement, contrairement à une centrale nucléaire ou à un équipement médical par exemple.) Les jeux sont vraiment temps réel «doux» ou «ferme». ( Définitions sur Wikipedia comme d'habitude .) Le type de jeu fait une différence quant à la rapidité avec laquelle vous avez besoin des informations, si vous pouvez perdre des informations et vous en tirer, etc. Il suffit de dire que TCP est assez bon pour de nombreux jeux, mais pour les autres jeux, UDP est préférable.

Je suppose que son approche consiste à envoyer l'état de jeu complet de chaque unité sur chaque image.

Il enverrait suffisamment d'informations pour reconstruire l'état de jeu pertinent de n'importe quelle unité qui a changé.

1. Vous n'avez pas besoin d'envoyer d'informations sur quelque chose qui n'a pas changé.
2. Vous n'avez pas besoin d'envoyer l'état complet si vous pouvez envoyer suffisamment d'informations pour que le destinataire puisse construire le nouvel état à partir de l'ancien état. (par exemple. Envoyez simplement une valeur delta par rapport à un ancien état. Ou envoyez simplement les parties de l'état qui ont changé et pas le reste.)
3. Si deux jeux exécutent exactement le même algorithme et ont exactement les mêmes données, vous pouvez simplement envoyer des entrées et le destinataire resimule les effets localement pour dériver le nouvel état.

La plupart des jeux ne remplissent pas les critères de 3, ils utilisent donc 1 et 2 à la place. Cependant, de nombreux jeux RTS peuvent utiliser et utilisent 3.

De plus, il ne doit pas nécessairement s'agir de "chaque image". Le concept de cadre est également nébuleux. Est-ce un cadre de rendu? Est-ce un lot de logique? S'agit-il d'une trame de données réseau envoyée? Les trois sont-ils toujours alignés un à un ou obtenez-vous un débit graphique variable avec des débits logiques fixes? Certains jeux, en particulier les jeux de stratégie en temps réel comme Starcraft 2, ou les jeux avec capacité de relecture (au fur et à mesure que vous touchez) aiment tout garder en parfait état en ayant des mises à jour réseau régulières (qui peuvent ou non correspondre à des `` cadres '' dans d'autres sens) mais ce n'est pas une exigence pour tous les jeux. De nombreux jeux envoient simplement des mises à jour sur une base semi-régulière, en fonction de la mesure dans laquelle ils sont prêts à laisser les clients s'exécuter.

L'entrée du joueur est importante et la séquence d'entrée est encore plus importante. Je ne pense pas qu'il soit possible pour SC2 d'envoyer un état de jeu de 200 unités et plus à 30 - 60 FPS.

De nombreux jeux ne traitent pas nécessairement un cadre de rendu comme un cadre logique. Ils peuvent avoir 60FPS dans les graphiques mais n'ont que 10 mises à jour logiques par seconde et envoyer 1 mise à jour réseau pour chacun. Mais même 30 mises à jour réseau par seconde sont raisonnables si vous utilisez la méthode «envoyer une entrée», certainement.

J'ai tenté d'identifier 2 types de données possibles. Quelles sont les autres techniques? Sera bon de qoute le jeu si vous voulez.

Ce n'est pas tant qu'il existe des techniques distinctes, mais plusieurs contraintes différentes sur les systèmes, et l'importance de chaque contrainte variera d'un jeu à l'autre. Il vous suffit donc de choisir un système qui fonctionne pour vous.

• Peu d'unités, se déplaçant rapidement et de manière irrégulière via l'entrée utilisateur, la latence est sensible, la synchronisation exacte entre les systèmes n'est pas importante - diffuser des positions via un protocole non fiable (par exemple UDP) pour obtenir une vitesse maximale, et les messages manqués n'auront pas d'importance car un nouveau le sera venez bientôt. Simulez la physique localement pour améliorer la qualité du rendu mais corrigez les positions lorsque de nouvelles informations arrivent. Bon pour les tireurs et les jeux de conduite.
• De nombreuses unités, mais la plupart ne sont pas pertinentes et se déplacent lentement - n'envoient que des mises à jour pour les unités proches du destinataire, les envoient sous forme de modifications plutôt que d'états complets, les envoient relativement rarement et envoient un protocole fiable (par exemple, TCP) pour éviter d'avoir pour vous demander comment gérer les mises à jour manquées. Bon pour les MMO.
• De nombreuses unités, déplacées par l'IA sur la base des entrées utilisateur précédentes, une synchronisation exacte entre les systèmes est très importante - envoyez des entrées utilisateur horodatées sur un protocole fiable et relancez localement pour que les algorithmes de jeu gardent l'état synchronisé. Bon pour les RTS et les jeux au tour par tour.

La technique principale à connaître est la technique des "1500 archers". Il était célèbre pour Age of Empires, mais il est également utilisé dans d'autres jeux tels que l'OpenTTD (open source) (basé sur Transport Tycoon Deluxe).

Pour être clair: en utilisant cette technique, vous n'avez pas besoin d'envoyer TOUT état de jeu pendant que vous jouez. L'état complet du jeu est envoyé au démarrage initial, à la connexion et à la resynchronisation. Les seules choses que vous devez envoyer régulièrement sont des signaux horaires et des vérifications de synchronisation. Seules les commandes des joueurs sont normalement envoyées du client au serveur et vice versa. Si un joueur n'exécute aucune commande (comme c'est le cas sur la plupart des ticks), aucune donnée ne doit être envoyée.

Voir ce lien.

http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php

Mise à jour: Kylotan appelle cette "technique 3" dans la réponse.