Table ronde sur la conception axée sur les données : Les réponses à vos questions

En décembre, nous avons organisé une table ronde des créateurs de DOTS avec Stunlock Studios (V Rising) et Sunblink Entertainment(HEROish, Hello Kitty Island Adventure). Nous avons invité ces pionniers à partager leur expérience de l'utilisation de la pile technologique orientée données (DOTS), à montrer quelles fonctionnalités et capacités la programmation orientée données a débloquées pour leurs jeux, et à voir comment ils tirent parti de la dernière technologie ECS (Entity Component System) dans Unity 2022 LTS.

Les questions-réponses ont fait rage pendant le webinaire, avec de nombreuses questions perspicaces de la part du public - tellement nombreuses que nous n'avons pas pu toutes les traiter en direct. Nous avons demandé à Joe Valenzuela, directeur de l'ingénierie logicielle chez Unity, et à Rasmus Höök, directeur technique chez Stunlock Studios, de répondre à quelques-unes de nos questions préférées de la session. Consultez-les ci-dessous et assistez au webinaire Maximisez le potentiel de votre jeu grâce à une conception axée sur les données , disponible à la demande ici.

"Est-il préférable de commencer les nouveaux projets avec DOTS dès le départ ou avec des GameObjects ordinaires, puis d'optimiser les performances en passant à ECS (soit pur, soit hybride) ?"

JOE VALENZUELA : L'ECS, le DOTS et la conception orientée données (DOD) ne se limitent pas à l'amélioration des performances. Il s'agit également d'éviter la complexité inhérente à la modélisation des problèmes à l'aide de la programmation orientée objet (POO).

Toute personne ayant l'intention de créer un jeu multijoueur - en particulier un jeu avec un serveur faisant autorité et une prédiction côté client - devrait sérieusement envisager de commencer avec DOTS. Netcode for Entities offre un système vraiment robuste et puissant qui s'adapte et vous permet d'écrire un code de jeu simple.

Si vous ne créez pas de jeu multijoueur, ou si vous ne faites que du prototypage et cherchez à essayer de nouvelles choses rapidement, vous pouvez envisager de tirer parti de MonoBehaviour/GameObjects.

"Est-il possible de créer un jeu entièrement sur le système DOTS, ou est-ce que DOTS ne supporte que le système GameObject ?"

JOE VALENZUELA : Non, vous aurez probablement besoin de GameObjects à un moment ou à un autre. Nous y travaillons.

"Quels sont les inconvénients ou les cas d'utilisation pour lesquels un développeur ne devrait pas utiliser les DOTS ?

JOE VALENZUELA : Vous vous adressez probablement à la mauvaise personne - je ne vois pas de cas où je préférerais utiliser autre chose que DOTS dans Unity ! Mais si vous me tordez le bras, je dirai que les projets traditionnels basés sur MonoBehaviour/GameObject excellent vraiment lorsqu'il s'agit de faire du prototypage. Lorsque vous vous attendez à des changements rapides, vous ne voulez pas nécessairement passer beaucoup de temps à créer des Bakers ou à concevoir vos données. C'est un domaine que nous espérons rationaliser à l'avenir pour les DOTS.

"Rasmus, as-tu des conseils à donner aux ingénieurs sur la programmation orientée vers les données ?

RASMUS HÖÖK : Je pense qu'un bon début consiste à écrire un code aussi simple et direct que possible pour résoudre le problème que vous rencontrez. Mettez-vous dans la peau d'un programmeur débutant et écrivez un code très axé sur les résultats, où l'objectif est de faire en sorte que le code fasse ce que vous voulez qu'il fasse. L'objectif initial ne devrait pas être d'écrire du code réutilisable, de créer des abstractions ou autre.

Dans le cadre de la mise en œuvre du SCE, il convient de ne pas trop réfléchir et de ne pas faire preuve d'une trop grande ingéniosité. Il est préférable d'utiliser d'abord des composants et des systèmes plus importants au lieu de les diviser en plusieurs petits éléments. Cela rendra votre code plus facile à suivre. Vous vous séparerez plus tard, lorsque vous aurez une raison de le faire. Nous avons certainement commis cette erreur très tôt.

Je dirais qu'une bonne occasion de pratiquer la programmation orientée données se présente lorsque vous avez quelque chose à optimiser. Vous disposez alors d'un problème réel sur lequel vous pouvez expérimenter et mesurer vos résultats. Vous verrez également l'importance de la réflexion sur les données.

"Nous entendons beaucoup parler de l'utilisation des DOTS pour passer à l'échelle supérieure et créer des jeux plus ambitieux, mais y a-t-il des avantages à passer à l'échelle inférieure? Comme l'utilisation de DOTS dans un petit projet pour cibler les systèmes bas de gamme ?

