# Évolution du moteur ## Construction progressive Le moteur est extrait des besoins des jeux. Une fonction n'entre pas dans le socle commun uniquement parce qu'un moteur généraliste la possède. Une trajectoire fonctionnelle possible est : ```text socle minimal ├── application ├── time ├── input ├── renderer ├── texture/sprite ├── audio ├── scene ├── storage └── platform ``` Puis, lorsque les jeux le justifient : animation, collisions, UI, caméra, particules, asset manager, object pooling, tilemaps, physique, localisation, réseau et scripting éventuel. ## Équivalent fonctionnel d'un moteur 2D léger La référence fonctionnelle de type melonJS n'implique aucune reprise de code. Les capacités recherchées à terme peuvent inclure : Application, Scene, Entity, Transform, Sprite, Animation, Collider, Camera, Input, Audio, AssetManager, Timer, UI et TileMap. ## ECS Un ECS n'est pas une exigence initiale. Des structures Rust directes restent préférables tant qu'elles suffisent. Un ECS devient pertinent avec un grand nombre d'entités, un survivor-like, un bullet hell ou des systèmes fortement composables. ## Physique Le premier niveau peut être une physique maison : AABB, cercles, vitesse, gravité et rebonds simples. Une bibliothèque spécialisée n'est introduite que pour des besoins comme corps rigides, contraintes ou empilage avancé. ## Mode headless et déterminisme Une séparation propre du gameplay doit permettre autant que possible des tests sans SDL. À terme, un mode headless peut servir aux tests, simulations, replays, validation anti-cheat ou backend. Un jeu déterministe peut enregistrer `seed + inputs`, ce qui ouvre la voie aux replays, ghosts, vérification de scores et challenges comparables. ## Générations `engine-vN` Une nouvelle génération est créée pour une vraie rupture. Plusieurs générations peuvent coexister afin qu'un nouveau jeu expérimente `engine-v2` pendant que des jeux existants restent sur `engine-v1`, puis soient migrés progressivement.