Comment Hologryph a construit SAND: Raiders of Sophie pour une cadence live ops durable

Pour Hologryph, SABLE en développement : Raiders of Sophie signifiait transformer une friche désertique datant de 1910 en un jeu d'extraction qui pourrait continuer à grandir longtemps après le lancement. L'équipage des joueurs et les pilotes de Tramplers - de gigantesques machines de marche qui servent à la fois de base, de coffre-fort de butin et d'arme - les chevauchent ensuite à travers un monde ouvert généré par la procédure à la recherche de récupération, et les uns des autres.

Offrir cette expérience exigeait une division stricte du serveur et du client faisant autorité, une génération de monde procédural qui s'exécute de façon identique des deux côtés, la synchronisation des centaines d'Entities qui composent un seul Trampler, et un streaming mondial suffisamment fluide pour vendre le sentiment d'en monter un. L'équipe avait également besoin d'un pipeline de contenu suffisamment rapide pour expédier de nouveaux compartiments, armes, effets et environnements saisonniers avec une cadence régulière sans déstabiliser les performances.

Nous avons discuté avec Serhiy Grinets, directeur technique et directeur du jeu chez Hologryph, de l'architecture du jeu sur le long terme, du maintien du pipeline de contenu, et de ce qu'il faut pour gérer des opérations en direct sur un jeu aussi ambitieux techniquement.

À quoi ressemble votre modèle d'opérations en direct, et que donne une mise à jour typique ?

Serhiy Grinets: Notre modèle d'opérations en direct pour SAND se concentre sur le maintien de l'évolution du jeu avec notre communauté passionnée. Notre priorité est de maintenir une cadence régulière de mises à jour qui combinent nouveau contenu, améliorations du gameplay, équilibrage, corrections de bugs et changements de qualité de vie. Notre objectif ultime est de construire un modèle d'opérations en direct durable qui soutienne le titre à long terme.

Quels étaient vos objectifs techniques fondamentaux et comment ont-ils façonné votre approche pour construire un jeu conçu pour vivre et évoluer à long terme ?

Nous avions trois grands objectifs:

• Une séparation stricte entre un serveur faisant autorité et un client, avec une génération de monde procédural qui s'exécute identiquement des deux côtés.
• Synchronisation d'un grand nombre d'Entities - un seul Trampler est composé de centaines d'entre elles.
• Smooth world streaming – le monde est vraiment grand, et pour vendre la sensation de monter sur un Trampler, vous avez besoin d’un endroit pour rouler.

Les trépieds sont au cœur de l’identité du jeu. Comment avez-vous construit le système de personnalisation pour pouvoir expédier de nouvelles pièces, cosmétiques et variantes en tant que contenu live ops continu ?

Tout le système est construit autour de compartiments. Un compartiment est une section d’un piétinement – un pont, une cabine, un cadre de soutien, une salle d’équipement – et chaque compartiment est conçu pour s’emboîter les uns dans les autres.

Les joueurs assemblent leur Piétineur à partir de ces blocs: Ils choisissent la disposition, empilent les decks, placent l’équipement et se retrouvent avec une machine qui leur appartient vraiment – leur base, leur coffre et leur arme en même temps.

Pour nous, en tant que développeurs, c'est aussi le pipeline de contenu. Pour ajouter un nouveau compartiment, nous le modélisons et le configurons sans code. Il se branche sur le système de construction comme tout autre bloc, et les joueurs peuvent immédiatement l'utiliser dans leurs conceptions. Un programmeur n’intervient que lorsqu’une pièce a besoin d’une nouvelle mécanique, et même dans ce cas, il s’agit d’un petit travail isolé.

C’est ce qui fait que les compartiments perfectionnent le contenu live ops : Chaque nouveau modèle multiplie le nombre de constructions possibles de Trampler, et elles sont peu coûteuses à produire pour nous.

A quoi ressemble l'architecture sous le système de compartiments, et comment vous permet-il de prototyper rapidement de nouvelles mécaniques ?

Nous utilisons une approche modulaire qui nous permet d'itérer sur des prototypes rapidement. Sous le capot, nous avons une inversion personnalisée du conteneur de contrôle pour brancher de nouvelles fonctionnalités, et il s'adapte très bien à notre système de composants d'entité (ECS). En plus de cela, notre moteur de réseau personnalisé signifie que nous n'avons presque jamais à penser au réseau lors de la construction de nouvelles mécaniques. La réplication est gérée une couche en dessous du code de gameplay.

Comment le compilateur C# Job System et Burst d’Unity vous a-t-il donné la marge de manœuvre nécessaire pour continuer à ajouter du contenu live sans régressions ?

Notre simulation s'exécute sur notre propre version modifiée d'Entitas, un framework ECS open source, plutôt que sur Unity Entities, mais le système de travail C# et le compilateur Burst sont critiques pour nos chemins chauds. La génération de terrain procédural, y compris les travaux d'échantillonnage de cartes en hauteur et de biomes, les mathématiques du mouvement des piétineurs et notre abattage personnalisé des occlusions, s'exécutent sous forme de chaînes de travaux compilées par Burst. Ce travail reste en dehors du fil conducteur, donc un monde plus dense ne nous coûte pas de cadres.

Quel rôle a joué VFX Graph en permettant à votre équipe d'itérer rapidement sur les effets pour les événements en direct, les moments saisonniers ou les étapes de réalisation ?

Tous nos effets - poussière de sable, fumée, boucliers, effets d'armes - sont construits sur VFX Graph, mais le point clé est la façon dont nous l'utilisons. En plus de cela, nous construisons des systèmes d'effet configurables, comme le flash initial ou l'impact de balle, qui existent sous la forme d'un graphique flexible avec un grand ensemble de paramètres exposés, y compris la taille, la couleur, le moment, les débris et la fumée.

