Quand on conçoit un jeu, surtout un jeu tactique ou systémique comme Darkwaar, on se retrouve vite à jongler entre :

• des entités (joueurs, ennemis, objets, cases),

• des comportements (mouvement, attaque, effet),

• et des systèmes (rendu, IA, collisions, effets de statut...).

Les approches orientées objet classiques finissent vite par créer des hiérarchies trop profondes : Player extends Character extends Entity extends Drawable extends Object… Résultat : une usine à gaz.

C’est là qu’intervient l’ECS — Entity Component System.

L’ECS part d’un principe simple :

séparer les données, le comportement, et l’exécution.

| Élément | Rôle | Exemple | | ------------- | ------------------------------------------- | --------------------------------------------------------- | | Entity | Identifiant unique | #23 = Guerrier sur la case (3,2) | | Component | Données brutes (pas de logique) | Position(3,2), Vie(10), Attaque(3) | | System | Comportement (agit sur certains composants) | SystemeDeMouvement, SystemeDeCombat, SystemeDeRendu |

L’ECS ne remplace pas la programmation orientée objet — il la déstructure pour la rendre évolutive. Au lieu d’écrire ce que fait chaque classe, on définit comment les données interagissent.

Prenons un exemple simplifié en GDScript (Godot) :

# Composant Position class_name CPosition extends Resource @export var q:int @export var r:int # Composant Vie class_name CVie extends Resource @export var hp:int = 10 # Système de rendu extends Node const CPosition = preload("res://components/CPosition.gd") func process_system(dt): for entity in get_entities_with([CPosition]): var pos = entity.get_component(CPosition) draw_unit(pos.q, pos.r)

Ici :

• l’entité ne “fait” rien — elle contient des composants ;

• les systèmes se déclenchent sur les entités qui possèdent un certain ensemble de composants.

C’est une approche data-driven : tout est piloté par les données.

L’ECS n’est pas juste un design pattern à la mode. C’est une approche structurante qui résout trois problèmes majeurs :

Tu peux ajouter de nouveaux comportements sans casser les anciens :

Ajouter un composant CInvisible suffit pour qu’un système “Rendu” ignore ton entité.

Tu peux rejouer une partie en appliquant la même séquence d’événements, car tout l’état du jeu est pur data, sérialisable, diffable et testable.

Les ECS modernes (comme Flecs, EnTT ou Unity DOTS) stockent les données en mémoire contiguë. Le CPU adore ça :

moins d’appels, moins de cache-miss, plus de vitesse.

Darkwaar 5 repose sur un ECS léger en GDScript, sans moteur externe. L’objectif est d’avoir :

• un monde (World) central,

• des entités simples (un Node par personnage ou objet),

• des composants (Resource) pour les données,

• des systèmes (Node) pour la logique.

Exemple simplifié :

# GameRoot.gd @onready var world := $World func ready(): var unit = world.createentity() unit.add_component(CPosition.new()) unit.add_component(CVie.new())

Chaque frame :

• le World passe sur les systèmes actifs ;

• les systèmes parcourent les entités qui les concernent ;

• et la logique s’exécute sur les données brutes.

Cette séparation permet d’ajouter facilement :

• un système de buffs (effets temporaires),

• un système de résolution de combat,

• ou un système de puzzle pour les niveaux.

L’ECS ne fait pas “mieux” qu’une approche orientée objet : il fait plus simple à maintenir.

Mais il y a un coût : il faut penser en flux de données, pas en hiérarchie d’objets.

• Pas de “Player.move()”, mais un SystemMouvement qui lit les CPosition et CVitesse.

• Pas de “Enemy.attack()”, mais un SystemCombat qui lit les CCombat et CVie.

C’est un changement de paradigme — mais une fois compris, tout devient plus clair.

Chez Darkwood, l’ECS n’est pas qu’une architecture de jeu. C’est une façon de penser la modularité :

• Dans Darkwaar, il structure le gameplay et les puzzles.

• Dans Uniflow, il inspire la logique des “flows” de données.

• Dans Flow, il sert de base pour la composition visuelle d’automatisations.

Même combat : séparer les données, les comportements et la logique d’exécution.

La prochaine étape pour Darkwaar 5 :

• intégrer l’ECS au système de carte isométrique ;

• lier chaque case à une entité ;

• et synchroniser les composants entre la vue (haut) et le HUD (bas).

Cela posera les fondations d’un moteur tactique isométrique open-source, pensé pour la génération procédurale, les puzzles et les systèmes émergents.

• ECS FAQ – Sander Mertens (Flecs)

• Zeste de Savoir – L’Entity Component System

• Bevy Engine – ECS in Rust

• Unity DOTS documentation