Architecture du workspace

Vue générale

games.sasedev/
├── crates/
│   ├── common/
│   │   ├── game-assets-lib/
│   │   └── game-logging-lib/
│   ├── engines/
│   │   ├── engine-v1-common/
│   │   ├── engine-v1-platform-api/
│   │   └── engine-v1-sdl/
│   ├── games/
│   │   ├── game-reflex-poc/
│   │   └── game-snake-poc/
│   └── apps/
│       ├── game-reflex-poc-desktop/
│       ├── game-snake-poc-desktop/
│       ├── game-reflex-poc-tauri/
│       ├── game-reflex-poc-wasm/
│       └── game-snake-poc-wasm/
├── assets/
│   ├── common/
│   ├── game-reflex-poc/
│   └── game-snake-poc/
├── Android/
│   ├── common/
│   ├── game-reflex-poc/
│   └── game-snake-poc/
├── Web/
│   └── game-snake-poc/
├── docs/
├── deltas/
├── prompts/
└── scripts/

Générations du moteur

Une génération engine-vN est une ligne de compatibilité. Un jeu peut rester sur engine-v1 pendant qu'un nouveau jeu expérimente engine-v2. Les anciens jeux sont ensuite migrés individuellement.

Les capacités transverses réutilisables sont séparées des générations moteur. game-assets-lib porte la résolution logique des assets et game-logging-lib le tracing commun.

Les subdivisions moteur sont exprimées par crates afin de ne pas forcer un jeu à dépendre de capacités inutiles. La baseline sépare déjà :

engine-v1-common : types et comportements génériques indépendants des plateformes ;
engine-v1-platform-api : contrats abstraits des services plateforme ;
engine-v1-sdl : frontière d'intégration SDL3, volontairement minimale dans la baseline.

Jeux

Chaque jeu est une crate indépendante sous crates/games/. Un jeu ne duplique pas une crate moteur. Il sélectionne explicitement la génération qu'il consomme.

Assets

Les assets sont extérieurs aux crates. Le packaging compose :

assets/common/
+
assets/<game>/

Le runtime devra conserver une distinction logique entre ressources communes et ressources spécifiques afin d'éviter les collisions silencieuses.

Runners Desktop

Chaque crate de jeu reste une bibliothèque. Une crate binaire Desktop séparée sous crates/apps/ la consomme pour permettre les itérations locales rapides. Cette séparation évite d’introduire main, des choix de plateforme ou du code de lancement dans le gameplay réutilisable.

Adapters WebAssembly et variante Tauri

Les adapters WASM sont distincts des runners SDL3 natifs et ne déplacent aucune règle de gameplay hors des crates de jeu.

game-reflex-poc-wasm adapte le POC Reflex à wasm-bindgen pour le host Tauri/WebView existant. game-snake-poc-wasm adapte séparément Snake pour le premier host navigateur direct de 0.3.0. Dans les deux cas, l'adapter expose l'état et la scène portable ; il ne possède pas les règles du jeu.

game-reflex-poc-tauri reste le binaire natif Tauri qui héberge la WebView Reflex locale. Son frontend Vite/TypeScript pilote un Canvas et appelle l'adapter Reflex WASM. La crate Tauri suit le modèle des apps Desk KSP : façade lib.rs, pont tauri.rs, modules propriétaires séparés et frontend local à la crate.

Le host Web Snake direct réside sous Web/game-snake-poc/. Ce package Vite/TypeScript consomme game-snake-poc-wasm, reprend la structure HTML/Sass/TypeScript et le thème Bootstrap/Bootswatch des applications Desk KSP sans dépendre de Tauri, traduit clavier/tactile vers les quatre directions logiques et dessine l'EngineScene dans un Canvas. Il reste extérieur au workspace Cargo et ne contient aucune règle de gameplay.

3.8 KiB Raw Blame History Unescape Escape