2.1 KiB
É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 :
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.