Mise à l'échelle des workflows Unity : Leçons tirées de projets de taille moyenne à grande

Cet article de blog est le premier d'une série de Mega Cat Studios, dans laquelle ils partagent leur expertise Unity et leurs solutions pour les défis de développement de jeux commerciaux réels. Découvrez les autres articles de cette série qui couvrent l'Input System ainsi que la conception de niveaux et d'environnements :

• Faire un sans-faute : Comment l'Input System piloté par les événements d'Unity alimente les commandes dans Backyard Baseball 2026
• Comment réimaginer un jeu de sport classique pour une nouvelle génération avec le level design, le worldbuilding et les VFX

Nous espérons que vous récolterez de bons conseils !

Vous avez une idée géniale, et le code défile aussi vite que vous pouvez le taper. À chaque commit, une nouvelle fonctionnalité prend forme. Mais c'est la vitesse même à laquelle vos idées se forment qui pourrait bientôt vous conduire à vous retrouver face à un gros désordre rempli de bugs.

Chez Mega Cat Studios, nous commençons tous nos projets avec passion, nous comprenons donc l'attrait de travailler rapidement et sans contrainte, et de terminer les choses le plus tôt possible. Pour un prototype, cette approche convient, et en fait, nous la recommandons ! Un développeur avisé sait quand privilégier la vitesse d'itération et quand privilégier la stabilité. Car lorsque vous quittez la phase de prototypage, cette approche « rapide et sans contrainte » devient un handicap.

Nous avons survécu à cette transition à maintes reprises chez Mega Cat Studios, et à chaque projet, nous apprenons quelque chose de nouveau. Nous aimerions partager certaines des leçons que nous avons apprises pour préparer notre projet le plus récent, Backyard Baseball, au lancement.

Leçon 1 : Structurer pour passer à l'échelle

Les problèmes de mise à l'échelle sont rarement causés par un mauvais code ; ils surviennent plutôt le plus souvent en raison d'une architecture non planifiée. Si un développeur ou un artiste ne peut pas trouver un asset en 10 secondes, le flux de travail doit changer. Voici quelques conseils pour configurer votre projet afin qu'il puisse évoluer :

• Organisez par type et par objectif : Nous regroupons par type, puis par objectif. Le type inclut des catégories comme l'art, le code et l'audio. L'objectif correspond à ce à quoi ils servent. Une organisation intuitive réduit les difficultés d'intégration ; un nouvel artiste doit savoir exactement où se trouve un sprite « Character Idle » sans avoir à demander.
• Gardez les scènes simples : Nous avons abandonné la « méga-scène » et optons plutôt pour des scènes plus petites, comme une scène principale qui contient les données de sauvegarde et les systèmes critiques, ainsi qu'un écran titre et des scènes de terrain de baseball qui se chargent de manière additive selon que le joueur est en plein match. De même, nous utilisons des prefabs pour les fonctionnalités autonomes, de sorte que les modifications sont moins susceptibles d'être sérialisées dans le fichier de scène qui les contient. Cela permet à un artiste de travailler sur l'environnement pendant qu'un concepteur ajuste le gameplay dans le même « niveau » sans conflits de fichiers (plus de détails à ce sujet plus tard).
• Configurez le système Addressables : Au lieu des dossiers Resources traditionnels, nous utilisons le système Addressables pour charger les ressources uniquement lorsque nécessaire, ce qui permet de limiter l'utilisation de la mémoire. De plus, charger une ressource avec sa clé Addressable est plus clair et moins susceptible de provoquer des erreurs que le chargement via un chemin d'accès à un emplacement spécifique dans le dossier Resources.

Le plus difficile n'est pas de comprendre ces bonnes pratiques. C'est de s'y engager dès le début et de maintenir cette discipline, même des années plus tard.

Sachez dans quelle phase de développement vous vous trouvez et ce que vous privilégiez à ce stade.

« Dans la phase de prototypage, comme il n'y a pratiquement pas de code, il est acceptable de rendre le projet fonctionnel avant de le rendre modulaire », explique Paolo Roxas, développeur sur Backyard Baseball. « Nous voulons voir comment le projet se déroule avant de le rendre plus complexe. »

Leçon 2 : Travaillez avec Unity, pas contre lui

« Il n'y a rien de plus puissant que de créer des blocs de construction – qu'il s'agisse de composants, de ScriptableObjects ou de classes personnalisées – qui sont ciblés, concis et autonomes », déclare David Chávez Armenteros, responsable de l'ingénierie chez Mega Cat Studios. Unity adopte la modularité au cœur de son fonctionnement. Pour rester flexible, nous suivons trois principes classiques :

1. Responsabilité unique : Chaque script ou classe doit avoir un rôle bien défini.

2. Faible couplage : Les systèmes doivent interagir via des interfaces ou des événements plutôt que par des références directes, et uniquement lorsque cela est approprié. Nous recommandons de cartographier les dépendances entre les systèmes avant de les implémenter dans le code pour éviter une architecture cyclique ou enchevêtrée.

3. Plug and play : Combinez de petites unités ciblées pour créer un comportement complexe plutôt que d'écrire des scripts « dieu » tentaculaires.