JOE VALENZUELA : Un fonctionnement efficace sur des systèmes à faible consommation d'énergie améliore la qualité du code de simulation qu'ils peuvent exécuter. Il réduit également les besoins en batterie pour les appareils fonctionnant sur batterie, ce qui se traduit par une durée de fonctionnement plus longue et une meilleure santé du système dans son ensemble.

"Lorsque l'on passe de SystemBase à ISystem, comment gérer les appels au code géré ?"

JOE VALENZUELA : Techniquement, il n'est pas nécessaire de se débarrasser du code géré pour utiliser ISystem - le code géré peut être appelé à partir d'ISystem. Ses données gérées ne peuvent pas être stockées directement dans un ISystem - pour cela, j'utiliserais les données gérées des composants.

Cependant, si vous vous demandez "Comment supprimer les appels au code géré de l'ISystem pour pouvoir utiliser Burst et obtenir les meilleures performances de mon code", la réponse est... cela dépend.

Si vous utilisez des conteneurs .NET, vous pouvez trouver un remplaçant adéquat dans com.unity.collections. Si vous interagissez avec une API Unity gérée et qu'il n'existe pas d'alternative non gérée, il est parfois utile de diviser le travail en phases de "récupération des données" et de "traitement", cette dernière étant celle où vous effectuez votre traitement basé sur l'ISystème.

"J'ai lu dans la documentation que le système ECS n'est pas compatible avec l'architecture à scènes multiples. Comment cette approche devrait-elle être réalisée à l'aide du système ECS ?

JOE VALENZUELA : Rien dans le SCE n'empêche le chargement additif de plusieurs scènes Unity. Cependant, ces scènes ne contiendront pas de données ECS, mais uniquement des GameObjects avec des MonoBehaviours.

Vous pouvez créer autant de sous-scènes que vous le souhaitez, et chacune d'entre elles transformera les GameObjects et les données MonoBehaviour de la création en entités compactes et en données de composants qui pourront être chargées au moment de l'exécution. Les sous-scènes peuvent être divisées en sections et chaque section peut être diffusée à l'intérieur ou à l'extérieur selon les besoins.

"Dans quelle mesure le fait d'avoir des monobehaviours/DOTS hybrides affecte-t-il le déterminisme dans un projet ?"

JOE VALENZUELA : Le déterminisme n'est pas un état binaire, et nous ne garantissons pas que chaque détail d'exécution soit identique d'un cycle à l'autre. En général, l'interopérabilité hybride est parfois nécessaire pour des détails de présentation tels que les systèmes de particules ou l'audio, pour lesquels une reproduction parfaite par image n'est pas nécessaire.

Pour des fonctions telles que le jeu prédictif, vous voudrez que votre simulation fonctionne avec ECS.

Comment gérer des centaines de systèmes ? Est-ce qu'ils fonctionnent tous en permanence et n'exécutent pas la logique lorsqu'il n'y a pas d'entités dans la requête ? Ou bien activez-vous les systèmes de manière contextuelle en fonction de l'état du jeu ?

JOE VALENZUELA : Pour faciliter le développement, nous avons fait en sorte que les systèmes soient mis à jour par défaut. La différence de performance n'est pas énorme, mais si vous avez vraiment des centaines de systèmes, vous pourriez bénéficier d'une mise à jour latente en appelant RequireForUpdate ou en utilisant l'attribut RequireMatchingQueriesForUpdate.

Dans ce cas, l'idiome consiste à ajouter un RequireForUpdate<Foo>() au système concerné, et à utiliser Foo IComponentData dans vos scènes comme une sorte de drapeau pour activer la mise à jour de ces systèmes.

"Je comprends que DOTS améliore les performances en termes de traitement de grandes quantités de données pendant le temps d'exécution, pendant le jeu (le rendu en particulier, d'après ce que j'ai entendu). Cependant, j'ai également entendu dire que les DOTS améliorent les performances de production en termes de facilitation de tout remaniement nécessaire. Pourriez-vous nous parler un peu de la façon dont DOTS aide au remaniement ?"

JOE VALENZUELA : Selon moi, l'un des grands avantages de DOTS, ECS et DoD en général est qu'ils rendent visible et inspectable une plus grande partie de l'état de votre simulation. Si vous avez déjà essayé d'ajouter des tests à une bibliothèque OOP, vous avez peut-être rencontré le problème suivant : vous devez simuler ou instancier un grand nombre de fonctionnalités afin de reproduire l'état nécessaire à l'invocation d'une "simple" instance de méthode. Avec les systèmes de style DoD, vous pouvez presque toujours représenter un noyau de transformation comme une fonction autonome qui transforme un type de valeur en un autre.

Il est beaucoup plus facile de raisonner, de tester et de paralléliser.

"D'après mon expérience (amateur), je constate que la DoD crée un couplage étroit entre les données et l'architecture, ce qui fait que les changements apportés aux structures de données entraînent un important travail de refonte. Est-ce votre expérience ? Comment avez-vous géré ou évité ce problème ?"

