Comment RUST LTD a construit la simulation d'armes à feu approfondie pour Hot Dogs, Horseshoes & Hand Grenades 2

Créer Hot Dogs, Horseshoes & Hand Grenades 2 (H3VR2), un bac à sable de tir VR de physique autonome et un roguelike d'extraction, signifiait recommencer plutôt que de reporter une décennie de dette technique et de conception dans une suite.

Au lieu de porter le jeu original, RUST LTD a commencé avec un nouveau projet Unity et a passé près de six mois à se concentrer sur l'architecture et les outils avant de passer à la production de contenu complète.

Cette fondation prend en charge tout, des composants d'armes à feu et de balistique à la perception de l'ennemi, au rendu, au son et aux outils d'édition. Les données réelles alimentent bon nombre de ces systèmes, permettant des différences mécaniques d'émerger à travers la simulation plutôt que l'équipe ne les rédige comme des valeurs de jeu isolées.

Nous avons parlé avec Luke Noonan, cofondateur et responsable de la production chez RUST LTD, et Anton Hand, cofondateur et directeur du jeu, de la reconstruction du jeu à partir de zéro, de l'augmentation de la complexité de la simulation, de l'équilibre entre la fidélité physique et les performances en VR, et de la création des outils nécessaires pour gérer des centaines d'armes à feu mécaniquement distinctes.

Qu'est-ce qui a changé pour la suite – en termes de portée et d'ambition?

Luke Noonan: L'une des grandes choses que nous voulions faire avec le nouveau titre était de corriger une grande partie de la dette technique et de conception qui s'était accumulée.

Nous avons fait une réécriture complète pour H3VR2. C'était un nouveau projet Unity lorsque nous avons commencé. Nous avons examiné des morceaux du jeu existant et avons tiré cette expérience de là, mais ce n'était pas un portage. C'était une reconstruction.

AH: Techniquement, nous avons construit ce projet presque à l'opposé de la manière dont nous avons construit H3VR.

Avec H3VR2, nous avons passé près de six mois sur l'architecture et les outils purs avant de nous préoccuper de quoi que ce soit approchant la production de contenu complète. Nous savions comment construire les armes puisque nous l'avions déjà fait pendant 10 ans. Nous avions besoin de systèmes capables de s'adapter à un projet de contenu de cinq ou dix ans.

LN: Nous savions aussi dès le début que ce serait une équipe beaucoup plus grande. H3VR était largement Anton avec d'autres personnes soutenant différentes parties de la production. Avec H3VR2, nous sommes au-delà de 20 personnes.

Cela nécessitait de meilleures opérations de développement dès le départ : une bonne hygiène de Version Control, de l'automatisation de la construction (Build Automation), des outils d'édition personnalisés et des processus de production adaptés à une équipe répartie sur cinq fuseaux horaires différents.

Qu'implique le niveau de simulation en coulisses, et qu'avez-vous déterminé devoir faire correctement?

AH: Notre processus commence par une quantité obsessionnelle de recherche classique. Nous commençons par trouver du matériel de référence réel, y compris des livres et des documentations techniques réels.

D'un point de vue de simulation, notre principe de base est de construire un modèle où nous pouvons y injecter des données réelles et faire en sorte que le modèle converge vers quelque chose entre le réalisme familier reçu et quelque chose qui fonctionne pour le jeu.

Cela devient important au moment où vous construisez une simulation vraiment complexe avec un grand nombre d'entrées. Nous aurons finalement des centaines d'armes, des centaines de cartouches et des douzaines de matériaux.

Avec H3VR2, nous avons pu aller beaucoup plus loin. Nous pouvons demander si nous pouvons introduire des constantes de rappel réelles dans un système et découvrir que, oui, nous le pouvons. Pouvons-nous intégrer des dimensions réelles et des relations mécaniques dans le système de fonctionnement de l'arme à feu ? Oui.

LN: Nous payons un coût initial pour cette approche systématique, mais nous obtenons beaucoup d'avantages en aval. Si nous voulons ajouter un nouveau type de cartouche, par exemple, nous pouvons examiner des propriétés telles que la masse du projectile et les caractéristiques de la cartouche plutôt que d'inventer un chiffre de jeu magique.

Où se situe NVIDIA PhysX dans la pile, et pourquoi avez-vous décidé d'avoir des systèmes personnalisés au lieu, ou en complément, du moteur physique intégré?

AH: Nous utilisons une quantité assez limitée de la complexité disponible via NVIDIA PhysX.

