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é.
- Vous n'avez pas besoin d'envoyer d'informations sur quelque chose qui n'a pas changé.
- 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.)
- 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.