Files
Ange-Marie MAURIN - A2M Systèmes da0d31385b build: arborescence bin/<plateforme>/<type> et build unifié (ADR 0010)
- platform/layout : racine sequa-root.json, chemins des composants, arguments et chemins en UTF-8.
- Règles install() : bin/windows-x64/{debug,release,asan}/ (core, render, studio + ui, engines).
- Le Core trouve sequa-render et les adaptateurs depuis la racine (--sequa-root, passé par
  Studio host à sa copie fantôme) : plus de render-unavailable depuis le panneau Rendu.
- L'adaptateur Godot cherche Godot et son projet à côté de lui (surcharge par --adapter-options) ;
  template_release pour le type release. Godot hébergé dans les presets debug et release.
- scripts/build-all.ps1 : Godot, C++, interface, arrêt des processus du dossier visé, install ;
  check.ps1 l'appelle (modification de l'ADR 0004).
- docs/installation/ : compiler, lancer, installer et désinstaller par plateforme.
2026-11-07 15:50:37 +01:00

5.0 KiB

SEQUA Core

SEQUA Engine en bref

SEQUA : Simulate Environments, Quantify Uncertainty, Adapt. SEQUA Engine est un environnement de création et d'exécution de mondes virtuels, d'abord pour le jeu vidéo, où l'auteur dirige un monde par l'intention, le ressenti et les règles plutôt que par des paramètres. Il est composé de quatre couches : Studio (outil de création web), Core (source de vérité), SEQUA 3D (seule porte vers un moteur 3D) et des moteurs 3D interchangeables (Godot, puis Unreal, puis un moteur maison).

Référence : docs/SEQUA_Engine_resume_complet_v2.md

Rôle de Core dans l'engine

Core est la source de vérité du projet. Il possède :

  • le format de projet et la scène de référence (§5.1) ;
  • la représentation du monde en quatre niveaux, de L0 structurel à L3 génératif (§5.2) ;
  • la simulation déterministe à pas fixe, l'enregistrement des entrées et le rejeu bit à bit (§5.3) ;
  • la couche d'intention ;
  • l'orchestrateur de rendu adaptatif (§5.4) et la mesure de la confiance (§5.5).

Core ne connaît aucun moteur 3D : il ne dépend que du contrat de données (schema/). Les modèles neuronaux et génératifs sont exclus de la boucle de simulation.

État

Phase 0. Simulation déterministe, enregistrement et rejeu en place (include/sequa/core/sim/) :

Élément Fichier Rôle
Fixed fixed.hpp Virgule fixe Q16.16 : calcul entier, identique bit à bit partout
Pcg32 rng.hpp Générateur aléatoire SEQUA à graine explicite (PCG32)
FixedStepClock clock.hpp Temps réel vers pas fixes, calcul entier exact, retard plafonné
Simulation simulation.hpp Pas fixe, entrées quantifiées, empreinte FNV-1a de l'état complet
Recording, SessionRecorder, replay replay.hpp Enregistrement des entrées horodatées, format binaire versionné, rejeu avec d'autres réglages, premier tick divergent

SIMULÉ / PROVISOIRE : le monde est un micro-mode 2D de démonstration (un joueur, un sol, des pièces, réglages de ressenti) qui sert à éprouver le déterminisme avant la vraie scène L0. Il sera remplacé.

Le test « empreinte de référence multiplateforme » fige l'empreinte d'une session d'une minute : toute plateforme doit la retrouver exactement (§10.1, §16).

Serveur WebSocket (protocole Studio - Core)

Bibliothèque sequa::core_server (include/sequa/core/server/) et exécutable sequa-core (ADR 0005) :

Protocole 0.2, JSON provisoire, spécifié dans docs/specs/protocole-studio-core-0.2.md :

  • ProtocolSession : poignée de main puis messages core/* (ping, status, attach, detach, shutdown) et session/* (start, pause, resume, status, input, export, import). Pure : ne dépend que de l'interface CoreServices, testée avec une implémentation factice.
  • CoreRuntime (implémente CoreServices) : bail réversible (--linked, attach/detach), demande d'arrêt, instanceId, compteurs.
  • LiveSession : session en direct à 60 Hz (fil dédié), entrée maintenue, export (enregistrement + empreintes par tick), import par rejeu puis poursuite dans le même enregistrement.
  • CoreServer : transport IXWebSocket, jeton (?token=) et contrôle de l'Origin à l'ouverture, écoute locale par défaut, refus explicite si le port est déjà pris.
  • Rendu piloté par Studio (protocole 0.3, §9 ; ADR 0010) : --render <godot|debug> lance sequa-render depuis l'arborescence bin/<plateforme>/<type>/ (repérée via sequa-root.json) ; option --sequa-root <dossier> pour forcer la racine.
.\bin\windows-x64\debug\core\sequa-core.exe --help
.\bin\windows-x64\debug\core\sequa-core.exe --port 9100 --token <hex> --linked

En usage normal, c'est Studio host (sequa-studio) qui lance et supervise le Core.

Construire et tester

Depuis la racine du dépôt :

.\scripts\build.ps1                            # Windows, preset windows-msvc-debug
.\scripts\build.ps1 -Preset windows-msvc-asan  # AddressSanitizer
.\scripts\check.ps1                            # tous les presets Windows + Studio
./scripts/build.sh                             # Linux / macOS

Règles de déterminisme appliquées à la compilation (§10.1) : pas de fast-math, pas de contraction multiplication-addition (/fp:precise sous MSVC, -ffp-contract=off ailleurs).

Licences

  • SEQUA Core : MPL 2.0.
  • Dépendances :
Dépendance Usage Licence
doctest 2.4.12 Tests uniquement MIT
IXWebSocket 12.1.0 Serveur WebSocket (sequa::core_server) BSD-3-Clause
nlohmann/json 3.12.0 Messages JSON provisoires (sequa::core_server) MIT

Politique (§10.2) : le cœur n'utilise que des dépendances permissives (MIT, BSD, Apache 2.0, zlib).