Ainsi, quand une nouvelle arme arrive, un artiste se contente de régler ces paramètres et obtient un effet unique – il n’y a pas d’artiste technique impliqué ou de nouveau graphique construit à partir de zéro. Le temps des artistes technologiques va à rendre ces systèmes plus riches au lieu de fabriquer à la main chaque effet pour cette arme.

C’est ce qui permet de maintenir la production assez rapide pour une cadence de contenu constante. Les nouvelles armes et événements obtiennent des effets de qualité au prix de la configuration, pas du développement.

Comment l'Unity Profiler a-t-il façonné votre flux de travail d'optimisation à mesure que votre pipeline de contenu ops en direct montait en puissance ?

Nous mesurons régulièrement les performances tant sur le client que sur le serveur pour trouver et optimiser les points faibles. La ventilation par système dans l'Unity Profiler montre exactement où va le temps, ce qui rend notre ECS très pratique à profiler.

Nous avons également des tests automatisés qui mesurent la performance dans des scénarios fixes, de sorte que nous voyons la tendance tous les jours et pouvons réagir aux changements immédiatement.

Comment utilisez-vous Addressables pour pousser les mises à jour de contenu en direct, les correctifs et les baisses saisonnières sans nécessiter une mise à jour complète du client ?

Addressables sont la colonne vertébrale de notre gestion de la mémoire. Le monde est diffusé: Alors que les joueurs traversent le désert, le contenu se charge et se décharge constamment derrière eux. Tout cela passe par Addressables, donc la mémoire reste à plat quelle que soit la distance parcourue par les joueurs.

Un deuxième rôle, moins évident, est que nous avons deux projets distincts, le projet client principal et le projet serveur, et nous avons construit une solution personnalisée qui transfère les actifs de l'un à l'autre. Cela permet de maintenir la cohérence des deux environnements: Le serveur voit les mêmes données que le client, construites via le même pipeline, donc les bugs de contenu « fonctionne sur le client, cassé sur le serveur » sont structurellement impossibles au lieu de quelque chose que nous devons tester.

Y a-t-il des outils Asset Store qui vous ont aidé à construire ou à maintenir votre pipeline d’opérations en direct plus rapidement ?

Depuis l'Unity Asset Store, GPU Instancer Pro restitue toute notre dispersion dans le désert, indispensable au monde ouvert, et Amplify Impostors gère les objets distants. Odin Inspector alimente notre outillage de conception, qui est essentiel pour un pipeline de contenu basé sur les données, et Rewired gère la saisie sur PC et consoles. Easy Save, DOTween et I2 Localization nous ont tous fait gagner du temps réel.

Comment Cinemachine a-t-il pris en compte la capture de moments partageables et dignes d’intérêt – batailles de mechs, grandes pièces de théâtre – qui alimentent votre stratégie de contenu ?

Notre utilisation de Cinemachine est volontairement simple. Il gère nos caméras et bascule entre elles – la caméra de gameplay, le hangar et la vue du spectateur. Nous ne faisons pas de mise en scène supplémentaire ou de cinématographie scénarisée en plus, et c’est un choix conscient. SABLE : Raiders of Sophie est un jeu à la première personne, très compétitif, et le travail de la caméra est d’être fiable, pas artistique.

La qualité cinématographique vient du jeu lui-même. Lorsque deux gigantesques forteresses ambulantes échangent des obus de canon, et que vous êtes sur le pont de l’une d’elles en train de recharger un canon, aucun travail de caméra scénarisé ne peut battre cela. L'épicité de la simulation est la cinématographie. Cinemachine veille à ce que la caméra ne gêne jamais.

Vous avez construit une configuration double canal Vivox - chat d'équipe plus chat de proximité spatiale. Qu'est-ce qui a permis de concevoir et de mettre en œuvre cela?

Chaque joueur est dans deux canaux Vivox à la fois: le canal régulier de l"équipe, qui est la "radio" où votre équipe vous entend toujours, et un canal positionnel via la voix de proximité 3D, afin que vous entendiez les joueurs à proximité d'autres équipes dans le monde.

Le canal positionnel utilise les propriétés Vivox 3D – range, falloff, fade model – réglées dans une configuration. Notre ECS repousse les positions des haut-parleurs et des auditeurs vers Vivox à une cadence plafonnée, seulement environ 20 fois par seconde et seulement lorsque le lecteur a bougé. L'Authentication passe par notre propre service de jetons backend.

Au-delà de la voix, comment Vivox a-t-il pris en compte votre stratégie globale d'opérations en direct, et comment a-t-il contribué à stimuler l'engagement social et la rétention ?

La voix de proximité est une fonctionnalité de gameplay pour nous, pas seulement pour la communication. Les jeux d'extraction vivent sur des moments sociaux émergents, où les équipes se réunissant dans le désert peuvent parler, négocier, faire équipe ou se trahir, et entendre la voix réelle d'un étranger à proximité crée une tension qu'aucun système scripté ne peut créer. La radio de l'équipage assure la coordination des équipes.

Quelle est votre meilleure astuce pour les développeurs qui cherchent à construire un jeu basé sur les opérations en direct ?

Développer un jeu d'opérations en direct est un parcours difficile, alors assurez-vous que votre équipe a la résilience nécessaire pour le mener à bien et que vous avez des partenaires et des outils fiables à vos côtés. Restez proche de votre communauté – écoutez vos joueurs, apprenez de leurs commentaires et laissez-les contribuer à façonner l’évolution du jeu au fil du temps.

Pour en savoir plus sur les projets Made with Unity, visitez la page Ressources .