💡 1 - ECS, le pourquoi

Manuel officiel Unity ECS

🔊 S'abonner au flux RSS

________________________________________________________

Je vais ici parler dans un contexte Game Dev, mais fondamentalement, c’est un sujet qui est transverse au métaverse (ouai j’ose le mot 😏) du développement : l’orienté Object VS l’orienté Data.

________________________________________________________

Aux origines de la galère : le OOP !

Le OOP (Object Oriented Programming) dispose de cette incroyable force qu’il épouse à merveille les prédispositions de nos cerveaux mollassons :

• on découpe nos concepts métier en objets
• ils portent à la fois des propriétés et des méthodes/fonctions
• chaque objet a droit à son instance distincte et il pourra donc être autonome dans son coin
• et on pourra ensuite lentement tomber dans l’enfer des héritages et des dépendances en cascade… mais c’est un autre sujet. 😌

Dans le cadre du jeu vidéo, cette approche est trèèèèèès attrayante. Parce que non seulement ça colle d’un point de vue découpage fonctionnel (un objet par joueur / ennemi / décors / UI…), mais ça colle aussi vachement bien d’un point de vue gameplay :

je veux créer plusieurs ennemis distincts qui attaquent mon joueur ? Hop, une instance d’objet par ennemi, chacun avec ses propres points de vie, son propre attack pattern, sa propre reconnaissance du terrain… et potentiellement, résultante de tout ça : un comportement unique par ennemi !

Tous les gros moteurs de jeux ont donc adopté cette approche dans leur design de base et dans le choix du langage adossé :

• Unreal Engine avec le C++
• Unity avec le C#
• Godot avec le C# et son langage dédié le GDScript (qui est une variante intéressante, plus modulaire autour d’un concept de composition/noeud).

Mais tout aussi flexible et adapté qu’est le POO pour le game design, il a un problème majeur : il scale très mal. A vouloir regrouper au sein d’un même objet à la fois les données et ses traitements, par design les objets deviennent des éléments extrêmement volatiles dont on ne sait à l’avance, ni ce qu’ils vont faire, ni la taille mémoire qu’ils vont occuper.

-- La flexibilité est un compromis de performance -- Source de l'image

Cette nature indéfinie de l’objet oblige une architecture qui permet de manager n’importe quel élément qui lui serait attaché. Ne pouvant anticiper la structure de l’objet, sa création se fait à la volée avec un rangement mémoire parcélaire (ou en moins poétique : yolo, je te range où je trouve de la place libre).

Travailler sur un objet nécessite alors de le reconstituer façon fil d’Ariane, en remontant à chaque section de mémoire où une partie de ses données est stockée.

Or les accès mémoires, c’est le coeur de la performance et ce scan incessant pour reconstituer les objets est un couperet brutal.

________________________________________________________

Le saint sauveur : le DOD !

L’ECS (Entity Component System) est une architecture qui rentre dans le paradigme du DOD (Data Oriented Design). Dans le cadre de Unity, c’est même très clair, on parle de DOTS (Data Oriented Technology Stack). Promis je m’arrête là avec les acronymes des enfers infernaux. 😚

L’ECS en soi n’est pas un concept nouveau. Si j’en crois Wikipédia, la 1ère version d’une architecture similaire à l’ECS dans un jeu commercial remonte à Thief : The Dark Project en 1998.

-Digression- Jeu extraordinaire au passage, auquel j’ai eu la chance de pouvoir jouer dans mon enfance (attention vos rétines : trailers d’époque).

Il disposait d’une quantité impressionnante d’objets interagissables et dotés de physique, qu’on pouvait lancer pour faire du bruit, faire bouger d’autres objets, assommer des gardes etc etc… en vue de commettre le vol parfait sans aucun mort. Une référence en terme d’infiltration. -Fin de digression-

L’essence de l’ECS : ne plus organiser le code autour d’une logique fonctionnelle, mais d’une logique qui vise à optimiser l’agencement de la donnée, aussi sommairement nommé le principe de localité.

Son design en soi est relativement simple :

• on remplace le concept d’objet par celui d’entity, qui n’est qu’un identifiant unique.
• à cette entité, on va lier des components, qui ne sont que des conteneurs de données (des structs)
• on regroupe les entités qui disposent des mêmes composants dans des archetypes : toutes les entités appartenant à un même archétype sont rangées de manière contiguë en mémoire
• on peut alors query des groupes d’entités en filtrant par composant (comme on requêterait une base de données)
• au travers de systems centralisés, on traitera la donnée requêtée en masse via un découpage en chunks et une répartition sur du multi-threading

Implémentation OOP vs ECS

En OOP, on aurait ici eu un personnage qui porterait une position, une direction et une vitesse ainsi qu'une méthode Move() qui s'exécuterait à chaque frame.