Leçon 3 : Utilisez les limitations pour vous libérer

Les Assembly Definitions (AsmDefs) sont des constructions C# qui regroupent votre code. Leur avantage annoncé est la réduction des temps de compilation, mais leur super-pouvoir secret est d'imposer la modularité.

Nico Gaudenzi, développeur principal et ennemi du code spaghetti, ne jure que par eux.

« Dans Backyard Baseball, la couche Input System et la couche Gameplay sont dans des DLL différentes. » Le gameplay est totalement agnostique aux détails de l'Input System. »

Cela sauve les ingénieurs d'eux-mêmes en faisant de chaque dépendance une décision calculée. Si nous devions vraiment le faire, nous pourrions réécrire l'intégralité de l'Input System – de la gestion de la manette au Netcode – sans risquer de casser la physique des joueurs ou le comportement de l'IA. Plus probablement, cela permet à un ingénieur de travailler dans un domaine unique de la base de code sans provoquer accidentellement des changements en cascade dans un autre système, et réduit la quantité de code qu'un développeur doit garder à l'esprit pour les implémentations de fonctionnalités et les corrections de bugs.

Leçon 4 : Testez plus intelligemment, pas plus durement

À mesure que les projets grandissent, « l'effet domino » peut prendre le dessus : Un petit changement ici casse quelque chose là-bas. Une bonne architecture aide beaucoup, mais ce n'est pas une solution miracle.

Avant que les changements de fonctionnalités n'atteignent les pattes de nos estimés chats de l'Assurance Qualité pour des tests manuels, le jeu est rigoureusement analysé dans une série de tests unitaires automatisés.

« Les tests fonctionnent comme une liste d'exigences », explique Nico. « Ils décrivent ce qui est attendu et fournissent des cas d'utilisation clés. »

Lorsqu'un personnage dans Backyard Baseball lance une balle rapide, vole une base ou frappe un coup de circuit, il y a des résultats de gameplay spécifiques que nous voulons atteindre, comme s'assurer que la balle se déplace à une vitesse qui semble authentique pour le lancer, que le timing du coureur s'aligne avec les mécaniques de vol de base, ou que les joueurs de champ réagissent correctement à un coup. Le personnage doit entrer correctement en collision avec le sol, la balle doit se déplacer à la bonne vitesse, et des systèmes plus granulaires comme les indicateurs du contrôleur de joueur qui suivent les actions telles que la préparation, le swing ou le sprint entre les bases, doivent fonctionner.

Lorsque nous apportons une modification à la puissance de Pablo Sanchez, ou plus critique encore, que nous ajustons le code partagé qui régit les swings de batte, nous devons nous assurer que chaque interaction, du timing de contact à la trajectoire de la balle, se comporte de manière cohérente dans tout le jeu.

Souvent, ce qui casse est quelque chose auquel vous ne vous attendriez pas, ce qui est la raison même pour laquelle les tests sont si importants.

Avec ce système intégré à notre flux de travail, nous sommes informés dès qu'une exigence spécifique est rompue, ce qui réduit les sessions de test et de dépannage qui sont aussi chronophages que de chercher une aiguille dans une botte de foin.

Le Test Runner d'Unity fonctionne plus efficacement lorsque vos systèmes sont modulaires, ce qui est une autre raison pour laquelle nous utilisons les Assembly Definitions.

Leçon 5 : Préparez vos ressources

« L'erreur est humaine ; le pardon, divin. »

Mais mettre en place des systèmes pour prévenir l'erreur humaine dès le départ est tout simplement légendaire.

Après des heures de codage et de débogage, il est inévitable qu'un développeur aux yeux fatigués fasse quelques clics erronés ou pousse accidentellement vers le dépôt des modifications qui n'étaient censées être que temporaires. Bien que pardonnable (dis-je, en tant que personne aux yeux parfois fatigués), une ressource avec des paramètres d'importation mal configurés pourrait avoir d'énormes conséquences. Et comme de nombreux développeurs travaillent sur des machines puissantes, le scénario catastrophe est que le problème de performance passe inaperçu jusqu'à plus tard, comme lorsqu'une scène de stade avec des personnages, des animations et des effets commence à provoquer des ralentissements ou une instabilité sur du matériel moins performant.

Pour atténuer ce risque, vous pourriez limiter l'accès aux ressources, mais cela crée un goulot d'étranglement en raison des nombreuses raisons pour lesquelles le contenu d'un jeu doit être ajusté :

• Le modèle est trop grand pour s'adapter à la configuration de la caméra.
• Ce clip audio a un volume plus faible, il nécessite donc un effet spécifique.
• Chaque texture doit être ajustée maintenant que le shader a changé.

Dans un jeu comme Backyard Baseball, où l'identité visuelle est primordiale, les modèles et les effets visuels reçoivent des centaines de modifications alors que nous peaufinons l'aspect et le rendu juste avant la sortie.

« Aucune quantité de spécifications techniques ne peut éviter le fait que la variété du contenu implique de gérer des différences légères mais significatives entre les différentes ressources », déclare Nico.

L'automatisation aide également ici :

