Logique de jeu commune sur le client et le serveur

Lors des Pixonic DevGAMM Talks, notre DTO Anton Grigoriev a également pris la parole. Nous, dans l'entreprise, avons déjà dit que nous travaillions sur un nouveau jeu de tir PvP et Anton a partagé certaines des nuances de l'architecture de ce projet. Il a expliqué comment construire le développement de manière à ce que les changements dans la logique de jeu du client apparaissent automatiquement sur le serveur (et vice versa), et s'il est possible de ne pas écrire de code, mais de minimiser le trafic. Vous trouverez ci-dessous un enregistrement et une transcription du rapport.


Je n’apprendrai pas à faire quelque chose, je parlerai de la façon dont nous l’avons fait. Pour ne pas marcher sur le même râteau et profiter de notre expérience. Il y a un an et demi, nous, dans l'entreprise, ne savions pas comment fabriquer des tireurs sur des téléphones portables. Vous dites comment c'est, vous avez des robots de guerre, 100 millions de téléchargements, 1,5 million de DAU. Mais dans ce jeu, les robots sont très lents, et nous voulions faire un tireur rapide, et l'architecture de War Robots ne le permettait pas.

Nous savions comment et quoi faire, mais nous n'avions aucune expérience. Ensuite, nous avons embauché une personne qui a eu cette expérience et lui avons dit: faites la même chose que vous avez déjà fait cent fois, mais en mieux. Puis ils se sont assis et ont commencé à penser à l'architecture.



Entré dans le système de composants d'entité (ECS). Je pense que beaucoup de gens savent ce que c'est. Tous les objets du monde sont représentés par des entités. Par exemple, un joueur, son arme, un objet sur la carte. Ils ont des propriétés décrites par les composants. Par exemple, le composant Transformer est la position du joueur dans l'espace et le composant Santé est sa santé. Il y a une logique - elle est séparée et représentée par des systèmes. En règle générale, les systèmes sont la méthode Execute (), qui passe à travers les composants d'un certain type et fait quelque chose avec eux, avec le monde du jeu. Par exemple, MoveSystem passe en revue tous les composants de Movement, examine la vitesse dans ce composant, le paramètre et, sur cette base, calcule la nouvelle position de l'objet, c'est-à-dire l'écrit dans Transform.

Une telle architecture a ses propres caractéristiques. Lors du développement sur ECS, vous devez penser et faire les choses différemment. L'un des avantages est la composition plutôt que l'héritage multiple. Rappelez-vous ce rhombique avec héritage multiple en C ++? Tous ses problèmes. Ce n'est pas le cas chez ECS.



La deuxième caractéristique est la séparation de la logique et des données, dont j'ai déjà parlé. Qu'est-ce que cela nous donne? Nous pouvons stocker l'état du monde et son histoire par lots, nous pouvons le sérialiser, nous pouvons envoyer ces données sur le réseau et les modifier en temps réel. Ce ne sont que des données en mémoire - nous pouvons modifier n'importe quelle valeur à tout moment. Ainsi, il est très pratique de changer la logique du jeu (ou pour le débogage).

Il est également très important de garder une trace de l'ordre des appels système. Tous les systèmes se succèdent, sont appelés par la méthode Execute () et, idéalement, doivent être indépendants. En pratique, cela ne se produit pas. Un système change quelque chose dans le monde, un autre système l'utilise ensuite. Et si nous cassons cet ordre, le jeu se déroulera différemment. Probablement pas beaucoup, mais certainement pas le même qu'auparavant.

Enfin, l'une des fonctionnalités principales et les plus importantes pour nous est que nous pouvons exécuter le même code à la fois sur le client et sur le serveur.

Donnez au développeur une opportunité, et il trouvera 99 façons et raisons de prendre sa décision, et n'utilisera pas celles existantes. Je pense que beaucoup l'ont fait. Nous recherchions le cadre ECS à cette époque. Nous avons considéré Entitas, Artemis C #, Ash.net et notre propre solution, qui pourrait être écrite à partir de l'expérience d'un spécialiste qui est venu chez nous.



N'essayez pas de lire ce qui est écrit sur la diapositive, ce n'est pas si important. L'important est la quantité de vert et de rouge dans les colonnes. Vert signifie que la solution prend en charge les exigences, rouge - ne prend pas en charge, jaune - prend en charge, mais pas tout à fait.

