🎮 Comprendre l’ECS : la brique invisible derrière les jeux modernes

le 13 octobre 2025

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’idée de base

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.

🧩 Exemple concret

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.

🧮 Pourquoi c’est puissant

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

1. Évolutivité

Tu peux ajouter de nouveaux comportements sans casser les anciens :

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

2. Rejeu et simulation

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.

3. Performance

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.

🧱 Dans Darkwaar 5

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.create_entity()
    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.

🧩 ECS ≠ magie

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.

🧭 Ce que Darkwood en retient

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.

🔮 Et après ?

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.

• Poster un commentaire