ECS orienté données : propriété et itération avant les étiquettes d'architecture

Partir du travail à effectuer

Une architecture entité-composant-système (ECS) est utile lorsqu'elle facilite l'organisation des données et des traitements d'un jeu. L'étiquette seule ne promet ni vitesse ni simplicité. Il faut commencer par une opération exécutée fréquemment : identifier les champs qu'elle lit, ceux qu'elle écrit, et les entités qui ont réellement besoin de cette opération.

Identité, données et systèmes

Les entités fournissent l'identité, les composants associent des données aux entités, et les systèmes opèrent sur des combinaisons de composants sélectionnées. Flecs documente ces rôles ainsi que les systèmes pilotés par des requêtes. [1] Le stockage par archétypes regroupe les entités ayant le même ensemble de composants ; Unity Entities stocke ces données dans des chunks, et les changements structurels peuvent déplacer des entités d'un groupe à un autre. [2] D'autres stratégies de stockage ECS font des compromis différents.

Exemple détaillé

Prenons, à titre d'illustration, la mise à jour de 20000 étincelles en mouvement. Chacune nécessite une position et une vitesse à trois composantes, chaque composante étant représentée par un flottant de 4-byte. La charge utile du mouvement est de 20000 × 6 × 4 = 480000 bytes.

Un enregistrement monolithique hypothétique de 128 bytes par étincelle occuperait 2560000 bytes, champs sans rapport inclus. Ces calculs de charge utile n'établissent ni le trafic réel du cache ni un gain de vitesse : l'alignement, le padding, le taux de remplissage des chunks et les schémas d'accès comptent toujours. Ils justifient de vérifier par un test si la boucle critique peut parcourir des tableaux compacts Position et Velocity sans suivre de pointeurs propres à chaque objet.

On définit le système d'intégration de manière qu'il lise Velocity et écrive Position. Un système de durée de vie gère seul l'expiration. Les suppressions sont mises en file d'attente jusqu'à une frontière de changement structurel documentée, au lieu d'invalider le parcours en cours. Le rendu peut lire les positions obtenues une fois que la dépendance requise est terminée.

Méthode de travail pratique

Avant de planifier du travail parallèle, cartographiez les lectures et écritures de chaque système. Deux systèmes qui écrivent le même composant exigent un ordonnancement ou un partitionnement sûr. Les handles d'entité stables doivent survivre aux déplacements dans le stockage ; les adresses de composants mises en cache, elles, peuvent devenir invalides. Précisez à quels moments les requêtes et les références doivent être rafraîchies.

Gardez les champs à haute fréquence d'accès près de l'opération qui les utilise, et séparez les données volumineuses et rarement utilisées lorsque les mesures le justifient. Examinez le nombre d'archétypes, le taux de remplissage des chunks, le coût des changements structurels et les accès aléatoires. Une relation entre entités qui saute à répétition vers des zones de stockage sans rapport peut dominer une mise à jour par ailleurs linéaire.

Compromis et validation

Ajouter et retirer des composants n'est pas gratuit dans tous les ECS. Un grand nombre de petites combinaisons de composants peut fragmenter la charge de travail, tandis qu'un composant géant peut obliger des systèmes sans rapport à toucher des données superflues. Choisissez la granularité d'après la propriété des données et les accès mesurés, et non selon une règle voulant que chaque scalaire mérite son composant.

Comparez des scènes représentatives au comportement identique, en incluant la création, la destruction et les transitions. Examinez le coût total d'une image et la mémoire, pas seulement la meilleure boucle interne. Un petit jeu comportant des objets très individualisés peut raisonnablement utiliser des objets classiques à côté d'une simulation de masse gérée par l'ECS.

Sources

[1] Flecs quickstart — Sander Mertens and Flecs contributors.

[2] Archetype concepts — Unity Entities documentation.