[DevLog] L'architecture Multi-Jeux du ZlormaEngine : La puissance du répertoire src/bin

Cuando se développe un moteur de jeu en solo, le plus grand piège est la redondance : copier-coller les composants d'affichage, réécrire la boucle principale pour chaque nouveau prototype, ou se retrouver avec dix dossiers de projet qui pèsent chacun plusieurs centaines de mégaoctets. Pour le ZlormaEngine, j'ai choisi une approche radicalement différente, propre à la philosophie de Rust et de son gestionnaire de paquets Cargo : l'architecture par cibles binaires (src/bin). Dans ce premier article technique, on va voir comment cette structure permet de faire tourner tout un catalogue de jeux (Mutant Shooter, Nexus Protocole, Windjet) sur un noyau unique, pour des builds finaux inférieurs à 1 Mo. 📁 La Grille : Structure du Projet Au lieu de créer un projet Cargo par jeu, le ZlormaEngine centralise tout dans un unique espace de travail. Les fondations du moteur résident dans le cœur du projet, tandis que chaque jeu est simplement un fichier d'entrée situé dans le sous-répertoire src/bin/. Voici à quoi ressemble l'arborescence sur mon terminal : Plaintext ZlormaEngine/ ├── Cargo.toml ├── README.txt └── src/ ├── engine/ │ ├── mod.rs # Initialisation du moteur │ ├── core.rs # Boucle principale et delta time │ └── input.rs # Mapping des touches (ZQSD + Souris) └── bin/ ├── mutant_shooter.rs # Code spécifique de Mutant Shooter ├── nexus_protocol.rs # Code spécifique de Nexus Protocole └── windjet.rs # Grille de test du Shmup vertical ⚙️ Sous le capot : Le Cargo.toml Pour l'instant, pas besoin d'une configuration complexe. Cargo comprend nativement que tout fichier placé dans src/bin/ est un exécutable autonome indépendant. La seule dépendance lourde sous le capot est Macroquad, notre framework de bas niveau. Ini, TOML [package] name = "zlorma_engine" version = "1.0.0" edition = "2021" [dependencies] macroquad = "0.4" # Rendu 2D/3D léger et rapide 🚀 Compilation et Exécution à la Volée C'est là que la magie de Rust opère. Si je veux tester ou compiler le jeu complet Mutant Shooter fraîchement mis en ligne, je n'ai pas besoin de changer de dossier ou de recompiler le moteur de zéro. Je lance simplement une directive ciblée dans mon terminal : Bash # Exécuter en mode développement cargo run --bin mutant_shooter # Compiler la version finale optimisée pour Windows ou Linux cargo build --release --bin mutant_shooter Cargo isole uniquement le code de mutant_shooter.rs, y injecte les fonctions nécessaires du dossier engine/, optimise le binaire au maximum, et sort un exécutable standalone d'une légèreté imbattable. 🧠 Pourquoi cette approche est idéale en Solo Dev ? Maintenance instantanée : Si j'optimise la gestion des collisions ou le rafraîchissement des entrées clavier dans src/engine/core.rs, tous mes jeux en profitent immédiatement à la prochaine compilation. Zéro duplication : Pas d'assets fantômes ou de fichiers systèmes dupliqués en tâche de fond. Le code partagé reste partagé. Le minimalisme comme mot d'ordre : Fidèle à la politique du studio, cette structure couplée à l'absence de modules audio lourds (Soundless by Design) permet d'obtenir des performances brutes de très haut niveau, un contrôle total du pipeline de rendu, et des releases qui se téléchargent en une fraction de seconde sur Itch.io. Le protocole est en place, les fondations sont saines. Dans le prochain article, nous analyserons la boucle de rendu et la gestion des vagues d'ennemis de Mutant Shooter. Restez connectés sur le flux. // Zlormack.