Dans la colonne, ECS est potentiellement notre solution. Comme vous pouvez le voir, il fait plus frais - nous pourrions prendre en charge beaucoup plus d'exigences. En conséquence, nous n'avons pas soutenu certains d'entre eux (principalement parce qu'ils n'étaient pas nécessaires), et certains, sans lesquels nous ne pourrions pas continuer à travailler, ont dû être faits. Nous avons choisi l'architecture, travaillé longtemps, réalisé une version minimalement jouable et ... fakap.



Il s'est avéré que la version la plus injouable. Le joueur recule constamment, freine, le serveur se bloque au milieu du match. Il était impossible de le jouer. Quelles étaient les raisons des échecs?

La raison n ° 1 et la plus importante est l'inexpérience. Mais comment ça? Nous avons embauché une personne expérimentée qui était censée tout faire magnifiquement. Oui, mais en réalité nous ne lui avons donné qu'une partie du travail. Nous avons dit: "Voici un serveur de jeu pour vous, travaillez dessus." Et dans notre architecture (plus à ce sujet plus tard), le client joue un rôle très important. Et c'est cette partie que nous avons donnée à un homme qui n'avait pas l'expérience nécessaire. Non, c'est un bon programmeur, sénateur - il n'y avait tout simplement aucune expérience. C'est-à-dire il n'avait aucune idée du genre de râteau qu'il pouvait y avoir.

Raison n ° 2 - allocations irréalistes. 80 Ko / trame. Est-ce beaucoup ou pas? Si nous prenons en compte le fait que nous avons 30 images par seconde, alors en une seconde nous obtenons 2,5 Mo, et pour un match de 5 minutes, il y a déjà plus de 600 Mo. Bref, beaucoup. Le garbage collector commence à essayer intensément de libérer toute cette mémoire (quand on en demande de plus en plus), ce qui conduit à des pics. Étant donné que nous voulions 30 images par seconde, ces pointes nous ont beaucoup gênés. De plus, à la fois sur le client et sur le serveur.

La principale raison des allocations est que nous avons constamment alloué des tableaux de données. Presque à chaque fois à chaque image. Utilisé LINQ, les expressions lambda et Photon. Photon est une bibliothèque réseau que nous connaissons et utilisons dans War Robots. Et tout semble aller bien, mais il alloue de la mémoire à chaque fois qu'il envoie ou reçoit des données.

Si nous avons réglé les premiers problèmes (réécrits dans nos collections personnalisées, mis en cache), il n'y avait pratiquement rien à faire avec Photon, car il s'agit d'une bibliothèque tierce. Il était seulement possible de réduire la taille des paquets, et nous avions 5 Ko. Beaucoup? Oui Il y a MTU - c'est la taille minimale réelle des paquets qui est envoyée via UDP, sans casser le paquet en petites parties. Il fait environ 1,5 kilo-octets et nous en avions 5 (en moyenne, il y en avait plus).

En conséquence, Photon a coupé notre colis en petits et a envoyé chaque pièce comme fiable, c'est-à-dire avec livraison garantie. Chaque fois que la pièce n'atteignait pas, il l'envoyait encore et encore. Nous avons encore plus de latence et le réseau a mal fonctionné.

Toutes ces allocations ont conduit au fait que nous avons reçu une trame d'environ 100 millisecondes quand 33 était nécessaire et là, rendu, simulation et autres actions - tout cela prend le CPU. Tous ces problèmes sont complexes, c'est-à-dire il était impossible d'en décider, et tout irait bien. Il fallait les résoudre tous en même temps.

Et un autre petit problème qui était pendant le développement - un grand nombre de référentiels. 5 est écrit sur la diapositive, mais il me semble qu'il y en avait encore plus. Tous ces référentiels (pour le client, le serveur de jeu, le code commun, les paramètres et quelque chose d'autre) ont été connectés par des sous-modules aux deux référentiels principaux pour le client et le serveur de jeu. C'était difficile de travailler avec. Les programmeurs peuvent travailler avec Git, SVN, mais il y a aussi des artistes, des designers, etc. Je pense que beaucoup ont essayé d'enseigner à un artiste ou un designer comment travailler avec un système de contrôle de version. C'est vraiment difficile, donc si votre designer sait comment le faire - prenez soin de lui, c'est un employé précieux. Dans notre cas, même les programmeurs ont paniqué et, par conséquent, nous avons tout réduit à un seul référentiel.