RASMUS HÖÖK : D'après notre expérience, lorsque l'on modifie les données, il faut généralement modifier le code qui les utilise, même avant d'utiliser ECS. Nous n'avons donc pas souffert plus que ce à quoi nous sommes habitués !

JOE VALENZUELA : Je ne pense pas qu'il s'agisse d'un problème fondamental du DoD ou même de notre SCE, du moins tel qu'il a évolué au fil du temps.

D'une part, la méthode traditionnelle pour rompre le couplage étroit dans la POO consiste généralement à créer des fonctions et des hiérarchies de classes orientées vers les instances. Bien que cela soit agréable en théorie, ce type d'abstraction est l'une des premières choses à disparaître dans la programmation des performances.

Rien ne vous empêche d'écrire des fonctions utilitaires dans un SCE. S'il est vrai que dans notre ECS, il faut revisiter les systèmes lorsque l'on modifie le contrat de données pour des requêtes spécifiques, cela peut être le signe que l'on interroge les données de manière dispersée. Transformez-vous sans cesse les données des composants ? Peut-on le réécrire pour réduire le nombre de mutations par image ? Lecture répétée des données des composants ? Il est peut-être possible de l'intégrer dans une structure de données immuable au début du cadre.

Enfin, je pense que l'on peut affirmer sans risque que le DoD, ou du moins le SCE, rend beaucoup plus explicite l'état du problème. Ce n'est pas un point négatif : Il s'agit d'un autre compromis. Je préfère de loin raisonner sur un couplage étroit lors de la refonte plutôt que sur un couplage lâche ou implicite.

"Le système ECS/OOP fonctionne-t-il bien pour les jeux mobiles, ou pouvez-vous recommander cette approche pour un projet de jeu mobile ? Y a-t-il des risques ou des considérations ?"

JOE VALENZUELA : Nous avons eu de nombreux clients qui ont utilisé avec succès ECS dans leurs jeux mobiles. Consultez cette conférence GDC pour découvrir comment Sunblink Entertainment l'a utilisé pour HEROish.

"Comment avez-vous procédé pour mettre en réseau V Rising? Avez-vous utilisé Netcode for Entities ou un autre framework ?"

RASMUS HÖÖK : Nous avons créé notre propre cadre. Nous avons commencé à utiliser les DOTS pour la production très tôt et nous étions conscients des risques que cela comportait. Afin d'éliminer autant de risques que possible, nous avons essayé de nous appuyer sur le moins de paquets possible et de rouler nos propres paquets lorsque c'était possible. Nous avons toujours créé des jeux multijoueurs et nous avons toujours utilisé nos propres solutions, nous étions donc à l'aise pour le faire nous-mêmes.

"Le système ECS est-il suffisamment stable pour la production ? Nous nous sommes débattus avec ce projet au cours des derniers mois avec un prototype et nous ne savons pas s'il s'agit de problèmes de croissance au fur et à mesure que nous apprenons ou s'il n'est pas tout à fait prêt à devenir un pur projet de production ECS.

RASMUS HÖÖK : Je dirais qu'il est suffisamment stable pour la production, mais qu'il manque des fonctionnalités que de nombreux développeurs de jeux considèrent comme acquises. Notre code de jeu est purement ECS dans V Rising, mais les éléments de présentation, tels que les personnages animés, les effets de particules et l'interface utilisateur, utilisent tous des GameObjects. De manière réaliste, je pense qu'une approche hybride est la meilleure solution pour la plupart des équipes qui démarrent un projet aujourd'hui.

Nous avons réalisé V Rising en utilisant une approche à sens unique. Nous utilisons l'ECS pur pour envoyer des données aux GameObjects, jamais dans l'autre sens. Par exemple, nous conservons l'état d'un personnage dans les données ECS - entrée, vitesse, etc., qui décideront de l'état de la locomotion et de l'animation à activer, à quel moment et à quelle vitesse. Nous nous assurons ensuite que l'animateur du GameObject est dans cet état. Quel que soit l'état dans lequel se trouve l'animateur, cela n'affecte jamais le gameplay. Je pense que cette séparation simplifie globalement le jeu.

JOE VALENZUELA : Le système ECS est prêt pour la production et est utilisé par des clients du monde entier, mais il nous reste encore un long chemin à parcourir avant que l'expérience soit aussi transparente que nous le souhaitons. Restez à l'écoute des développements futurs - et merci d'utiliser les DOTS !

Faites de votre jeu ambitieux une réalité avec DOTS, qui vous permet de créer des jeux évolutifs et performants et des expériences inoubliables. Bénéficiez des dernières fonctionnalités avec Unity 2022 LTS et essayez les dernières technologies avec Unity 6 Preview.