0.1.0-0-pre.2
This commit is contained in:
10
CHANGELOG.md
10
CHANGELOG.md
@@ -1,8 +1,16 @@
|
||||
<!-- file: CHANGELOG.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Changelog
|
||||
|
||||
## 0.1.0-0-pre.2 — 2026-09-15
|
||||
|
||||
- intégration de l'architecture de référence dans une documentation thématique durable ;
|
||||
- ajout des objectifs projet, classification des jeux, abstraction SDL3 multi-plateforme, contrôles, assets, évolution moteur, monétisation et services en ligne ;
|
||||
- ajout d'une crate binaire Desktop par POC, chacune consommant exclusivement la crate lib du jeu correspondant ;
|
||||
- ajout de la politique normative des commandes Cargo, audits, runners, Android, Web et Git ;
|
||||
- mise à jour de l'index documentaire, des contrats de fichiers, de la roadmap et des gates.
|
||||
|
||||
## 0.1.0-0-pre.1 — 2026-09-15
|
||||
|
||||
- création du workspace Cargo multi-crates ;
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
# file: Cargo.toml
|
||||
# version: 2
|
||||
# version: 3
|
||||
|
||||
[workspace]
|
||||
resolver = "3"
|
||||
@@ -9,10 +9,12 @@ members = [
|
||||
"crates/engines/engine-v1-sdl",
|
||||
"crates/games/game-reflex-poc",
|
||||
"crates/games/game-snake-poc",
|
||||
"crates/apps/game-reflex-poc-desktop",
|
||||
"crates/apps/game-snake-poc-desktop",
|
||||
]
|
||||
|
||||
[workspace.package]
|
||||
version = "0.1.0-0-pre.1"
|
||||
version = "0.1.0-0-pre.2"
|
||||
edition = "2024"
|
||||
license = "MIT"
|
||||
repository = "https://git.sasedev.com/Sasedev/games"
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: README.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# games.sasedev
|
||||
|
||||
@@ -21,7 +21,7 @@ Workspace expérimental puis productif pour des jeux multiplateformes principale
|
||||
|
||||
## Baseline
|
||||
|
||||
Version initiale : `0.1.0-0-pre.1`.
|
||||
Version courante : `0.1.0-0-pre.2`.
|
||||
|
||||
Les deux premiers jeux sont des POC structurels : `game-reflex-poc` et `game-snake-poc`. Ils existent d'abord pour valider les frontières du workspace, le moteur, les assets et le packaging multiplateforme.
|
||||
|
||||
@@ -32,3 +32,5 @@ Les deux premiers jeux sont des POC structurels : `game-reflex-poc` et `game-sna
|
||||
- [`CHANGELOG.md`](CHANGELOG.md)
|
||||
- [`docs/000-README.md`](docs/000-README.md)
|
||||
- [`docs/architecture/001-WORKSPACE_ARCHITECTURE.md`](docs/architecture/001-WORKSPACE_ARCHITECTURE.md)
|
||||
- [`docs/objectives/001-PROJECT_OBJECTIVES.md`](docs/objectives/001-PROJECT_OBJECTIVES.md)
|
||||
- [`docs/games/001-GAME_CLASSIFICATION.md`](docs/games/001-GAME_CLASSIFICATION.md)
|
||||
|
||||
17
ROADMAP.md
17
ROADMAP.md
@@ -1,18 +1,19 @@
|
||||
<!-- file: ROADMAP.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Roadmap
|
||||
|
||||
## 0.1.0 — Fondation POC
|
||||
|
||||
- [x] `0-pre.1` — squelette du workspace, règles, architecture, versions, assets, Java Android commun/spécifique et deux crates POC.
|
||||
- [ ] `0-pre.2` — première boucle moteur exécutable Desktop : temps, input abstrait, état de jeu minimal.
|
||||
- [ ] `0-pre.3` — intégration SDL3 Desktop réelle et premier rendu POC Reflex.
|
||||
- [ ] `0-pre.4` — projet Gradle Android exécutable, SDL3 AAR/NDK, compilation Rust `cdylib`, lancement sur appareil/émulateur.
|
||||
- [ ] `0-pre.5` — bridge Java/JNI minimal et input tactile Android.
|
||||
- [ ] `0-pre.6` — assets communs + spécifiques empaquetés sans copie dans les crates.
|
||||
- [ ] `0-pre.7` — POC Reflex jouable Desktop + Android.
|
||||
- [ ] `0-pre.8` — POC Snake jouable et validation de la réutilisation du moteur.
|
||||
- [x] `0-pre.2` — consolidation documentaire issue de l'architecture de référence, runners Desktop par jeu et politique normative des commandes.
|
||||
- [ ] `0-pre.3` — première boucle moteur exécutable Desktop : temps, input abstrait et état de jeu minimal via les runners.
|
||||
- [ ] `0-pre.4` — intégration SDL3 Desktop réelle et premier rendu POC Reflex.
|
||||
- [ ] `0-pre.5` — projet Gradle Android exécutable, SDL3 AAR/NDK, compilation Rust `cdylib`, lancement sur appareil/émulateur.
|
||||
- [ ] `0-pre.6` — bridge Java/JNI minimal et input tactile Android.
|
||||
- [ ] `0-pre.7` — assets communs + spécifiques empaquetés sans copie dans les crates.
|
||||
- [ ] `0-pre.8` — POC Reflex jouable Desktop + Android.
|
||||
- [ ] `0-pre.9` — POC Snake jouable et validation de la réutilisation du moteur.
|
||||
- [ ] `1-alpha.1` — première API moteur V1 volontairement stabilisée.
|
||||
- [ ] `2-beta.1` — stabilisation, packaging, tests multi-appareils.
|
||||
- [ ] `3-rc.1` — candidat de release du socle 0.1.0.
|
||||
|
||||
5
RULES.md
5
RULES.md
@@ -1,5 +1,5 @@
|
||||
<!-- file: RULES.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Index normatif games.sasedev
|
||||
|
||||
@@ -14,7 +14,8 @@ Les règles détaillées sont maintenues sous `docs/rules/` et sont cumulatives
|
||||
3. [`docs/rules/RULES_PROJECT.md`](docs/rules/RULES_PROJECT.md) — architecture propre à games.sasedev, moteurs, jeux, assets et plateformes ;
|
||||
4. [`docs/rules/RULES_DOCUMENTATION.md`](docs/rules/RULES_DOCUMENTATION.md) — règles Markdown et cycle documentaire ;
|
||||
5. [`docs/rules/FILE_CONTRACTS.md`](docs/rules/FILE_CONTRACTS.md) — responsabilités des principales familles de fichiers ;
|
||||
6. [`docs/rules/VERSION_WORKFLOW.md`](docs/rules/VERSION_WORKFLOW.md) — SemVer, niveaux de maturité, fixes, deltas et livraisons.
|
||||
6. [`docs/rules/VERSION_WORKFLOW.md`](docs/rules/VERSION_WORKFLOW.md) — SemVer, niveaux de maturité, fixes, deltas et livraisons ;
|
||||
7. [`docs/rules/RULES_COMMANDS.md`](docs/rules/RULES_COMMANDS.md) — politique d’exécution des commandes Cargo, audits, runners, Android, Web et Git.
|
||||
|
||||
## Hiérarchie
|
||||
|
||||
|
||||
17
crates/apps/game-reflex-poc-desktop/Cargo.toml
Normal file
17
crates/apps/game-reflex-poc-desktop/Cargo.toml
Normal file
@@ -0,0 +1,17 @@
|
||||
# file: crates/apps/game-reflex-poc-desktop/Cargo.toml
|
||||
# version: 1
|
||||
|
||||
[package]
|
||||
name = "game-reflex-poc-desktop"
|
||||
version.workspace = true
|
||||
edition.workspace = true
|
||||
license.workspace = true
|
||||
repository.workspace = true
|
||||
authors.workspace = true
|
||||
publish.workspace = true
|
||||
|
||||
[dependencies]
|
||||
game-reflex-poc = { path = "../../games/game-reflex-poc" }
|
||||
|
||||
[lints]
|
||||
workspace = true
|
||||
16
crates/apps/game-reflex-poc-desktop/src/main.rs
Normal file
16
crates/apps/game-reflex-poc-desktop/src/main.rs
Normal file
@@ -0,0 +1,16 @@
|
||||
// file: crates/apps/game-reflex-poc-desktop/src/main.rs
|
||||
// version: 1
|
||||
|
||||
#![warn(missing_docs)]
|
||||
#![deny(unreachable_pub)]
|
||||
#![forbid(unsafe_code)]
|
||||
|
||||
//! Desktop development runner for the Reflex POC game library.
|
||||
//!
|
||||
//! This binary is intentionally minimal until the executable SDL3 runtime is introduced.
|
||||
|
||||
fn main() {
|
||||
let state = game_reflex_poc::ReflexState::new();
|
||||
println!("Reflex POC desktop runner: score={}", state.score());
|
||||
return;
|
||||
}
|
||||
17
crates/apps/game-snake-poc-desktop/Cargo.toml
Normal file
17
crates/apps/game-snake-poc-desktop/Cargo.toml
Normal file
@@ -0,0 +1,17 @@
|
||||
# file: crates/apps/game-snake-poc-desktop/Cargo.toml
|
||||
# version: 1
|
||||
|
||||
[package]
|
||||
name = "game-snake-poc-desktop"
|
||||
version.workspace = true
|
||||
edition.workspace = true
|
||||
license.workspace = true
|
||||
repository.workspace = true
|
||||
authors.workspace = true
|
||||
publish.workspace = true
|
||||
|
||||
[dependencies]
|
||||
game-snake-poc = { path = "../../games/game-snake-poc" }
|
||||
|
||||
[lints]
|
||||
workspace = true
|
||||
16
crates/apps/game-snake-poc-desktop/src/main.rs
Normal file
16
crates/apps/game-snake-poc-desktop/src/main.rs
Normal file
@@ -0,0 +1,16 @@
|
||||
// file: crates/apps/game-snake-poc-desktop/src/main.rs
|
||||
// version: 1
|
||||
|
||||
#![warn(missing_docs)]
|
||||
#![deny(unreachable_pub)]
|
||||
#![forbid(unsafe_code)]
|
||||
|
||||
//! Desktop development runner for the Snake POC game library.
|
||||
//!
|
||||
//! This binary is intentionally minimal until the executable SDL3 runtime is introduced.
|
||||
|
||||
fn main() {
|
||||
let state = game_snake_poc::SnakeState::new();
|
||||
println!("Snake POC desktop runner: length={}", state.length());
|
||||
return;
|
||||
}
|
||||
54
deltas/0.1.0/0-pre.2.md
Normal file
54
deltas/0.1.0/0-pre.2.md
Normal file
@@ -0,0 +1,54 @@
|
||||
<!-- file: deltas/0.1.0/0-pre.2.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.1.0-0-pre.2
|
||||
|
||||
## Base
|
||||
|
||||
Base déclarée : `0.1.0-0-pre.1` modifiée localement par l'utilisateur et fournie comme archive `games-0.1.0-0-pre.1.zip`.
|
||||
|
||||
## Objectif
|
||||
|
||||
Consolider avant le développement SDL3 réel la documentation fonctionnelle et architecturale, prévoir une voie d'exécution Desktop par jeu et formaliser les commandes autorisées/recommandées.
|
||||
|
||||
## Ajouts
|
||||
|
||||
- documentation thématique sous `docs/objectives/`, `docs/games/`, `docs/engine/`, `docs/monetization/`, `docs/services/` et `docs/development/` ;
|
||||
- documents d'architecture SDL3 multi-plateforme, input et assets ;
|
||||
- `docs/rules/RULES_COMMANDS.md` ;
|
||||
- `crates/apps/game-reflex-poc-desktop` ;
|
||||
- `crates/apps/game-snake-poc-desktop`.
|
||||
|
||||
## Changements
|
||||
|
||||
- version workspace portée à `0.1.0-0-pre.2` ;
|
||||
- index normatif et documentaire étendus ;
|
||||
- règles workspace étendues aux runners `bin` ;
|
||||
- roadmap redécoupée pour conserver une tranche dédiée à la vraie boucle moteur Desktop ;
|
||||
- gates de validation alignées sur les commandes réellement prévues.
|
||||
|
||||
## Intention des runners
|
||||
|
||||
Les runners de cette prerelease sont structurels et exécutables mais ne constituent pas encore la boucle SDL3. Ils prouvent que chaque jeu peut rester une crate lib et être consommé par un exécutable Desktop distinct.
|
||||
|
||||
## Source documentaire
|
||||
|
||||
La documentation thématique est issue du document de travail `architecture_jeux_rust_sdl_multiplateformes.md`, réorganisé en documents durables adaptés aux conventions du dépôt. Les choix déjà fixés par les règles du dépôt priment sur les formulations exploratoires de ce document de travail.
|
||||
|
||||
## Validation de la base fournie
|
||||
|
||||
La base `0.1.0-0-pre.1` fournie par l'utilisateur a été annoncée propre avec `cargo fmt --all -- --check`, les audits Python, `cargo check --workspace`, Clippy strict et `cargo test --workspace --all-targets --all-features`.
|
||||
|
||||
## Validation réalisée sur ce delta
|
||||
|
||||
Les contrôles exécutables dans l'environnement de génération sont propres :
|
||||
|
||||
```text
|
||||
General Rust rule audit: clean
|
||||
Rust export completeness audit: 0 candidate(s)
|
||||
games.sasedev workspace audit: clean
|
||||
Markdown table audit: clean (1 table(s), 28 file(s))
|
||||
Cargo.toml parsing: clean
|
||||
```
|
||||
|
||||
`cargo` n'est pas installé dans l'environnement de génération. Les gates Cargo de `0.1.0-0-pre.2`, y compris les deux nouveaux runners Desktop, doivent donc être rejouées sur le poste de développement avant acceptation de la prerelease.
|
||||
@@ -1,17 +1,44 @@
|
||||
<!-- file: docs/000-README.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Documentation games.sasedev
|
||||
|
||||
## Objectifs
|
||||
|
||||
- [`objectives/001-PROJECT_OBJECTIVES.md`](objectives/001-PROJECT_OBJECTIVES.md) — finalité, principes structurants, stratégie de construction et vision du SDK.
|
||||
|
||||
## Architecture
|
||||
|
||||
- [`architecture/001-WORKSPACE_ARCHITECTURE.md`](architecture/001-WORKSPACE_ARCHITECTURE.md) — workspace, générations de moteur, jeux, assets et Android.
|
||||
- [`architecture/001-WORKSPACE_ARCHITECTURE.md`](architecture/001-WORKSPACE_ARCHITECTURE.md) — workspace, générations de moteur, jeux, runners, assets et Android.
|
||||
- [`architecture/002-ANDROID_ARCHITECTURE.md`](architecture/002-ANDROID_ARCHITECTURE.md) — séparation Rust/SDL3/Java/JNI et modules Android.
|
||||
- [`architecture/003-SDL3_PLATFORM_ABSTRACTION.md`](architecture/003-SDL3_PLATFORM_ABSTRACTION.md) — frontière SDL3 entre Desktop, Android et Web.
|
||||
- [`architecture/004-INPUT_AND_CONTROLS.md`](architecture/004-INPUT_AND_CONTROLS.md) — abstraction clavier, souris, gamepad, tactile, gestes et capteurs.
|
||||
- [`architecture/005-ASSET_ARCHITECTURE.md`](architecture/005-ASSET_ARCHITECTURE.md) — assets communs/spécifiques hors crates et packaging.
|
||||
|
||||
## Jeux
|
||||
|
||||
- [`games/001-GAME_CLASSIFICATION.md`](games/001-GAME_CLASSIFICATION.md) — familles de jeux rapides, déclinaisons, contrôles et potentiel d'évolution.
|
||||
|
||||
## Moteur
|
||||
|
||||
- [`engine/001-ENGINE_EVOLUTION.md`](engine/001-ENGINE_EVOLUTION.md) — construction incrémentale, équivalent fonctionnel d'un moteur 2D léger, ECS, physique et générations.
|
||||
|
||||
## Monétisation
|
||||
|
||||
- [`monetization/001-MONETIZATION.md`](monetization/001-MONETIZATION.md) — publicité, rewarded, interstitiels, billing, médiation et configuration distante.
|
||||
|
||||
## Services
|
||||
|
||||
- [`services/001-ONLINE_AND_VIRAL_SERVICES.md`](services/001-ONLINE_AND_VIRAL_SERVICES.md) — leaderboards, challenges, partage, progression, replays, anti-cheat et backend.
|
||||
|
||||
## Développement
|
||||
|
||||
- [`development/001-DESKTOP_RUNNERS.md`](development/001-DESKTOP_RUNNERS.md) — runners Desktop séparés des crates lib de jeu.
|
||||
|
||||
## Règles
|
||||
|
||||
Voir [`../RULES.md`](../RULES.md).
|
||||
Voir [`../RULES.md`](../RULES.md), notamment [`rules/RULES_COMMANDS.md`](rules/RULES_COMMANDS.md) pour la politique d'exécution des commandes.
|
||||
|
||||
## Validation
|
||||
|
||||
- [`validation/001-VALIDATION_GATES.md`](validation/001-VALIDATION_GATES.md) — gates manuelles de la baseline.
|
||||
- [`validation/001-VALIDATION_GATES.md`](validation/001-VALIDATION_GATES.md) — gates manuelles du workspace.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/architecture/001-WORKSPACE_ARCHITECTURE.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Architecture du workspace
|
||||
|
||||
@@ -12,9 +12,12 @@ games.sasedev/
|
||||
│ │ ├── engine-v1-common/
|
||||
│ │ ├── engine-v1-platform-api/
|
||||
│ │ └── engine-v1-sdl/
|
||||
│ └── games/
|
||||
│ ├── game-reflex-poc/
|
||||
│ └── game-snake-poc/
|
||||
│ ├── games/
|
||||
│ │ ├── game-reflex-poc/
|
||||
│ │ └── game-snake-poc/
|
||||
│ └── apps/
|
||||
│ ├── game-reflex-poc-desktop/
|
||||
│ └── game-snake-poc-desktop/
|
||||
├── assets/
|
||||
│ ├── common/
|
||||
│ ├── game-reflex-poc/
|
||||
@@ -54,3 +57,7 @@ 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.
|
||||
|
||||
58
docs/architecture/003-SDL3_PLATFORM_ABSTRACTION.md
Normal file
58
docs/architecture/003-SDL3_PLATFORM_ABSTRACTION.md
Normal file
@@ -0,0 +1,58 @@
|
||||
<!-- file: docs/architecture/003-SDL3_PLATFORM_ABSTRACTION.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Abstraction SDL3 et plateformes
|
||||
|
||||
## Frontière générale
|
||||
|
||||
Le gameplay ne doit pas connaître directement Linux, Windows, macOS, Android ou le navigateur. SDL3 est une frontière technique commune, complétée par des services plateforme lorsqu'une capacité n'appartient pas au cœur SDL.
|
||||
|
||||
```text
|
||||
Game library
|
||||
│
|
||||
Engine API
|
||||
│
|
||||
SDL3 boundary
|
||||
┌───┼───────────────┐
|
||||
│ │ │
|
||||
Desktop Android Web
|
||||
native SDL/JNI WASM/browser
|
||||
```
|
||||
|
||||
## Desktop
|
||||
|
||||
Le runner Desktop est la cible d'itération la plus rapide. Il utilise la crate lib du jeu et, à terme, le runtime SDL3 natif. Les entrées disponibles peuvent inclure clavier, souris, trackpad, gamepad et joystick.
|
||||
|
||||
La cible Desktop sert à tester le gameplay, le rendu, la boucle de jeu, l'audio et les abstractions communes sans imposer un déploiement sur émulateur ou téléphone.
|
||||
|
||||
## Android
|
||||
|
||||
Android empaquette le jeu natif dans une application standard. La structure cible combine : SDL3 Android, une bibliothèque native Rust, la couche Java commune, les extensions Java spécifiques au jeu, les assets communs et spécifiques, puis les SDK Android requis.
|
||||
|
||||
Les fonctionnalités suivantes restent côté plateforme Android : lifecycle, JNI, Ads, Billing, haptique, share sheet, intégrations Play et autres API Android spécifiques.
|
||||
|
||||
Le gameplay Rust ne doit pas dépendre des classes Java ni d'une régie publicitaire particulière.
|
||||
|
||||
## Web / WASM
|
||||
|
||||
La cible Web est prévue comme cible ultérieure. SDL3 peut être utilisé avec une chaîne Web adaptée, notamment Emscripten, tandis que le navigateur fournit ses propres contraintes de boucle d'événements, audio, stockage, permissions et interaction utilisateur.
|
||||
|
||||
Une version Web peut être équivalente au jeu natif ou être volontairement réduite pour jouer immédiatement depuis un lien, partager un challenge et orienter vers l'installation Android.
|
||||
|
||||
## Contrats plateforme
|
||||
|
||||
Les différences non couvertes proprement par SDL3 passent par des contrats explicites, par exemple :
|
||||
|
||||
```text
|
||||
PlatformServices
|
||||
├── Advertising
|
||||
├── Billing
|
||||
├── Sharing
|
||||
├── Haptics
|
||||
├── Leaderboard
|
||||
├── CloudSave
|
||||
├── Analytics
|
||||
└── Notifications
|
||||
```
|
||||
|
||||
Une génération de moteur ne doit pas obligatoirement imposer une nouvelle génération de bridge Android si ce contrat reste compatible.
|
||||
55
docs/architecture/004-INPUT_AND_CONTROLS.md
Normal file
55
docs/architecture/004-INPUT_AND_CONTROLS.md
Normal file
@@ -0,0 +1,55 @@
|
||||
<!-- file: docs/architecture/004-INPUT_AND_CONTROLS.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Abstraction des entrées et contrôles
|
||||
|
||||
## Règle générale
|
||||
|
||||
Le gameplay manipule des actions logiques et non des périphériques physiques. Une action comme `Primary`, `Left` ou `Pause` peut donc provenir d'un clavier, d'une souris, d'un écran tactile ou d'un gamepad sans modifier les règles du jeu.
|
||||
|
||||
## Desktop
|
||||
|
||||
Entrées possibles :
|
||||
|
||||
- clavier : flèches, WASD, espace, touches de fonction ;
|
||||
- souris : clic principal/secondaire, position, mouvement relatif, molette ;
|
||||
- gamepad et joystick ;
|
||||
- trackpad lorsqu'il est présenté comme pointeur ou geste exploitable.
|
||||
|
||||
## Android
|
||||
|
||||
Schémas de contrôle envisagés :
|
||||
|
||||
- boutons virtuels ;
|
||||
- tap simple ;
|
||||
- swipe horizontal ou vertical ;
|
||||
- drag direct ;
|
||||
- joystick virtuel ;
|
||||
- touch relatif sans joystick visible ;
|
||||
- multitouch ;
|
||||
- accéléromètre, gyroscope et orientation lorsqu'un jeu le justifie ;
|
||||
- vibration/haptique comme retour, derrière un service plateforme.
|
||||
|
||||
## Web
|
||||
|
||||
Le navigateur peut combiner clavier, souris et tactile. Le mapping doit produire les mêmes actions logiques que les autres plateformes.
|
||||
|
||||
## État normalisé
|
||||
|
||||
Une représentation de type suivant peut être introduite lorsque nécessaire :
|
||||
|
||||
```rust
|
||||
pub struct InputState {
|
||||
pub move_x: f32,
|
||||
pub move_y: f32,
|
||||
pub primary: bool,
|
||||
pub secondary: bool,
|
||||
pub pause: bool,
|
||||
}
|
||||
```
|
||||
|
||||
Cette structure n'est pas imposée comme API définitive à la baseline ; elle illustre le contrat recherché.
|
||||
|
||||
## Orientation d'écran
|
||||
|
||||
Portrait convient particulièrement aux jeux one-button, merge, puzzle, idle, stacking et climber. Paysage convient mieux aux shooters, runners latéraux, survivor-like, tower defense et jeux utilisant deux zones de contrôle.
|
||||
49
docs/architecture/005-ASSET_ARCHITECTURE.md
Normal file
49
docs/architecture/005-ASSET_ARCHITECTURE.md
Normal file
@@ -0,0 +1,49 @@
|
||||
<!-- file: docs/architecture/005-ASSET_ARCHITECTURE.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Architecture des assets
|
||||
|
||||
## Séparation physique
|
||||
|
||||
Les assets ne résident jamais dans les crates Rust. La racine `assets/` contient :
|
||||
|
||||
```text
|
||||
assets/
|
||||
├── common/
|
||||
├── game-reflex-poc/
|
||||
├── game-snake-poc/
|
||||
└── <future-game>/
|
||||
```
|
||||
|
||||
`assets/common/` ne contient que les ressources dont la mutualisation est réelle : fonts, UI générique, sons communs, icônes, particules ou shaders selon les besoins.
|
||||
|
||||
Chaque jeu possède son propre répertoire pour textures, audio, données, niveaux et autres ressources spécifiques.
|
||||
|
||||
## Espace logique
|
||||
|
||||
Le runtime doit éviter les collisions silencieuses. Une résolution logique peut distinguer :
|
||||
|
||||
```text
|
||||
common://ui/button.png
|
||||
game://textures/player.png
|
||||
```
|
||||
|
||||
ou préserver des préfixes équivalents dans le package final.
|
||||
|
||||
## Packaging
|
||||
|
||||
Chaque plateforme assemble les deux sources sans créer de copie source durable dans la crate :
|
||||
|
||||
```text
|
||||
assets/common/
|
||||
+
|
||||
assets/<game>/
|
||||
=
|
||||
package runtime du jeu
|
||||
```
|
||||
|
||||
Desktop, Android et Web peuvent utiliser des mécanismes de packaging différents tout en conservant les mêmes noms logiques.
|
||||
|
||||
## Évolution
|
||||
|
||||
Un AssetManager commun pourra ultérieurement prendre en charge cache, loaders, textures, audio, fonts, données, erreurs, hot-reload de développement et éventuellement bundles. Ces capacités ne doivent être ajoutées qu'au rythme des besoins réels des jeux.
|
||||
34
docs/development/001-DESKTOP_RUNNERS.md
Normal file
34
docs/development/001-DESKTOP_RUNNERS.md
Normal file
@@ -0,0 +1,34 @@
|
||||
<!-- file: docs/development/001-DESKTOP_RUNNERS.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Runners Desktop de développement
|
||||
|
||||
## Objectif
|
||||
|
||||
Chaque jeu reste d'abord une crate `lib` contenant son gameplay et ses états. Une crate `bin` Desktop séparée consomme cette bibliothèque afin de lancer rapidement le jeu sur la machine de développement sans déployer systématiquement sur un émulateur ou un téléphone Android.
|
||||
|
||||
## Arborescence
|
||||
|
||||
```text
|
||||
crates/
|
||||
├── games/
|
||||
│ ├── game-reflex-poc/
|
||||
│ └── game-snake-poc/
|
||||
└── apps/
|
||||
├── game-reflex-poc-desktop/
|
||||
└── game-snake-poc-desktop/
|
||||
```
|
||||
|
||||
La crate binaire ne duplique ni règles ni état de jeu. Elle fournit uniquement l'entrée exécutable et, à terme, la composition Desktop du moteur et des services plateforme.
|
||||
|
||||
## Responsabilités
|
||||
|
||||
La crate lib du jeu porte gameplay, règles, état, progression et interfaces nécessaires. Le runner Desktop porte `main`, initialisation Desktop, sélection de l'implémentation plateforme et lancement du runtime SDL3.
|
||||
|
||||
## Limite
|
||||
|
||||
Le runner Desktop ne remplace pas les tests Android. Lifecycle, JNI, tactile réel, Ads, Billing, haptique, permissions et APIs Play nécessitent une validation sur la cible Android.
|
||||
|
||||
## Baseline `0.1.0-0-pre.2`
|
||||
|
||||
Les deux runners sont volontairement minimaux : ils lient les crates de jeu et permettent de vérifier leur exécution locale. La vraie boucle SDL3 Desktop reste planifiée dans une tranche dédiée.
|
||||
47
docs/engine/001-ENGINE_EVOLUTION.md
Normal file
47
docs/engine/001-ENGINE_EVOLUTION.md
Normal file
@@ -0,0 +1,47 @@
|
||||
<!-- file: docs/engine/001-ENGINE_EVOLUTION.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# É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 :
|
||||
|
||||
```text
|
||||
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.
|
||||
64
docs/games/001-GAME_CLASSIFICATION.md
Normal file
64
docs/games/001-GAME_CLASSIFICATION.md
Normal file
@@ -0,0 +1,64 @@
|
||||
<!-- file: docs/games/001-GAME_CLASSIFICATION.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Classification des jeux candidats
|
||||
|
||||
## Critères
|
||||
|
||||
Les premiers jeux recherchés doivent privilégier une boucle courte, peu d'assets obligatoires, des règles simples, une UI maîtrisable et des contrôles facilement mappables sur Desktop, Android et Web.
|
||||
|
||||
| Famille | Prototype | Contrôles naturels | Évolutions principales | Intérêt POC |
|
||||
|----------------------|--------------------|-------------------------------|------------------------------------------------|---------------------|
|
||||
| One-button / reflex | très rapide | tap, clic, espace | combos, perfect timing, skins, daily challenge | excellent |
|
||||
| Flappy-like | très rapide | tap/clic | gravité, obstacles dynamiques, pouvoirs, boss | excellent |
|
||||
| Snake | très rapide | directions, swipe, analogique | battle, shooter, survivor, roguelite, merge | excellent |
|
||||
| 2048-like | rapide | swipe, clavier | thèmes, pouvoirs, campagne, daily board | très bon |
|
||||
| Merge | rapide | drag/tap | idle, collection, progression, événements | très bon |
|
||||
| Pong | très rapide | souris, clavier, touch | IA, pouvoirs, multiball, arènes | excellent |
|
||||
| Breakout | rapide | souris, doigt | multiball, lasers, boss, niveaux procéduraux | excellent |
|
||||
| Endless runner | rapide à moyen | tap, swipe, lanes | missions, skins, véhicules, événements | excellent |
|
||||
| Endless climber | rapide | tap, gauche/droite | plateformes, altitude, pouvoirs | très bon |
|
||||
| Asteroids / shooter | moyen | clavier+souris, twin-stick | armes, vagues, bosses, roguelite | très bon |
|
||||
| Space Invaders-like | rapide | gauche/droite+tir | formations, bosses, coop, scrolling | très bon |
|
||||
| Survivor-like | moyen | déplacement analogique | armes, synergies, classes, boss, endless | excellent |
|
||||
| Physics stacking | rapide à moyen | drag/tap | fusion, vents, plateformes, challenges | très bon |
|
||||
| Pachinko / ball drop | rapide | tap/position | puzzle, idle, multiplicateurs, roguelite | bon |
|
||||
| Maze | rapide | clavier, swipe, tilt | génération, clés, ennemis, brouillard | bon |
|
||||
| Sokoban | rapide | directions | glace, téléports, contraintes, génération | bon |
|
||||
| Minesweeper-like | rapide | pointage/tap | campagne, temps, thèmes, pouvoirs | bon |
|
||||
| Puzzle connexions | rapide | tap/rotation | tuyaux, rails, circuits, réseaux | très bon |
|
||||
| Match-3 | moyen | swipe/drag | cascades, objectifs, pouvoirs, événements | bon |
|
||||
| Memory / Simon | très rapide | tap/clic | sons, couleurs, séquences, difficulté | bon |
|
||||
| Score challenge | très rapide | dépend du challenge | daily, leaderboard, partage, ghosts | excellent |
|
||||
| Quiz / lettres | rapide côté moteur | tap/clavier | contenu distant, daily, catégories | bon |
|
||||
| Sudoku / logique | rapide | pointage/clavier | génération, streak, statistiques | bon |
|
||||
| Tower defense | moyen à élevé | pointage/tap | tours, vagues, économie, maps | très bon à terme |
|
||||
| Roguelite | moyen | dépend du genre | runs, choix, progression, génération | très bon à terme |
|
||||
| Auto-battler | moyen | sélection/drag | unités, synergies, progression | bon mobile |
|
||||
| Idle / clicker | très rapide | tap/clic | automation, prestige, collection | très bon mobile/web |
|
||||
|
||||
## Déclinaisons notables
|
||||
|
||||
### Snake
|
||||
|
||||
Le même socle peut devenir Snake classique, libre, battle, survivor, shooter, roguelite ou merge. C'est un excellent jeu de validation de collisions, entités et input abstrait.
|
||||
|
||||
### One-button et score challenge
|
||||
|
||||
Une action unique peut contrôler saut, rotation, inversion de gravité, changement de direction, esquive ou timing. Des parties de 10 à 60 secondes se prêtent particulièrement aux classements, challenges quotidiens et partage viral.
|
||||
|
||||
### 2048 et Merge
|
||||
|
||||
Les règles peuvent rester identiques tandis que le thème change : nombres, animaux, planètes, civilisations, technologies, fruits, monstres ou objets. Ces familles sont adaptées au tactile et demandent peu de contenu moteur.
|
||||
|
||||
### Survivor-like
|
||||
|
||||
Une version minimale peut commencer avec un personnage, quelques armes, quelques types d'ennemis, une carte et une dizaine d'améliorations. Elle devient ensuite un bon banc d'essai pour pooling, nombreuses entités, progression et éventuellement ECS.
|
||||
|
||||
## Réinterprétation rétro
|
||||
|
||||
Les mécaniques générales de Pong, Breakout, Asteroids, Space Invaders, Snake, maze-chase, artillery, digging, lunar landing ou top-down racing peuvent inspirer de nouveaux jeux. Les produits publiés doivent conserver leurs propres noms, graphismes, sons, niveaux, personnages, univers et interfaces.
|
||||
|
||||
## Ordre expérimental envisagé
|
||||
|
||||
Une séquence utile pour construire progressivement le moteur est : one-button/reflex, Pong ou Breakout, Snake, 2048/Merge, Runner, Physics Stacking, Shoot'em up, Survivor-like, Tower Defense, Roguelite.
|
||||
46
docs/monetization/001-MONETIZATION.md
Normal file
46
docs/monetization/001-MONETIZATION.md
Normal file
@@ -0,0 +1,46 @@
|
||||
<!-- file: docs/monetization/001-MONETIZATION.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Monétisation
|
||||
|
||||
## Principe d'abstraction
|
||||
|
||||
Le gameplay ne dépend pas directement d'AdMob, AppLovin, LevelPlay ou d'un autre fournisseur. Il consomme un contrat de publicité ou de billing, tandis que l'implémentation Android passe par Java/JNI et les SDK natifs Android.
|
||||
|
||||
```text
|
||||
Rust game
|
||||
↓
|
||||
Advertising/Billing API
|
||||
↓
|
||||
platform implementation
|
||||
↓
|
||||
Java/JNI Android
|
||||
↓
|
||||
provider SDK
|
||||
```
|
||||
|
||||
## Publicités récompensées
|
||||
|
||||
Usages possibles : seconde chance, revive, bonus x2, coffre gratuit, accélération, skin temporaire, monnaie supplémentaire, nouveau tirage ou poursuite d'une série.
|
||||
|
||||
La récompense n'est accordée qu'après réception de l'événement plateforme indiquant que la condition publicitaire requise est satisfaite.
|
||||
|
||||
## Interstitiels
|
||||
|
||||
Les emplacements naturels sont entre deux parties, après plusieurs manches, à la fin d'un niveau ou après un écran de résultats. Ils ne doivent pas interrompre arbitrairement une action en cours.
|
||||
|
||||
## Achat de suppression des publicités
|
||||
|
||||
Une option `remove ads` peut supprimer les publicités non récompensées tout en laissant éventuellement disponibles les rewarded ads volontaires.
|
||||
|
||||
## Autres achats
|
||||
|
||||
Des achats ou déblocages peuvent concerner skins, personnages, cosmétiques ou packs. Les achats numériques doivent respecter les règles de facturation de la plateforme de distribution utilisée.
|
||||
|
||||
## Médiation
|
||||
|
||||
Une plateforme de médiation peut agréger plusieurs demandes publicitaires. Cette architecture ne doit pas remonter dans le gameplay : le moteur manipule placements, disponibilité, affichage, fermeture, récompense et erreurs, pas le réseau publicitaire gagnant.
|
||||
|
||||
## Configuration distante
|
||||
|
||||
Des paramètres comme la fréquence des interstitiels ou un multiplicateur de récompense peuvent à terme être configurables à distance, avec garde-fous et valeurs par défaut locales. Les règles critiques ne doivent pas dépendre exclusivement d'une configuration distante non vérifiée.
|
||||
43
docs/objectives/001-PROJECT_OBJECTIVES.md
Normal file
43
docs/objectives/001-PROJECT_OBJECTIVES.md
Normal file
@@ -0,0 +1,43 @@
|
||||
<!-- file: docs/objectives/001-PROJECT_OBJECTIVES.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Objectifs du projet games.sasedev
|
||||
|
||||
## Finalité
|
||||
|
||||
Le dépôt doit permettre de développer rapidement plusieurs petits jeux, notamment rétro, arcade, casual et hyper-casual, en réutilisant un socle technique commun tout en conservant l'indépendance fonctionnelle de chaque jeu.
|
||||
|
||||
La première orientation produit est Android, sans enfermer le gameplay dans Android. Les mêmes crates de jeu doivent pouvoir servir à des runners Desktop et, lorsque le support sera introduit, à une cible Web/WASM.
|
||||
|
||||
## Principes structurants
|
||||
|
||||
- Rust porte le moteur, le gameplay et le maximum de logique portable.
|
||||
- SDL3 constitue la frontière principale pour fenêtre, rendu, événements, audio et entrées lorsque ces capacités sont disponibles sur la cible.
|
||||
- Android ajoute une couche Java/JNI externe au workspace Rust pour les services spécifiques à la plateforme.
|
||||
- Les assets sont externes aux crates et composent un espace commun et un espace propre à chaque jeu.
|
||||
- Les jeux restent des crates `lib` réutilisables ; des crates `bin` Desktop distinctes servent au développement et aux smokes locaux.
|
||||
- Les générations `engine-vN` peuvent coexister lorsqu'une rupture d'API ou d'architecture l'exige.
|
||||
|
||||
## Stratégie de construction
|
||||
|
||||
Le moteur n'est pas conçu intégralement avant les jeux. Les POC alimentent progressivement le moteur : un besoin réellement rencontré est extrait vers une abstraction commune, puis stabilisé lorsque plusieurs jeux le réutilisent.
|
||||
|
||||
La séquence générale visée est :
|
||||
|
||||
```text
|
||||
POC jeu
|
||||
↓
|
||||
besoin concret
|
||||
↓
|
||||
abstraction minimale
|
||||
↓
|
||||
réutilisation par un second jeu
|
||||
↓
|
||||
stabilisation du moteur
|
||||
```
|
||||
|
||||
## Vision à moyen terme
|
||||
|
||||
Le socle peut évoluer vers un SDK interne comprenant notamment : core, SDL, input, audio, UI, assets, physique optionnelle, services plateforme, publicité, billing, leaderboard, achievements, analytics, réseau et outillage.
|
||||
|
||||
Le but n'est pas d'imiter un moteur généraliste complet dès le départ, mais d'obtenir un moteur 2D léger comparable fonctionnellement aux briques utiles d'un moteur comme melonJS : scènes, entités, sprites, animations, input, collisions, audio, tilemaps, UI, particules, caméra et loaders.
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/FILE_CONTRACTS.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Contrats des fichiers principaux
|
||||
|
||||
@@ -10,8 +10,15 @@
|
||||
- `docs/000-README.md` indexe la documentation détaillée.
|
||||
- `docs/rules/` contient les règles durables.
|
||||
- `docs/architecture/` contient les décisions et descriptions d'architecture.
|
||||
- `docs/objectives/` décrit les objectifs et la stratégie produit/technique.
|
||||
- `docs/games/` classe les familles de jeux, leurs contrôles et leurs évolutions.
|
||||
- `docs/engine/` décrit l’évolution fonctionnelle des générations de moteur.
|
||||
- `docs/monetization/` décrit les modèles de monétisation indépendamment des fournisseurs.
|
||||
- `docs/services/` décrit leaderboards, backend, partage, anti-cheat et services communautaires.
|
||||
- `docs/development/` décrit les workflows de développement non normatifs complémentaires aux règles.
|
||||
- `deltas/` contient un document par livraison ou correctif versionné.
|
||||
- `prompts/` peut contenir les prompts de reprise de session lorsqu'ils deviennent utiles.
|
||||
- `scripts/` contient des audits en lecture seule et des outils du dépôt.
|
||||
- `assets/` contient les ressources runtime communes et spécifiques aux jeux ; aucune ressource runtime n'est placée dans une crate Rust.
|
||||
- `Android/` contient le projet Gradle multi-module et son code Java commun/spécifique.
|
||||
- `crates/apps/` contient les exécutables de développement et launchers Rust, notamment les runners Desktop par jeu.
|
||||
|
||||
52
docs/rules/RULES_COMMANDS.md
Normal file
52
docs/rules/RULES_COMMANDS.md
Normal file
@@ -0,0 +1,52 @@
|
||||
<!-- file: docs/rules/RULES_COMMANDS.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Règles d'exécution des commandes
|
||||
|
||||
## Principes
|
||||
|
||||
- **CMD-GEN-001** — Une commande est exécutée avec un objectif explicite : inspection, formatage, compilation, lint, test, packaging ou diagnostic.
|
||||
- **CMD-GEN-002** — Une commande mutante n'est pas utilisée lorsqu'une commande de contrôle en lecture seule suffit.
|
||||
- **CMD-GEN-003** — Les commandes destructives ou de nettoyage global ne sont jamais exécutées par habitude.
|
||||
- **CMD-GEN-004** — Une gate n'est déclarée réussie que si la commande exacte a été exécutée sur l'état livré.
|
||||
- **CMD-GEN-005** — Les commandes ciblées sont préférées pendant le développement ; les commandes workspace complètes sont utilisées aux gates de livraison.
|
||||
- **CMD-GEN-006** — Les scripts `audit_*` sont des contrôles en lecture seule et ne corrigent jamais automatiquement les fichiers.
|
||||
|
||||
## Rust et Cargo
|
||||
|
||||
- **CMD-RUST-001** — `cargo fmt --all` peut être utilisé après une tranche cohérente pour appliquer le formatage ; il ne sert pas de diagnostic.
|
||||
- **CMD-RUST-002** — `cargo fmt --all -- --check` est la gate canonique de formatage et doit être exécutée avant livraison.
|
||||
- **CMD-RUST-003** — `cargo check --workspace` est la première gate de compilation globale après les audits statiques.
|
||||
- **CMD-RUST-004** — `cargo clippy --workspace --all-targets --all-features -- -D warnings` est exécuté après un `cargo check --workspace` propre pour la gate complète.
|
||||
- **CMD-RUST-005** — `cargo test --workspace --all-targets --all-features` est la gate de tests globale ; des tests `-p <crate>` peuvent être utilisés plus tôt pendant le développement.
|
||||
- **CMD-RUST-006** — `cargo run -p <desktop-runner>` sert aux smokes manuels Desktop et n'est pas substitué aux tests automatisés.
|
||||
- **CMD-RUST-007** — `cargo build` est utilisé lorsqu'un artefact exécutable ou une bibliothèque est réellement nécessaire ; il n'est pas lancé systématiquement en plus de `cargo check`.
|
||||
- **CMD-RUST-008** — `cargo tree` et ses variantes sont des commandes de diagnostic de dépendances, pas des gates obligatoires de chaque delta.
|
||||
- **CMD-RUST-009** — `cargo update` n'est jamais exécuté opportunistement. Toute mise à jour de dépendance doit appartenir à une tranche explicitement consacrée aux dépendances ou être nécessaire à la fonctionnalité en cours.
|
||||
- **CMD-RUST-010** — `cargo clean` n'est pas une gate et n'est pas utilisé en routine. Il n'est autorisé qu'en cas de diagnostic de build corrompu, de contrainte disque explicite ou de demande ciblée, avec justification.
|
||||
- **CMD-RUST-011** — La suppression manuelle de `target/` ne remplace pas `cargo clean` et suit les mêmes restrictions.
|
||||
|
||||
## Runners Desktop
|
||||
|
||||
- **CMD-DESKTOP-001** — Chaque jeu possédant une crate lib dispose d'une crate binaire Desktop distincte sous `crates/apps/` dès qu'un smoke local exécutable est utile.
|
||||
- **CMD-DESKTOP-002** — Le runner Desktop dépend de la crate lib du jeu et ne duplique pas le gameplay.
|
||||
- **CMD-DESKTOP-003** — Le runner Desktop est la voie privilégiée pour les itérations fonctionnelles rapides qui ne nécessitent pas une capacité Android spécifique.
|
||||
- **CMD-DESKTOP-004** — Un test Android reste obligatoire pour toute fonctionnalité dépendant du lifecycle, du tactile réel, de JNI, d'Ads, de Billing, de haptique ou d'une API Android.
|
||||
|
||||
## Android et Gradle
|
||||
|
||||
- **CMD-ANDROID-001** — Les commandes Gradle Android sont exécutées depuis `Android/` ou avec un chemin explicite vers le wrapper du projet.
|
||||
- **CMD-ANDROID-002** — Les tâches ciblées par application sont préférées, par exemple `./gradlew :game-reflex-poc:assembleDebug`, lorsqu'elles existent.
|
||||
- **CMD-ANDROID-003** — Un build Android global n'est pas exécuté si la tranche ne touche ni Android ni le contrat natif utilisé par Android.
|
||||
- **CMD-ANDROID-004** — `gradle clean` ou `./gradlew clean` n'est pas une gate normale et suit la même politique restrictive que `cargo clean`.
|
||||
- **CMD-ANDROID-005** — Les commandes Android réelles ne deviennent des gates qu'après introduction du wrapper Gradle, de l'AGP, du NDK, de SDL3 et des modules exécutables correspondants.
|
||||
|
||||
## Web
|
||||
|
||||
- **CMD-WEB-001** — Aucun gestionnaire de paquets JavaScript ni build Web n'est exécuté tant qu'un frontend Web réel n'a pas été introduit dans le dépôt.
|
||||
- **CMD-WEB-002** — Lorsqu'une cible Web existe, ses commandes de build et test sont documentées avant d'être ajoutées aux gates.
|
||||
|
||||
## Git et fichiers générés
|
||||
|
||||
- **CMD-GIT-001** — Les commandes Git destructives (`reset --hard`, nettoyage forcé, réécriture non demandée) ne sont jamais utilisées pour remettre artificiellement le workspace en état.
|
||||
- **CMD-GIT-002** — Les fichiers générés ne sont pas commités sauf contrat explicite du dépôt ou exigence de distribution.
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/RULES_DOCUMENTATION.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Règles de documentation
|
||||
|
||||
@@ -8,6 +8,7 @@
|
||||
- **DOC-003** — Les documents normatifs résident sous `docs/rules/`.
|
||||
- **DOC-004** — Les documents d'architecture résident sous `docs/architecture/`.
|
||||
- **DOC-005** — Les documents de validation résident sous `docs/validation/`.
|
||||
- **DOC-005A** — Les objectifs, classifications de jeux, évolutions moteur, monétisation, services et workflows résident dans leurs sous-répertoires thématiques de `docs/` et sont indexés par `docs/000-README.md`.
|
||||
- **DOC-006** — Les documents internes sont en français ; code, symboles et extraits techniques conservent leur langue naturelle.
|
||||
- **DOC-007** — Les tableaux Markdown suivent le format contrôlé par `scripts/audit_markdown_tables.py`.
|
||||
- **DOC-008** — Deux lignes blanches consécutives sont interdites hors blocs de code.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/RULES_PROJECT.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Règles spécifiques games.sasedev
|
||||
|
||||
@@ -7,10 +7,12 @@
|
||||
|
||||
- **GAME-WS-001** — Un seul workspace Cargo racine contient les crates Rust du dépôt.
|
||||
- **GAME-WS-002** — Toutes les crates Rust résident sous `crates/`.
|
||||
- **GAME-WS-003** — Les crates moteur résident sous `crates/engines/` et les crates jeu sous `crates/games/`.
|
||||
- **GAME-WS-003** — Les crates moteur résident sous `crates/engines/`, les crates jeu sous `crates/games/` et les exécutables/launchers réutilisant ces libs sous `crates/apps/`.
|
||||
- **GAME-WS-004** — Une crate hérite par défaut de `workspace.package.version`.
|
||||
- **GAME-WS-005** — Une crate arrivée à maturité peut porter sa propre version SemVer lorsqu'une décision documentée rend son cycle autonome nécessaire.
|
||||
- **GAME-WS-006** — Les dépendances tierces communes sont centralisées sous `[workspace.dependencies]` et consommées avec `workspace = true` lorsqu'elles sont partagées.
|
||||
- **GAME-WS-007** — Un jeu est prioritairement une crate `lib`; lorsqu’un lancement Desktop est nécessaire, une crate `bin` séparée sous `crates/apps/` dépend de cette lib et ne duplique pas son gameplay.
|
||||
- **GAME-WS-008** — Les runners Desktop sont nommés `<game>-desktop` et restent indépendants des frontends Android.
|
||||
|
||||
## Générations du moteur
|
||||
|
||||
|
||||
44
docs/services/001-ONLINE_AND_VIRAL_SERVICES.md
Normal file
44
docs/services/001-ONLINE_AND_VIRAL_SERVICES.md
Normal file
@@ -0,0 +1,44 @@
|
||||
<!-- file: docs/services/001-ONLINE_AND_VIRAL_SERVICES.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Services en ligne, compétition et viralité
|
||||
|
||||
## Leaderboards
|
||||
|
||||
Un classement peut être local, propre à une plateforme ou cross-platform via un backend commun. Les variantes envisagées incluent classement mondial, quotidien, hebdomadaire, mensuel, par pays, par plateforme ou entre amis.
|
||||
|
||||
Un backend cross-platform peut recevoir Android, Desktop et Web via HTTP et/ou WebSocket puis stocker les résultats dans une base commune.
|
||||
|
||||
## Challenges quotidiens
|
||||
|
||||
Un seed quotidien peut fournir les mêmes conditions à tous les joueurs. Ce mécanisme combine contenu peu coûteux, compétition, rétention et partage.
|
||||
|
||||
## Partage et deep links
|
||||
|
||||
Le jeu peut générer score, image, URL, QR code, replay court ou challenge personnalisé. Un lien peut ouvrir une version Web, l'application Android ou la page d'installation.
|
||||
|
||||
## Achievements et progression
|
||||
|
||||
Les achievements peuvent être locaux, liés à une plateforme ou gérés par un backend. Une méta-progression peut transformer score et sessions en XP, monnaie, skins, personnages, pouvoirs ou autres déblocages.
|
||||
|
||||
## Replays et ghosts
|
||||
|
||||
Avec un modèle suffisamment déterministe, `seed + inputs` peut représenter une partie. Cela permet replays, ghosts, comparaison avec un ami ou un meilleur score, et améliore les options anti-cheat.
|
||||
|
||||
## Anti-cheat
|
||||
|
||||
Un leaderboard public ne doit jamais considérer un score client comme intrinsèquement fiable. La progression possible va d'une acceptation simple en POC à des contrôles statistiques, une trace condensée ou une resimulation déterministe côté serveur.
|
||||
|
||||
## Backend optionnel
|
||||
|
||||
Le backend n'est pas requis pour les premiers POC. Lorsqu'il devient utile, ses capacités peuvent inclure comptes, leaderboard, cloud save, défis journaliers, statistiques, événements, saisons, anti-cheat et matchmaking.
|
||||
|
||||
Une implémentation Rust avec un framework HTTP, PostgreSQL, Redis et WebSocket est envisageable mais n'est pas imposée tant que le besoin n'existe pas.
|
||||
|
||||
## Web comme acquisition
|
||||
|
||||
La version Web peut devenir un canal marketing : ouverture immédiate depuis un lien, partie ou challenge, score, puis proposition d'installation Android. Une PWA ou une démo Web limitée peut être ajoutée ultérieurement.
|
||||
|
||||
## Cross-promotion
|
||||
|
||||
Lorsque plusieurs jeux existent, chaque produit peut proposer les autres jeux du portefeuille. Un launcher commun de type arcade reste une évolution possible, sans remplacer nécessairement les applications séparées.
|
||||
@@ -1,17 +1,26 @@
|
||||
<!-- file: docs/validation/001-VALIDATION_GATES.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Gates de validation
|
||||
|
||||
Baseline Rust et documentation :
|
||||
Gate Rust et documentation canonique :
|
||||
|
||||
```bash
|
||||
cargo fmt --all -- --check
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas prompts
|
||||
python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates Android deltas
|
||||
cargo check --workspace
|
||||
cargo clippy --workspace --all-targets --all-features -- -D warnings
|
||||
cargo test --workspace
|
||||
cargo test --workspace --all-targets --all-features
|
||||
```
|
||||
|
||||
Le build Android n'est pas une gate de `0.1.0-0-pre.1` : le projet Gradle exécutable et l'intégration SDL3/NDK sont planifiés pour une prerelease dédiée.
|
||||
Smokes Desktop ciblés lorsque le comportement exécutable concerné doit être observé :
|
||||
|
||||
```bash
|
||||
cargo run -p game-reflex-poc-desktop
|
||||
cargo run -p game-snake-poc-desktop
|
||||
```
|
||||
|
||||
Les smokes `cargo run` ne remplacent pas la gate de tests et ne sont pas obligatoires pour une modification purement documentaire.
|
||||
|
||||
Le build Android n'est pas encore une gate : le projet Gradle exécutable et l'intégration SDL3/NDK restent planifiés pour une prerelease dédiée. Dès leur introduction, les tâches ciblées par module seront documentées avant d'être rendues obligatoires.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
<!-- file: prompts/000-V0_1_0_START_PROMPT.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Prompt de reprise 0.1.0
|
||||
|
||||
Partir de la dernière livraison `0.1.0-*`, lire `RULES.md`, `ROADMAP.md`, `CHANGELOG.md`, le dernier delta et les documents d'architecture concernés. Vérifier l'état réel du workspace avant toute modification. Respecter le format de livraison delta et le cycle SemVer défini dans `docs/rules/VERSION_WORKFLOW.md`.
|
||||
Partir de la dernière livraison `0.1.0-*`, lire `RULES.md`, `ROADMAP.md`, `CHANGELOG.md`, le dernier delta et les documents d'architecture concernés. Vérifier l'état réel du workspace avant toute modification. Respecter le format de livraison delta, le cycle SemVer défini dans `docs/rules/VERSION_WORKFLOW.md` et la politique d’exécution de `docs/rules/RULES_COMMANDS.md`. Pour une évolution de gameplay portable, privilégier le runner Desktop du jeu avant Android lorsque la fonctionnalité ne dépend pas d’une API Android.
|
||||
|
||||
Reference in New Issue
Block a user