C'était une excellente solution au problème. Nous avons là un dossier avec un serveur et un dossier avec un client. Le serveur se compose d'un projet de serveur de jeu, d'un générateur de code et d'outils auxiliaires.



Un client est un client Unity et un code commun. Un code commun est une structure de données mondiale, c'est-à-dire Entités, composants et simulation système. Ce code est principalement généré par le générateur de serveur. Il est utilisé par le serveur. C'est-à-dire Il s'agit d'une partie commune pour le client et le serveur.

La vie. Nous prenons TeamCity, le mettons sur notre référentiel, collectons et déployons le serveur. Chaque fois qu'un client change de logique générale, un serveur de jeu est assemblé ici - maintenant, un programmeur de serveur n'est plus nécessaire pour cela. Il y a généralement un serveur, un client et certaines fonctionnalités. Le client le voit à la maison, le serveur à la maison, et un jour cela fonctionnera pour eux. Dans notre cas, ce n'est pas le cas - le client peut écrire cette fonctionnalité et tout fonctionne sur le serveur.

Le match se compose d'une partie commune (désignée comme ECS) et d'une présentation (ce sont des classes unitaires de MonoBehavior, des GameObjects, des modèles, des effets - tout ce que le monde représente). Ils ne sont pas connectés.



Entre eux, il y a des présentateurs, qui fonctionnent avec les deux parties. Comme vous le comprenez, il s'agit de MVP (Model-View-Presenter) et n'importe laquelle de ces pièces peut être remplacée si nécessaire. Il y a une autre partie qui fonctionne avec le réseau (sur la diapositive - Réseau). Il s'agit de la sérialisation des informations sur le monde, de la sérialisation des entrées, de l'envoi au serveur, de la réception par le serveur, de la connexion au serveur, etc.

Plus de likes. Nous prenons et remplaçons cette partie par un package qui n'est pas réel, sur le réseau, mais virtuel. Nous créons un objet à l'intérieur du client et lui envoyons des messages. Il implémente une simulation de serveur - maintenant cet objet fait tout ce qui s'est passé sur le serveur de jeu. Les joueurs restants sont remplacés par des bots.



C'est fait. Nous avons obtenu le jeu et la possibilité de le tester sans serveur de jeux. Qu'est-ce que cela signifie? Cela signifie que l'artiste, après avoir fait un nouvel effet, peut cliquer sur le bouton Lecture dans l'éditeur, accéder immédiatement au match sur la carte et voir comment cela fonctionne. Ou déboguez pour les programmeurs clients ce qu'ils ont écrit.

Mais nous sommes allés plus loin et attaché à cette couche l'émulation du jitter ping des retards réseau (c'est lorsque les paquets sur le réseau n'arrivent pas dans l'ordre dans lequel ils ont été envoyés) et d'autres choses sur le réseau. En conséquence, nous avons obtenu un match pratiquement réel sans serveur de jeu. Cela fonctionne, vérifié.

Revenons à la génération de code.



J'ai déjà dit que nous avons un générateur de code dans un serveur de jeux. Il existe un langage spécifique au domaine, qui est en fait une simple classe C #. Dans ce cas, la classe Santé. Nous le marquons avec nos attributs. Par exemple, il existe un attribut de composant. Il dit que la santé est une composante de notre monde. Sur la base de cet attribut, le générateur créera une nouvelle classe C # dans laquelle il y aura un tas de choses. Ils peuvent être écrits à la main, mais cela va générer. Par exemple, la méthode d'ajout d'un composant à Entity, la méthode de recherche de composants, la sérialisation des données, etc. Il existe un attribut du type DontSend, qui indique qu'il n'est pas nécessaire d'envoyer un champ sur le réseau - le serveur n'en a pas besoin ou le client n'en a pas besoin. Ou l'attribut Mach, qui indique que le joueur a une valeur de santé maximale de mille. Qu'est-ce que cela nous donne? Au lieu d'un champ qui occupe 32 bits (int), nous envoyons 10 bits - trois fois moins. Un tel générateur de code nous a permis de réduire la taille des paquets de 5 Ko à 1.



