Élargir les flux de travail Unity : Leçons tirées de projets de taille moyenne à grande

Cet article de blog est le premier d'une série par Mega Cat Studios, où ils partagent leur expertise et leurs solutions Unity pour les défis de développement de jeux commerciaux dans le monde réel. Nous espérons que vous découvrirez de super conseils !

Vous avez une idée géniale, et le code s'écrit aussi vite que vous pouvez le taper. Avec chaque commit, une nouvelle fonctionnalité prend forme. Mais c'est la rapidité avec laquelle vos idées se forment qui pourrait bientôt vous amener à regarder un grand désordre bogué.

Chez Mega Cat Studios, nous commençons tous nos projets avec passion, donc nous comprenons l'attrait de travailler rapidement et de faire les choses le plus tôt possible. Pour un prototype, cette approche est acceptable, et en fait, nous la recommandons ! Un développeur avisé sait quand prioriser la vitesse d'itération et quand prioriser la stabilité. Parce que lorsque vous sortez de la phase de prototype, cette approche "rapide et désordonnée" devient un inconvénient.

Nous avons survécu à cette transition de nombreuses fois chez Mega Cat Studios, et avec 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, pour le lancement.

Leçon 1 : Structure pour l'échelle

Les problèmes d'échelle sont rarement causés par un mauvais code ; au contraire, ils surviennent 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. Quelques conseils pour configurer votre projet pour l'échelle incluent :

• Organiser par Type et But : Nous regroupons par Type, puis par But. Le type inclut des catégories comme l'art, le code et l'audio. Le but est ce pour quoi ils sont utilisés. Une organisation intuitive réduit les frictions d'intégration ; un nouvel artiste devrait savoir exactement où appartient un sprite "Character Idle" sans avoir à demander.
• Gardez les scènes simples : Nous avons abandonné la "Mega-Scene" 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 match ou non. De même, nous utilisons des prefabs pour des 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 designer ajuste le gameplay dans le même "niveau" sans conflits de fichiers (plus à ce sujet plus tard).
• Configurer le système Addressables : Au lieu des dossiers Resources traditionnels, nous utilisons le système Addressables pour charger les ressources uniquement lorsque cela est nécessaire, gardant ainsi l'utilisation de la mémoire légère. De plus, charger une ressource avec sa clé Addressable est plus clair et moins susceptible de se casser que de charger via un chemin de fichier vers un emplacement spécifique dans le dossier Resources.

La partie difficile n'est pas de comprendre ces meilleures pratiques. C'est de s'y engager dès le départ 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 priorisez à ce stade.

« Dans la phase de prototypage, comme il y a à peine du code, il est acceptable de le rendre fonctionnel d'abord avant de le rendre modulaire, » dit Paolo Roxas, un 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 – que ce soient des Composants, ScriptableObjects ou des 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 embrasse 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. Couplage lâche : Les systèmes doivent interagir par le biais d'interfaces ou d'événements plutôt que par des références directes, et seulement 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

Définitions d'assemblage (AsmDefs) sont des constructions C# qui regroupent votre code. Leur avantage annoncé est la réduction des temps de compilation, mais leur superpouvoir secret est d'imposer la modularité.

Nico Gaudenzi, développeur principal et détracteur du code spaghetti, jure par eux.

« Dans Backyard Baseball, la couche d'entrée et la couche de gameplay se trouvent dans des DLL différentes. Le gameplay est complètement agnostique aux détails d'entrée. »

Cela évite aux ingénieurs de se nuire en faisant de chaque dépendance une décision calculée. Si nous devions vraiment le faire, nous pourrions réécrire l'ensemble du système d'entrée – de la gestion des manettes 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 seul domaine de la base de code sans risquer de provoquer des changements en cascade dans un autre système, et réduit la quantité de code qu'un développeur doit garder en tête pour les mises en œuvre de fonctionnalités et les corrections de bogues.

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 va loin, mais ce n'est pas une solution miracle.

Avant que les changements de fonctionnalités n'atteignent les pattes de nos estimés chats d'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 de exigences, » dit 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 home run, il y a des résultats de jeu spécifiques que nous voulons atteindre, comme s'assurer que la balle se déplace à une vitesse qui semble authentique au lancer, que le timing du coureur s'aligne avec les mécaniques de vol de base, ou que les joueurs réagissent correctement à un coup. Le personnage doit entrer en collision correctement avec le sol, la balle doit se déplacer à la bonne vitesse, et des systèmes plus granulaires comme les indicateurs de contrôleur de joueur qui suivent des actions comme se préparer, frapper ou sprinter entre les bases, doivent fonctionner.

Lorsque nous apportons un ajustement à la puissance de Pablo Sanchez, ou encore plus critique, 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 l'ensemble du jeu.

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

Avec ce système intégré dans notre flux de travail, nous prenons conscience au moment où une exigence spécifique échoue, ce qui réduit le temps consacré aux sessions de test et de dépannage qui sont aussi chronophages que de trouver une aiguille dans une botte de foin.