• AssetPostprocessor : Nous écrivons une logique d'importation personnalisée qui impose les normes du projet.
• OnValidate : Nous utilisons la méthode OnValidate pour signaler les références manquantes dans l'Éditeur, ce qui se déclenche toujours avant la compilation.

Enfin, ne laissez pas tout ce discours sur l'automatisation vous distraire de solutions manuelles simples lorsqu'elles sont plus rapides.

« Ne passez jamais 10 jours à automatiser une tâche qui prend 10 minutes à faire manuellement », prévient David.

Leçon 6 : Maîtriser l'élément humain (collaboration)

Les systèmes de Version Control comme Git sont parmi les premières choses qui viennent à l'esprit lors de la coordination de centaines de changements provenant de dizaines de développeurs chaque jour. David préconise ces méthodologies éprouvées pour tous nos projets chez Mega Cat :

• Petits changements atomiques : Évitez les « méga commits » qui touchent plusieurs systèmes à la fois. Isolez le travail sur des branches de fonctionnalités individuelles jusqu'à ce qu'elles soient stables et révisées. Gardez les changements individuels dans des commits individuels pour un historique de Version Control bien documenté qui facilite également le cherry picking et d'autres magies de Git si nécessaire.
• Fusions quotidiennes depuis la branche principale : Maintenez les branches de fonctionnalités, de département et de longue durée à jour avec la branche principale, car cela peut réduire la taille et la complexité des fusions finales, aidant à prévenir les conflits à grande échelle.
• Révision des demandes de fusion : C'est la première ligne d'assurance qualité, où vous détectez les bugs, appliquez les normes du projet et assurez la cohésion avec le système global.

« Dans les grands projets Unity, les revues de code ne sont pas juste une formalité », conseille David. « Elles sont un élément clé de la prévention des conflits et de la qualité globale du projet. »

Assurez-vous simplement que ceux qui révisent le code possèdent une expertise dans le domaine mis en œuvre et sont conscients des meilleures pratiques de codage, afin qu'ils puissent évaluer avec précision l'exactitude et la maintenabilité.

Il existe des conseils et astuces spécifiques pour rendre le Version Control aussi fluide que possible dans Unity. Les scènes et les prefabs constituent le socle de votre projet, alors optimisez-les non seulement pour les performances du CPU, mais aussi pour la collaboration entre développeurs.

Nous préférons toujours les composants plus petits, additifs et imbriqués à une grande scène ou à un prefab monolithique. De cette façon, les développeurs peuvent travailler en parallèle sans conflits.

C'est important, car les conflits de fusion dans les scènes et les prefabs sont les plus difficiles à résoudre, leurs données n'étant pas facilement lisibles par les développeurs. Pour faciliter ce processus, nous sérialisons ces fichiers en texte, et non en binaire, et nous activons la fonction de fusion automatique de notre configuration Git pour les fichiers YAML. Cela permet à Git de résoudre plus facilement les conflits de fusion lui-même et préserve le temps des développeurs pour le travail important de création de nouvelles fonctionnalités.

Mais malgré tout cela :

« Prévenir les conflits est généralement une meilleure stratégie que d'essayer de les résoudre », déclare Nico.

Une propriété claire des assets peut grandement y contribuer.

« Définissez qui peut modifier des scènes ou des prefabs spécifiques », déclare David. « Ensuite, les membres de l'équipe demandent des modifications en dehors de leur périmètre de responsabilité au lieu de modifier directement les assets. »

Nico décrit une procédure similaire comme un « système de sémaphore ». Il s'agit essentiellement d'une feuille de calcul où les développeurs consignent le moment où ils modifient un asset, ce qui le « verrouille » efficacement. Si un autre développeur doit apporter des modifications à ce fichier, il doit attendre que le développeur qui a verrouillé le fichier envoie sa modification vers le dépôt et le « déverrouille ».

Comme toujours, trouvez la procédure qui convient le mieux à votre équipe.

Construire pour l'avenir

Chez Mega Cat Studios, nous avons appris que le passage à l'échelle d'un projet Unity ne consiste pas tant à « coder plus dur » qu'à faire preuve de discipline architecturale. En respectant la nature basée sur les composants de Unity, en imposant des limites avec les Assembly Definitions et en organisant les assets dans une optique de pérennité, nous conservons une grande partie du flux créatif de la phase de prototypage sans faire s'effondrer le projet sous une dette technique avant le lancement.

Bien que ces leçons soient importantes, n'oubliez pas qu'aucune base de code n'est parfaite. Le développement logiciel est une bataille épique où les modèles de programmation recommandés et les considérations pratiques s'affrontent au quotidien. Si le respect de l'un de ces principes ralentit le développement sans offrir de compromis avantageux, c'est le signe que vous devez être plus attentif aux spécificités de votre propre équipe plutôt qu'aux recommandations théoriques. Après tout, chaque projet, chaque équipe et chaque personne est différent(e).

Nous essayons de trouver cet équilibre chaque jour chez Mega Cat Studios. Avec chaque nouveau projet, à mesure que notre bibliothèque de jeux continue de s'agrandir, nous espérons devenir de meilleurs développeurs Unity et de meilleurs collaborateurs.