1 Ko <1,5 - c'est-à-dire Nous avons rencontré le MTU. Photon a cessé de couper et le réseau s'est beaucoup amélioré. Presque tous ses problèmes ont disparu. Mais nous sommes allés plus loin et avons fait une compression delta.



C'est lorsque vous envoyez un état complet, puis uniquement ses modifications. Il n’arrive pas que le monde entier ait immédiatement complètement changé. Seules certaines parties changent constamment et ces changements sont beaucoup plus petits que l'état lui-même. Nous avons reçu en moyenne 300 octets, soit 17 fois moins qu'à l'origine.

Pourquoi est-ce nécessaire si vous êtes déjà entré dans MTU? Le jeu est en constante évolution, de nouvelles fonctionnalités apparaissent, et avec elles apparaissent des objets, des entités, de nouveaux composants. La taille des données augmente. Si nous nous arrêtions à 1 Ko, nous reviendrions très bientôt au même problème. Maintenant, après l'avoir réécrit pour la compression delta, nous n'atteindrons pas cela très bientôt.

Maintenant, la partie la plus douce. Sync Si vous jouez à des tireurs, vous savez ce qu'est le décalage d'entrée - lorsque vous cliquez sur le bouton, et le personnage commence à se déplacer après un certain temps, par exemple, une demi-seconde. Pour certains jeux du genre mob, c'est normal. Mais dans le jeu de tir, vous voulez que le héros tire et fasse des dégâts juste là.



Pourquoi Input Lag se produit-il? Le client recueille l'entrée du joueur (entrée) et l'envoie au serveur de jeu (l'envoi prend du temps). Ensuite, le serveur de jeu le traite (à nouveau, le temps) et renvoie le résultat (à nouveau, le temps). C'est un retard. Comment l'enlever? Il y a une chose appelée prédiction - le client n'attend pas de réponse du serveur et commence immédiatement à essayer de faire la même chose que le serveur de jeu, c'est-à-dire feint. Prend l'entrée du joueur et démarre la simulation. Nous simulons uniquement un client local, car nous ne connaissons pas la contribution des autres joueurs - ils ne viennent pas à nous. Par conséquent, nous exécutons le système de simulation uniquement sur notre lecteur.

Tout d'abord, cela permet de réduire le temps de simulation. Le client démarre la simulation dès qu'il reçoit l'entrée et a plusieurs étapes d'avance par rapport au serveur de jeu. Disons que sur cette image, il simule le tick # 20. À ce stade, le serveur de jeu simule le tick # 15 dans le passé. Le client voit le reste du monde, encore une fois, dans le passé, lui-même - dans le futur. Pendant qu'il envoie le 20ème tick au serveur, alors que cette entrée atteint, le serveur de jeu commencera déjà à simuler le 18ème tick ou déjà le 20ème. Si le 18, il le met dans le tampon, atteint le 20, traite et renvoie le résultat.

Disons maintenant qu'il simule la tique n ° 15. Traitée, renvoie le résultat au client. Le client a une sorte de 15e tick, 15e état de jeu simulé et le monde du jeu qu'il a prédit. La comparaison avec le serveur commence. En fait, il ne compare pas le monde entier, mais seulement son client, car nous ne sommes pas responsables du reste du monde. Nous ne sommes responsables que de nous-mêmes. Si le joueur coïncide, tout va bien, ce qui signifie que nous avons correctement simulé, la physique a fonctionné correctement et aucune collision n'est survenue. Ensuite, nous continuons à simuler le 20ème tick, le 21ème et ainsi de suite.

Si le client / joueur ne correspond pas, cela signifie que nous nous sommes trompés quelque part. Exemple: la physique n'étant pas déterministe, elle n'a pas correctement calculé notre position ou quelque chose s'est produit. Peut-être juste un bug. Ensuite, le client prend l'état du serveur de jeu, car le serveur de jeu l'a déjà confirmé (il fait confiance au serveur - s'il ne faisait pas confiance, les joueurs tricheraient), et simulerait le reste du 15 au 20. Parce que cette branche temporelle est désormais erronée.