Les moteurs de physique de jeux ne gèrent pas vraiment les petits composants à l'intérieur d'un référentiel local pendant que le joueur porte l'objet parent et le lance potentiellement à travers la pièce. Nous avons donc beaucoup de simulations internes très sur mesure pour les composants d'armes à feu qui existent effectivement dans leurs propres univers. Nous gérons la traduction des forces et des impulsions entre ces systèmes internes et l'espace de jeu plus vaste.

Au niveau de l'espace de jeu, nous utilisons la physique de manière beaucoup plus directe. Les Sosigs, nos personnages de hot-dogs, sont probablement notre plus grande utilisation de la physique. Ce sont des marionnettes de physique perpétuelles.

LN: À très petite échelle, pour la simulation de composants à l'intérieur des canons, nous avons construit des systèmes personnalisés. À l'autre bout, pour la balistique et une partie importante des systèmes d'agents, nous avons construit une autre couche en utilisant ECS pour Unity et Burst.

Comment avez-vous architecturé la simulation balistique en utilisant ECS pour Unity?

LN: Nous savions que nous devions avoir beaucoup d'armes à feu, que les armes peuvent tirer très rapidement, et que tous ces combats de fusils pouvaient se produire en même temps. Cela met beaucoup de pression sur les performances de la simulation, et nous avons dû faire des compromis à ce sujet dans le premier jeu.

L'utilisation d'ECS pour Unity et de Burst nous permet de faire apparaître d'énormes nombres d'Entités balistiques pour les armes à feu, les explosions et d'autres systèmes.

Cela nous a aidés à augmenter la fidélité plutôt qu'à simplement atteindre notre objectif initial. Nous pouvons effectuer un échantillonnage de sous-étapes plus petites pour une collision plus précise, modéliser la résistance de l'air plus précisément et gérer avec une fidélité plus élevée la pénétration et les projectiles se déplaçant dans et hors de différents matériaux.

Quels ont été les plus grands défis de performance créés par une simulation aussi profonde?

LN: Une grande partie de la période de développement précoce consistait à tester systématiquement ces domaines. Qu'est-ce qui est bon marché ? Qu'est-ce qui est cher ? Qu'est-ce que cette nouvelle plateforme peut ou ne peut pas faire ? Une fois que nous avions ces limites, il est devenu beaucoup plus facile de maintenir le temps de trame en ligne.

AH: Nous avons développé une compréhension très affinée de ce qui est rapide et de ce qui ne l'est pas pendant H3VR. C'est l'une des raisons pour lesquelles nous sommes restés en dehors de la VR autonome jusqu'à Quest 3.

Côté CPU, cela signifiait construire les systèmes de simulation de base autour d'ECS et de Burst. Côté rendu, nous savions que des modèles d'armes sophistiqués en 3D allaient consommer une part importante du budget de trame, donc tout le reste – le nombre total de polygones, la mémoire des textures, la bande passante, la structure de l'environnement – devait rester très léger.

Nous n'étions pas prêts à décimer ce pour quoi les gens viennent au match. Nous avons donc conçu les environnements, la densité d'interaction, la typologie de contenu et la structure des niveaux autour de ces contraintes dès le début.

L'optimisation n'était pas une voie parallèle qui est venue après un ensemble de décisions de conception inflexibles. Cela faisait partie du processus de gestation verticalement à travers tout le projet.

LN: L'installation utilise des niveaux assemblés par procédure que nous construisons à partir de kits modulaires, nous avons donc également validé très tôt comment le modèle d'éclairage fonctionnerait. Nous avons examiné comment nous pouvions utiliser des sondes lumineuses, des sondes de réflexion et le reste de la pile d'éclairage, puis nous avons remonté ces décisions jusqu'à la direction artistique elle-même.

Comment la mise à niveau vers Unity 6.3 a-t-elle bénéficié au projet?

AH: Passer à Unity 6.3 pour H3VR2 est essentiellement un saut d'une décennie par rapport à H3VR.

Il y a les améliorations évidentes de la qualité de vie, telles que nested prefabs, mais certaines des choses les plus percutantes pour nous ont été les performances du SRP Batcher, les améliorations de la compilation des shaders et le post-traitement par tuile.

La compilation des shaders a aidé à rendre ces grands shaders uber plus petits sur le disque. Le post-traitement sur tuile était particulièrement important pour notre approche visuelle. Je ne veux pas livrer un jeu sans mappage de tonalité, mais à l'origine, nous avons écrit notre passe de mappage de tonalité HDR directement dans nos shaders parce qu'un blit d'effet de post-traitement séparé n'était pas assez performant sur le matériel VR autonome. Avec un post-traitement sur le terrain, nous avons pu supprimer ce code.

