Ange-Marie MAURIN - A2M Systèmes
98c778aa28
L'adaptateur traduit clavier et manette en actions SEQUA (PlayerInput) ; le Core ne recoit et n'enregistre que ces actions, le rejeu reste exact. - SEQUA 3D : PlayerInput, poll_input(), capacite player_input (interface des adaptateurs en version 2) - protocole Core - rendu 0.2 : render/input, envoye quand les actions changent ; entree remise au neutre si le rendu disparait - Godot : InputMap du projet (ZQSD, fleches, espace, manette) ou script SequaInput.sequa_player_input() pour une correspondance avancee ; entree neutre sans focus ; exemple examples/sequa_input.gd - adaptateur debug : entrees scriptees par numero d'image - Studio : ligne "Entrees du joueur" du panneau Rendu
SEQUA Engine
SEQUA : Simulate Environments, Quantify Uncertainty, Adapt.
Environnement de création et d'exécution de mondes virtuels, piloté par l'intention de l'auteur, au-dessus d'un noyau déterministe et rejouable. Les moteurs 3D et les modèles IA sont des composants interchangeables.
Documentation de référence : docs/SEQUA_Engine_resume_complet_v2.md
Organisation du dépôt (monorepo)
| Dossier | Rôle | Langage |
|---|---|---|
| studio/ | SEQUA Studio : host/ (exécutable qui gère le Core et sert l'interface) + ui/ (interface web) |
C++20, TypeScript |
| core/ | SEQUA Core : projet, simulation déterministe, rejeu, intentions, orchestrateur, confiance | C++20 |
| 3d/ | SEQUA 3D : interface vers les moteurs 3D (adaptateurs, capacités, synchronisation) | C++20 |
| render/ | sequa-render : processus de rendu lancé par le Core, charge une bibliothèque d'adaptateur (ADR 0009) |
C++20 |
| engines/ | Adaptateurs des moteurs 3D : godot/adapter + godot/vendor/godot-src (fork de Godot 4.7.2-stable) et godot/vendor/godot-cpp (10.0.0-stable), sous-modules ; debug/adapter (rendu 2D sans GPU, en images ou vidéo) |
C++20 |
| platform/ | Code propre à chaque système, partagé : lancement de processus enfants liés au parent (process/), arborescence des binaires et racine sequa-root.json (layout/) |
C++20 |
| schema/ | Contrat de données et protocole Studio↔Core | Protobuf / FlatBuffers |
| docs/ | Documentation, décisions d'architecture (docs/adr/), spécifications des protocoles (docs/specs/), tutoriels (docs/tutoriels/) |
Markdown |
| artwork/ | Identité graphique et sources visuelles | PNG |
| prototypes/ | Prototypes jetables (ex. échange GPU rendu vers inférence), hors produit | C++ |
| cmake/, scripts/ | Options de compilation, build et vérification locaux | CMake, PowerShell, Bash |
Les moteurs eux-mêmes sont des sous-modules git, inutiles pour construire SEQUA : git submodule update --init engines/godot/vendor/godot-src engines/godot/vendor/godot-cpp pour travailler sur l'adaptateur Godot (ADR 0007).
État
Phase 0 : fondations. Le chemin de bout en bout existe sous une forme minimale :
- le Core simule de façon déterministe un micro-mode 2D de démonstration (SIMULÉ), enregistre et rejoue les sessions, et sert le protocole Studio - Core 0.3 (spécification) ;
- Studio (
sequa-studioet l'interface web) démarre ou rejoint le Core, recharge le Core recompilé par rejeu et pilote le rendu depuis son panneau Rendu ; - le Core lance
sequa-render, qui affiche la scène simulée dans Godot (hébergé par LibGodot) ou l'écrit en images avec l'adaptateur de débogage (protocole Core - rendu 0.2) ; on joue dans la fenêtre Godot, les entrées traduites par l'adaptateur sont enregistrées par le Core (ADR 0011).
Pas encore de rendu neuronal ni de carte de confiance. Seul Windows a été construit et testé (ADR 0004).
Construire et vérifier
Il n'y a pas d'intégration continue sur serveur : les vérifications se lancent localement. Voir aussi docs/installation/ pour les pages par plateforme (prérequis, compiler, lancer, installer, désinstaller).
| Plateforme | Commande | Prérequis |
|---|---|---|
| Windows (build complet) | .\scripts\build-all.ps1 [-Type debug|release|asan|all] [-NoTests] [-Godot] [-SkipGodot] [-SkipUi] [-NoStop] [-Clean] |
Visual Studio 2022 avec outils C++ (MSVC, CMake, Ninja fournis), Python 3, Node.js 24, sous-modules Godot, GPU Vulkan |
| Windows (un preset CMake seul) | .\scripts\build.ps1 [-Preset <nom>] [-Clean] [-NoTests] |
idem |
| Windows, avant commit | .\scripts\check.ps1 |
idem + Node.js pour Studio |
| Linux / macOS | ./scripts/build.sh [<preset>] |
CMake ≥ 3.25, Ninja, GCC ou Clang |
| Lancer SEQUA Studio (Core + interface) | .\bin\windows-x64\debug\studio\sequa-studio.exe [--dev] [--watch] |
build complet |
| Interface seule (développement) | .\scripts\studio.ps1 [-Core ws://hôte:port] [-MockCore] ou ./scripts/studio.sh |
Node.js 24 |
| Windows, cuDNN pour l'inférence GPU | .\scripts\install-cudnn.ps1 [-Version <x.y.z>] [-CudaMajor 12|13] [-DryRun] |
CUDA Toolkit installé + GPU NVIDIA ; télécharge cuDNN (~1,3 Go), demande d'accepter la licence NVIDIA et définit CUDNN_PATH (utilisateur, sans droits admin) |
Chaque script PowerShell affiche son aide avec -Help.
Presets : windows-msvc-debug, windows-msvc-release, windows-msvc-asan, windows-msvc-prototypes, linux-gcc-debug, linux-clang-sanitize, macos-clang-debug (voir CMakePresets.json).
Sous Windows PowerShell, si les scripts sont bloqués : powershell -ExecutionPolicy Bypass -File scripts\build.ps1.
Licence
MPL 2.0. © Ange-Marie MAURIN - A2M Systèmes (https://a2msystemes.org)