Créez une nouvelle branche horaire, c.-à-d. mondes parallèles. Nous resimulons ces cinq ticks en un seul tick. Une fois que notre simulation a pris 5 millisecondes, mais si nous devons simuler 10 ticks, c'est déjà 50 millisecondes et nous ne tombons pas dans nos 30 millisecondes. Ils ont optimisé et obtenu une milliseconde - maintenant 10 ticks sont traités en 10 millisecondes. Parce qu'il y a encore du rendu.

Toutes ces choses fonctionnent sur le client, et nous l'avons donné à la personne sans l'expérience nécessaire. Moins - nous avions un fakap, et plus - que le programmeur sait maintenant comment le faire correctement.



Ce schéma a ses propres caractéristiques. Le client sur la photo de gauche tente de traquer l'ennemi. Il est au 20ème tick, l'adversaire est au 15ème tick. Parce que ping et le client ont 5 ticks d'avance sur le serveur. Le client tire et doit frapper avec précision et causer des dommages, peut-être même un tir à la tête. Mais l'image est différente sur le serveur - lorsque le serveur commence à simuler le 20e tick, l'ennemi peut déjà se déplacer. Par exemple, si l'ennemi se déplaçait. En théorie, nous ne devrions pas obtenir. Mais si cela fonctionnait comme ça, personne ne jouerait aux tireurs en ligne en raison de ratés constants. Selon le ping, la probabilité de frapper a également changé: plus le ping est mauvais, pire vous obtenez. Par conséquent, ils le font différemment.

Le serveur prend et roule le monde entier dans le teck dans lequel le joueur a vu le monde. Le serveur sait quand il était, le ramène au 15ème tick et voit l'image de gauche. Il voit que le joueur devrait avoir touché et inflige des dégâts à son adversaire déjà dans le 20e tick. Tout va bien. Presque. Si l'ennemi s'est enfui et a couru derrière un obstacle, alors nous avons déjà tiré à la tête à travers le mur. Mais c'est un problème connu, les joueurs le savent et ne s'inquiètent pas. Donc ça marche, il n'y a rien à faire.



Ainsi, nous avons atteint 30 ticks par seconde, 30 images par seconde. Maintenant, environ 600 joueurs jouent sur notre serveur en même temps. Il y a 6 joueurs dans le match, soit environ 100 matchs. Nous n'avons pas de programmeur serveur, nous n'en avons pas besoin. Les clients écrivent toute la logique dans l'éditeur Unity, Rider, en C # et cela fonctionne sur un serveur de jeux. Presque toujours. Nous avons réduit la taille des paquets de 17 fois et réduit les allocations de mémoire de 80 fois - maintenant même moins d'un kilo-octet sur le client et le serveur. Le ping moyen était de 200 à 250 ms, maintenant il est de 150. 200 est la norme pour les jeux en réseau mobile, contrairement à un PC, où tout se passe beaucoup plus rapidement, en particulier sur un réseau local.



Nous prévoyons d'isoler ce qui est écrit dans un cadre distinct pour l'utiliser sur d'autres projets. Mais jusqu'à présent, il n'est pas question d'Open Source. Et ajoutez-y l'interpolation. Maintenant, nous avons 30 ticks par seconde, nous pouvons dessiner au fur et à mesure. Mais il y a des jeux où 20 ticks par seconde ou 10 suffisent. Par conséquent, si nous tirons 10 fois par seconde, les personnages se déplaceront par à-coups. Par conséquent, une interpolation est nécessaire. Nous avons écrit notre propre bibliothèque réseau au lieu de Photon - il n'y a pas d'allocations de mémoire là-bas.

Il y a encore des parties que vous ne pouvez pas écrire avec vos mains, mais générer du code. Par exemple, lorsque nous envoyons l'état du monde à un client, nous supprimons les données dont il n'a pas besoin. Pendant que nous le faisons avec nos mains et lorsqu'une nouvelle fonctionnalité apparaît, et que nous oublions de supprimer ces données, quelque chose ne va pas. En fait, cela peut être généré en marquant un attribut.

Questions du public

- Qu'utilisez-vous pour la génération de code? Votre propre décision?