Le Test Runner de Unity fonctionne le plus efficacement lorsque vos systèmes sont modulaires, ce qui est une autre raison pour laquelle nous utilisons des définitions d'assemblage.

Leçon 5 : Mettez vos actifs en ordre

"Errer est humain ; pardonner, divin."

Mais mettre en place des systèmes pour prévenir les erreurs humaines 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 erreurs de clic ou pousse accidentellement des modifications dans le dépôt qui n'étaient destinées qu'à être temporaires. Bien que cela soit pardonnable (je le dis en tant que l'un des développeurs aux yeux parfois fatigués), un actif avec des paramètres d'importation mal configurés pourrait avoir d'énormes conséquences. Et puisque de nombreux développeurs travaillent sur des machines puissantes, le scénario cauchemardesque est que le problème de performance passe inaperçu jusqu'à plus tard, comme lorsque une scène de stade avec des personnages, des animations et des effets commence à provoquer des ralentissements ou de l'instabilité sur du matériel moins performant.

Pour atténuer ce risque, vous pourriez limiter l'accès aux actifs, mais cela entraîne un goulot d'étranglement en raison des nombreuses raisons pour lesquelles le contenu du 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 inférieur, donc il nécessite un effet spécifique.
• Chaque texture nécessite un ajustement 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 obtenons le look et la sensation juste avant la sortie.

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

L'automatisation aide également ici :

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

Enfin, cependant, ne laissez pas toute cette discussion sur l'automatisation vous distraire des corrections manuelles simples lorsque celles-ci sont plus rapides.

"Ne passez jamais 10 jours à automatiser une tâche qui prend 10 minutes à faire manuellement," avertit David.

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

Les systèmes de contrôle de version comme Git sont parmi les premières choses qui viennent à l'esprit lorsqu'il s'agit de coordonner des 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 de nombreux systèmes à la fois. Isolez le travail sur des branches de fonctionnalités individuelles jusqu'à ce qu'elles soient stables et examinées. Conservez les changements individuels dans des commits individuels pour un historique de version bien documenté qui facilite également le cherry picking et d'autres astuces git lorsque cela est nécessaire.
• Fusions quotidiennes depuis la branche principale : Maintenez les branches de fonctionnalités, de départements 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.
• Examiner les demandes de fusion : C'est la première ligne d'assurance qualité, où vous détectez les bogues, appliquez les normes du projet et assurez la cohésion avec l'ensemble du système.

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

Assurez-vous simplement que ceux qui examinent le code ont une expertise dans le domaine mis en œuvre et sont conscients des meilleures pratiques de codage, afin qu'ils puissent évaluer avec précision la justesse et la maintenabilité.

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

Nous préférons toujours des composants plus petits, additifs et imbriqués plutôt qu'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 car leurs données ne sont pas facilement lisibles par les développeurs. Pour faciliter ce processus, nous sérialisons ces fichiers en tant que texte, et non binaire, et activons la fonction de fusion automatique de notre configuration Git pour les fichiers YAML. Cela rend Git plus susceptible de résoudre 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 », dit Nico.

Une propriété claire des actifs peut grandement aider à cela.

« Définissez qui peut modifier des scènes ou des prefabs spécifiques », dit David. « Ensuite, les membres de l'équipe demandent des modifications en dehors de leur propriété au lieu de modifier directement les actifs. »

Nico décrit une procédure similaire comme un « système de sémaphore ». C'est essentiellement un tableau où les développeurs enregistrent quand ils changent un actif, le « verrouillant » effectivement. Si un autre développeur a besoin de modifier ce fichier, il doit attendre que le développeur qui a verrouillé le fichier pousse son changement dans le dépôt et le « déverrouille ».

Comme toujours, trouvez la procédure qui fonctionne le mieux pour votre équipe.

Construire pour l'avenir

Chez Mega Cat Studios, nous avons appris que l'échelle d'un projet Unity dépend moins de "coder plus dur" et plus de discipline architecturale. En respectant la nature basée sur les composants de Unity, en imposant des limites avec des définitions d'assemblage et en organisant les actifs avec une vision à long terme, nous préservons une grande partie du flux créatif de la phase de prototype sans faire sombrer le projet dans une dette technique avant le lancement.

Bien que ces leçons soient importantes, rappelez-vous 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 quotidiennement. Si le suivi de l'un de ces principes bloque le développement sans offrir un compromis bénéfique, c'est un signe que vous devez être plus sensible aux spécificités de votre propre équipe et non aux recommandations théoriques. Après tout, chaque projet, équipe et personne est différente.

Nous essayons de trouver cet équilibre chaque jour chez Mega Cat Studios. Avec chaque nouveau projet, alors que notre bibliothèque de jeux continue de croître, nous espérons devenir de meilleurs développeurs Unity et de meilleurs collaborateurs.