En ECS, on crée 3 composants de données, liés entre eux par l’ID unique d’une entité. Ensuite un système isolé va requêter toutes les entités qui disposent de la combinaison de ces 3 composants (qu’ils appartiennent ou non au même archétype, seule la combinaison de composants importe) et va traiter le calcul du mouvement en parallèle.

Cette approche permet d’augmenter d’au moins un facteur (x10) les performances. Des exemples seront plus parlant :

Pas d'ECS, 1k unités sans VAT*, sans simulation, sans décors

ECS, 100k unités avec VAT*, simulation simple, sans décors

ECS, 50k unités avec VAT*, simulation avancée, 180k décors

VAT (Vertex Animated Texture)

C'est une technique d'animation qui stocke les mouvements des modèles dans une texture lue directement par le GPU. Allège fortement la charge CPU, au détriment d'un coût en RAM et d'une perte de flexibilité dans le process d'implémentation des animations. Lien vers un article (anglais) si vous voulez plus de détails.

- Les 3 vidéos tournent autour de 40-60 FPS. L’approche OOP me permet d’animer 1 000 unités (disclaimer : en y ajoutant le VAT, entre 5k et 10k serait une cible envisageable). Avec l’approche ECS, je peux monter à 100 000 unités, avec par dessus une simulation qui leur permet de s’esquiver et d’avoir un vrai pathfinding via un champs de vecteurs. L’écart de performance entre les 2 implémentations est abyssal pour ce genre de cas d’usage. -

C’est donc une architecture extrêmement puissante, qui a trouvé moult cas d’usage dans des simulations de :

• foules
• trafic
• villes / écosystèmes
• projectiles / particules
• sandbox / MMO

qui manipulent tous de grandes quantités d’objets non-statiques et pour lesquels le DOD fait des merveilles.

Mais vous remarquerez que cette liste est plutôt restreinte et qu’on n’utilise pas cette architecture partout… 👀

________________________________________________________

Un grand pouvoir implique…

Il est un piège dans lequel il ne faut pas tomber : la performance pour la performance, ce bon vieux over-engineering ! (et bon sang que c’est dur de ne pas tomber dans ce piège quand on fait de l’ingénierie…).

S’il est vrai que — La flexibilité est un compromis de performance —, l’inverse est tout aussi vrai — La performance est un compromis de flexibilité —. Or la flexibilité est l’un des coeurs de la productivité.

La performance n’est que rarement un objectif en soi (à part si vous vous appelez Google/Amazon et que vous devez répondre à des milliards de requêtes utilisateurs à la seconde). Non elle est surtout un pré-requis minimal d’acceptation de l’utilisateur :

• si la performance est trop dégradée, l’expérience utilisateur le sera aussi et il partira
• mais être trop performant n’améliorera pas l’expérience perçue côté utilisateur et vous aurez dépensé temps/argent en pure perte

La performance est donc une affaire d’équilibre : une limite basse stricte à ne jamais franchir et une limite haute diffuse à tempérer, afin de maximiser la productivité de features, qui est le but premier.

L’ECS étant une réponse de performance, il est par nature plus complexe et peu flexible au changement. Il est beaucoup plus long à mettre en place, demande de nombreux composants distincts, impose des restrictions sur le type de données et globalement, rallonge drastiquement les temps de développement, même pour des features simples.

L’industrie a choisi comme toujours l’approche la plus pragmatique : l’hybride. Savoir choisir ce qui mérite une approche ECS pour la performance VS choisir l’approche OOP quand le fonctionnel et l’itération priment. L’approche ECS est par exemple inutile dans la plupart des jeux avec des scènes restreintes, qui compose l’immense majorité de nos catalogues. Au contraire, la moindre simulation de masse gagnera massivement à l’implementer.

Mais si l’industrie a longtemps dû traiter l’ECS et l’OOP comme deux mondes séparés, une nouvelle voie s’ouvre peut-être. A la GDC de mars 2026, Unity a décidé de taper fort : pourquoi ne pas fusionner les 2 approches ?

L’ECS deviendrait un package core du moteur (et non plus un add-on à installer), à la manière d’un Bevy (un moteur de jeu en Rust nativement ECS). Les entités deviendront alors le backend de tout le moteur, mais pour autant les GameObjects ne disparaissent pas : ils deviennent une couche de confort par dessus les entités, le moteur prenant la main pour faire la conversion. La force du design OOP par dessus, la puissance de l’ECS en dessous. — L’ECS ne sera plus un choix, mais le socle. Le GameObject ne sera plus une alternative, mais une interface. —

En d’autres termes, l’approche hybride dont je parlais plus haut ne sera plus un compromis d’architecture, mais le mode de fonctionnement par défaut du moteur. Vous voulez du prototypage rapide ? Vous restez au niveau GameObject. Vous voulez de la performance brute ? Le moteur vous permettra de basculer votre architecture en GameObjects vers de l’ECS et ainsi profiter de ses options. Même données, même moteur, mais deux mondes en un.

Et je vous avoue que je suis très curieux de voir le résultat. 👀