- Tout est simple - les mains. Nous avons pensé à préparer quelque chose, mais il s'est avéré plus rapide d'écrire de nos propres mains. Suivez ce chemin, cela a bien fonctionné à l'époque et maintenant.

- Vous avez refusé le développeur du serveur, mais vous n'avez pas seulement réduit le temps de développement car le même code est réutilisé. Unity ne prend pas en charge la dernière version de C #, il a son propre moteur sous le capot. Vous ne pouvez pas utiliser .NET Core, vous ne pouvez pas utiliser les dernières fonctionnalités, certaines structures et plus encore. La performance n'en souffre-t-elle pas environ un tiers?

- Lorsque nous avons commencé à faire tout cela, nous pensions que pour utiliser non pas des classes, mais des structures, cela aurait dû fonctionner beaucoup plus rapidement. Nous avons écrit un prototype de l'apparence du code, de la façon dont les programmeurs utiliseront ces structures pour écrire la logique. Et c'était terriblement inconfortable. Nous nous sommes installés sur les classes et la performance que nous avons maintenant nous suffit.

- Comment vivez-vous maintenant sans interpolation? Et comment prétendez-vous être un joueur si l'instantané ne vient pas dans le bon cadre?

- Nous avons une interpolation, seulement elle n'est pas visuelle, mais sur les paquets qui arrivent sur le réseau. Disons que nous avons les 18e, 19e et 20e états.Le 18 est arrivé, le 20 est arrivé, et le 19 s'est perdu ou n'a pas encore atteint - nous l'interpolons ici. Utilisez simplement la génération de code afin de ne pas écrire le code d'interpolation.

- Y a-t-il d'autres astuces de vie pour compresser plus fortement les quaternions?

- J'ai parlé de 2D - il n'y a qu'un angle alpha, et sur les nouveaux projets, les quaternions ont aussi leurs propres problèmes. Des hacks de vie, je peux également dire ceci: puisque nous utilisons UDP pour que l'entrée ne soit pas perdue, nous l'envoyons par lots: de zéro à cinquième entrée, puis de première à sixième et ainsi de suite. C'est moins cher et l'expédition est meilleure.

"Mais l'ordre de reproduction des entrées sur le serveur joue un rôle?"

"Oui, bien sûr." - ( , , ), 2 : , .

— . ? ? 1000 , ? , ?

— , . , -, , . , 30 .

— , ?

- Bien sûr. , ( ), . — , , . - , , . , , , , . .

— ECS, , ? ?

— 30 , . 80 , . .

— prediction. 20- - , , - — , ? , . - ?

— : . (, 15-) 16-,17-,18- .

— ?

— , . , , . Entity ( ), . — , . ID , .

— - — , , , ? , ?

— , , . 3D , — , , - . , , . top-down, — . . , , , . .

— ?

— . Cela arrive aussi.

— , , - . - . - , , , 500 , , - - . ?

— .



, .. 20- 20- , . — , . : 20- , ? , . , — - . , . , « - , 21-, 18-». : «, - ». .

— .. , ?

— , .

— reliable UDP — - ?

— Photon, Photon reliable UDP, unreliable, c .

— ?

— , -. , . , . , . , . 100%, , 80%, .

— ?

— , , Photon , MTU.

— ? ?

— , , , . . , . , , , .

— , , ?

— , . , . , , . , - . , . , .

— / — - . , .

— , . , ( ), -, , -. , . — , .

— , - . ?

— , . : ECS, . , ECS . , ECS . , . , , , ( , , , , , ). 2D , , 3D — . 3D , , . . - , . , - -, .

— , ECS , . , , C#?

— — .

— .. ES ? , ECS — , , , . .. ECS — , .

— , , . , . — , , . , O - , , .

— , ECS- ?

— -, ECS , , ( ) — , . , — . — , , . , , , ..

Pixonic DevGAMM Talks

• Consul stateful- ( , DevOps BIT.GAMES);
• CICD: ( , Pixonic);
• - Quake Champions ( , backend- Saber Interactive);
• - - Tacticool ( , Lead Software Engineer PanzerDog);
• ECS, C# Job System SRP ( , Field Engineer Unity);
• KISS ( , Lead Game Programmer 1C Game Studios);
• Cucumber : BDD- ( , Technical Product Manager, ALICE Platform).