Il y a quelques années, notre équipe a eu l'honneur de créer un «Almaty» mobile. En respectant les règles «nous créons un jeu, pas une technologie» , nous avons créé un prototype sur ce qui est déjà dans le moteur. C'était UE 4.9, basé sur le modèle physique - Véhicules PhysX, et beaucoup de douleur (avec et sans).

De plus, notre équipe a créé le plugin open source PsRealVehicle , disponible sous la licence MIT . Ce plugin est réglé pour la physique des chars et des véhicules à roues pour les tireurs de réseau très chargés, et vous pouvez regarder son travail à tout moment dans notre projet Armored Warfare: Assault .

Noms, apparences, mots de passe.

De toute évidence. Je vois. Et seulement pour affaires.

Référentiel de plugins

Documentation de configuration principale

Utilisé dans le projet: Armored Warfare: Assault

Un peu d'histoire ou Retour aux sources

Nous avons commencé à travailler sur le projet sur Unreal Engine 4.9 . À cette époque, la physique des machines «prête à l'emploi» ne supportait que les véhicules à quatre roues, et pour les «bancs» à six roues (LAV-400, notre premier prototype de véhicule de «combat»), nous devions utiliser immédiatement le moteur personnalisé. Avec la physique intégrée des réservoirs, c'était encore pire: les données sur la façon dont tout fonctionnait et était configuré, devaient être petit à petit pour sortir du code.

En suivant la règle "prototype" , nous avons formulé les exigences suivantes pour nous-mêmes:

• La physique devrait simuler le mouvement d'un char (programme minimum) et de véhicules à roues (hautement souhaitable - c'est une caractéristique de la série de jeux AW).
• Un serveur dédié doit supporter jusqu'à 20 machines par session en ligne et le client doit les gérer.
• Toutes les roues et chenilles doivent suivre les irrégularités de la surface, la suspension doit fonctionner et le réservoir doit pivoter.
• Le réglage physique doit être déterminé par des valeurs réelles (masse de la machine, puissance du moteur) et conduire à un comportement réaliste (la capacité de surmonter certains types de terrain).
• Moins nous écrivons de code technique, mieux c'est: Epic Games devrait faire le moteur, pas nous .

Donc, les exigences sont à peu près claires, passez aux choses sérieuses. Assez rapidement, nous avons assemblé le premier prototype, les chars sont partis, les voitures ont roulé, mais nous avons eu deux problèmes:

1. Tout cela dévorait très vigoureusement le processeur.
2. L'image du monde créée ne voulait pas s'inscrire dans le cadre d'un comportement réaliste des équipements lourds. Le réservoir de trente tonnes dans tous les paramètres ne pouvait pas prendre une augmentation de 15 degrés (et c'est l'une des options les plus faciles). Nous avons passé beaucoup de temps à bricoler les paramètres de simulation et de frottement du paysage, mais cela a conduit soit à tirer la puissance vers les valeurs cosmiques (20+ fois plus que les valeurs réelles, et en conséquence, les voitures se sont comportées de manière instable et imprévisible), ou vers des masses d'équipement jouets (PhysX fonctionne très bien avec une masse de véhicule de l'ordre d'une tonne et demie).

Les concepteurs de jeux en étaient loin d'être enthousiastes. Les programmeurs ont pleuré, piqué, mais ont continué à manger un cactus (la fête nécessite une solution de travail!). Le prototype a été approuvé par la direction et envoyé pour créer une version alpha (à propos, la vidéo du prototype est sur Youtube . Mais le temps a passé et les espoirs d'un avenir meilleur pour une telle physique sont devenus de moins en moins. Les réglages n'étaient pas suffisants, leur comportement ressemblait à de la magie noire. Et la position Le «jeu, pas la technologie» s'est lié les mains à sa manière, du moins avec des doutes quant à savoir si nous pouvions le retirer.

Armé tranquillement de Wikipédia, de connaissances scolaires résiduelles et d'une expérience de travail sur la physique «sur des pontons» à la Assassin's Creed, j'ai créé en quelques jours un prototype de la nouvelle physique de réservoir, qui a constitué la base du plugin PsRealVehicle. En une semaine, la preuve de concept a été mise sur pied, les équipes CTO ont été montrées et protégées par des tests de charge. Les chiffres disaient: être votre physique.

...-..., et en production