LN: La stabilité et la fiabilité globales de la version actuelle d'Unity ont également été vraiment importantes. Nous faisons passer beaucoup d'outils personnalisés via l'Éditeur, et ce processus a été très fluide.

Chaque arme du jeu a son propre comportement mécanique. Comment rédiger et le maintenir axé sur les données, et comment maintenir une liste aussi grande ?

AH: Garder quelque chose maintenable est une lutte constante. Le volume de documents Google que nous avons pour tout est assez fou, bien que les actifs eux-mêmes deviennent finalement la source unique de vérité sur la manière dont nous configurons ces armes à feu.

Cela revient à avoir des outils d'inspection très puissants. Ces outils ne servent pas simplement à entrer des informations. Nous avons des outils d'édition axés sur le calcul, des outils de validation et des outils d'analyse que nous avons construits spécifiquement pour les armes à feu.

La simulation est assez poussée que je décrirais une grande partie du travail comme étant plus proche de l'armurerie réelle. Nous entrons des choses telles que les constantes de ressort et les masses des composants. Les cartouches possèdent des données de courbe de pression et des informations décrivant les différents composants de la cartouche.

Si ces valeurs sont incorrectes, l'arme à feu dans la simulation ne fonctionne pas correctement.

Comment Odin Inspector et l'Asset Store ont-ils aidé votre équipe à gérer la complexité du développement et de la maintenance du jeu?

AH: Si je devais identifier la proposition de valeur centrale d'Unity pour un jeu comme le nôtre, ce serait l'extensibilité de l'Éditeur.

Nous utilisons Odin Inspector intensivement, et je ne pense pas que ce projet soit réalisable de la même manière sans lui.

Tous ceux qui ont écrit du code pour le jeu ont écrit des inspecteurs personnalisés. Odin minimise drastiquement la quantité de travail impliquée parce qu'il vous donne un raccourci incroyablement puissant pour construire ces outils.

C'est particulièrement important lorsque vous traitez de quelque chose d'aussi complexe ontologiquement et taxonomiquement qu'une arme à feu. Pour n'importe quelle arme individuelle, peut-être 95 % ou 98 % de tout ce que le système de base pourrait théoriquement configurer est sans importance pour cet objet particulier. Odin nous permet de supprimer ces options sans rapport.

Technie Collider Creator 2 de Triangular Pixels dans l'Asset Store a également changé la donne. Cela a fait gagner des centaines, voire des milliers d'heures à l'équipe au cours de la production.

Pour un jeu VR axé sur la physique, la création de coques physiques nécessite une combinaison maladroite de travail manuel et d'automatisation. Une solution entièrement automatisée n'est généralement pas appropriée. Vous voulez utiliser autant que possible des primitives physiques et ensuite des maillages convexes uniquement là où vous en avez absolument besoin.

Quel est votre meilleur conseil pour les développeurs souhaitant créer un jeu de simulation techniquement complexe?

AH: Validez ce dont vous avez besoin assez tôt. Il y a une très grande différence entre construire des systèmes de simulation parce que vous aimez le processus de construction de systèmes de simulation et construire des systèmes de simulation dont votre jeu a besoin.

Si je regarde en arrière sur H3VR, il y a des travaux de simulation que j'ai écrits qui n'étaient pas lisibles pour le joueur. L'utilisateur final n'en a pas vraiment ressenti la présence. Cela n'a pas facilité ma vie, dans certains cas, cela a rendu ma vie plus difficile en tant que développeur et designer, et cela n'a pas abouti à un gameplay plus gratifiant.

C'est le risque avec n'importe quel jeu de simulation complexe. Vous pouvez finir par faire un travail qui ne bénéficie à personne, sauf peut-être à votre propre expérience de le faire, tout en vous éloignant de l'objectif macro du projet.

LN: Je pointerais également du doigt les gens. Nous avons énormément bénéficié de trouver les bons experts pour l'équipe : un expert solide qui est également très compétent en matière d'armes à feu, des artistes d'armes qui comprennent le sujet et les besoins de la VR, et des ingénieurs intéressés par les types de systèmes que nous construisons.

Hot Dogs, Horseshoes & Hand Grenades 2 peut être précommandé maintenant pour Quest 3. La version Steam peut être mise sur liste de souhaits maintenant avant son lancement en 2027. Consultez plus d'histoires de développeurs sur le Blog Unity et le Unity Resource Hub.