Je suis intéressé par la façon dont les protocoles (et la boucle de jeu) fonctionnent pour ce type de jeux; tous les pointeurs ou idées sont appréciés.
Je suppose que la boucle principale aurait un état mondial qui serait avancé de quelques "ticks" par seconde, mais comment les commandes des joueurs sont-elles exécutées? Quels types de données doivent être échangés?
Je peux aller dans beaucoup de détails à ce sujet, mais d'abord, allez lire "1500 archers" http://www.gamasutra.com/view/feature/3094/1500%5Farchers%5Fon%5Fa%5F288%5Fnetwork%5F.php et cela permettra de répondre à beaucoup de vos questions. Voici un résumé: Tout d'abord, la plupart des jeux utilisent UDP en raison de la nature en temps réel de la partie. La boucle de jeu ressemble à quelque chose comme ceci:
C'est largement simplifiée et "jouer avec la physique" pourrait facilement être un livre de 200 pages sur son propre, mais il s'agit de prédire côté client où quelque chose est susceptible d'être, d'obtenir des données à partir du serveur qui est vieux, mais indique exactement l'endroit où l'objet a été ou devraient être, et puis en interpolant les valeurs en quelque sorte à faire apparaître l'objet "assez proche" à l'endroit où il est supposé être que personne ne remarque. C'est super-critique à la première personne tireurs, mais pas autant pour de stratégie en temps réel.
Pour de stratégie en temps réel, ce qui se passe en général est un système basé sur des où le temps est divisé en discret morceaux appelés "tours" qui se produisent de façon séquentielle et à chaque tour un nombre généré par une fonction monotone qui garantit jamais l'augmentation des valeurs dans un ordre particulier sans doublons. Sur tout tourner à n, chaque client envoie un message à tous les autres clients à leur action au tour n + m, où m est un nombre arbitraire qui est généralement assez petite et peut être mieux déterminée par essai et erreur ainsi que des tests. Une fois que tous les clients ont envoyé leur action, chaque client exécute toutes les actions qui ont été envoyés au tour n + m. Cela introduit un tout petit retard lorsqu'une action est commandée par l'utilisateur et lorsqu'il s'exécute, mais ce n'est généralement pas perceptible.
Il existe plusieurs techniques qui peuvent être utilisés pour fudge le temps. Par exemple, si vous highlite une unité et ensuite, dites-lui de se déplacer, il va faire du bruit et d'animation quand il commence à se déplacer, mais ne fait pas bouger tout de suite. Cependant, le message sur le réseau de l'intention de déplacer cet appareil est envoyé immédiatement par le temps, l'écran réagit au joueur d'entrée, le réseau des messages ont déjà été envoyés et reconnu. Vous pouvez fudge plus loin en introduisant un peu de retard (100 ms ou plus) entre le clic de la souris et le jeu de l'objet de réponse. Ce n'est généralement pas perceptible par le lecteur, mais 100ms c'est une éternité dans un jeu de LAN, et même avec une connexion à large bande sur un ordinateur à la maison le ping moyen est probablement autour de 15-60ms, ce qui vous donne suffisamment de temps pour envoyer le paquet avant de le déplacer.
Comme pour les données à envoyer, il y a deux types de données dans les jeux: déterministe et non déterministe. déterministe actions sont fondées sur la physique du jeu, de sorte que lorsque l'action commence, il y a une garantie à 100% que je peux prédire le résultat de cette action. Ces données ne doit jamais être envoyé à travers le réseau depuis que j'ai peut déterminer ce qu'il en sera sur le client, en fonction de l'état initial. Notez que l'utilisation d'un générateur de nombre aléatoire avec la même semence sur chaque client de tours "aléatoire" des événements dans le comportement déterministe. Non-déterministe de données est généralement la saisie de l'utilisateur, mais il est possible de prédire ce que l'entrée d'un utilisateur est susceptible d'être dans de nombreux cas. La façon dont ces paire dans un véritable jeu de stratégie en temps, c'est que le non-déterministe de l'événement est d'un certain ordre à l'un de mes objets du jeu. Une fois le jeu de l'objet a été ordonné de se déplacer, de la façon dont elle se déplace est 100% déterministe. Donc, tout ce que vous devez envoyer sur le réseau est l'ID de l'objet, l'ordre donné (faire un enum pour économiser de la bande passante), et la cible de la commande (le cas échéant, si un sort peut ne pas avoir de cible, s'il est un domaine de affet mais une commande de déplacement a une fin-destination). Si l'utilisateur clique sur comme 100 fois pour faire une unité de se déplacer, il n'est pas nécessaire d'envoyer une distinct de la commande de déplacement pour chaque clic, car ils sont tous dans la même zone générale afin d'être sûr de filtre à cela, car il va tuer votre bande passante.
Une dernière astuce pour le traitement d'un éventuel retard entre une commande et son exécution est quelque chose qui s'appelle une perception locale de filtre. Si je reçois un déplacement de l'ordre de quelques temps t après que l'ordre a été donné, je sais que lorsque l'unité doit avoir commencé à bouger et je sais que sa destination finale. Plutôt que de téléporter l'unité d'obtenir à l'endroit où il est censé être, je peux commencer son mouvement fin, puis mess avec la physique de l'accélérer légèrement, de sorte qu'il peut attraper jusqu'à l'endroit où il est censé être, et puis lente vers le bas pour la mettre dans le bon endroit. La valeur exacte vous avez besoin de vitesse, il est également relative et les tests est la seule façon de déterminer la valeur correcte, car il suffit de le "sentir" pour qu'elle soit correcte. Vous pouvez faire la même chose avec la mise à feu des balles et des missiles en tant que bien et il est très efficace pour cela. La raison pour laquelle cela fonctionne est que les humains ne sont pas terriblement bon à voir des changements subtils dans le mouvement, en particulier si un objet se dirige directement vers ou loin d'eux, de sorte qu'ils ne s'en aperçoivent pas.
La prochaine chose à penser est de couper vers le bas sur la bande passante. Ne pas envoyer des messages à des clients qui ne pouvaient pas possible de voir ou d'interagir avec une unité qui est en mouvement. N'envoyez pas le même message encore et encore parce que l'utilisateur clique. Ne pas envoyer des messages immédiatement pour les événements qui n'ont pas d'impact immédiat. Enfin, ne pas exiger un accusé de réception pour des événements qui seront obsolètes devraient-ils ne sont pas reçues. Si je n'ai pas un mouvement de mise à jour, le temps que je re-transmettre cette mise à jour, sa valeur sera tellement vieux qu'il est plus pertinent de sorte qu'il est préférable de simplement envoyer un autre mouvement et l'utilisation d'une perception locale de filtre à rattraper ou à l'utilisation d'une spline cubique d'interpolation du mouvement de sorte qu'il semble plus correct, ou quelque chose de cette nature. Toutefois, un événement critique, comme un "vous êtes mort" ou "votre drapeau a été prise" doit être reconnu et re-transmis en cas de besoin. J'enseigne le jeu du réseau de la programmation à Digipen, alors n'hésitez pas à poser toutes vos questions à propos de ce que je peux probablement vous fournir une réponse. Réseau de la programmation de jeux vidéo peut être assez compliqué, mais en fin de compte, il est tout au sujet de faire des choix dans la mise en place et de comprendre les conséquences de votre choix.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