Le chemin du prototype à la vente est beaucoup plus long. Si une semaine était suffisante pour une vérification conceptuelle, cela a pris un mois et demi pour une version bêta adéquate . La création d'une version «prod» à part entière a pris environ six mois, un raffinement et une correction constants - tout au long du travail sur le projet. À bien des égards, nous devons une telle vitesse au développement et à la mise en œuvre de la physique dans le projet au concepteur de jeux techniques Igor, qui est venu à notre équipe à l'époque, dont la minutie dans les aspects du modèle mathématique et sa perception subjective par les joueurs ont conduit au résultat actuel. Je dois admettre, dans un sens technologique, que je suis un barbare : c'est mon travail de fabriquer une hache pour abattre une forêt. Après le traitement par Igor et le réglage fin du modèle avec d'autres gars, nous avons obtenu une solution ouverte prête pour la production, évolutive et hautement optimisée pour les besoins du multijoueur . Il y a de quoi être fier: des nombreux plug-ins disponibles sur le marché (y compris les véhicules PhysX intégrés), notre configuration la plus rapide et la plus transparente.

Au fait, il y avait des cas amusants. Alors que nous travaillions avec le véhicule PhysX et que nos véhicules à plusieurs roues extrêmement glissants ne pouvaient pas gravir de petites collines, j'ai entendu des reproches plus d'une fois, disent-ils, notre équipe ne peut pas le configurer pour que les gens l'aient. La décision d'utiliser son plugin a été prise, notamment sous l'influence de ce cadre:

Le dernier développement de l'armée soviétique! Un réservoir d'araignée qui peut escalader des murs à 89 degrés . Il n'y avait tout simplement rien à couvrir: D

Caractéristiques de notre solution

Avant de passer à la description de la configuration des chars et des véhicules dans PsRealVehicle comme exemple de notre AW: Assault, je voudrais mentionner quelques éléments qui ont constitué la base du modèle physique utilisé.

Premièrement, nous adhérons clairement au fait que nous ne faisons pas un simulateur de physique de char, mais un jeu suffisamment arcade. C'est triste, mais peu de gens ont besoin d'un vrai tank dans leur comportement - ce n'est cool que sur les vidéos de présentation, et pas en contrôle, et plus encore dans un jeu de tir. Le joueur a besoin d'un tank qui se comporte comme un tank dans le sens où d'autres blockbusters ont déjà créé. Et pour travailler sur un appareil ordinaire, et non sur un Titan.

Le premier point a une conséquence: certaines choses dans le jeu fonctionnent très fausses. Si quelque chose ressemble à un char et se comporte comme un char, alors c'est un char , et peu importe que ce soit à l'intérieur une petite frégate, ou que cette partie de la physique soit configurée avec une magie de friction conditionnelle. L'une de ces conventions est de contrôler la rotation de la machine en modifiant la vitesse angulaire, et non par les forces appliquées aux roues et à la suspension. Classiquement, le tank tourne de X degrés par seconde, car nous l'avons décidé sur la base de considérations de gameplay, et non pas parce que ses pistes tournent à telle ou telle vitesse.

Soit dit en passant, cela ne nie pas le fait que «sous le capot», vous pouvez activer la physique «réelle» de la rotation, elle a été utilisée dans les premiers prototypes . Dans le bon sens, il vaut la peine de fixer le travail de la suspension angulaire, la base de la roue et ainsi de suite. Si nous commençons à faire des simulations de course, nous y reviendrons certainement, mais pour l'instant, c'est l'un des éléments de la liste des améliorations probables.

Structure du char dans AW: Assaut

Hiérarchie des classes

AAwmVehicle est la principale classe C ++ responsable de la machine dans le jeu, divisée en de nombreux composants (mouvement - UPsRealVehicleMovementComponent , sons, VFX, statistiques, armure et autres). Le BP_DefaultVehicle hérité, qui est une couche supplémentaire pour les paramètres par défaut pour toutes les machines. Tous les autres sont des plans privés de paramètres pour chaque pièce d'équipement du jeu.

Chaque machine est un ensemble de ces données:

• Blueprint, où tous les actifs externes sont enregistrés, les sons, les propriétés à la «véhicules à roues / à chenilles» sont définis et la physique est mise en place.
• Un squelette maillé et des actifs qui lui sont liés:
  - Atout physique (il n'y a pas de magie, tout est standard).
  - Arbre animé.
• Textures (diffuses, carte normale, RMM).
• Matériel d'instance (coque, chenilles + état brisé).
• Un ensemble de mailles d'armure pour le système de pénétration.
• Caméras, vérificateurs de niveau d'eau et autres collisions auxiliaires.

Animation de réservoir

La configuration d'un réservoir est une bagatelle, quelle que soit la complexité de l'arbre d'animation. Configurer des dizaines de ces réservoirs et les tenir à jour lors du changement d'os, de maillage, etc. est une quantité complètement inadéquate pour le travail manuel . Heureusement, dans notre cas, nous parlons d'un «personnage» assez standardisé: un char peut être disséqué en entités et les appeler stéréotypées. Il s'agit bien sûr de nommer les os.

Cette approche nous a permis d'utiliser essentiellement le même arbre d'animation, que les saints Ctrl + C / Ctrl + V multiplient par n'importe quel nombre de réservoirs et ne nécessitent aucun support, sauf le contrôle qualité initial.

Toute magie se produit à l'intérieur de noeuds sipy personnalisés. Cela a permis non seulement de normaliser l'arbre, mais aussi de réduire considérablement le nombre de calculs par animation (les nœuds standard aiment conduire les systèmes de coordonnées dans les deux sens).

Matériaux du réservoir

Pour toutes les parties du réservoir, un matériau maître est utilisé , personnalisé par une paire de nœuds Switch.

Ensuite, nous obtenons un arbre comme celui-ci:

  - M_Vehicles
  - - MI_Vehicles_Clean_Body
  - - - MI_Leopard2
  - - - - MI_Leopard2_LOD
  - - MI_Vehicles_Clean_Treads (coché "Treads")
  - - - MI_Leopard2_Treads
  - - - - MI_Leopard2_Treads_LOD 

Le véritable «poids» ici n'est que M_Vehicles et MI_Vehicles_Clean_Treads , toutes les autres instances ne sont que des ensembles de paramètres et consomment un minimum de mémoire et d'espace disque.

En général, l'ensemble des ressources graphiques pour le tank est très standard pour n'importe quel jeu.

Travail d'armure

Plusieurs fois lors de la communication avec des collègues, la question s'est posée, pourquoi chaque pièce d'armure avait-elle un maillage séparé, et pourquoi n'utilisons-nous pas le système de collisions Anrilov?

En fait, nous utilisons les collisions habituelles d'Anrilov, mais uniquement pour «attraper» la balle . Une fois que le projectile s'est enfoncé dans le réservoir, les dégâts sont calculés polygonalement sur toutes les feuilles d'armure, en tenant compte des propriétés de chaque pièce, multicouches, de la réflexion du projectile, de l'entonnoir cumulatif et d'autres mécanismes intéressants.

Le plus pratique dans ce cas est de lire les données de maillage «nues», que nous ne supprimons pas pour un serveur dédié.

Réseau et optimisation supplémentaire

Quelques points «proches du char» que je voudrais également mentionner brièvement.

• Tous les mouvements de réservoirs sont effectués uniquement sur le serveur , les clients interpolent uniquement les valeurs reçues. Aucune extrapolation n'est utilisée. La fréquence de synchronisation est de 10 fois par seconde .

  
  

• En fonction de la taille d'écran du tank, nous sautons l'un ou l'autre nombre de ticks du maillage squelette, qui comprend un calcul de toutes les animations et de certaines interactions physiques. Si le tank n'est pas visible à l'écran, c'est une stupide boîte non animée flottant dans l'espace . L'optimisation du taux de mise à jour intégrée, malgré une bonne idée, a une implémentation très grossière qui ne donne pas une augmentation tangible des performances. Surtout quand il s'agit de téléphones portables.

  
  

• Pour tous les réservoirs, à l'exception du sien, tous les composants, à l'exception des plus basiques, sont coupés par le client: caméras, contrôleurs et autres éléments qui composent le réservoir. En fait, ils n'ont que l'apparence .

  
  

• Un réservoir LOD1 dédié fonctionne sur un serveur dédié. Moins de pics - moins d'utilisation du processeur. De plus, la mise à jour de la position des pièces d'armure personnalisées ne se produit qu'au moment où le projectile frappe: cela n'a aucun sens de mettre à jour l'état des pièces à chaque tick.

Moi, moi-même & Tanks

Chez Pushkin Studio, nous pensons que l'échange d'expériences de développement est très important, y compris pour la croissance du niveau professionnel au sein de l'équipe. Les projets Open Source sont une composante importante de cette approche, et je suis heureux de pouvoir présenter à la communauté des technologies telles que PsRealVehicle .

À mon avis, il est très important que nous utilisions nous-mêmes tous les plugins et utilitaires publiés quotidiennement. Après tout, le chemin clairement démontré par Epic Games eux-mêmes est que le succès d'une bonne technologie est de l'utiliser par les développeurs eux-mêmes dans leurs propres produits. Maintenant, nous travaillons déjà sur la version UE 4.20 , notre plugin a fait tout ce chemin avec nous, et nous n'allons pas nous arrêter!