From f231188880252d0a12962435da610fc2cac1aefc Mon Sep 17 00:00:00 2001 From: StillHammer Date: Wed, 29 Oct 2025 07:28:34 +0800 Subject: [PATCH] Refactor documentation structure and add language learning MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Reorganize docs/ (flatten to architecture/ and implementation/) - Remove MonitoringModule from MVP (no app detection) - Add LanguageLearningModule to MVP - Create CLAUDE.md (concise project overview) - Add language learning to README and architecture - Update all examples to use SchedulerModule instead of MonitoringModule đŸ€– Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude --- .claude/settings.json | 7 + CLAUDE.md | 112 + docs/00-overview/README.md | 161 -- docs/00-overview/contexte-narratif.md | 100 - docs/00-overview/dlc-prevus.md | 15 - docs/00-overview/vue-ensemble.md | 268 --- .../01-architecture/architecture-technique.md | 924 -------- .../behavior-composition-patterns.md | 305 --- docs/01-architecture/player-integration.md | 397 ---- docs/02-systems/CLIMATE_SIMULATION_SYSTEM.md | 488 ----- .../GEOLOGICAL_SIMULATION_SYSTEM.md | 1886 ----------------- docs/02-systems/HYBRID_SIZE_SYSTEM.md | 46 - docs/02-systems/SIZE_CONSTRAINTS_GUIDE.md | 166 -- docs/02-systems/economie-logistique.md | 459 ---- .../factory-architecture-post-player.md | 431 ---- docs/02-systems/gameplay-industriel.md | 210 -- docs/02-systems/map-system.md | 1001 --------- .../message-communication-system.md | 419 ---- docs/02-systems/systeme-militaire.md | 884 -------- .../transport-economic-system.md | 549 ----- docs/03-implementation/systemes-techniques.md | 98 - docs/03-implementation/testing-strategy.md | 214 -- docs/04-reference/INTEGRATION-MASTER-LIST.md | 395 ---- docs/04-reference/arbre-technologique.md | 973 --------- docs/04-reference/coherence-problem.md | 486 ----- docs/04-reference/content-integrated.md | 122 -- docs/04-reference/effets-attendus.md | 89 - docs/04-reference/mecaniques-jeu.md | 525 ----- docs/04-reference/metriques-joueur.md | 269 --- docs/04-reference/questions-ouvertes.md | 319 --- docs/04-reference/updates-long-terme.md | 174 -- docs/README.md | 216 +- docs/Sources Documentaires/SMP.md | 173 -- docs/ai-framework.md | 1414 ------------ .../architecture-modulaire.md | 0 docs/architecture/architecture-technique.md | 502 +++++ .../claude-code-integration.md | 0 docs/calcul-menace.md | 752 ------- .../ADVANCED_TESTING.md | 0 .../AUTOMATION_GUIDE.md | 0 .../CLAUDE-HOT-RELOAD-GUIDE.md | 0 .../configuration/README.md | 0 .../configuration/deployment-strategies.md | 0 .../configuration/error-handling.md | 0 .../configuration/module-configuration.md | 0 .../configuration/module-versioning.md | 0 .../configuration/security-measures.md | 0 docs/systeme-diplomatique.md | 1090 ---------- docs/systeme-sauvegarde.md | 715 ------- src/Application/Program.cs | 0 50 files changed, 781 insertions(+), 16573 deletions(-) create mode 100644 .claude/settings.json create mode 100644 CLAUDE.md delete mode 100644 docs/00-overview/README.md delete mode 100644 docs/00-overview/contexte-narratif.md delete mode 100644 docs/00-overview/dlc-prevus.md delete mode 100644 docs/00-overview/vue-ensemble.md delete mode 100644 docs/01-architecture/architecture-technique.md delete mode 100644 docs/01-architecture/behavior-composition-patterns.md delete mode 100644 docs/01-architecture/player-integration.md delete mode 100644 docs/02-systems/CLIMATE_SIMULATION_SYSTEM.md delete mode 100644 docs/02-systems/GEOLOGICAL_SIMULATION_SYSTEM.md delete mode 100644 docs/02-systems/HYBRID_SIZE_SYSTEM.md delete mode 100644 docs/02-systems/SIZE_CONSTRAINTS_GUIDE.md delete mode 100644 docs/02-systems/economie-logistique.md delete mode 100644 docs/02-systems/factory-architecture-post-player.md delete mode 100644 docs/02-systems/gameplay-industriel.md delete mode 100644 docs/02-systems/map-system.md delete mode 100644 docs/02-systems/message-communication-system.md delete mode 100644 docs/02-systems/systeme-militaire.md delete mode 100644 docs/03-implementation/configuration/transport-economic-system.md delete mode 100644 docs/03-implementation/systemes-techniques.md delete mode 100644 docs/03-implementation/testing-strategy.md delete mode 100644 docs/04-reference/INTEGRATION-MASTER-LIST.md delete mode 100644 docs/04-reference/arbre-technologique.md delete mode 100644 docs/04-reference/coherence-problem.md delete mode 100644 docs/04-reference/content-integrated.md delete mode 100644 docs/04-reference/effets-attendus.md delete mode 100644 docs/04-reference/mecaniques-jeu.md delete mode 100644 docs/04-reference/metriques-joueur.md delete mode 100644 docs/04-reference/questions-ouvertes.md delete mode 100644 docs/04-reference/updates-long-terme.md delete mode 100644 docs/Sources Documentaires/SMP.md delete mode 100644 docs/ai-framework.md rename docs/{01-architecture => architecture}/architecture-modulaire.md (100%) create mode 100644 docs/architecture/architecture-technique.md rename docs/{01-architecture => architecture}/claude-code-integration.md (100%) delete mode 100644 docs/calcul-menace.md rename docs/{03-implementation => implementation}/ADVANCED_TESTING.md (100%) rename docs/{03-implementation => implementation}/AUTOMATION_GUIDE.md (100%) rename docs/{03-implementation => implementation}/CLAUDE-HOT-RELOAD-GUIDE.md (100%) rename docs/{03-implementation => implementation}/configuration/README.md (100%) rename docs/{03-implementation => implementation}/configuration/deployment-strategies.md (100%) rename docs/{03-implementation => implementation}/configuration/error-handling.md (100%) rename docs/{03-implementation => implementation}/configuration/module-configuration.md (100%) rename docs/{03-implementation => implementation}/configuration/module-versioning.md (100%) rename docs/{03-implementation => implementation}/configuration/security-measures.md (100%) delete mode 100644 docs/systeme-diplomatique.md delete mode 100644 docs/systeme-sauvegarde.md delete mode 100644 src/Application/Program.cs diff --git a/.claude/settings.json b/.claude/settings.json new file mode 100644 index 0000000..c3efb2c --- /dev/null +++ b/.claude/settings.json @@ -0,0 +1,7 @@ +{ + "permissions": { + "additionalDirectories": [ + "../GroveEngine" + ] + } +} diff --git a/CLAUDE.md b/CLAUDE.md new file mode 100644 index 0000000..aa6d787 --- /dev/null +++ b/CLAUDE.md @@ -0,0 +1,112 @@ +# AISSIA - Assistant Personnel Intelligent + +## Description + +Assistant personnel qui aide Ă  gĂ©rer le temps, l'hyperfocus et l'apprentissage de langues. Interventions proactives avec l'IA pour forcer les transitions et planifier intelligemment. + +## FonctionnalitĂ©s MVP + +1. **SchedulerModule** : Planning de tĂąches, dĂ©tection hyperfocus (max 2h), rappels de pauses +2. **AIAssistantModule** : Interventions contextuelles via Claude, dialogue naturel +3. **LanguageLearningModule** : Conversation dans langue cible, corrections intelligentes +4. **NotificationModule** : Alertes systĂšme Windows, TTS, support multilingue +5. **DataModule** : SQLite local, historique, mĂ©triques + +## Architecture Technique + +### Principe : Architecture Modulaire WarFactory + +Hot-reload 0.4ms, modules 200-300 lignes, build autonome par module. + +``` +MainServer Process +├── CoordinationModule → Charge appconfig.json +├── DebugEngine → SequentialModuleSystem +└── Modules (.dll) + ├── scheduler.dll + ├── ai-assistant.dll + ├── language.dll + ├── notification.dll + └── data.dll +``` + +### 5 Interfaces Fondamentales + +```cpp +ICoordinationModule → Orchestrateur global +IEngine → DebugEngine → HighPerfEngine +IModuleSystem → Sequential → Threaded → Cluster +IModule → Logique mĂ©tier pure (200 lignes max) +IIO → IntraIO → LocalIO → NetworkIO +``` + +### Contraintes Critiques + +**Modules** : +- 200-300 lignes maximum +- Logique mĂ©tier pure (pas de threading, network) +- Communication JSON uniquement +- Build autonome : `cmake .` depuis module + +**NEVER** : +- ❌ `cmake ..` ou `#include "../"` +- ❌ Modules > 300 lignes +- ❌ DĂ©pendances entre modules + +**ALWAYS** : +- ✅ Build autonome +- ✅ JSON communication +- ✅ Hot-reload ready +- ✅ Task-centric design + +### Workflow DĂ©veloppement + +```bash +cd modules/scheduler/ +cmake . # NEVER cmake .. +make +./scheduler-test + +# Edit SchedulerModule.cpp → Save → Hot-reload 0.4ms +``` + +### Communication Inter-Modules (JSON) + +```json +{"event": "hyperfocus", "duration_minutes": 120} + → AIAssistantModule +{"type": "break_suggestion", "message": "Pause ?"} + → NotificationModule +{"notification": "system_toast", "tts": true} +``` + +## Structure Projet + +``` +Aissia/ +├── CLAUDE.md +├── docs/ # Documentation dĂ©taillĂ©e +├── modules/ # À crĂ©er +│ ├── scheduler/ +│ ├── ai-assistant/ +│ ├── language-learning/ +│ ├── notification/ +│ └── data/ +└── src/ # Infrastructure +``` + +## PrioritĂ©s + +1. Infrastructure (IModule, IEngine, hot-reload) +2. SchedulerModule +3. NotificationModule +4. AIAssistantModule +5. LanguageLearningModule +6. DataModule + +## RĂ©fĂ©rences + +- `docs/README.md` : Vue d'ensemble +- `docs/architecture/architecture-technique.md` : Architecture complĂšte +- `CDCDraft.md` : Cahier des charges +- GroveEngine : Architecture source WarFactory (accĂšs via `.claude/settings.json`) diff --git a/docs/00-overview/README.md b/docs/00-overview/README.md deleted file mode 100644 index 33d3aac..0000000 --- a/docs/00-overview/README.md +++ /dev/null @@ -1,161 +0,0 @@ -# Documentation Warfactory - -## 🏭 Vue d'Ensemble du Projet - -Warfactory est un jeu de simulation industrielle militaire inspirĂ© de Factorio, utilisant une **architecture modulaire rĂ©volutionnaire** optimisĂ©e pour le dĂ©veloppement avec **Claude Code**. - -## 📚 Documentation Principale - -### Architecture & Design -- **[Vue Ensemble](vue-ensemble.md)** - Vision, philosophie et design du jeu -- **[Architecture Technique](architecture-technique.md)** - Multi-serveur, engines, spĂ©cifications -- **[Architecture Modulaire](architecture-modulaire.md)** - đŸ”„ **NOUVEAU** : Architecture triple interface -- **[Claude Code Integration](claude-code-integration.md)** - đŸ”„ **NOUVEAU** : Guide dĂ©veloppement IA -- **[Player Integration](player-integration.md)** - đŸ”„ **NOUVEAU** : Client/Server modulaire -- **[Factory Architecture Post-Player](factory-architecture-post-player.md)** - đŸ”„ **NOUVEAU** : Factory engine optimisĂ© -- **[Transport Economic System](transport-economic-system.md)** - đŸ”„ **NOUVEAU** : SystĂšme transport & Ă©conomique - -### SystĂšmes de Jeu -- **[Gameplay Industriel](gameplay-industriel.md)** - Production, ressources, optimisation -- **[SystĂšme Militaire](systeme-militaire.md)** - Design vĂ©hicules, combat -- **[Économie & Logistique](economie-logistique.md)** - MarchĂ©s, chaĂźnes d'approvisionnement -- **[MĂ©caniques de Jeu](mecaniques-jeu.md)** - Recherche, progression, administration - -### SystĂšmes Techniques -- **[SystĂšmes Techniques](systemes-techniques.md)** - Tiles, mĂ©moire, chunks -- **[Map System](map-system.md)** - GĂ©nĂ©ration procĂ©durale, 218+ Ă©lĂ©ments -- **[Arbre Technologique](arbre-technologique.md)** - 3000+ technologies -- **[MĂ©triques Joueur](metriques-joueur.md)** - Analytics (3.1GB par partie) - -### RĂ©solution de ProblĂšmes -- **[Coherence Problem](coherence-problem.md)** - Contradictions rĂ©solues -- **[Questions Ouvertes](questions-ouvertes.md)** - 11 items Ă  rĂ©soudre - -### Planification -- **[Contexte Narratif](contexte-narratif.md)** - Background et univers -- **[DLC PrĂ©vus](dlc-prevus.md)** - Contenus futurs -- **[Updates Long Terme](updates-long-terme.md)** - Roadmap - -## 🚀 Architecture RĂ©volutionnaire - -### Triple Interface Pattern -``` -IEngine → Coordination (Debug → Production → DataOriented) -IModuleSystem → ExĂ©cution (Sequential → Threaded → Cluster) -IModule → Logique Pure (Tank.so, Economy.so, Factory.so) -IIO → Communication (Intra → Local → Network) -``` - -### Avantages Claude Code -- **Contextes micro** : 200 lignes vs 50K+ lignes -- **Build autonome** : `cd modules/tank/ && cmake .` -- **Hot-reload** : Modifications instantanĂ©es -- **DĂ©veloppement parallĂšle** : Multiple instances Claude Code - -## 🎯 Focus Development - -### Phase Actuelle : Architecture Modulaire -- ✅ **Interfaces C++** : IEngine, IModuleSystem, IModule, IIO -- ✅ **Modules de base** : Factory, Economy, Logistic -- ✅ **Build autonome** : Chaque module = contexte indĂ©pendant -- 🔄 **Prochaine Ă©tape** : ImplĂ©mentations concrĂštes - -### Workflow de DĂ©veloppement -```bash -# DĂ©veloppement module spĂ©cifique -cd modules/factory/ -cmake . && make factory-module # → factory.so - -# Test isolĂ© -./build/factory-module - -# Hot-reload dans le jeu principal -# Aucun restart nĂ©cessaire ! -``` - -## 🎼 Vision du Jeu - -### Concept Core -- **Factory + Military** : Production industrielle + doctrine militaire -- **Échelles multiples** : Local (usines) → RĂ©gional (logistique) → Global (diplomatie) -- **Progression** : PMC → Entreprise → Corporation → Super-pouvoir - -### MĂ©caniques Principales -1. **Production Factorio-like** : ChaĂźnes d'assemblage, optimisation -2. **Design vĂ©hicules** : Grille irrĂ©guliĂšre, placement composants -3. **Combat auto-battler** : Frontlines persistantes, supervision joueur -4. **Économie dynamique** : MarchĂ©s, inflation, cycles Ă©conomiques - -## 📖 Comment Utiliser Cette Documentation - -### Pour les DĂ©veloppeurs -1. **Commencer par** : [Architecture Modulaire](architecture-modulaire.md) -2. **Puis** : [Claude Code Integration](claude-code-integration.md) -3. **Ensuite** : [Vue Ensemble](vue-ensemble.md) pour le contexte - -### Pour les Game Designers -1. **Commencer par** : [Vue Ensemble](vue-ensemble.md) -2. **Puis** : [Gameplay Industriel](gameplay-industriel.md) -3. **Ensuite** : [SystĂšme Militaire](systeme-militaire.md) - -### Pour Claude Code Sessions -1. **Toujours lire** : `/modules/{module}/CLAUDE.md` -2. **Context limitĂ©** : Module spĂ©cifique uniquement -3. **Build autonome** : `cmake .` depuis le module -4. **Max 300 lignes** : Logique pure, zĂ©ro infrastructure - -## 🔄 Statut du Projet - -### ✅ ComplĂ©tĂ© -- **Design complet** : 15+ documents de spĂ©cification -- **Architecture modulaire** : Triple interface implĂ©mentĂ©e -- **Build system** : CMake + defensive programming -- **Structure modules** : Factory, Economy, Logistic - -### 🔄 En Cours -- **Transport System** : Mode hierarchy (ship/train/air/truck) avec cost optimization -- **Market Mechanics** : Economic phases, order stacking, dynamic pricing -- **Trading Companies** : Arbitrage, transport optimization, market making -- **Geographic Economics** : Infrastructure investment, regional specialization - -### 📋 Prochaines Étapes -- **TradingModule Implementation** : Business models (arbitrage, optimization, market making) -- **MarketModule Implementation** : Economic phases, order matching, price discovery -- **InfrastructureModule Implementation** : ROI calculation, regional development -- **Integration Testing** : Transport system avec ProductionModule - ---- - -## 💡 Philosophy - -**"Complexity through Simplicity"** : CrĂ©er un jeu AAA complexe via une architecture de modules simples, chacun comprĂ©hensible et modifiable par Claude Code en isolation totale. - -**RĂ©sultat** : DĂ©veloppement 10x plus rapide avec qualitĂ© maintenue. - ---- - -## 📋 Build Commands Quick Reference - -```bash -# Module development (autonomous) -cd modules/factory/ -cmake . && make factory-module # Build factory.so -./build/factory-module # Test standalone - -# Core system -cmake . && make warfactory-core # Build core engine -./build/bin/warfactory-engine # Run main engine - -# Full system -make warfactory-modules # Build all modules -make test-all-modules # Test all modules -``` - -## 🔧 Legacy Documentation - -### Ancienne Architecture (rĂ©fĂ©rence) -- **[Engines Documentation](./engines/)** - Anciens engines (supplantĂ© par modules) -- **[Client Documentation](./client/)** - Interface system -- **[Server Documentation](./serveur/)** - Coordination (supplantĂ© par IEngine) - -Ces documents restent utiles pour comprendre le design original, mais l'implĂ©mentation actuelle utilise l'architecture modulaire. \ No newline at end of file diff --git a/docs/00-overview/contexte-narratif.md b/docs/00-overview/contexte-narratif.md deleted file mode 100644 index d0ff545..0000000 --- a/docs/00-overview/contexte-narratif.md +++ /dev/null @@ -1,100 +0,0 @@ -# Contexte narratif - -## Inspiration Ukraine - -### Motivation morale -L'Ukraine parce qu'ils sont des hĂ©ros, parce qu'ils meurent pour leur libertĂ© et pour la nĂŽtre. Sachant ce que je sais aujourd'hui, j'ai l'obligation morale de mettre en avant leur combat et leur valeur. - -Je l'oublie parfois mais la conclusion s'impose systĂ©matiquement. - -### Justification artistique -Effectivement il serait plus simple de faire un monde gĂ©nĂ©rĂ© procĂ©duralement ou whatever mais Ă  travers l'art (ce JV) l'imaginaire collectif doit se souvenir qu'il y a des gens qui meurent pour leur libertĂ©. - -De ce point de vue lĂ , je pense qu'il devient injustifiable de drop l'Ukraine. - -### Origine du concept -Sans parler que c'est de leur combat qu'a Ă©tĂ© le concept de ce jeu. Je leur dois ce jeu et ma libertĂ© Ă  "faible prix (relativement parlant)" peut-ĂȘtre autant qu'Ă  mes ancĂȘtres. - -**SLAVA UKRAINI !** - -## Lore gĂ©opolitique - -### Contexte gĂ©opolitique -**Les russes les mĂ©chants c'est sĂ»r !** - -**ScĂ©narios gĂ©opolitiques** : -- Une victoire russe en Ukraine provoque une agression chinoise sur Taiwan -- Une victoire russe en Ukraine prĂ©pare les prochains conflits en Europe - -### IntĂ©gration du lore rĂ©el -Le lore IRL doit ĂȘtre intĂ©grĂ© autant que possible sans ĂȘtre overwhelming. - -### ProblĂ©matique nuclĂ©aire -**Les nukes** : -Nations → nukes → utilisations ? → c'est chiant - -## Terrain de combat PMC - -### Zones d'opĂ©ration -- AmĂ©rique du Sud dans les zones peu peuplĂ©es -- Madagascar -- Afrique -- Ouest de la Chine -- Russie -- Moyen-Orient - -## ScĂ©narios de crise (Endgame Crisis) - -Au moins trois options avec leurs propres consĂ©quences, mĂ©caniques et variations. - -### 1. Zombie Apocalypse (militaire) - -**DĂ©fi principal** : Être surtout trĂšs rapide pour neutraliser les menaces quand elles apparaissent et de tenir les lignes si la manƓuvre a Ă©chouĂ©. - -**Types d'invasion** : -- **Romero zombie** : lent mais solide -- **Fast zombie** : rapide mais fragile -- **Bunny zombie** : Il saute c'est trĂšs fort mais trĂšs fragile -- **Classique + spĂ©ciaux** - -**Objectifs** : -- Garder le plus de gens en vie possible -- Trouver le(s) laboratoire(s) d'origine -- Y Ă©tablir une base -- Rechercher le vaccin - -### 2. Invasion ET (militaire) - -**CaractĂ©ristiques de l'ennemi** : -- Technologie supĂ©rieure et trĂšs aĂ©rienne -- RĂ©solument hostile -- Plusieurs stratĂ©gies possibles - -**Axes stratĂ©giques possibles** : -- Destruction des systĂšmes Ă©nergĂ©tiques -- Destruction des assets navals -- Invasion des points stratĂ©giques - -**Objectifs** : -- Surtout survivre -- La survie des Ă©tats peut donner un sacrĂ© boost sur la dĂ©fense planĂ©taire -- Pour les vaincre il faut dĂ©truire le vaisseau mĂšre ainsi que toutes les Ancres aliennes sur la planĂšte - -### 3. Demon Portal Invasion (militaire) - -**MĂ©caniques** : -- Impossible de savoir oĂč le portail suivant va s'ouvrir -- Il faut ĂȘtre prĂȘt Ă  agir vite et fort pour dĂ©truire les portails qui laisseront rentrer des dĂ©mons tant qu'ils ne seront pas dĂ©truits - -**StratĂ©gie ennemie** : -- Les dĂ©mons ayant pour objectif de tout dĂ©truire -- La plupart des ouvertures de portail se feront dans les villes pour occasionner un max de dĂ©gĂąts - -**MĂ©caniques de pression** : -- C'est la course pour Ă©viter les victimes -- Si trop de victimes → appelle des dĂ©mons majeurs -- Et puis du dĂ©mon mangeur de monde - -## Inspiration choix gĂ©opolitiques - -Peut-ĂȘtre s'inspirer d'Undertale pour la partie choix gĂ©opolitique. \ No newline at end of file diff --git a/docs/00-overview/dlc-prevus.md b/docs/00-overview/dlc-prevus.md deleted file mode 100644 index cde7d30..0000000 --- a/docs/00-overview/dlc-prevus.md +++ /dev/null @@ -1,15 +0,0 @@ -# DLC PrĂ©vus - -## Inspiration RimWorld - -Le projet prĂ©voit des extensions inspirĂ©es des DLC de RimWorld : - -### DLC PlanifiĂ©s -- **Anomaly** - *À dĂ©finir* -- **Biotech** - *À dĂ©finir* -- **Ideology** - *À dĂ©finir* -- **Odyssey** - *À dĂ©finir* - ---- - -*DĂ©tails et mĂ©caniques Ă  dĂ©velopper ultĂ©rieurement* \ No newline at end of file diff --git a/docs/00-overview/vue-ensemble.md b/docs/00-overview/vue-ensemble.md deleted file mode 100644 index 0430913..0000000 --- a/docs/00-overview/vue-ensemble.md +++ /dev/null @@ -1,268 +0,0 @@ -# Warfactory : Vue d'Ensemble du Projet - -## Vision Globale - -**Warfactory** est un RTS/4X rĂ©volutionnaire fusionnant la profondeur industrielle de Factorio avec une simulation militaire rĂ©aliste et une Ă©conomie mondiale dynamique. Le projet allie l'hommage moral Ă  l'Ukraine avec une architecture technique modulaire ultra-innovante, optimisĂ©e pour le dĂ©veloppement assistĂ© par IA. - -**Innovation Centrale** : Un systĂšme Ă©conomique oĂč TOUS les acteurs (joueur, IA, États) suivent exactement les mĂȘmes rĂšgles Ă©conomiques, crĂ©ant une simulation authentique et Ă©ducative des marchĂ©s mondiaux. - -## Concept de Jeu et Progression - -### De PMC Ă  GĂ©ant Industriel -**Progression naturelle** : -- **Phase PMC** : OpĂ©rations irrĂ©guliĂšres limitĂ©es, contrats d'État -- **Phase Industrielle** : Production civile/militaire, expansion gĂ©ographique -- **Phase GĂ©opolitique** : Influence mondiale, doctrines militaires, crises planĂ©taires - -**LibertĂ© d'Ă©chelle** : Philosophie bac Ă  sable permettant au joueur de rester artisan local ou de dĂ©fier Lockheed Martin selon ses ambitions. - -### Principe "Skip vs Optimize" -**Design fondamental** : Tous les systĂšmes peuvent ĂȘtre automatisĂ©s ou micro-gĂ©rĂ©s -- **Skip** : Solutions automatisĂ©es, efficacitĂ© rĂ©duite mais accessibles -- **Optimize** : ContrĂŽle manuel complet, efficacitĂ© maximale -- **Hybride** : Mix selon prĂ©fĂ©rences et contexte - -Exemples concrets : -- **Production** : Usines tout-en-un vs layouts Factorio optimisĂ©s -- **Combat** : IA tactique vs commande directe -- **Commerce** : Auto-trade vs nĂ©gociation manuelle - -## SystĂšmes Industriels IntĂ©grĂ©s - -### Architecture Factorio-like AvancĂ©e -**CƓur productif** : -- **Production modulaire** : Belts, inserters, factories avec Ă©volution progressive -- **4 phases de complexitĂ©** : Mono → Multi-lanes → Bidirectionnel → Full Factorio -- **QualitĂ© d'assemblage** : Placement optimal vs automatique avec pĂ©nalitĂ©s rĂ©alistes - -**Innovation : Dual Production System** : -- **Production brute** : Transformation ressources primaires (minerai → plaques) -- **Assemblage prĂ©cis** : Placement composants selon grilles vehicules - -### FlexibilitĂ© de Reconversion Industrielle -**MĂ©caniques rĂ©alistes** basĂ©es sur similaritĂ© des processus : -- **Facile** : Tables fer → Blindages (mĂȘme matĂ©riaux, processus similaires) -- **Complexe** : Tables → Canons (prĂ©cision usinage, alliages spĂ©ciaux) -- **Impossible** : Menuiserie → Production hydrogĂšne (zĂ©ro overlap technologique) - -## SystĂšme Militaire RĂ©volutionnaire - -### Conception de VĂ©hicules par Grilles -**Innovation gameplay** : Design sur chĂąssis irrĂ©guliers avec zones spĂ©cialisĂ©es - -**Interface intuitive** : -- **Pick & Place** : Drag & drop composants avec rotations A/E -- **Snap toggle** : R pour alignement grille -- **Validation temps rĂ©el** : Contraintes poids/Ă©nergie vĂ©rifiĂ©es durant placement - -**DiversitĂ© massive** : -- **ChĂąssis nommĂ©s** : "Griffon" (chenillĂ©), "Viper" (modulaire), "Fennec" (ultra-lĂ©ger) -- **3 layers** : ChĂąssis → SystĂšmes → Armes & Capteurs -- **1000+ composants** : Formes uniques, jamais carrĂ©es ni 1x1 - -### SystĂšme d'AmĂ©lioration GĂ©nĂ©rique -**AmĂ©liorations universelles** stackables avec rendements dĂ©croissants : -- **High ROF** : +20% cadence, +40% chaleur (stack 1), puis +10%/+40% (stack 2) -- **Efficiency** : -20% consommation, -15% performance -- **Reliability** : +30% durabilitĂ©, -10% performance - -**CoĂ»t exponentiel** : 1.25^n per stack avec malus cumulatifs linĂ©aires - -## Économie Mondiale SimulĂ©e - -### ÉgalitĂ© Économique Fondamentale -**RÈGLE NON-NÉGOCIABLE** : Le joueur n'a AUCUN privilĂšge Ă©conomique artificiel - -```cpp -// INTERDIT - Avantage joueur -if(agent.isPlayer()) order.cost *= 0.9f; - -// OBLIGATOIRE - Traitement Ă©gal -float cost = calculateRealTransportCost(order); -agent.processOrder(order, cost); -``` - -**RĂ©sultat** : RĂ©ussite basĂ©e sur comprĂ©hension Ă©conomique rĂ©elle, pas sur privilĂšges artificiels. - -### SystĂšme de Companies avec Features -**Chaque IA company** a 2-4 features dĂ©finissant ses capacitĂ©s : -- **Domaines** : Metal, Electronic, Tank, Plane, Wood, Food, Engine, Cannon, Missile -- **Modificateurs** : Quality, Quantity, Speed, Cost, Modularity, Innovation - -**Exemple** : Company "Metal + Plane + Quantity + Electronic" excelle en avions mĂ©talliques de masse avec Ă©lectronique embarquĂ©e, mais manque raffinement vs spĂ©cialistes Quality. - -### Transport Multi-Modal RĂ©aliste -**HiĂ©rarchie des coĂ»ts** (indicative) : -- **Maritime** : ~0.10€/kg (volume massif, ultra-Ă©conomique) -- **Ferroviaire** : ~0.50€/kg (grandes quantitĂ©s, infrastructure) -- **AĂ©rien** : ~2.00€/kg (rapide, coĂ»teux) -- **Routier** : ~5.00€/kg (flexible, dernier kilomĂštre) - -**Impact stratĂ©gique** : Localisation cĂŽtiĂšre = avantage Ă©conomique 50x - -### MarchĂ©s SegmentĂ©s et Restrictions -**Types de marchĂ©s** : -- **Nationaux** : Par pays avec politiques douaniĂšres -- **Companies privĂ©s** : Accords bilatĂ©raux -- **Blocs multinationaux** : UE, OTAN avec prĂ©fĂ©rences -- **Mondial** : MarchĂ© libre avec sanctions possibles - -**Doubles verrous** : Companies ET États peuvent bloquer accĂšs - -## Architecture Technique RĂ©volutionnaire - -### ModularitĂ© Claude Code OptimisĂ©e -**Innovation dĂ©veloppement** : Architecture modulaire rĂ©volutionnaire pour dĂ©veloppement IA - -**Contraintes strictes** : -- **200-300 lignes max** par module (EXCEPTION : ProductionModule 500-800) -- **Build autonome** : `cd modules/tank/ && cmake .` - zĂ©ro dĂ©pendance parent -- **Hot-reload 0.4ms** : Modifications instantanĂ©es sans restart -- **DĂ©veloppement parallĂšle** : 3+ instances Claude Code simultanĂ©es - -### Interface System IMMUTABLE -**5 interfaces fondamentales** (JAMAIS modifiĂ©es une fois finalisĂ©es) : -```cpp -ICoordinationModule → Orchestrateur global systĂšme -IEngine → Coordination locale (Debug → HighPerf → DataOriented) -IModuleSystem → StratĂ©gie d'exĂ©cution (Sequential → Threaded → Cluster) -IModule → Logique mĂ©tier pure (TankModule.so, EconomyModule.so) -IIO → Communication (IntraIO → LocalIO → NetworkIO) -``` - -### Évolution Progressive Sans RĂ©gression -```cpp -// Phase 1 : Prototype -DebugEngine + SequentialModuleSystem + IntraIO - -// Phase 2 : Optimization -DebugEngine + ThreadedModuleSystem + IntraIO - -// Phase 3 : Production -HighPerfEngine + MultithreadedModuleSystem + LocalIO - -// Phase 4 : MMO Scale -DataOrientedEngine + ClusterModuleSystem + NetworkIO -``` - -**Avantage rĂ©volutionnaire** : Modules mĂ©tier inchangĂ©s Ă  travers toutes les phases ! - -## Carte et Exploration - -### Architecture Multi-Échelles -**2 niveaux discrets** : -- **Large Map** : Carte mondiale Ă©ditable, navigation node-based -- **Local Map** : Tiles 1m×1m, chunks 64×64, style Factorio prĂ©cis - -### GĂ©nĂ©ration ProcĂ©durale par Budget de Points -**Innovation systĂšme** : Chaque tile reçoit score (-10 Ă  +10) Ă©quilibrant automatiquement risques/rĂ©compenses - -**218+ Ă©lĂ©ments** avec tendances rĂ©gionales : -- **Bassins pĂ©troliers** : PĂ©trole ×5 probabilitĂ©, terrains marĂ©cageux ×2 -- **Zones ex-miniĂšres** : Fer/charbon ×3-4, teritons ×8, pollution hĂ©ritĂ©e ×3 -- **RĂ©gions forestiĂšres** : ForĂȘt dense ×3-4, grottes ×2-3, pentes abruptes ×2 - -**DĂ©couverte stratifiĂ©e** : -- **Visible** : Relief, vĂ©gĂ©tation, structures surface -- **CachĂ© niveau 1** : Prospection gĂ©ologique (gisements souterrains) -- **CachĂ© niveau 2** : MagnĂ©tomĂ©trie (anomalies, structures enfouies) -- **CachĂ© niveau 3** : Analyse NRBC (contaminations invisibles) - -## Arbre Technologique Massif - -### 3000+ Technologies pour RejouabilitĂ© Infinie -**Principe dĂ©couverte** : Player ne recherche PAS toutes les technologies ! -- **Discovery organique** : Breakthrough via gameplay naturel -- **10-50 techs Ă©ligibles** simultanĂ©ment (jamais 3000) -- **SystĂšme de passerelles** : Expertise dans un domaine dĂ©bloque prototypes dans autres - -**Exemple passerelles ChĂąssis** : -``` -MĂ©tallurgie AvancĂ©e → [PROTOTYPE] ChĂąssis Composite -Électronique → [PROTOTYPE] ChĂąssis Smart -Moteur → [PROTOTYPE] ChĂąssis Performance -``` - -## Contexte Narratif et Éthique - -### Hommage Ă  l'Ukraine -**Motivation morale fondamentale** : "L'Ukraine parce qu'ils sont des hĂ©ros, parce qu'ils meurent pour leur libertĂ© et pour la nĂŽtre." - -**IntĂ©gration authentique** : -- **GĂ©ographie rĂ©elle** : Ukraine, Europe sur carte mondiale -- **Contexte historique** : Zones post-industrielles, vestiges soviĂ©tiques -- **Enjeux gĂ©opolitiques** : RĂ©sistance dĂ©mocratique vs autoritarisme - -### Crises Endgame -**3 scĂ©narios apocalyptiques** avec mĂ©caniques distinctes : -- **Zombie Apocalypse** : Vitesse de rĂ©action, lignes de dĂ©fense -- **Invasion ET** : Technologie supĂ©rieure aĂ©rienne, survie planĂ©taire -- **Demon Portal** : Portails imprĂ©visibles, course contre extermination - -## Interface Utilisateur RĂ©volutionnaire - -### SystĂšme IUI Data-Agnostic -**Architecture gĂ©nĂ©rique** supportant tous types de contenu : -- **Enums type-safe** : `DataType::ECONOMY`, `RequestType::GET_PRICES` -- **Windowing hiĂ©rarchique** : Parent → Dock → Split → Tab → Window -- **Hybrid Sizing System** : Cibles pourcentage avec contraintes pixels - -**Layout professionnel** : Topbar Ă©conomique + panel companies + carte stratĂ©gique + console - -## Performance et ScalabilitĂ© - -### FrĂ©quences Modulaires OptimisĂ©es -- **ProductionModule** : 60Hz (frame-perfect factory) -- **TankModule Targeting** : 60Hz (combat rĂ©actif) -- **TankModule Movement** : 30Hz (positions) -- **TankModule Tactical** : 1Hz (dĂ©cisions stratĂ©giques) -- **EconomyModule** : 0.01-0.1Hz (cycles Ă©conomiques) - -### Targets Performance -- **V1 Client** : 30+ fps, 10+ joueurs serveur -- **V2 Client** : 60+ fps, 100+ joueurs serveur avec prĂ©diction locale - -## Philosophie de Design AvancĂ©e - -### "Complexity through Simplicity" -**ComplexitĂ© AAA** Ă©mergeant de modules simples Claude-friendly : -- **Modules 200 lignes** = comprĂ©hension IA parfaite -- **Interactions complexes** = gameplay Ă©mergent sophistiquĂ© -- **Testing granulaire** = fiabilitĂ© et dĂ©bug facilitĂ©s - -### Configuration vs Modding -**Philosophy YAGNI** : Configuration JSON couvre 90% besoins modding -```json -{ - "tank_mk2_custom": { - "health": 150, "speed": 30, - "weapons": ["cannon_105mm", "mg_coaxial"] - }, - "aggressive_ai": { - "engagement_range": 1000, - "retreat_threshold": 20 - } -} -``` - -## État Actuel et Roadmap - -### PRODUCTION-READY Achievements -- ✅ **Core Interfaces COMPLETE** : Architecture modulaire immutable finalisĂ©e -- ✅ **UI System COMPLETE** : IUI + ImGuiUI avec hybrid sizing rĂ©volutionnaire -- ✅ **Hot-Reload 0.4ms** : Workflow dĂ©veloppement rĂ©volutionnĂ© -- ✅ **Configuration System** : IDataTree avec validation SHA256 -- ✅ **Cross-Platform Pipeline** : Linux dev → Windows .exe automatisĂ© - -### Next Phases -1. **Phase 2** : ImplĂ©mentations concrĂštes (DebugEngine, JSONDataTree) -2. **Phase 3** : Modules gameplay (ProductionModule, TankModule) -3. **Phase 4** : Integration Ă©conomique et multijoueur - -## Conclusion : Une Vision RĂ©volutionnaire - -Warfactory transcende les genres traditionnels en unifiant industrie, stratĂ©gie militaire et simulation Ă©conomique authentique dans une architecture technique rĂ©volutionnaire. - -Le projet honore l'hĂ©roĂŻsme ukrainien tout en repoussant les limites du dĂ©veloppement assistĂ© par IA, crĂ©ant un gameplay Ă©mergent d'une profondeur inĂ©galĂ©e oĂč chaque choix - industriel, militaire, Ă©conomique - rĂ©sonne Ă  travers un systĂšme interconnectĂ© d'une complexitĂ© et d'un rĂ©alisme saisissants. - -**Slava Ukraini !** \ No newline at end of file diff --git a/docs/01-architecture/architecture-technique.md b/docs/01-architecture/architecture-technique.md deleted file mode 100644 index 423566e..0000000 --- a/docs/01-architecture/architecture-technique.md +++ /dev/null @@ -1,924 +0,0 @@ -# Architecture Technique - -## Vision Globale - -**Concept** : RTS/4X hybride hommageant l'Ukraine avec systĂšme industriel complexe (Factorio-like), simulation militaire rĂ©aliste et gestion gĂ©opolitique. - -**Innovation clĂ©** : Architecture multi-serveurs modulaire permettant scaling horizontal et dĂ©veloppement parallĂšle par IA. - -## Architecture SystĂšme - -### Core Interface Architecture - -**ARCHITECTURE MODULAIRE** - SystĂšme modulaire optimisĂ© pour le dĂ©veloppement avec Claude Code. - -#### Les 5 Interfaces Fondamentales - -```cpp -ICoordinationModule → Orchestrateur global systĂšme (MainServer, dĂ©ploiement, config) -IEngine → Coordination locale (DebugEngine → HighPerfEngine → DataOrientedEngine) -IModuleSystem → StratĂ©gie d'exĂ©cution (Sequential → Threaded → Multithread → Cluster) -IModule → Logique mĂ©tier pure (TankModule.so, EconomyModule.so, FactoryModule.so) -IIO → Communication (IntraIO → LocalIO → NetworkIO) -``` - -#### Architecture de DĂ©ploiement Global - -``` -MainServer Process: -├── CoordinationModule (Global Orchestrator) -│ ├── Loads gameconfig.json via IDataTree -│ ├── Manages local IEngine + modules -│ └── Launches remote servers + engines -├── Local IEngine (manages local modules) -│ ├── IModuleSystem (Sequential/Threaded/etc.) -│ └── Local Modules (.so files) -└── Remote Servers (launched by coordination) - ├── Remote IEngine (manages remote modules) - ├── IModuleSystem (execution strategy) - └── Remote Modules (.so files) -``` - -#### SĂ©paration des ResponsabilitĂ©s - -**IEngine** : Orchestration et coordination -- DebugEngine : DĂ©veloppement et test (step-by-step, verbose logging) -- HighPerfEngine : Production optimisĂ©e (threading, memory management) -- DataOrientedEngine : Scale massive (SIMD, cluster distribution) - -**IModuleSystem** : StratĂ©gies d'exĂ©cution -- SequentialModuleSystem : Debug/test (1 module Ă  la fois) -- ThreadedModuleSystem : Chaque module dans son thread -- MultithreadedModuleSystem : Pool de threads pour tasks -- ClusterModuleSystem : Distribution sur plusieurs machines - -**ICoordinationModule** : Orchestrateur global systĂšme -- Premier module lancĂ©, dernier fermĂ© -- Charge gameconfig.json via IDataTree -- DĂ©ploie modules selon topologie (local/distant) -- Synchronise configurations entre tous les modules - -**IModule** : Logique mĂ©tier pure (BREAKING CHANGES) -```cpp -class IModule { - virtual json process(const json& input) = 0; // PURE FUNCTION - virtual void setConfiguration(const IDataNode& configNode, IIO* io, ITaskScheduler* scheduler) = 0; // NEW - virtual const IDataNode& getConfiguration() = 0; // NEW - virtual json getHealthStatus() = 0; // NEW - detailed JSON instead of bool - virtual void shutdown() = 0; - // initialize() method REMOVED -}; -``` - -**Contraintes strictes** : -- **200-300 lignes maximum** par module (EXCEPTION: ProductionModule 500-800 lignes) -- **Aucune dĂ©pendance infrastructure** (threading, network, etc.) -- **JSON in/out uniquement** pour communication -- **Logic mĂ©tier pure** sans effets de bord - -**Exception ProductionModule** : -- **Belt+Inserter+Factory DOIVENT cohabiter** dans le mĂȘme module pour performance critique -- **500-800 lignes acceptĂ©es** pour ce module spĂ©cifiquement -- **Raison** : ISocket overhead >1ms inacceptable pour production 60 FPS -- **Trade-off conscient** : ComplexitĂ© accrue mais performance garantie - -### DĂ©composition War en SubsystĂšmes Asynchrones - -**Principe** : Le module War dĂ©composĂ© en subsystĂšmes avec frĂ©quences d'exĂ©cution diffĂ©rentes - -**SubsystĂšmes identifiĂ©s** : -- **Targeting** : Acquisition et tracking des cibles (haute frĂ©quence) -- **Movement** : DĂ©placement et physique des unitĂ©s (frĂ©quence moyenne) -- **Pathfinding** : Calcul des routes optimales (Ă  la demande) -- **Tactical** : DĂ©cisions tactiques et IA (basse frĂ©quence) -- **Analytics** : MĂ©triques et statistiques de combat (trĂšs basse frĂ©quence) - -**Avantages de la dĂ©synchronisation** : -- **Performance** : Chaque systĂšme tourne Ă  sa frĂ©quence optimale -- **ScalabilitĂ©** : Distribution possible sur threads/cores diffĂ©rents -- **ModularitĂ©** : SystĂšmes indĂ©pendants plus faciles Ă  maintenir -- **RĂ©activitĂ©** : SystĂšmes critiques (targeting) restent fluides - -**TolĂ©rance RĂ©seau War** : -- **50-100ms de latence acceptable** pour dĂ©cisions stratĂ©giques -- Combat n'est pas frame-perfect comme un FPS -- Synchronisation relaxĂ©e suffisante pour RTS/stratĂ©gie -- Permet joueurs avec connexions moyennes - -**IIO** : Couche transport -- IntraIO : Appel direct (mĂȘme processus) -- LocalIO : Named pipes/sockets (mĂȘme machine) -- NetworkIO : TCP/WebSocket (rĂ©seau) - -#### Évolution Progressive Sans RĂ©gression - -```cpp -// Phase 1 : Prototype -DebugEngine + SequentialModuleSystem + IntraIO -→ DĂ©veloppement ultra-rapide, Claude Code 100% focus logique - -// Phase 2 : Optimization -DebugEngine + ThreadedModuleSystem + IntraIO -→ Performance boost sans changer 1 ligne de game logic - -// Phase 3 : Production -HighPerfEngine + MultithreadedModuleSystem + LocalIO -→ Scale transparent, TankModule.so inchangĂ© - -// Phase 4 : MMO Scale -DataOrientedEngine + ClusterModuleSystem + NetworkIO -→ Distribution massive, mĂȘme logique mĂ©tier -``` - -**Avantage rĂ©volutionnaire** : Les modules de logique mĂ©tier (TankModule.so, EconomyModule.so) restent identiques Ă  travers toutes les phases d'Ă©volution ! - -### Contrainte Design Fondamentale : Task-Centric Logic - -**CRITICAL** : Les modules doivent ĂȘtre conçus avec une **task-centric logic** dĂšs le dĂ©but pour supporter l'Ă©volution progressive. - -#### Task-Centric Logic Requirements -```cpp -class IModule { - virtual json process(const json& task) = 0; // TASK-CENTRIC DESIGN - // task = unitĂ© de travail atomique, pas state global - // Permet distribution future sans refactoring -}; -``` - -**Implications design** : -- **Stateless preferred** : Tasks indĂ©pendantes autant que possible -- **GranularitĂ© fine** : 1 task = 1 opĂ©ration logique discrĂšte -- **Context minimal** : Task contient tout le contexte nĂ©cessaire -- **Results self-contained** : Output complet pour la task - -#### Évolution Progressive DĂ©taillĂ©e - -**Phase 1 : Debug/Prototype** -```cpp -DebugEngine + SequentialModuleSystem + IntraIO -``` -- **Execution** : Tasks traitĂ©es sĂ©quentiellement par mĂȘme thread -- **Flow** : Module1.process(task1) → Module2.process(task2) → Module3.process(task3) -- **Avantage** : Debug step-by-step, Claude Code friendly -- **Task-centric** : PrĂ©pare la distribution future - -**Phase 2 : Optimization** -```cpp -DebugEngine + ThreadedModuleSystem + IntraIO -``` -- **Execution** : Tasks distribuĂ©es par module sur threads dĂ©diĂ©s -- **Flow** : Module1(Thread A), Module2(Thread B) - tasks parallĂšles -- **Avantage** : Performance sans changer task logic - -**Phase 3 : Production** -```cpp -HighPerfEngine + MultithreadedModuleSystem + LocalIO -``` -- **Execution** : **Task queue + worker thread pool** -- **Flow** : Tasks distribuĂ©es sur pool selon disponibilitĂ© et prioritĂ© -- **Avantage** : Load balancing automatique des tasks - -**Phase 4 : MMO Scale** -```cpp -DataOrientedEngine + ClusterModuleSystem + NetworkIO -``` -- **Execution** : **Tasks distribuĂ©es sur machines diffĂ©rentes** -- **Flow** : TankTasks (Server A), EconomyTasks (Server B) -- **Avantage** : Scale horizontal transparent grĂące au task-centric design - -**Évolution Garantie** : Le task-centric design initial permet l'Ă©volution automatique vers la distribution sans rĂ©Ă©criture de logique mĂ©tier ! - -### Distribution Performance-Based - -**Classification :** CRITICAL - ImplĂ©mentation immĂ©diate requise -**Principe :** Distribution intelligente basĂ©e sur contraintes de performance - -#### Classification des Modules par Performance - -**Critical Locale (ExĂ©cution Locale Obligatoire) :** -- **ProductionModule** : <1ms latence pour 60fps frame-perfect -- **TankModule (targeting)** : <16ms pour 60Hz combat responsiveness -- **UI/Input modules** : <5ms pour rĂ©activitĂ© utilisateur immĂ©diate - -**Strategic DistribuĂ©e (Distribution RĂ©seau Acceptable) :** -- **EconomyModule** : 1000ms tolĂ©rable pour dĂ©cisions Ă©conomiques -- **MapModule (chunks)** : 500ms acceptable pour streaming asynchrone -- **Analytics modules** : 5000ms+ acceptable pour mĂ©triques - -**Mixed (Performance Contextuelle) :** -- **LogisticModule** : 50ms transport temps rĂ©el vs 1000ms planification - -#### Table de Distribution Performance - -| Module | Type | Latence Max | IIO Optimal | Justification | -|--------|------|-------------|-------------|---------------| -| ProductionModule | Critical | <1ms | IntraIO | 60fps frame-perfect requis | -| TankModule | Critical | <16ms | IntraIO/LocalIO | Combat responsiveness | -| EconomyModule | Strategic | 1000ms | NetworkIO | DĂ©cisions tolĂšrent dĂ©lai | -| MapModule | Strategic | 500ms | NetworkIO | Streaming asynchrone | -| LogisticModule | Mixed | 50-1000ms | LocalIO/NetworkIO | Context-dependent | - -#### Implications Utilisateurs - -**Performance garantie :** -- **ResponsivitĂ© critique preservĂ©e** : Factory/combat toujours fluides (local) -- **Scaling transparent** : Ajout joueurs sans impact performance locale -- **Adaptation rĂ©seau automatique** : QualitĂ© connexion n'affecte pas gameplay core -- **Mode dĂ©gradĂ© intelligent** : Basculement local si rĂ©seau dĂ©faillant - -**ExpĂ©rience utilisateur optimisĂ©e :** -- **Latence imperceptible** : Actions critiques feedback instantanĂ© -- **Bandwidth efficient** : Seuls modules strategic utilisent rĂ©seau -- **Offline capability** : Modules critical fonctionnent sans connexion -- **Performance prĂ©visible** : ExpĂ©rience identique solo vs multiplayer - -#### Implications DĂ©veloppeurs - -**Architecture optimisĂ©e Claude Code :** -- **Classification dĂšs design** : Contraintes performance explicites par module -- **Debugging simplifiĂ©** : Modules critical toujours accessibles localement -- **Testing isolĂ©** : Performance testing sans infrastructure rĂ©seau -- **Build autonome** : Profiling performance intĂ©grĂ© par module - -**Workflow dĂ©veloppement :** -- **Distribution automatique** : IIO routing basĂ© sur profil performance -- **Evolution progressive** : Migration Critical→Strategic selon optimisation -- **Profiling prĂ©cis** : MĂ©triques performance par catĂ©gorie module -- **Context minimal** : Focus logique mĂ©tier pure, classification implicite - -#### IntĂ©gration Triple Interface - -**IIO Performance-Aware Routing :** -```cpp -// Automatic routing based on module performance profile -if (module.latencyRequirement < 1ms) { - use IntraIO; // Critical - same process -} else if (module.latencyRequirement < 50ms) { - use LocalIO; // Mixed - same machine -} else { - use NetworkIO; // Strategic - distributed -} -``` - -**Migration transparente par phases :** -- **Phase 1 (Dev)** : Tous modules IntraIO pour debugging -- **Phase 2 (Prod)** : Critical IntraIO, Strategic LocalIO -- **Phase 3 (MMO)** : Critical IntraIO, Strategic NetworkIO worldwide - -### Build Autonome par Module - -**Classification :** HIGH - ImplĂ©mentation prioritaire -**Principe :** `cmake .` depuis chaque module, zĂ©ro dĂ©pendance parent - -#### Structure de Build Autonome - -**Directory pattern requis :** -``` -modules/tank/ -├── CMakeLists.txt # Autonomous build config -├── CLAUDE.md # Module-specific instructions -├── src/ -│ ├── TankModule.cpp # 200 lignes max -│ └── TankModule.h # Interface pure -├── tests/ -│ └── tank_test.cpp # Standalone testing -└── build/ # Local build artifacts - └── tank.so # Hot-reloadable module -``` - -**CMake autonome pattern :** -```cmake -# NEVER cmake .. - ALWAYS cmake . -cmake_minimum_required(VERSION 3.20) -project(TankModule) - -# Self-contained dependencies -find_package(nlohmann_json REQUIRED) - -# Pure module compilation -add_library(tank MODULE src/TankModule.cpp) -target_link_libraries(tank nlohmann_json::nlohmann_json) - -# Standalone testing -add_executable(tank-test tests/tank_test.cpp) -target_link_libraries(tank-test tank) -``` - -#### Implications Utilisateurs - -**Performance dĂ©veloppement rĂ©volutionnaire :** -- **Build ultra-rapide** : 5 secondes vs 5 minutes (60x faster) -- **Debugging isolĂ©** : Test module sans infrastructure complĂšte -- **ParallĂ©lisme naturel** : Multiple builds simultanĂ©s sans conflit -- **StabilitĂ© accrue** : Modification module N n'affecte jamais module M - -**ExpĂ©rience dĂ©veloppeur optimisĂ©e :** -- **Context switching minimal** : Focus total sur logique module -- **Error isolation parfaite** : Compilation errors localisĂ©es uniquement -- **Testing granulaire** : Validation unitaire immĂ©diate et autonome -- **Hot-reload ready** : Module.so prĂȘt pour remplacement instantanĂ© - -#### Implications DĂ©veloppeurs - -**Architecture modulaire pure :** -- **Zero dependencies up** : Jamais `#include "../core/engine.h"` -- **Self-contained units** : Chaque module = micro-projet autonome -- **Interface contracts only** : Communication via JSON/IModule uniquement -- **Infrastructure agnostic** : Module ignore engine/system hosting - -**Workflow Claude Code rĂ©volutionnaire :** -- **Micro-context focus** : 200-300 lignes + CMakeLists.txt + CLAUDE.md total -- **Parallel instances** : 3+ Claude Code travaillant simultanĂ©ment -- **Build verification** : `cmake . && make` validation automatique -- **Development velocity** : 10x improvement mesurable - -#### Contraintes Strictes CRITICAL - -**NEVER patterns (violations = build failure) :** -- `cd ..` ou `cmake ..` - Toujours rester dans module directory -- `#include "../"` - Aucune rĂ©fĂ©rence parent directory -- Dependency sur `core/` ou `shared/` - Module = island complet -- Shared C++ objects - JSON communication exclusive - -**ALWAYS patterns (required for autonomy) :** -- `cd modules/tank/ && cmake .` - Build depuis module directory -- Interface-only dependencies - IModule.h via find_package uniquement -- Local build artifacts - `build/` directory dans module -- Standalone testing - Tests s'exĂ©cutent sans infrastructure -- Unit tests intĂ©grĂ©s - `#ifdef TESTING` validation autonome modules -- Behavior composition - Modules comportements combinables via config JSON - -#### MĂ©triques de Performance - -| Metric | Avant (Monolithe) | AprĂšs (Autonome) | AmĂ©lioration | -|--------|-------------------|------------------|--------------| -| Build time | 2-5 min | <5 sec | 24-60x faster | -| Context size | 50K+ lignes | 200-300 lignes | 250x smaller | -| Parallel dev | 1 instance | 3+ instances | 3x+ throughput | -| Error isolation | Project-wide | Module-only | Perfect isolation | -| Iteration cycle | 5-10 min | 5 sec | 60-120x faster | - -### Hot-Reload Infrastructure - -**Classification :** HIGH - ImplĂ©mentation prioritaire -**Principe :** Remplacement temps rĂ©el modules DLL/SO avec sauvegarde Ă©tat - -#### Architecture Hot-Reload - -**Platform Support :** -- **Primary** : .dll (Windows gaming natif) -- **Future** : .so (Linux server/dev support) -- **Unified interface** : MĂȘme mĂ©canisme, extension diffĂ©rente - -**Workflow cible :** -```bash -# Edit TankModule.cpp → Save → Auto-rebuild tank.dll -# SystĂšme dĂ©tecte changement → Hot-reload → Game continue -# <5 secondes total sans interruption -``` - -#### MĂ©canisme Technique - -**Windows DLL Hot-Reload :** -```cpp -// State preservation avant reload -json moduleState = currentModule->exportState(); - -// Hot-swap DLL -FreeLibrary(tankDLL); // DĂ©charge ancienne -tankDLL = LoadLibrary(L"tank.dll"); // Charge nouvelle version - -// State restoration aprĂšs reload -auto createFunc = GetProcAddress(tankDLL, "CreateTankModule"); -newModule = createFunc(); -newModule->importState(moduleState); // Restore Ă©tat -``` - -**Build DLL autonome :** -```cmake -# modules/tank/CMakeLists.txt -add_library(tank SHARED src/TankModule.cpp) -set_target_properties(tank PROPERTIES - SUFFIX ".dll" # Windows primary - POSITION_INDEPENDENT_CODE ON # Linux SO ready -) -``` - -#### Implications Utilisateurs - -**DĂ©veloppement rĂ©volutionnaire :** -- **Feedback instantanĂ©** : Changements visibles immĂ©diatement sans restart -- **Flow state preserved** : Concentration maintenue, zĂ©ro interruption -- **Session continuity** : DonnĂ©es de jeu prĂ©servĂ©es pendant dĂ©veloppement -- **Real-time testing** : Validation changements en contexte rĂ©el - -**ExpĂ©rience gameplay optimisĂ©e :** -- **Config tweaking live** : Modification paramĂštres Ă  chaud -- **Balance updates instant** : Ajustements gameplay sans redĂ©marrage -- **Bug fixes immediate** : Corrections appliquĂ©es en temps rĂ©el -- **A/B testing dynamic** : Switch comportements dynamiquement - -#### Implications DĂ©veloppeurs - -**Workflow ultra-optimisĂ© :** -- **Edit → Save → Test** : Cycle 5 secondes vs 5 minutes (60x faster) -- **State preservation** : Contexte dĂ©veloppement totalement maintenu -- **Debug facilitĂ©** : Isolation prĂ©cise des changements -- **Experimentation rapide** : Testing hypothĂšses ultra-rapide - -**Architecture requirements :** -- **State serialization** : JSON export/import complet Ă©tat module -- **Interface stability** : IModule contracts prĂ©servĂ©s pendant reload -- **Memory safety** : Cleanup automatique ancien module, zĂ©ro leak -- **Thread safety** : Hot-swap sans race conditions - -#### File Watching & Auto-Rebuild - -**Monitoring automatique :** -```cpp -// File system watcher -FileWatcher watcher("modules/tank/"); -watcher.onChange("*.cpp", [](){ - rebuildModule("tank"); - hotReloadModule("tank.dll"); -}); -``` - -**Build pipeline intĂ©grĂ© :** -- **Change detection** : .cpp modification trigger auto-build -- **Compilation rapide** : Module isolĂ© <5 sec build -- **Success validation** : Hot-reload seulement si build rĂ©ussi -- **Error handling** : Fallback ancien module si Ă©chec - -#### Contraintes & Performance - -**Requirements techniques :** -- **Interface compatibility** : IModule contracts identiques pre/post reload -- **State serializability** : Toutes donnĂ©es JSON-serializable -- **No static globals** : État encapsulĂ© dans instances module -- **Export functions** : CreateModule, DestroyModule standardisĂ©es - -**Performance impact :** -- **Reload time** : <5 secondes garantis (target <2 sec) -- **Runtime overhead** : <1% en production (hot-reload disabled) -- **Memory usage** : Temporairement doublĂ© pendant transition -- **Gaming performance** : ZĂ©ro impact, Windows DLL natif - -### Contrainte Claude Code : Micro-Context Optimization - -**CRITICAL** : Modules limitĂ©s Ă  **200-300 lignes maximum** pour optimiser l'efficacitĂ© de dĂ©veloppement avec Claude Code. - -#### ProblĂšme RĂ©solu : Context Window -- **Avant** : Claude Code doit comprendre 50K+ lignes interconnectĂ©es -- **AprĂšs** : Claude Code travaille sur modules isolĂ©s de 200-300 lignes max -- **RĂ©sultat** : **250x rĂ©duction** de la complexitĂ© contextuelle - -#### Contraintes Strictes de Taille -- **MAX 300 lignes** par fichier module -- **Target 200-250 lignes** optimal pour Claude Code -- **~200K tokens** maximum context window Claude Code -- **280 lignes** typiquement utilisĂ©es (CLAUDE.md + Module.cpp + Interface.h) - -#### Architecture Micro-Context -```cpp -// ✅ CORRECT - Module optimisĂ© Claude Code -class TankModule : public IModule { - json process(const json& task) override { - // 200 lignes de pure tank logic - // Aucune infrastructure, networking, threading - // JSON in/out uniquement - return {"status": "moving", "position": newPos}; - } -}; -``` - -```cpp -// ❌ INCORRECT - Trop complexe pour Claude Code -class MegaTankSystem { - // 5000+ lignes avec networking, threading, UI, etc. - // Claude Code ne peut pas apprĂ©hender efficacement -}; -``` - -#### Workflow RĂ©volutionnaire : DĂ©veloppement ParallĂšle -```bash -# Instance Claude Code A - 280 lignes context -cd modules/tank/ -# Context: CLAUDE.md (50) + TankModule.cpp (200) + IModule.h (30) - -# Instance Claude Code B - 250 lignes context -cd modules/economy/ -# Context: CLAUDE.md (70) + EconomyModule.cpp (150) + IModule.h (30) - -# Instance Claude Code C - 230 lignes context -cd modules/factory/ -# Context: CLAUDE.md (60) + FactoryModule.cpp (140) + IModule.h (30) -``` - -#### Contexte Ultra-Simple Garantit -- **ZĂ©ro infrastructure** dans le contexte Claude Code -- **Information hiding** : Claude ne voit jamais l'architecture complĂšte -- **Focus 100%** sur logique mĂ©tier pure -- **Build autonome** : `cmake .` depuis le module - -#### Avantages Claude Code MesurĂ©s -- **Iteration rapide** : 5 secondes vs 5-10 minutes traditional -- **ComprĂ©hension parfaite** : Context entiĂšrement maĂźtrisable par IA -- **Quality boost** : Focus intense sur logique pure -- **Parallel instances** : 3+ Claude Code travaillant simultanĂ©ment - -## Performance Scaling Architecture (Point 39) - -**HiĂ©rarchie temporelle optimisĂ©e** pour balance performance/complexitĂ© : - -### 4 Tiers Performance -```cpp -enum PerformanceTier { - LOCAL_REALTIME, // Transport mode selection (real-time) - REGIONAL_HOURLY, // Market clearing (hourly) - ECONOMIC_DAILY, // Complex modeling (daily) - INFRASTRUCTURE_MONTHLY // Long-term investment (monthly) -}; -``` - -### Local Decisions (Real-time) -- **Target** : 60fps gameplay garanti -- **Scope** : Factory production, transport mode selection, player input -- **Constraint** : Zero network latency impact -- **Budget** : 16ms per frame maximum - -### Regional Coordination (Hourly) -- **Target** : Market clearing operations -- **Scope** : Order matching, price updates, transport assignment -- **Tolerance** : 50-100ms network delays acceptable -- **Budget** : 5-10 seconds processing time - -### Economic Simulation (Daily) -- **Target** : Complex economic modeling -- **Scope** : Demographics, market volatility, AI behaviors -- **Frequency** : 0.01-0.1Hz processing -- **Budget** : Up to 30 seconds computation acceptable - -### Infrastructure Planning (Monthly) -- **Target** : Long-term strategic calculations -- **Scope** : ROI analysis, regional development, policy changes -- **Tolerance** : High latency, batch processing -- **Budget** : Several minutes computation acceptable - -**Architecture Benefits** : -- **Performance isolation** : Critical path (60fps) protected from complex simulation -- **Resource allocation** : CPU budget appropriĂ© per tier -- **Network optimization** : Frequency matching network tolerance -- **Modular scaling** : Each module operates at optimal frequency -- **Development velocity** : 10x improvement dĂ©montrĂ© - -## Modules Principaux - -L'architecture modulaire remplace les anciens engines par des modules spĂ©cialisĂ©s, chacun implĂ©mentant l'interface IModule avec logique mĂ©tier pure. - -### ProductionModule -- **ResponsabilitĂ©** : Production Factorio-like (Belt + Inserter + Factory intĂ©grĂ©) -- **Scope** : Mining, assemblage, transport items, stockage -- **Contrainte** : Monolithe nĂ©cessaire pour performance frame-perfect (60fps) -- **Frequency** : 60Hz processing pour frame-perfect timing -- **War Isolation** : ZERO interaction directe avec WarModule/TankModule -- **Communication** : JSON avec LogisticModule pour export/import uniquement - -### EconomyModule -- **ResponsabilitĂ©** : Simulation Ă©conomique, marchĂ©s, pricing dynamique -- **Scope** : Agent-based economy, supply/demand, transport optimization -- **Frequency** : 0.01-0.1Hz (cycles Ă©conomiques lents) -- **Business Models** : Arbitrage, Market Making, Transport Optimization -- **Communication** : JSON market data, price updates - -### TankModule -- **ResponsabilitĂ©** : Comportement vĂ©hicules de combat -- **Scope** : Movement, targeting, combat states, damage calculation -- **Frequency** : 0.1-60Hz (Targeting 60Hz → Movement 30Hz → Tactical 1Hz → Analytics 0.1Hz) -- **Factory Isolation** : Aucune interaction directe avec ProductionModule -- **Turret Supply** : Approvisionnement via LogisticModule uniquement -- **Communication** : JSON commands, state updates - -### LogisticModule -- **ResponsabilitĂ©** : Transport goods, supply chains, turret supply -- **Scope** : Route optimization, convoy management, infrastructure, war asset supply -- **Frequency** : Variable (50ms temps rĂ©el → 1000ms planification) -- **War Integration** : Approvisionne turrets/war assets, PAS inserters directs -- **Economic Integration** : Cost-based transport mode selection -- **Communication** : JSON transport requests, delivery confirmations - -### MapModule -- **ResponsabilitĂ©** : Terrain, procedural generation, FOW -- **Scope** : Multi-scale maps, chunk streaming, 218+ generation elements -- **Frequency** : Variable selon context (streaming asynchrone) -- **Performance** : Lazy loading, memory management - -## Module Frequencies & Isolation Rules - -### Frequency Specifications (Points 109-125) - -**Performance-Critical Modules :** -- **ProductionModule** : 60Hz (frame-perfect factory operations) -- **TankModule Targeting** : 60Hz (combat responsiveness) -- **TankModule Movement** : 30Hz (position updates) - -**Strategic Modules :** -- **TankModule Tactical** : 1Hz (strategic decisions) -- **TankModule Analytics** : 0.1Hz (long-term analysis) -- **EconomyModule** : 0.01-0.1Hz (economic cycles) - -**Context-Dependent Modules :** -- **LogisticModule** : 50ms (real-time) → 1000ms (planning) -- **MapModule** : Asynchronous (on-demand streaming) - -### Isolation Rules (Points 133-134) - -**War Module Isolation :** -```cpp -// ✅ CORRECT - War assets via LogisticModule -LogisticModule → TurretSupply → Ammunition -LogisticModule → VehicleSupply → Fuel/Parts - -// ❌ FORBIDDEN - Direct factory interaction -ProductionModule → TankModule // ZERO interaction -FactoryInserter → Turret // NO direct supply -``` - -**ProductionModule Isolation :** -```cpp -// ✅ CORRECT - Only LogisticModule interface -ProductionModule ↔ LogisticModule // Export/Import only -LogisticModule ↔ WarModule // Supply war assets - -// ❌ FORBIDDEN - Any direct war interaction -ProductionModule ↔ TankModule // ZERO interaction -ProductionModule ↔ TurretModule // ZERO interaction -``` - -**Supply Chain Architecture :** -- **Factory → Logistics → War** (unidirectional flow) -- **NO shortcuts** : Direct factory-to-war connections prohibited -- **Reason** : Module isolation, testability, hot-reload safety -- **Communication** : JSON terrain queries, chunk data - -## Architecture Communication - -### Communication Modulaire - -**Protocole uniforme** : JSON-only entre tous les modules via interfaces IIO - -### Architecture Client/Server Modulaire - -**Classification :** CRITICAL - ImplĂ©mentation immĂ©diate requise -**Evolution progressive :** V1 Thin Client → V2 Shared Logic - -#### Phase V1 : Thin Client Validation -**Architecture :** -- Client display-only, toute logique cĂŽtĂ© serveur -- Validation authoritative centralisĂ©e -- Communication via NetworkIO pour toutes les dĂ©cisions - -**Performance Targets (Points 98-103) :** -- **V1 Client Target** : 30+ fps stable (Point 98) -- **V1 Server Capacity** : 10+ concurrent players (Point 100) -- **V1 Latency** : <150ms validation acceptable (Point 102) - -**Pour les utilisateurs :** -- **Latence perceptible** : 50-150ms dĂ©lai entre action et feedback -- **Connexion requise** : ImpossibilitĂ© de jouer hors ligne -- **Synchronisation garantie** : Aucune dĂ©synchronisation possible - -**Pour les dĂ©veloppeurs :** -- **DĂ©veloppement simplifiĂ©** : Une seule source de vĂ©ritĂ© cĂŽtĂ© serveur -- **Debug facilitĂ©** : Toute la logique centralisĂ©e et traçable -- **SĂ©curitĂ© native** : Anti-cheat par design via validation serveur -- **DĂ©ploiement rapide** : Architecture simple, mise en production directe - -#### Phase V2 : Shared Logic Prediction -**Architecture :** -- Logique mĂ©tier partagĂ©e client/serveur -- PrĂ©diction locale avec rĂ©conciliation serveur -- Communication optimisĂ©e via NetworkIO intelligent - -**Performance Targets (Points 99-103) :** -- **V2 Client Target** : 60+ fps avec prediction (Point 99) -- **V2 Server Capacity** : 100+ concurrent players (Point 101) -- **V2 Network** : 30ms server, 0ms perceived client (Point 103) - -**Pour les utilisateurs :** -- **Latence zĂ©ro perçue** : Feedback instantanĂ© via prĂ©diction locale -- **Mode hors ligne** : Gameplay possible avec synchronisation diffĂ©rĂ©e -- **Performance optimale** : 60fps avec prĂ©diction fluide -- **ExpĂ©rience premium** : RĂ©activitĂ© comparable aux jeux locaux - -**Pour les dĂ©veloppeurs :** -- **ComplexitĂ© accrue** : Synchronisation client/serveur Ă  gĂ©rer -- **Logic partagĂ©e** : Modules identiques cĂŽtĂ© client et serveur -- **Testing avancĂ©** : Validation prĂ©diction + rĂ©conciliation -- **Migration progressive** : Évolution V1→V2 sans rĂ©Ă©criture complĂšte - -#### MĂ©triques de Performance - -| Phase | Latence Perçue | FPS Client | CapacitĂ© Serveur | Mode Offline | -|-------|---------------|------------|------------------|--------------| -| V1 | 50-150ms | 30+ fps | 10+ joueurs | Non | -| V2 | 0ms (prĂ©diction) | 60+ fps | 100+ joueurs | Oui | - -#### IntĂ©gration Architecture Modulaire - -**Distribution intelligente :** -- **Critical modules** (ProductionModule) : Toujours locaux pour 60fps -- **Strategic modules** (EconomyModule) : DistribuĂ©s selon tolĂ©rance latence -- **War modules** : V1 serveur, V2 client avec rĂ©conciliation - -**Migration sans risque (Point 10) :** -**Évolution sans risque architecture client/server** - -- **Pattern hot-swappable** : Transition V1→V2 transparente pour modules -- **A/B testing** : Validation progressive par groupes d'utilisateurs (10% → 50% → 100%) -- **Fallback automatique** : Retour V1 en cas d'Ă©chec V2 -- **ZĂ©ro rĂ©Ă©criture** : V1 code reste valide, V2 = extension progressive -- **Forward-compatible** : Architecture V1 compatible V2 dĂšs le design initial - -**Exemple migration progressive :** -```cpp -// Code adaptable V1/V2 sans rĂ©Ă©criture -if (config.enable_v2_prediction) { - // V2: Client prediction + server validation -} else { - // V1: Server authoritative (fallback sĂ»r) -} -``` - -**Communication standardisĂ©e :** -- **JSON exclusivement** : Interface uniforme client/serveur -- **NetworkIO Ă©volutif** : Support V1 et V2 simultanĂ© -- **State preservation** : ContinuitĂ© Ă©tat durant migration - -### Stack Technique Modulaire -- **IntraIO** : Communication intra-processus (dĂ©veloppement/debug) -- **LocalIO** : Named pipes/sockets (mĂȘme machine, production) -- **NetworkIO** : TCP/WebSocket avec support V1/V2 client/server - -### Patterns Communication -- **Modules → JSON in/out** : Interface pure, pas de dĂ©pendances directes -- **Hot-reload compatible** : Communication prĂ©servĂ©e durant updates modules -- **Client/Server agnostic** : MĂȘme logique mĂ©tier, dĂ©ploiement diffĂ©rent selon phase - -## Avantages Architecture Modulaire - -### DĂ©veloppement Claude Code OptimisĂ© -- **Contextes micro** : 200-300 lignes par module vs 50K+ lignes systĂšme monolithique -- **Build autonome** : `cd modules/tank/ && cmake .` - zĂ©ro dĂ©pendance parent -- **Hot-reload** : Modifications instantanĂ©es sans restart systĂšme -- **DĂ©veloppement parallĂšle** : Multiple instances Claude Code simultanĂ©es - -### Performance & ScalabilitĂ© -- **Évolution progressive** : Debug → Production → MMO sans rĂ©Ă©criture -- **Module isolation** : Failures localisĂ©es, pas de cascade -- **Infrastructure hot-swappable** : Change performance sans affecter logique mĂ©tier - -### Maintenance & Evolution -- **Testing isolĂ©** : Chaque module testable indĂ©pendamment -- **Migration zero-risk** : A/B testing, fallback automatique -- **Code reuse** : Modules rĂ©utilisables entre projets - -## Development Philosophy & Patterns - -### Point 51 : Backward Compatibility Framework -**Proxy pattern ancien→nouveau coexistence** - -```cpp -// Backward compatibility via proxy pattern -class LegacyTankAdapter : public IModule { - std::unique_ptr legacySystem; - std::unique_ptr modernSystem; - bool useModern = false; - -public: - json process(const json& input) override { - if (useModern && modernSystem->isReady()) { - try { - return modernSystem->process(input); - } catch (const std::exception&) { - // Fallback to legacy on failure - return legacySystem->processLegacy(convertToOldFormat(input)); - } - } - return legacySystem->processLegacy(convertToOldFormat(input)); - } - - void enableModernSystem() { useModern = true; } - void fallbackToLegacy() { useModern = false; } -}; -``` - -**Benefits Architecture :** -- **Zero-risk migration** : Ancien systĂšme reste fonctionnel -- **A/B testing** : Switch runtime entre old/new -- **Progressive rollout** : Migration progressive users -- **Instant rollback** : Retour automatique si problĂšme - -### Point 52 : YAGNI Modding Philosophy -**Pas modding pre-release, config system suffit 90% cas** - -**Philosophy :** Configuration-driven flexibility plutĂŽt que modding infrastructure complexe - -```json -// Config-driven "modding" via JSON -{ - "tank_variants": { - "tank_mk1": { - "health": 100, - "speed": 35, - "armor": "medium", - "weapons": ["cannon_75mm"] - }, - "tank_mk2_custom": { - "health": 150, - "speed": 30, - "armor": "heavy", - "weapons": ["cannon_105mm", "mg_coaxial"] - } - }, - "behavior_mods": { - "aggressive_ai": { - "engagement_range": 1000, - "retreat_threshold": 20, - "target_priority": "closest" - } - } -} -``` - -**Architecture Benefits :** -- **90% modding needs** : Config JSON couvre la majoritĂ© des besoins -- **Zero complexity** : Pas infrastructure modding complexe -- **Claude-friendly** : Config changes = instant AI comprehension -- **Runtime modification** : Hot-reload configs sans restart - -**Future Extension :** -```cpp -// When modding eventually needed (post-release) -class ModdingInterface : public IModule { - json process(const json& input) override { - // Modding hooks will be added here later - // For now, config-driven behavior is sufficient - return processConfigDriven(input); - } -}; -``` - -### Point 53 : "Complexity through Simplicity" -**AAA complexitĂ© via modules simples Claude-friendly** - -**Core Philosophy :** Complex gameplay emerges from interaction of simple, well-designed modules - -```cpp -// Simple tank module (200 lines) -class TankModule : public IModule { - json process(const json& input) override { - // Simple tank behavior: move, shoot, retreat - return processSimpleTankLogic(input); - } -}; - -// Simple economy module (250 lines) -class EconomyModule : public IModule { - json process(const json& input) override { - // Simple market: supply, demand, price discovery - return processSimpleMarket(input); - } -}; - -// Complex gameplay emerges from interaction -// Tank + Economy = Resource-constrained warfare -// Tank + Factory = Production-line optimization -// Economy + Factory = Industrial economic simulation -``` - -**Emergent Complexity Examples :** - -**Simple Rules → Complex Behavior :** -```cpp -// Rule 1: Tanks need fuel (EconomyModule) -// Rule 2: Fuel costs money (MarketModule) -// Rule 3: Money comes from production (FactoryModule) -// Rule 4: Production needs resources (LogisticModule) - -// Emergent behavior: Complex supply-chain warfare -// Players must balance factory output, resource extraction, -// economic planning, and military operations -``` - -**Architecture Benefits :** -- **Claude comprehension** : Each module easily understood by AI -- **Debugging simplicity** : Issues isolated to specific modules -- **Testing granularity** : Simple modules = simple tests -- **Development velocity** : Small contexts = fast iteration - -**AAA Complexity Achieved Through :** -- **Module interaction** : Simple rules create complex systems -- **Configuration depth** : JSON configs add sophistication -- **Emergent gameplay** : Player strategies emerge naturally -- **Progressive revelation** : Complexity unlocked gradually diff --git a/docs/01-architecture/behavior-composition-patterns.md b/docs/01-architecture/behavior-composition-patterns.md deleted file mode 100644 index 15c5c61..0000000 --- a/docs/01-architecture/behavior-composition-patterns.md +++ /dev/null @@ -1,305 +0,0 @@ -# Behavior Composition Patterns - Warfactory - -**Philosophy** : Modules comportements combinables via configuration JSON pour AI flexibility - -## Point 46 : Behavior Composition Pattern - -### Concept Core - -**Modular Behaviors** : Chaque comportement AI = module autonome combinable - -```cpp -// Base behavior interface -class IBehaviorModule : public IModule { -public: - virtual json process(const json& context) = 0; - virtual float getWeight() const = 0; - virtual bool shouldActivate(const json& triggers) const = 0; -}; -``` - -### Behavior Module Examples - -#### AggressiveBehavior Module -```cpp -class AggressiveBehavior : public IBehaviorModule { - json process(const json& context) override { - auto enemy_detected = context["enemy_detected"].get(); - auto health = context["health"].get(); - - if (enemy_detected && health > 50.0f) { - return { - {"action", "attack"}, - {"priority", "high"}, - {"target_selection", "closest_enemy"} - }; - } - - return {{"action", "patrol"}}; - } - - float getWeight() const override { return 0.8f; } // High aggression - - bool shouldActivate(const json& triggers) override { - return triggers.contains("enemy_nearby") || triggers.contains("under_attack"); - } -}; -``` - -#### CautiousBehavior Module -```cpp -class CautiousBehavior : public IBehaviorModule { - json process(const json& context) override { - auto health = context["health"].get(); - auto enemy_count = context["enemy_count"].get(); - - if (health < 30.0f || enemy_count > 2) { - return { - {"action", "retreat"}, - {"priority", "critical"}, - {"retreat_direction", "base"} - }; - } - - return {{"action", "defensive_position"}}; - } - - float getWeight() const override { return 0.6f; } // Moderate caution - - bool shouldActivate(const json& triggers) override { - return triggers.contains("low_health") || triggers.contains("outnumbered"); - } -}; -``` - -#### EconomicBehavior Module -```cpp -class EconomicBehavior : public IBehaviorModule { - json process(const json& context) override { - auto resources = context["resources"].get(); - auto factory_status = context["factory_active"].get(); - - if (resources < 100 && factory_status) { - return { - {"action", "gather_resources"}, - {"priority", "medium"}, - {"resource_type", "preferred"} - }; - } - - return {{"action", "optimize_production"}}; - } - - float getWeight() const override { return 0.4f; } // Economic focus - - bool shouldActivate(const json& triggers) override { - return triggers.contains("low_resources") || triggers.contains("economic_opportunity"); - } -}; -``` - -### Composition Engine - -#### BehaviorCompositionEngine -```cpp -class BehaviorCompositionEngine : public IModule { -private: - std::map> behaviors; - json composition_config; - -public: - void initialize(const json& config) override { - composition_config = config["behavior_composition"]; - - // Load configured behavior modules - for (const auto& behavior_name : composition_config["modules"]) { - loadBehaviorModule(behavior_name); - } - } - - json process(const json& context) override { - std::vector behavior_outputs; - std::vector weights; - - // Process all active behaviors - for (const auto& [name, behavior] : behaviors) { - if (shouldActivateBehavior(name, context)) { - auto output = behavior->process(context); - behavior_outputs.push_back(output); - weights.push_back(getBehaviorWeight(name)); - } - } - - // Compose final decision - return composeBehaviors(behavior_outputs, weights); - } - -private: - bool shouldActivateBehavior(const std::string& name, const json& context) { - auto triggers = extractTriggers(context); - return behaviors[name]->shouldActivate(triggers); - } - - float getBehaviorWeight(const std::string& name) { - auto weights = composition_config["weights"]; - if (weights.contains(name)) { - return weights[name].get(); - } - return behaviors[name]->getWeight(); - } - - json composeBehaviors(const std::vector& outputs, const std::vector& weights) { - // Weighted decision composition - json final_decision; - float total_weight = 0.0f; - - // Calculate weighted priorities - for (size_t i = 0; i < outputs.size(); ++i) { - auto priority = getPriorityValue(outputs[i]["priority"]); - auto weighted_priority = priority * weights[i]; - - if (weighted_priority > total_weight) { - final_decision = outputs[i]; - total_weight = weighted_priority; - } - } - - return final_decision; - } -}; -``` - -### Configuration-Driven Composition - -#### Example Configuration -```json -{ - "behavior_composition": { - "modules": ["aggressive", "cautious", "economic"], - "weights": { - "aggressive": 0.7, - "cautious": 0.8, - "economic": 0.3 - }, - "triggers": { - "low_health": "switch_to_cautious", - "enemy_nearby": "activate_aggressive", - "low_resources": "activate_economic" - }, - "priority_matrix": { - "critical": 1.0, - "high": 0.8, - "medium": 0.5, - "low": 0.2 - }, - "dynamic_weights": { - "health_modifier": { - "high_health": {"aggressive": 1.2, "cautious": 0.8}, - "low_health": {"aggressive": 0.3, "cautious": 1.5} - } - } - } -} -``` - -#### Advanced Composition Features -```json -{ - "behavior_composition": { - "modules": ["aggressive", "cautious", "economic", "tactical"], - "composition_strategy": "weighted_priority", - "context_modifiers": { - "time_of_day": { - "night": {"cautious": 1.3, "aggressive": 0.7}, - "day": {"aggressive": 1.1, "tactical": 1.2} - }, - "resource_level": { - "abundant": {"economic": 0.5, "aggressive": 1.3}, - "scarce": {"economic": 1.5, "cautious": 1.2} - } - }, - "behavior_transitions": { - "aggressive_to_cautious": { - "trigger": "health < 25%", - "transition_time": 2.0 - }, - "economic_to_aggressive": { - "trigger": "resources > 500", - "transition_time": 1.0 - } - } - } -} -``` - -### Usage Examples - -#### Tank AI Composition -```json -{ - "tank_ai": { - "modules": ["aggressive", "tactical", "survival"], - "weights": {"aggressive": 0.8, "tactical": 0.9, "survival": 1.0}, - "context": "combat_heavy" - } -} -``` - -#### Economic AI Composition -```json -{ - "company_ai": { - "modules": ["economic", "cautious", "opportunistic"], - "weights": {"economic": 1.0, "cautious": 0.6, "opportunistic": 0.4}, - "context": "market_trading" - } -} -``` - -#### Diplomatic AI Composition -```json -{ - "diplomatic_ai": { - "modules": ["cooperative", "strategic", "economic"], - "weights": {"cooperative": 0.7, "strategic": 0.9, "economic": 0.5}, - "context": "international_relations" - } -} -``` - -## Architecture Benefits - -### Development Advantages -- **Module Reusability** : Behaviors rĂ©utilisables entre diffĂ©rents AI agents -- **Easy Testing** : Chaque behavior testable indĂ©pendamment -- **Claude-Friendly** : Modules 200 lignes max, comprehensibles par IA -- **Hot-Reload** : Modification behaviors sans restart systĂšme - -### Gameplay Advantages -- **AI Diversity** : Combinations crĂ©ent personnalitĂ©s AI distinctes -- **Dynamic Adaptation** : Behaviors s'adaptent selon context/triggers -- **Emergent Complexity** : Interactions behaviors crĂ©ent sophistication Ă©mergente -- **Player Customization** : Players peuvent configurer AI allies - -### Performance Benefits -- **Selective Activation** : Seuls behaviors pertinents s'activent -- **Lightweight Composition** : JSON processing minimal overhead -- **Parallel Processing** : Behaviors processables en parallĂšle -- **Efficient Caching** : Composition results cachables - -## Implementation Strategy - -### Phase 1 : Core Behaviors -- Implement basic behavior modules (Aggressive, Cautious, Economic) -- Simple weighted composition -- JSON configuration loading - -### Phase 2 : Advanced Composition -- Context modifiers et dynamic weights -- Behavior transitions -- Priority matrices sophistiquĂ©es - -### Phase 3 : AI Personalities -- Predefined personality templates -- Player customization interface -- Emergent behavior analysis \ No newline at end of file diff --git a/docs/01-architecture/player-integration.md b/docs/01-architecture/player-integration.md deleted file mode 100644 index c389e7c..0000000 --- a/docs/01-architecture/player-integration.md +++ /dev/null @@ -1,397 +0,0 @@ -# IntĂ©gration du Joueur dans l'Architecture Modulaire - -## 🎯 ProblĂšme IdentifiĂ© - -**Architecture modulaire parfaite... mais oĂč est le joueur ?** - -L'architecture triple interface actuelle gĂšre brillamment la logique mĂ©tier et la performance, mais il manque un Ă©lĂ©ment crucial : **l'interaction humaine**. - -### Gaps Actuels -- ❌ **Pas d'inputs** clavier/souris -- ❌ **Pas de rĂ©activitĂ© UI** temps rĂ©el -- ❌ **Client/Server separation** manquante -- ❌ **Multiplayer architecture** non dĂ©finie - -## 📋 Solution : Client/Server Modulaire - -### Architecture Duale ProposĂ©e - -``` -ClientEngine (Local, RĂ©actif) ←→ ServerEngine (DistribuĂ©, Autoritaire) -├─ InputModule ├─ TankModule -├─ UIModule ├─ CombatModule -├─ RenderModule ├─ EconomyModule -└─ NetworkModule └─ NetworkModule -``` - -### Principe : MĂȘme Architecture, Contexte DiffĂ©rent - -**Client Modules** : Focus UX, rĂ©activitĂ©, prĂ©diction -**Server Modules** : Focus logique, autoritĂ©, performance - -**Code Sharing** : Logique mĂ©tier identique, contexte d'exĂ©cution diffĂ©rent - -## 🚀 Plan de DĂ©veloppement : 2 Phases Progressives - -### **Phase 1 : V1 - Thin Client (Validation Rapide)** - -#### Objectifs V1 -- ✅ **Validation architecture** : Prouver que l'approche modulaire fonctionne -- ✅ **Focus core logic** : TankModule, CombatModule opĂ©rationnels -- ✅ **Gameplay jouable** : Latence acceptable pour validation concept -- ✅ **Claude Code friendly** : DĂ©veloppement parallĂšle client/server - -#### Architecture V1 : Simple & Efficace - -``` -ClientEngine (Thin) -├─ InputModule → Capture inputs → JSON messages -├─ NetworkModule → WebSocket client → Send to server -└─ RenderModule → Display server state → Simple rendering - -ServerEngine (All Logic) -├─ TankModule → Authoritative tank logic -├─ CombatModule → Game mechanics & physics -├─ EconomyModule → Market simulation -└─ NetworkModule → WebSocket server → Broadcast state -``` - -#### Flow V1 : Server-Authoritative - -``` -Player Input → ClientEngine → Network → ServerEngine → Game Logic → Network → ClientEngine → Display - 50ms 5ms 30ms 20ms 30ms 5ms 10ms -Total : ~150ms latency (acceptable pour validation) -``` - -#### DĂ©veloppement V1 : Claude Code Parallel - -```bash -# Instance Claude A : Client Input -cd modules/client/input/ -cmake . && make input-module # → input.so - -# Instance Claude B : Server Logic -cd modules/server/tank/ -cmake . && make tank-module # → tank.so - -# Instance Claude C : Network -cd modules/shared/network/ -cmake . && make network-module # → network.so -``` - -#### Modules V1 Implementation - -##### InputModule (Client) -```cpp -class InputModule : public ModuleBase { - json process(const json& input) override { - // Keyboard/mouse events → Structured commands - if(input["type"] == "keydown") { - if(input["key"] == "w") return {{"command", "move"}, {"direction", "north"}}; - if(input["key"] == "space") return {{"command", "attack"}}; - } - return {{"command", "idle"}}; - } -}; -``` - -##### NetworkModule (Client) -```cpp -class ClientNetworkModule : public ModuleBase { - json process(const json& input) override { - // Send commands to server via WebSocket - if(input["command"] != "idle") { - webSocketClient.send(input.dump()); - } - - // Receive server state updates - if(webSocketClient.hasMessage()) { - return json::parse(webSocketClient.receive()); - } - - return {{"status", "connected"}}; - } -}; -``` - -##### TankModule (Server) - **MĂȘme logique qu'avant !** -```cpp -class TankModule : public ModuleBase { - json process(const json& input) override { - // IDENTICAL logic to single-player version - if(input["command"] == "move") return handleMovement(input); - if(input["command"] == "attack") return handleCombat(input); - return getCurrentState(); - } -}; -``` - -### **Phase 2 : V2 - Client Prediction (Polish UX)** - -#### Objectifs V2 -- ✅ **RĂ©activitĂ© client** : Illusion 0ms lag via prĂ©diction -- ✅ **Code sharing** : Logique mĂ©tier partagĂ©e client/server -- ✅ **Smooth gameplay** : Corrections invisibles, UX fluide -- ✅ **Competitive ready** : Performance multijoueur AAA - -#### Architecture V2 : Shared Logic + Prediction - -``` -SharedGameLogic.so (Code Commun) -├─ TankLogic.cpp -├─ CombatLogic.cpp -└─ PhysicsLogic.cpp - -ClientEngine (Predictive) ServerEngine (Authoritative) -├─ ClientTankModule (Shared + prediction) ├─ ServerTankModule (Shared + validation) -├─ SyncModule (reconciliation) ├─ ValidationModule (anti-cheat) -└─ PredictionModule (client-side) └─ PersistenceModule (save/load) -``` - -#### Flow V2 : Client Prediction + Server Authority - -``` -Player Input → Immediate Client Prediction + Network to Server → Server Validation → Client Reconciliation - 0ms 5ms 30ms 20ms 5ms -User Experience : 0ms (predicted), Corrections invisibles -``` - -#### Migration V1 → V2 : Zero-Risk Evolution - -```cpp -// 1. Extract Shared Logic (TankModule → SharedTankLogic.so) -class SharedTankLogic { - static json CalculateMovement(const json& tank, const json& input) { - // SINGLE SOURCE OF TRUTH for both client & server - return processMovement(tank, input); - } -}; - -// 2. Client Prediction (ClientTankModule) -class ClientTankModule : public ModuleBase { - json process(const json& input) override { - // Immediate prediction using shared logic - auto predicted = SharedTankLogic::CalculateMovement(currentState, input); - - // Send to server for validation - networkModule.send(input); - - return predicted; // Display immediately - } -}; - -// 3. Server Validation (ServerTankModule) -class ServerTankModule : public ModuleBase { - json process(const json& input) override { - // Authoritative calculation using SAME shared logic - auto authoritative = SharedTankLogic::CalculateMovement(serverState, input); - - // Anti-cheat validation - if(validateInput(input)) { - return authoritative; - } - - return {{"error", "invalid_input"}}; - } -}; -``` - -## đŸ› ïž Implementation Strategy - -### DĂ©veloppement V1 : Thin Client - -#### 1. Client Modules -```bash -modules/client/ -├─ input/ # InputModule : Clavier/souris → JSON -├─ render/ # RenderModule : Server state → Display -└─ network/ # NetworkModule : WebSocket client -``` - -#### 2. Server Modules (Extension Actuelle) -```bash -modules/server/ -├─ tank/ # TankModule : Combat logic (EXISTING) -├─ economy/ # EconomyModule : Market logic (EXISTING) -├─ network/ # NetworkModule : WebSocket server -└─ persistence/ # PersistenceModule : Save/load state -``` - -#### 3. Shared Infrastructure -```bash -modules/shared/ -├─ protocol/ # ProtocolModule : Client/server messages -├─ serialization/ # SerializationModule : JSON optimization -└─ compression/ # CompressionModule : Network optimization -``` - -### DĂ©veloppement V2 : Shared Logic - -#### 1. Logic Extraction -```bash -modules/shared/logic/ -├─ tank-logic/ # SharedTankLogic.so -├─ combat-logic/ # SharedCombatLogic.so -└─ physics-logic/ # SharedPhysicsLogic.so -``` - -#### 2. Client Prediction -```bash -modules/client/prediction/ -├─ tank-prediction/ # ClientTankModule with prediction -├─ sync/ # SyncModule : Reconciliation -└─ interpolation/ # InterpolationModule : Smooth corrections -``` - -#### 3. Server Authority -```bash -modules/server/authority/ -├─ validation/ # ValidationModule : Anti-cheat -├─ simulation/ # SimulationModule : Server-side physics -└─ persistence/ # PersistenceModule : World state -``` - -## 🎼 Claude Code Development Workflow - -### V1 Development : Parallel Instances - -```bash -# Claude Instance A : Client Input -cd modules/client/input/ -# Context : 200 lignes input handling -# Focus : Keyboard/mouse → JSON commands -# Build : cmake . && make input-module - -# Claude Instance B : Server Tank Logic -cd modules/server/tank/ -# Context : 250 lignes tank logic (EXISTING) -# Focus : Command processing, game state -# Build : cmake . && make tank-module - -# Claude Instance C : Network Protocol -cd modules/shared/protocol/ -# Context : 180 lignes network messages -# Focus : JSON serialization, WebSocket -# Build : cmake . && make protocol-module -``` - -### V2 Development : Shared Logic Focus - -```bash -# Claude Instance A : Shared Tank Logic -cd modules/shared/logic/tank/ -# Context : 200 lignes pure tank logic -# Focus : Movement, combat calculations -# Used by : BOTH client prediction AND server authority - -# Claude Instance B : Client Prediction -cd modules/client/prediction/tank/ -# Context : 150 lignes prediction + SharedTankLogic -# Focus : Immediate response, reconciliation -# Build : Links SharedTankLogic.so - -# Claude Instance C : Server Authority -cd modules/server/authority/tank/ -# Context : 180 lignes validation + SharedTankLogic -# Focus : Anti-cheat, persistence -# Build : Links SharedTankLogic.so -``` - -## 📊 Success Metrics & Validation - -### V1 Success Criteria -- [ ] **Player Control** : Tank respond to WASD + mouse -- [ ] **Multiplayer** : 2+ players see synchronized world -- [ ] **Hot-Reload** : Server modules reload without client disconnect -- [ ] **Latency** : <150ms acceptable for core gameplay validation -- [ ] **Claude Code** : 3+ parallel development instances - -### V2 Success Criteria -- [ ] **Instant Response** : Input feels 0ms via client prediction -- [ ] **Smooth Corrections** : No jittering during server reconciliation -- [ ] **Logic Sync** : Client/server calculations stay identical -- [ ] **Hot-Reload** : Both engines support module hot-reload -- [ ] **Performance** : 60fps client, server handles 100+ concurrent players - -### Performance Targets - -#### V1 Targets (Validation) -- **Client FPS** : 30+ fps stable -- **Server Capacity** : 10+ concurrent players -- **Network** : 150ms acceptable latency -- **Development** : Claude Code 200-line contexts - -#### V2 Targets (Production) -- **Client FPS** : 60+ fps with prediction -- **Server Capacity** : 100+ concurrent players -- **Network** : 30ms server latency, 0ms perceived client latency -- **Development** : Shared logic reduces duplication by 80% - -## 🎯 Development Priority & Timeline - -### Immediate : Start V1 (80% effort) -1. **Week 1-2** : InputModule + NetworkModule basique -2. **Week 3-4** : Server TankModule integration + basic rendering -3. **Week 5-6** : Multi-player testing + hot-reload validation -4. **Week 7-8** : Polish V1 + documentation - -### Future : V2 When V1 Stable (20% effort) -1. **Extract** : Shared logic from working V1 modules -2. **Implement** : Client prediction with shared logic -3. **Test** : Prediction accuracy vs server authority -4. **Deploy** : Seamless V1 → V2 migration - -### Development Philosophy -- **V1 first** : Prove architecture works end-to-end -- **Claude Code optimized** : 200-line contexts maintained -- **Hot-reload everywhere** : Both client and server modules -- **Progressive enhancement** : V1 → V2 without code rewrite - -## 🔄 Integration avec Architecture Existante - -### Extension Naturelle -L'architecture modulaire actuelle **s'Ă©tend parfaitement** pour supporter client/server : - -```cpp -// EXISTING : Single-player modules -TankModule.so → Pure tank logic - -// V1 EXTENSION : Server-side modules -ServerTankModule.so → Same logic + network authority - -// V2 EVOLUTION : Client + Server + Shared -SharedTankLogic.so → Pure logic (used by both) -ClientTankModule.so → SharedLogic + prediction -ServerTankModule.so → SharedLogic + validation -``` - -### Code Reuse Maximized -- **0% rewrite** : TankModule.cpp devient ServerTankModule.cpp -- **Logic preserved** : MĂȘme algorithmes, contexte d'exĂ©cution diffĂ©rent -- **Claude Code contexts** : Toujours 200-300 lignes par module -- **Hot-reload maintained** : Architecture triple interface intacte - -## 🎼 User Experience Vision - -### V1 Experience : Functional -- **Responsive** : 150ms latency acceptable pour validation -- **Multiplayer** : Joueurs voient le mĂȘme monde -- **Development** : Hot-reload permet iteration rapide - -### V2 Experience : Polished -- **Instant** : Inputs feel immediate via prediction -- **Smooth** : Corrections invisibles Ă  l'utilisateur -- **Competitive** : PrĂȘt pour gameplay multijoueur sĂ©rieux - -**RĂ©sultat** : Architecture modulaire + Player integration = **Jeu AAA dĂ©veloppĂ© avec Claude Code** Ă  vitesse rĂ©volutionnaire ! 🚀 - ---- - -## Conclusion - -L'intĂ©gration du joueur dans l'architecture modulaire suit la mĂȘme philosophie : - -**"Complexity through Simplicity"** : Chaque module (client ou server) reste simple (200 lignes), mais l'ensemble crĂ©e une expĂ©rience multijoueur complexe et performante. - -**Claude Code** continue Ă  travailler sur des contextes micro-simples, mais produit maintenant un **jeu multijoueur complet** ! \ No newline at end of file diff --git a/docs/02-systems/CLIMATE_SIMULATION_SYSTEM.md b/docs/02-systems/CLIMATE_SIMULATION_SYSTEM.md deleted file mode 100644 index 3712d86..0000000 --- a/docs/02-systems/CLIMATE_SIMULATION_SYSTEM.md +++ /dev/null @@ -1,488 +0,0 @@ -# Climate Simulation System - -**Status**: Designed - Ready for Implementation -**Scope**: Realistic climate patterns through mobile wind regions and convergence zones -**Integration**: Uses existing TectonicRegions framework - -## System Overview - -Revolutionary climate simulation using **mobile wind regions** that spawn, evolve, and interact to create emergent weather patterns. Solves the "Sahara vs Congo" problem through **Inter-Tropical Convergence Zones (ITCZ)** and **planetary rotation bands** without complex 3D atmospheric physics. - -### Key Innovations -- **Mobile WindRegions** with token-based distribution system -- **ITCZ gravitational zones** based on continental mass -- **Planetary rotation bands** for realistic circulation patterns -- **Emergent storm evolution** from simple wind interactions -- **Destruction token system** for persistent terrain effects - -## Core Concepts - -### WindRegion Mobile Entities -```json -"wind_region": { - "position": [x, y], - "wind_strength": 1.0, // Base intensity (decays over time) - "wetness": 0.0, // Moisture content (gained over ocean) - "velocity": [vx, vy], // Movement vector - "wind_tokens": 100, // Distributed to tiles - "decay_per_move": 0.02, // -2% strength per movement - "decay_per_tile": 0.01 // -1% strength per tile crossed -} -``` - -### ITCZ Convergence Zones -```json -"itcz_zone": { - "center": [x, y], - "gravitational_range": "sqrt(landmass_area) * 50", - "aspiration_strength": "landmass_mass / distance^2", - "amplification_factor": 3.0, // Wind strength multiplier at center - "latitude_requirement": [0.45, 0.55] // Equatorial band only -} -``` - -## Simulation Architecture - -### Phase 1: Landmass Analysis and ITCZ Generation - -**Uses Existing TectonicRegions:** -```cpp -// Analyze continental masses from existing tectonic data -std::vector continents = groupTectonicRegions(); - -// Generate water masses by inverse analysis -std::vector oceans = detectOceanBasins(continents); - -// Place ITCZ zones on qualifying equatorial landmasses -for (auto& continent : continents) { - if (continent.latitude >= 0.45 && continent.latitude <= 0.55 && - continent.area > MIN_LANDMASS_SIZE) { - createITCZ(continent.center, sqrt(continent.area)); - } -} -``` - -**ITCZ Requirements:** -- **Latitude Band**: 45-55% of map height (equatorial) -- **Minimum Landmass**: 10,000+ tiles -- **Ocean Proximity**: Within 800km for moisture source -- **Continental Heating**: Large thermal mass for convection - -### Phase 2: WindRegion Spawning System - -**Procedural Spawn Rules:** -```json -"wind_spawn_system": { - "spawn_locations": "ocean_masses_only", - "spawn_frequency": "water_mass_size / 1000", - "initial_strength": "water_temperature * evaporation_factor", - "region_size": "sqrt(water_mass_area) / 10", - "tokens_per_region": "base_tokens * size_factor", - "spawn_distribution": "random_within_water_region_biased_toward_center" -} -``` - -**Note**: WindRegions spawn alĂ©atoirement dans le rayon de la waterRegion avec une distribution de spawn plutĂŽt vers le centre pour Ă©viter les spawns en bordure systĂ©matiques. - -**Spawn Distribution:** -- **Large Oceans** (Pacific): Big regions, high frequency -- **Medium Seas** (Mediterranean): Medium regions, moderate frequency -- **Small Bays**: Small regions, low frequency -- **No Land Spawning**: All weather originates from water bodies - -### Phase 3: Movement and Planetary Circulation - -**Planetary Rotation Bands** (based on real 10hPa atmospheric data): -```json -"planetary_circulation": { - "polar_jet_north": { - "latitude_range": [0.10, 0.25], - "direction": "west_to_east", - "strength": 1.8 - }, - "calm_transition_1": { - "latitude_range": [0.25, 0.40], - "movement": "chaos_plus_procedural" - }, - "equatorial_trades": { - "latitude_range": [0.40, 0.60], - "direction": "east_to_west", - "strength": 1.5 - }, - "calm_transition_2": { - "latitude_range": [0.60, 0.75], - "movement": "chaos_plus_procedural" - }, - "polar_jet_south": { - "latitude_range": [0.75, 0.95], - "direction": "west_to_east", - "strength": 1.8 - } -} -``` - -**Movement Calculation:** -```cpp -Vector2 movement = - planetary_rotation_band * 0.6 + // 60% planetary circulation - equator_to_pole_bias * 0.2 + // 20% thermal circulation - terrain_deflection * 0.1 + // 10% topographic influence - random_variation * 0.1; // 10% chaos -``` - -### Phase 4: WindRegion Evolution and Interactions - -**Dynamic Evolution:** -```cpp -void updateWindRegion(WindRegion& region) { - // Gain moisture over water - if (currentTile.isOcean()) { - region.wetness += OCEAN_MOISTURE_GAIN; - } - - // Repulsion from other regions = acceleration - // NOTE: Not physical repulsion - proxy for spatial competition and turbulence - // Prevents region stacking while creating realistic dispersion patterns - // CRITIQUE POINT: May cause "force field" effect around ITCZ zones where regions - // oscillate/scatter instead of converging due to attraction vs repulsion conflict. - // Alternative approaches: density-based drift, no interaction, or collision division. - // TODO: Implement as configurable algorithm options for empirical testing. - float repulsion = calculateRepulsionForce(region, nearbyRegions); - region.wind_strength += repulsion * ACCELERATION_FACTOR; - - // Movement decay - region.wind_strength *= (1.0 - DECAY_PER_MOVE); - - // Tile crossing cost - region.wind_strength *= (1.0 - DECAY_PER_TILE); - - // Die when too weak - if (region.wind_strength < MINIMUM_THRESHOLD) { - destroyRegion(region); - } -} -``` - -**ITCZ Gravitational Effects:** -```cpp -void applyITCZGravity(WindRegion& region) { - for (auto& itcz : active_itcz_zones) { - float distance = calculateDistance(region.position, itcz.center); - - if (distance < itcz.gravitational_range) { - // Attraction force (inverse square law) - // NOTE: "Gravitational" metaphor for influence strength, not literal physics - // Like saying someone has "gravitas" - clear semantic meaning for developers - float attraction = itcz.mass / (distance * distance); - Vector2 pull_direction = normalize(itcz.center - region.position); - - // Apply attraction - region.velocity += pull_direction * attraction; - - // Amplification effect as region approaches - float proximity = (itcz.range - distance) / itcz.range; - float amplification = 1.0 + (itcz.max_amplification * proximity); - - region.wind_strength *= amplification; - region.wetness *= amplification; - } - } -} -``` - -### Phase 5: Storm Classification and Token Distribution - -**Climate Zone Classification:** -```cpp -// Simple thresholds for climate zone determination -const float HIGH_WIND_THRESHOLD = 2.0; -const float FLOOD_THRESHOLD = 1.5; -const float HURRICANE_WIND = 2.5; -const float HURRICANE_RAIN = 2.0; - -bool isHighWindZone(const WindRegion& region) { - return region.wind_strength >= HIGH_WIND_THRESHOLD; -} - -bool isFloodZone(const WindRegion& region) { - return region.wetness >= FLOOD_THRESHOLD; -} - -bool isHurricaneZone(const WindRegion& region) { - return region.wind_strength >= HURRICANE_WIND && region.wetness >= HURRICANE_RAIN; -} -``` - -**Token Distribution System:** -```cpp -void distributeTokens(WindRegion& region) { - // Basic climate tokens for all regions - int wind_tokens = static_cast(region.wind_strength * 10); - int rain_tokens = static_cast(region.wetness * 10); - - WorldTile& tile = world_map.getTile(region.position); - tile.addTokens("wind", wind_tokens); - tile.addTokens("rain", rain_tokens); - - // Special climate zone tokens for extreme weather - if (isHighWindZone(region)) { - tile.addTokens("highWind", 1); // Hostile to forests - } - if (isFloodZone(region)) { - tile.addTokens("flood", 1); // Forces wetlands/marshes - } - if (isHurricaneZone(region)) { - tile.addTokens("hurricane", 1); // Specialized hurricane biome - } - - // Consume distributed tokens from region - region.wind_tokens -= wind_tokens; - region.rain_tokens -= rain_tokens; -} -``` - -## Geographic Climate Patterns - -### Realistic Climate Formation - -**Congo Basin (Rainforest):** -``` -1. Large African landmass → Strong ITCZ at equator -2. Atlantic wind regions spawn → Move east via trade winds -3. ITCZ aspiration → Convergence at Congo → Amplification ×3 -4. Super-humid storms → Massive rain token distribution -5. Result: Dense rainforest biome -``` - -**Sahara Desert:** -``` -1. Sahara latitude (25-35°N) → Outside ITCZ band -2. No convergence zone → Wind regions pass through -3. Continental distance → Low initial moisture -4. Subtropical high pressure → Air descends (simulated via movement patterns) -5. Result: Minimal rain tokens → Desert biome -``` - -**Egypt/Algeria Coastal:** -``` -1. Mediterranean wind regions → Moderate moisture -2. Coastal proximity → Some rain tokens -3. Sahara interior → Moisture depleted inland -4. Result: Mediterranean coastal climate → Desert interior gradient -``` - -### Emergent Seasonal Patterns - -**ITCZ Strength Variation:** -```json -"seasonal_modulation": { - "itcz_strength_summer": 1.5, // Stronger convection - "itcz_strength_winter": 0.8, // Weaker convection - "spawn_rate_summer": 1.3, // More wind regions - "spawn_rate_winter": 0.7 // Fewer wind regions -} -``` - -**Results:** -- **Monsoon Seasons**: ITCZ amplification cycles -- **Hurricane Seasons**: Increased spawn rates + ITCZ amplification -- **Dry Seasons**: Reduced ITCZ strength + lower spawn rates - -## Climate Zone Effects on Biome Generation - -### Token-Based Biome Classification - -**Climate Token Usage:** -```cpp -BiomeType classifyBiome(const WorldTile& tile) { - int total_rain = tile.getAccumulatedTokens("rain"); - int total_wind = tile.getAccumulatedTokens("wind"); - int highWind_tokens = tile.getAccumulatedTokens("highWind"); - int flood_tokens = tile.getAccumulatedTokens("flood"); - int hurricane_tokens = tile.getAccumulatedTokens("hurricane"); - - // Special climate zones override normal biome classification - if (hurricane_tokens > 0) { - return BiomeType::HURRICANE_ZONE; // Specialized storm-resistant vegetation - } - if (flood_tokens > FLOOD_THRESHOLD) { - return BiomeType::WETLANDS; // Forced marshes/swamps - } - if (highWind_tokens > STORM_THRESHOLD) { - // High wind prevents forest growth - if (total_rain > 300) { - return BiomeType::STORM_PRAIRIE; // Grasslands that can handle wind - } else { - return BiomeType::BADLANDS; // Sparse, wind-resistant vegetation - } - } - - // Normal biome classification using basic rain/wind tokens - if (total_rain > 500) { - return BiomeType::TROPICAL_RAINFOREST; - } else if (total_rain < 50) { - return BiomeType::HOT_DESERT; - } - // ... additional normal biome logic -} -``` - -**Climate Zone Characteristics:** -- **Hurricane Zones** → Storm-resistant palms, specialized coastal vegetation -- **Flood Zones** → Wetlands, marshes, swamp vegetation mandatory -- **High Wind Zones** → No forests allowed, prairie/badlands only -- **Normal Zones** → Standard biome classification by rain/temperature - -## Performance Characteristics - -### Computational Complexity -- **Wind Regions**: O(n) for n active regions (~50-200 simultaneously) -- **ITCZ Calculations**: O(m) for m convergence zones (~5-15 globally) -- **Token Distribution**: O(tiles_visited) per region movement -- **Total per cycle**: O(n × average_movement_distance) - -### Memory Usage -- **WindRegion**: 32 bytes per region -- **ITCZ Zone**: 24 bytes per zone -- **Token accumulation**: Uses existing tile data structure -- **Estimated total**: <5MB for global weather simulation - -### Generation Time -- **Landmass analysis**: 1-2 seconds (one-time setup) -- **Per simulation cycle**: 10-50ms for 100-200 wind regions -- **Full climate stabilization**: 100-500 cycles → 10-30 seconds total - -## Integration with Existing Systems - -### TectonicRegions Reuse -```cpp -// Leverage existing tectonic analysis -class ClimateSystem { - void initializeFromTectonics(const std::vector& regions) { - auto continents = groupRegionsByProximity(regions); - auto oceans = calculateOceanBasins(continents); - - generateITCZFromContinents(continents); - setupWindSpawnFromOceans(oceans); - } -}; -``` - -### RegionalInfluence Framework -```cpp -// Wind regions as mobile regional influences -class WindRegion : public RegionalInfluence { - void applyInfluenceToTile(WorldTile& tile) override { - distributeTokens(tile); - - // Create regional influence for persistent effects - if (isStormLevel()) { - createPersistentInfluence(tile, getStormType()); - } - } -}; -``` - -### Biome Generation Integration -```cpp -// Use accumulated climate tokens for biome classification -BiomeType classifyBiome(const WorldTile& tile) { - int total_rain = tile.getAccumulatedTokens("rain"); - int total_wind = tile.getAccumulatedTokens("wind"); - float temperature = tile.getTemperature(); - - if (total_rain > 500 && temperature > 20.0f) { - return BiomeType::TROPICAL_RAINFOREST; - } else if (total_rain < 50 && temperature > 15.0f) { - return BiomeType::HOT_DESERT; - } - // ... additional biome logic -} -``` - -## Implementation Priority - -### Phase 1: Core Framework (1-2 weeks) -1. WindRegion class and basic movement -2. Token distribution system -3. Simple spawn from ocean detection -4. Basic planetary circulation bands - -### Phase 2: ITCZ System (1-2 weeks) -1. Landmass analysis from TectonicRegions -2. ITCZ generation and gravitational effects -3. Wind region amplification mechanics -4. Storm classification system - -### Phase 3: Advanced Features (1-2 weeks) -1. Destruction token system and persistent effects -2. Seasonal variation and modulation -3. Performance optimization -4. Integration with biome generation - -### Phase 4: Tuning and Validation (1 week) -1. Parameter adjustment for realistic patterns -2. Verification of Congo/Sahara differentiation -3. Performance profiling and optimization -4. Documentation and examples - -## Configuration Example - -```json -{ - "climate_simulation": { - "wind_spawn_system": { - "base_spawn_rate": 0.1, - "ocean_size_factor": 0.001, - "max_concurrent_regions": 200 - }, - "planetary_circulation": { - "trade_winds_strength": 1.5, - "jet_stream_strength": 1.8, - "calm_zone_chaos": 0.3 - }, - "itcz_system": { - "latitude_band": [0.45, 0.55], - "min_landmass_size": 10000, - "max_ocean_distance": 800, - "amplification_max": 3.0 - }, - "storm_thresholds": { - "high_wind_min": 2.0, - "flood_wetness_min": 1.5, - "hurricane_wind_min": 2.5, - "hurricane_rain_min": 2.0 - }, - "token_distribution": { - "wind_token_factor": 10, - "rain_token_factor": 10, - "climate_zone_rate": 1 - } - } -} -``` - -**Note**: All parameters are hot-reloadable via the modular configuration system. Magic numbers are intentionally externalizable for real-time tuning during development - adjust values, save config, see immediate results without recompilation. -``` - -## Scientific Accuracy vs Gameplay - -### Scientifically Inspired Elements -- ✅ ITCZ formation from continental heating -- ✅ Planetary circulation bands (trade winds, jet streams) -- ✅ Storm formation from wind-moisture interaction -- ✅ Geographic influence on climate patterns -- ✅ Persistent landscape effects from weather - -### Gameplay Simplifications -- ⚠ 2D simulation instead of 3D atmospheric layers -- ⚠ Simplified storm evolution (no pressure systems) -- ⚠ Discrete token system instead of continuous fields -- ⚠ Accelerated timeframes for practical simulation - -### Result -**Plausible climate science** that creates **engaging gameplay** with **emergent complexity** from **simple, understandable rules**. - ---- - -**Status**: System designed and ready for implementation. Provides realistic climate differentiation (Sahara vs Congo) through elegant mobile region simulation using existing tectonic framework. \ No newline at end of file diff --git a/docs/02-systems/GEOLOGICAL_SIMULATION_SYSTEM.md b/docs/02-systems/GEOLOGICAL_SIMULATION_SYSTEM.md deleted file mode 100644 index 892d0a7..0000000 --- a/docs/02-systems/GEOLOGICAL_SIMULATION_SYSTEM.md +++ /dev/null @@ -1,1886 +0,0 @@ -# Geological Simulation System - -**Status**: Designed - Ready for Implementation -**Scope**: Complete planetary formation from accretion to industrial-ready geology -**Duration**: 4.65 billion years simulation in 95 cycles - -## System Overview - -Revolutionary geological simulation system that generates realistic planetary geology through scientifically-inspired processes. Creates diverse, coherent geology with proper resource distribution for industrial gameplay. - -### Key Innovations -- **RegionalInfluence framework** adapted for geological processes -- **Tectonic regions** as simple circles with forces (not complex mesh) -- **Carbon region system** for realistic coal/oil formation -- **Dynamic sea level** affecting all geological processes -- **Optimized 24-byte tiles** supporting geological temperature ranges - -## Simulation Phases - -### Phase 1: Planetary Accretion (30 cycles × 100M years = 3.0 Ga) - -**Initial Conditions**: -- Temperature: -100°C (space cold) -- Elevation: -30,000m (no surface) -- Empty planetary core - -**Process - Meteorite Bombardment**: -``` -For each wave (100M years): - 1. Generate 100-500 random meteorite impacts - 2. Each impact adds: - - Kinetic energy → heat (up to +2000°C) - - Mass → elevation change (+crater formation) - - Metal composition → resource deposits - 3. Heavy metals sink to planetary core - 4. Core temperature drives volcanic eruptions - 5. Eruptions redistribute core metals to surface - 6. Gradual cooling between waves -``` - -**Expected Results**: -- Surface elevation: -30,000m → -15,000m -- Core composition: 80% iron, 15% nickel, 5% precious metals -- Crater-based geology with metal deposits -- Temperature stabilization around 1000-1500°C - -### Phase 2: Tectonic Formation (25 cycles × 100M years = 2.5 Ga) - -**Reduced Meteorite Activity**: -```cpp -// Phase 2 meteorite parameters (reduced from Phase 1) -impacts_per_wave = rng.randInt(10, 50); // 10x reduction -meteorite_mass = rng.randFloat(10^12, 10^15); // Smaller impacts -impact_probability = 0.3f; // 30% chance per cycle -``` - -**Tectonic Region System**: -```cpp -struct TectonicRegion { - uint32_t region_id; - float center_x, center_y; // Mobile center (world coordinates) - float radius; // Current radius (tiles) - float velocity_x, velocity_y; // Movement (tiles per cycle) - float mass; // For repulsive force calculations - RegionType type; // OCEANIC, CONTINENTAL, VOLCANIC - - // Evolution parameters - float split_probability; // Chance to divide (0.01 = 1% per cycle) - float growth_rate; // Radius change per cycle (+/- tiles) - float stability; // Resistance to external forces - - // Formation tracking - int formation_cycle; // When this region was created - uint32_t parent_region_id; // If split from another region -}; - -enum class RegionType { - OCEANIC, // Dense, subducts under continental - CONTINENTAL, // Light, forms mountains when compressed - VOLCANIC, // Active volcanic zone (temporary) -}; -``` - -**Tectonic Physics Engine**: -```cpp -void updateTectonicRegions(float time_step) { - // 1. Calculate repulsive forces between all regions - for (auto& region1 : tectonic_regions) { - Vector2 total_force = {0.0f, 0.0f}; - - for (auto& region2 : tectonic_regions) { - if (region1.region_id == region2.region_id) continue; - - float distance = calculateDistance(region1.center, region2.center); - float overlap = (region1.radius + region2.radius) - distance; - - if (overlap > 0) { - // Collision detected! - Vector2 repulsion_direction = normalize(region1.center - region2.center); - - // Force magnitude: F = k * overlap^2 / (mass1 + mass2) - float force_magnitude = REPULSION_CONSTANT * overlap * overlap / - (region1.mass + region2.mass); - - Vector2 repulsion_force = repulsion_direction * force_magnitude; - total_force += repulsion_force; - - // Create volcanic zone at collision point - createVolcanicZone(region1, region2, overlap); - } - } - - // Apply acceleration: a = F/m - Vector2 acceleration = total_force / region1.mass; - region1.velocity_x += acceleration.x * time_step; - region1.velocity_y += acceleration.y * time_step; - - // Apply velocity damping (friction) - region1.velocity_x *= VELOCITY_DAMPING; - region1.velocity_y *= VELOCITY_DAMPING; - } - - // 2. Update positions and sizes - for (auto& region : tectonic_regions) { - // Move regions - region.center_x += region.velocity_x * time_step; - region.center_y += region.velocity_y * time_step; - - // Boundary wrapping (world is spherical) - wrapCoordinates(region.center_x, region.center_y); - - // Evolve size - region.radius += region.growth_rate * time_step; - region.radius = std::clamp(region.radius, MIN_REGION_RADIUS, MAX_REGION_RADIUS); - - // Check for splitting - if (region.radius > SPLIT_THRESHOLD && - rng.probability(region.split_probability * time_step)) { - splitTectonicRegion(region); - } - } -} -``` - -**Volcanic Zone Creation**: -```cpp -void createVolcanicZone(TectonicRegion& r1, TectonicRegion& r2, float collision_intensity) { - // Volcanic zone at intersection point - Vector2 intersection = calculateIntersectionCenter(r1, r2); - float volcanic_radius = collision_intensity * VOLCANIC_RADIUS_FACTOR; - - // Create temporary volcanic region - TectonicRegion volcanic_zone = { - .center_x = intersection.x, - .center_y = intersection.y, - .radius = volcanic_radius, - .type = RegionType::VOLCANIC, - .formation_cycle = current_cycle, - .split_probability = 0.05f, // High chance to break apart - .growth_rate = -0.1f // Shrinks over time - }; - - // Apply volcanic influence to affected tiles - RegionalInfluence volcanic_influence = { - .type = "volcanic_mountain_formation", - .intensity = collision_intensity, - .properties = json{ - {"elevation_bonus", collision_intensity * 500.0f}, // +500m per intensity - {"temperature_bonus", collision_intensity * 300.0f}, // +300°C - {"resource_deposits", json::array({"iron", "sulfur", "rare_metals"})}, - {"volcanic_features", json::array({"volcano", "hot_springs", "lava_tubes"})} - } - }; - - applyRegionalInfluence(volcanic_influence, intersection.x, intersection.y, volcanic_radius); - tectonic_regions.push_back(volcanic_zone); -} -``` - -**Region Splitting Algorithm**: -```cpp -void splitTectonicRegion(TectonicRegion& parent) { - // Create two child regions - float split_distance = parent.radius * 0.4f; - Vector2 split_direction = randomUnitVector(); - - TectonicRegion child1 = parent; - TectonicRegion child2 = parent; - - // Assign new IDs - child1.region_id = next_region_id++; - child2.region_id = next_region_id++; - child1.parent_region_id = parent.region_id; - child2.parent_region_id = parent.region_id; - - // Separate positions - child1.center_x += split_direction.x * split_distance; - child1.center_y += split_direction.y * split_distance; - child2.center_x -= split_direction.x * split_distance; - child2.center_y -= split_direction.y * split_distance; - - // Reduce sizes - child1.radius *= 0.7f; - child2.radius *= 0.7f; - - // Opposite velocities (moving apart) - child1.velocity_x = split_direction.x * SPLIT_VELOCITY; - child1.velocity_y = split_direction.y * SPLIT_VELOCITY; - child2.velocity_x = -split_direction.x * SPLIT_VELOCITY; - child2.velocity_y = -split_direction.y * SPLIT_VELOCITY; - - // Replace parent with children - removeRegion(parent); - addRegion(child1); - addRegion(child2); - - // Create rift valley between children - createRiftValley(child1, child2); -} -``` - -**Expected Results**: -- Surface elevation: -15,000m → -5,000m (+10km crustal thickening) -- Formation of 15-25 stable tectonic regions -- Mountain ranges at collision zones (+1000-3000m elevation) -- Rift valleys where regions separate (-500m elevation) -- Distinct continental vs oceanic regions - -### Phase 3: Hydrological Cycles (25 cycles × 20M years = 0.5 Ga) - -**Dynamic Sea Level System**: -```cpp -struct OceanLevel { - float current_sea_level; // Global reference (meters) - float ice_volume; // Polar ice volume (kmÂł) - float thermal_expansion_factor; // Ocean thermal expansion coefficient - float tectonic_basin_volume; // Total oceanic basin volume - - void updateSeaLevel(float global_temperature, float volcanic_co2) { - // 1. Ice volume changes (glaciation/melting) - float target_ice_volume = calculateIceVolume(global_temperature); - float ice_change = (target_ice_volume - ice_volume) * 0.1f; // 10% change per cycle - ice_volume += ice_change; - - // Sea level change: 1 kmÂł ice = +2.7mm sea level - float ice_effect = -ice_change * 0.0027f; - - // 2. Thermal expansion - float thermal_effect = (global_temperature - 15.0f) * thermal_expansion_factor; - - // 3. Tectonic effects (basin formation/destruction) - float tectonic_effect = (tectonic_basin_volume - baseline_basin_volume) * 0.001f; - - // 4. Update sea level - current_sea_level += ice_effect + thermal_effect + tectonic_effect; - current_sea_level = std::clamp(current_sea_level, -200.0f, +100.0f); // Realistic bounds - } - - float calculateIceVolume(float global_temp) const { - if (global_temp < -5.0f) return MAX_ICE_VOLUME; // Ice age - if (global_temp > 25.0f) return 0.0f; // No ice - return MAX_ICE_VOLUME * (25.0f - global_temp) / 30.0f; // Linear interpolation - } -}; -``` - -**Hydraulic Erosion System**: -```cpp -void applyHydraulicErosion(float cycle_duration_years) { - const float HYDRAULIC_EFFICIENCY = 10.0f; // 10x more effective than tectonic - - for (int y = 0; y < map_height; ++y) { - for (int x = 0; x < map_width; ++x) { - WorldTile tile = world_map->getTile(x, y); - float elevation = tile.getElevation(); - - if (elevation > current_sea_level) { - // CONTINENTAL EROSION - - // 1. Calculate water flow (slope-based) - float average_neighbor_elevation = calculateAverageNeighborElevation(x, y); - float slope = elevation - average_neighbor_elevation; - float water_flow = std::max(0.0f, slope * 0.01f); // Flow intensity - - // 2. Erosion rate based on elevation and flow - float elevation_factor = (elevation - current_sea_level) / 1000.0f; // Higher = more erosion - float erosion_rate = water_flow * elevation_factor * HYDRAULIC_EFFICIENCY; - - // 3. Apply erosion - float erosion_amount = erosion_rate * cycle_duration_years / 1000000.0f; // Per million years - tile.setElevation(elevation - erosion_amount); - - // 4. Transport sediments downstream - transportSediments(tile, x, y, erosion_amount); - - } else if (elevation > current_sea_level - 200.0f) { - // COASTAL EROSION - - float depth_below_sea = current_sea_level - elevation; - float coastal_erosion_rate = 50.0f; // Intense coastal erosion - - if (depth_below_sea < 50.0f) { // Shallow coastal zone - float erosion_amount = coastal_erosion_rate * cycle_duration_years / 1000000.0f; - tile.setElevation(elevation - erosion_amount); - - // Form beaches and deltas - if (hasRiverInput(x, y)) { - formDelta(tile, x, y); - } - } - - } else { - // DEEP OCEAN - sediment deposition - - float sedimentation_rate = calculateSedimentInput(x, y); - float deposition_amount = sedimentation_rate * cycle_duration_years / 1000000.0f; - tile.setElevation(elevation + deposition_amount); - } - } - } -} - -void transportSediments(WorldTile& source_tile, int x, int y, float sediment_amount) { - // Find steepest downhill direction - auto [target_x, target_y] = findSteepestDescentDirection(x, y); - - if (target_x != x || target_y != y) { - WorldTile target_tile = world_map->getTile(target_x, target_y); - - // Deposit sediments at target - float current_elevation = target_tile.getElevation(); - target_tile.setElevation(current_elevation + sediment_amount * 0.5f); // 50% deposition - - // Create river network - createRiverSegment(x, y, target_x, target_y); - - // Continue transport if target is above sea level - if (target_tile.getElevation() > current_sea_level) { - transportSediments(target_tile, target_x, target_y, sediment_amount * 0.5f); - } - } -} -``` - -**River Network Formation**: -```cpp -struct RiverNetwork { - std::unordered_map> river_connections; // tile -> downstream tiles - std::unordered_map flow_volumes; // tile -> water volume - - void createRiverSegment(int from_x, int from_y, int to_x, int to_y) { - uint32_t from_index = from_y * map_width + from_x; - uint32_t to_index = to_y * map_width + to_x; - - // Add connection - river_connections[from_index].push_back(to_index); - - // Increase flow volume - flow_volumes[to_index] += flow_volumes[from_index] + 1.0f; - - // Mark tiles as having river features - WorldTile from_tile = world_map->getTile(from_x, from_y); - WorldTile to_tile = world_map->getTile(to_x, to_y); - - from_tile.setFlag(TileFlags::HAS_RIVER, true); - to_tile.setFlag(TileFlags::HAS_RIVER, true); - } - - void formDelta(WorldTile& tile, int x, int y) { - // Delta formation where river meets ocean - RegionalInfluence delta_influence = { - .type = "river_delta", - .intensity = flow_volumes[y * map_width + x] / 100.0f, // Intensity based on river size - .properties = json{ - {"elevation_bonus", 10.0f}, // Slight elevation increase - {"sediment_richness", 1.5f}, // Rich sediments - {"features", json::array({"wetlands", "fertile_soil", "natural_harbors"})} - } - }; - - applyRegionalInfluence(delta_influence, x, y, 5.0f); // 5-tile radius - } -}; -``` - -**Climate Integration**: -```cpp -void updateGlobalClimate(float cycle_duration) { - // 1. Volcanic CO2 emissions - float volcanic_co2 = calculateVolcanicCO2Emissions(); - atmospheric_co2 += volcanic_co2; - - // 2. Weathering CO2 absorption - float weathering_absorption = calculateWeatheringRate() * cycle_duration; - atmospheric_co2 -= weathering_absorption; - - // 3. Temperature from CO2 (greenhouse effect) - global_temperature = BASE_TEMPERATURE + log(atmospheric_co2 / BASELINE_CO2) * CLIMATE_SENSITIVITY; - - // 4. Update sea level based on new temperature - ocean_level.updateSeaLevel(global_temperature, volcanic_co2); - - // 5. Regional climate effects - updateRegionalClimate(); -} - -void updateRegionalClimate() { - for (int y = 0; y < map_height; ++y) { - for (int x = 0; x < map_width; ++x) { - WorldTile tile = world_map->getTile(x, y); - float elevation = tile.getElevation(); - - // Temperature varies with elevation (lapse rate: -6.5°C/km) - float local_temperature = global_temperature - (elevation / 1000.0f) * 6.5f; - - // Distance from ocean affects temperature (continental effect) - float ocean_distance = calculateDistanceToOcean(x, y); - float continental_effect = ocean_distance / 1000.0f * 2.0f; // +2°C per 1000km inland - local_temperature += continental_effect; - - tile.setTemperature(local_temperature); - - // Humidity based on proximity to water and temperature - float humidity = calculateHumidity(ocean_distance, local_temperature, elevation); - tile.setHumidity(humidity); - } - } -} -``` - -**Expected Results**: -- Surface elevation: -5,000m → 0m (modern sea level) -- Formation of permanent river networks draining to oceans -- Coastal features: deltas, beaches, fjords, cliffs -- Climate zones established based on elevation and ocean proximity -- Sedimentary basins filled with eroded material - -### Phase 4: Carboniferous Period (35 cycles × 10M years = 0.35 Ga) - -**Dynamic Forest System**: -```cpp -// Forest seeds are continuously created and destroyed by geological events -void manageDynamicForests(GMap& map, int cycle) { - // Always seed new forests with base probability - seedNewForests(map); - - // Existing forests attempt to expand - expandExistingForests(map); - - // Geological events destroy forests - destroyForestsByGeologicalEvents(map, cycle); -} - -void seedNewForests(GMap& map) { - for (each_tile) { - float seed_probability = base_forest_seed_rate; - - // Environmental modifiers - if (tile.getTemperature() >= 15.0f && tile.getTemperature() <= 35.0f) { - seed_probability *= temperature_bonus; // Optimal temperature - } - if (tile.getHumidity() > 0.4f) { - seed_probability *= humidity_bonus; // Sufficient moisture - } - if (tile.getElevation() < 2000.0f) { - seed_probability *= elevation_bonus; // Below treeline - } - - if (random() < seed_probability) { - createForestSeed(tile); - } - } -} - -void expandExistingForests(GMap& map) { - for (each_forest_tile) { - for (each_neighbor) { - if (isViableForForest(neighbor) && random() < forest_expansion_rate) { - expandForestTo(neighbor); - } - } - } -} - -void destroyForestsByGeologicalEvents(GMap& map, int cycle) { - // Volcanic eruptions destroy forests - for (auto& volcanic_event : getCurrentVolcanicEvents(cycle)) { - destroyForestsInRadius(volcanic_event.center, volcanic_event.destruction_radius); - } - - // Major floods destroy forests - for (each_tile_with_extreme_water_level) { - if (tile.getWaterLevel() > flood_destruction_threshold) { - destroyForest(tile); - } - } - - // Extreme erosion destroys forests - for (each_tile) { - if (getCurrentErosionRate(tile) > erosion_destruction_threshold) { - destroyForest(tile); - } - } - - // Climate extremes destroy forests - if (tile.getTemperature() < -10.0f || tile.getTemperature() > 50.0f) { - destroyForest(tile); - } -} -``` - -**Carbon Region System**: -```cpp -struct CarbonRegion { - uint32_t region_id; - float center_x, center_y; // Position (world coordinates) - float radius; // Affected area (tiles) - float carbon_mass; // Total carbon content (megatons) - int formation_cycle; // When this region was created - CarbonType type; // Current state: COAL, OIL, GAS - - // Tectonic attachment - uint32_t attached_tectonic_region_id; // Moves with tectonic plate - float attachment_strength; // 0.8-1.0 (strong attachment) - - // Conversion tracking - float original_coal_mass; // Initial coal amount - float conversion_progress; // 0.0-1.0 (coal→oil conversion) - int cycles_underwater; // How long submerged -}; - -enum class CarbonType { - COAL, // Terrestrial formation - OIL, // Marine conversion - NATURAL_GAS // Late-stage oil maturation -}; -``` - -**Forest Growth and Coal Formation**: -```cpp -void processForestGrowth(int cycle) { - for (int y = 0; y < map_height; ++y) { - for (int x = 0; x < map_width; ++x) { - WorldTile tile = world_map->getTile(x, y); - - if (isForestSuitable(tile, x, y)) { - float biomass_potential = calculateBiomassPotential(tile); - float forest_density = std::min(1.0f, biomass_potential); - - if (forest_density > 0.3f) { // Minimum density for coal formation - // Create or enhance carbon region - CarbonRegion* existing_region = findNearestCarbonRegion(x, y, 5.0f); - - if (existing_region) { - // Add to existing region - enhanceCarbonRegion(*existing_region, forest_density); - } else { - // Create new carbon region - CarbonRegion new_region = createCarbonRegion(x, y, forest_density, cycle); - carbon_regions.push_back(new_region); - } - } - } - } - } - - // Merge nearby carbon regions - mergeCarbonRegions(); -} - -bool isForestSuitable(const WorldTile& tile, int x, int y) { - float elevation = tile.getElevation(); - float temperature = tile.getTemperature(); - float humidity = tile.getHumidity(); - - return (elevation > current_sea_level + 10.0f) && // Above sea level - (elevation < current_sea_level + 1000.0f) && // Not too mountainous - (temperature >= 10.0f && temperature <= 30.0f) && // Temperate range - (humidity > 0.4f) && // Sufficient moisture - (!tile.getFlag(TileFlags::VOLCANIC_ACTIVE)); // Not volcanically active -} - -CarbonRegion createCarbonRegion(int x, int y, float forest_density, int cycle) { - CarbonRegion region; - region.region_id = next_carbon_region_id++; - region.center_x = x; - region.center_y = y; - region.radius = forest_density * 8.0f; // Dense forests = larger regions - region.carbon_mass = forest_density * 100.0f; // Base carbon mass (megatons) - region.formation_cycle = cycle; - region.type = CarbonType::COAL; - - // Attach to nearest tectonic region - TectonicRegion* nearest_tectonic = findNearestTectonicRegion(x, y); - if (nearest_tectonic) { - region.attached_tectonic_region_id = nearest_tectonic->region_id; - region.attachment_strength = 0.9f; // Strong attachment - } - - return region; -} -``` - -**Carbon Region Movement and Merging**: -```cpp -void updateCarbonRegionMovement(float time_step) { - for (auto& carbon_region : carbon_regions) { - TectonicRegion* tectonic = getTectonicRegion(carbon_region.attached_tectonic_region_id); - - if (tectonic) { - // Move with tectonic plate - carbon_region.center_x += tectonic->velocity_x * carbon_region.attachment_strength * time_step; - carbon_region.center_y += tectonic->velocity_y * carbon_region.attachment_strength * time_step; - - // Handle tectonic collisions - if (tectonic->isInCollision()) { - float collision_stress = tectonic->getCollisionIntensity(); - - if (collision_stress > 2.0f) { - // High stress can redistribute carbon deposits - redistributeCarbonDeposit(carbon_region, collision_stress); - } - } - } - } -} - -void mergeCarbonRegions() { - for (size_t i = 0; i < carbon_regions.size(); ++i) { - for (size_t j = i + 1; j < carbon_regions.size(); ++j) { - float distance = calculateDistance(carbon_regions[i].center, carbon_regions[j].center); - float merge_threshold = (carbon_regions[i].radius + carbon_regions[j].radius) * 0.8f; - - if (distance < merge_threshold) { - // Merge regions - CarbonRegion merged; - merged.region_id = next_carbon_region_id++; - merged.center_x = (carbon_regions[i].center_x + carbon_regions[j].center_x) / 2.0f; - merged.center_y = (carbon_regions[i].center_y + carbon_regions[j].center_y) / 2.0f; - merged.radius = sqrt(carbon_regions[i].radius * carbon_regions[i].radius + - carbon_regions[j].radius * carbon_regions[j].radius); - merged.carbon_mass = carbon_regions[i].carbon_mass + carbon_regions[j].carbon_mass; - merged.formation_cycle = std::min(carbon_regions[i].formation_cycle, carbon_regions[j].formation_cycle); - merged.type = CarbonType::COAL; // Combined regions start as coal - - // Remove original regions and add merged - carbon_regions.erase(carbon_regions.begin() + j); - carbon_regions.erase(carbon_regions.begin() + i); - carbon_regions.push_back(merged); - - break; // Start over after modification - } - } - } -} -``` - -**Coal to Oil Conversion**: -```cpp -void processCoalToOilConversion(int current_cycle) { - const float CONVERSION_RATE_PER_CYCLE = 0.05f; // 5% per cycle (10M years) - const float NATURAL_GAS_RATIO = 0.15f; // 15% of oil becomes gas - - for (auto& coal_region : carbon_regions) { - if (coal_region.type == CarbonType::COAL && isRegionUnderwater(coal_region)) { - coal_region.cycles_underwater++; - - // Only convert if underwater for multiple cycles (pressure + time) - if (coal_region.cycles_underwater >= 3) { - float conversion_amount = coal_region.carbon_mass * CONVERSION_RATE_PER_CYCLE; - - if (conversion_amount > 1.0f) { // Minimum threshold - // Create oil region at same location - CarbonRegion oil_region = coal_region; - oil_region.region_id = next_carbon_region_id++; - oil_region.type = CarbonType::OIL; - oil_region.carbon_mass = conversion_amount; - oil_region.radius *= 0.8f; // Oil regions are more concentrated - oil_region.formation_cycle = current_cycle; - - // Create natural gas as byproduct - if (conversion_amount > 10.0f) { - CarbonRegion gas_region = oil_region; - gas_region.region_id = next_carbon_region_id++; - gas_region.type = CarbonType::NATURAL_GAS; - gas_region.carbon_mass = conversion_amount * NATURAL_GAS_RATIO; - gas_region.radius *= 1.2f; // Gas spreads more widely - - carbon_regions.push_back(gas_region); - } - - // Reduce original coal region - coal_region.carbon_mass -= conversion_amount; - coal_region.conversion_progress += CONVERSION_RATE_PER_CYCLE; - - // Add oil region - carbon_regions.push_back(oil_region); - - // Remove depleted coal regions - if (coal_region.carbon_mass < 1.0f) { - // Mark for removal - coal_region.carbon_mass = 0.0f; - } - } - } - } - } - - // Remove depleted regions - carbon_regions.erase( - std::remove_if(carbon_regions.begin(), carbon_regions.end(), - [](const CarbonRegion& region) { return region.carbon_mass < 1.0f; }), - carbon_regions.end() - ); -} - -bool isRegionUnderwater(const CarbonRegion& region) { - // Check if majority of region is below sea level - int underwater_tiles = 0; - int total_tiles = 0; - - int radius_int = static_cast(region.radius); - for (int dy = -radius_int; dy <= radius_int; ++dy) { - for (int dx = -radius_int; dx <= radius_int; ++dx) { - float distance = sqrt(dx*dx + dy*dy); - if (distance <= region.radius) { - int x = static_cast(region.center_x) + dx; - int y = static_cast(region.center_y) + dy; - - if (world_map->isValidCoordinate(x, y)) { - WorldTile tile = world_map->getTile(x, y); - total_tiles++; - - if (tile.getElevation() < current_sea_level - 50.0f) { // 50m underwater minimum - underwater_tiles++; - } - } - } - } - } - - return (static_cast(underwater_tiles) / total_tiles) > 0.6f; // 60% underwater -} -``` - -**Resource Application to Tiles**: -```cpp -void applyCarbonRegionsToTiles() { - for (const auto& region : carbon_regions) { - int radius_int = static_cast(region.radius); - - for (int dy = -radius_int; dy <= radius_int; ++dy) { - for (int dx = -radius_int; dx <= radius_int; ++dx) { - float distance = sqrt(dx*dx + dy*dy); - if (distance <= region.radius) { - int x = static_cast(region.center_x) + dx; - int y = static_cast(region.center_y) + dy; - - if (world_map->isValidCoordinate(x, y)) { - WorldTile tile = world_map->getTile(x, y); - float influence = 1.0f - (distance / region.radius); // Gradient from center - - // Apply resource based on carbon type - switch (region.type) { - case CarbonType::COAL: - addResourceToTile(tile, "coal", region.carbon_mass * influence); - break; - case CarbonType::OIL: - addResourceToTile(tile, "petroleum", region.carbon_mass * influence); - break; - case CarbonType::NATURAL_GAS: - addResourceToTile(tile, "natural_gas", region.carbon_mass * influence); - break; - } - } - } - } - } - } -} -``` - -**Expected Results**: -- **Dynamic forest evolution**: Forests continuously seed, expand, and get destroyed by geological events -- **Multiple forest generations**: Layers of carbon deposits from different geological periods -- **Realistic forest patterns**: Forests avoid active volcanic zones, extreme climates, and flood-prone areas -- **Coal deposit diversity**: Various ages and qualities of coal from different forest cycles -- **Oil formation**: Submerged forest areas naturally convert to petroleum over time -- **Geological storytelling**: Each coal seam represents a specific period of forest growth and burial - -### Phase 5: Pre-Faunal Stabilization (15 cycles × 10M years = 0.15 Ga) - -**Maturation-Only Phase - No New Formation**: -```cpp -void processStabilizationCycle(int cycle) { - // 1. HYDROCARBON MATURATION (no new formation) - continueHydrocarbonMaturation(); - - // 2. PETROLEUM MIGRATION TO TRAPS - migratePetroleumToGeologicalTraps(); - - // 3. FINAL EROSION PHASE - applyFinalErosion(); - - // 4. SOIL LAYER DEVELOPMENT - developSoilLayers(); - - // 5. CLIMATE STABILIZATION - stabilizeClimate(); - - // 6. GEOLOGICAL STRUCTURE FINALIZATION - finalizeGeologicalStructures(); -} -``` - -**Continued Hydrocarbon Maturation**: -```cpp -void continueHydrocarbonMaturation() { - const float REDUCED_CONVERSION_RATE = 0.03f; // Slower than Carboniferous (3% per cycle) - - for (auto& coal_region : carbon_regions) { - if (coal_region.type == CarbonType::COAL && isRegionUnderwater(coal_region)) { - // Continue coal→oil conversion at reduced rate - float conversion_amount = coal_region.carbon_mass * REDUCED_CONVERSION_RATE; - - if (conversion_amount > 0.5f) { // Lower threshold for final conversion - processCoalToOilConversion(coal_region, conversion_amount); - } - } - } - - // Oil→Gas maturation for old oil deposits - for (auto& oil_region : carbon_regions) { - if (oil_region.type == CarbonType::OIL) { - int oil_age = current_cycle - oil_region.formation_cycle; - - if (oil_age > 10 && oil_region.carbon_mass > 5.0f) { // Mature oil deposits - float gas_conversion = oil_region.carbon_mass * 0.02f; // 2% oil→gas - - createNaturalGasFromOil(oil_region, gas_conversion); - } - } - } -} -``` - -**Petroleum Migration to Geological Traps**: -```cpp -struct GeologicalTrap { - float center_x, center_y; - float capacity; // Maximum hydrocarbon storage - float current_fill; // Current hydrocarbon content - TrapType type; // ANTICLINE, FAULT, SALT_DOME, STRATIGRAPHIC - float formation_cycle; // When trap was formed -}; - -enum class TrapType { - ANTICLINE, // Upward fold in rock layers - FAULT_TRAP, // Hydrocarbon blocked by fault - SALT_DOME, // Hydrocarbon trapped around salt intrusion - STRATIGRAPHIC // Trapped between different rock types -}; - -void migratePetroleumToGeologicalTraps() { - // 1. Identify geological traps from tectonic history - std::vector traps = identifyGeologicalTraps(); - - // 2. Migrate oil and gas to nearest suitable traps - for (auto& hydrocarbon_region : carbon_regions) { - if (hydrocarbon_region.type == CarbonType::OIL || hydrocarbon_region.type == CarbonType::NATURAL_GAS) { - GeologicalTrap* nearest_trap = findNearestTrap(hydrocarbon_region, traps); - - if (nearest_trap && nearest_trap->current_fill < nearest_trap->capacity) { - float migration_amount = calculateMigrationAmount(hydrocarbon_region, *nearest_trap); - - // Move hydrocarbons to trap - nearest_trap->current_fill += migration_amount; - hydrocarbon_region.carbon_mass -= migration_amount; - - // Concentrate hydrocarbons in trap location - concentrateHydrocarbonsAtTrap(*nearest_trap, hydrocarbon_region.type, migration_amount); - } - } - } -} - -std::vector identifyGeologicalTraps() { - std::vector traps; - - // Find anticlines (upward folds) from tectonic compression - for (const auto& tectonic_region : tectonic_regions) { - if (tectonic_region.type == RegionType::CONTINENTAL) { - // Look for elevation highs within the region (potential anticlines) - auto high_points = findElevationHighsInRegion(tectonic_region); - - for (const auto& point : high_points) { - GeologicalTrap anticline = { - .center_x = point.x, - .center_y = point.y, - .capacity = calculateAnticlineCapacity(point), - .current_fill = 0.0f, - .type = TrapType::ANTICLINE, - .formation_cycle = tectonic_region.formation_cycle - }; - traps.push_back(anticline); - } - } - } - - // Find fault traps from tectonic collisions - for (const auto& collision_zone : historical_tectonic_collisions) { - GeologicalTrap fault_trap = { - .center_x = collision_zone.center_x, - .center_y = collision_zone.center_y, - .capacity = collision_zone.intensity * 50.0f, // Capacity based on collision intensity - .current_fill = 0.0f, - .type = TrapType::FAULT_TRAP, - .formation_cycle = collision_zone.formation_cycle - }; - traps.push_back(fault_trap); - } - - return traps; -} -``` - -**Final Erosion and Surface Formation**: -```cpp -void applyFinalErosion() { - const float FINAL_EROSION_RATE = 5.0f; // Reduced from active hydrological phase - - for (int y = 0; y < map_height; ++y) { - for (int x = 0; x < map_width; ++x) { - WorldTile tile = world_map->getTile(x, y); - float elevation = tile.getElevation(); - - if (elevation > current_sea_level) { - // Expose coal seams through erosion - exposeCoalSeams(tile, x, y); - - // Carve final river valleys - carveRiverValleys(tile, x, y); - - // Form final coastal features - if (elevation < current_sea_level + 100.0f) { // Coastal zone - formCoastalFeatures(tile, x, y); - } - } - } - } -} - -void exposeCoalSeams(WorldTile& tile, int x, int y) { - // Check if there are coal deposits below current elevation - CarbonRegion* coal_region = findCoalRegionAt(x, y); - - if (coal_region && coal_region->type == CarbonType::COAL) { - float erosion_depth = calculateErosionDepth(tile); - - if (erosion_depth > 50.0f) { // Significant erosion - // Expose coal seam at surface - tile.setFlag(TileFlags::SURFACE_COAL, true); - - // Add surface coal resource - addResourceToTile(tile, "surface_coal", coal_region->carbon_mass * 0.1f); - } - } -} -``` - -**Soil Development System**: -```cpp -void developSoilLayers() { - for (int y = 0; y < map_height; ++y) { - for (int x = 0; x < map_width; ++x) { - WorldTile tile = world_map->getTile(x, y); - - if (tile.getElevation() > current_sea_level + 5.0f) { // Above sea level - SoilType soil = determineSoilType(tile, x, y); - float soil_depth = calculateSoilDepth(tile, x, y); - - // Apply soil influence - RegionalInfluence soil_influence = { - .type = "soil_development", - .intensity = soil_depth / 10.0f, // Depth in meters / 10 - .properties = json{ - {"soil_type", getSoilTypeName(soil)}, - {"fertility", calculateSoilFertility(soil, tile)}, - {"drainage", calculateSoilDrainage(soil, tile)}, - {"ph_level", calculateSoilPH(soil, tile)} - } - }; - - applyRegionalInfluence(soil_influence, x, y, 1.0f); - } - } - } -} - -enum class SoilType { - CLAY, // Heavy, nutrient-rich, poor drainage - SAND, // Light, good drainage, low nutrients - LOAM, // Balanced, ideal for agriculture - PEAT, // Organic-rich, acidic, wetland areas - ROCKY, // Thin soil, mountainous areas - ALLUVIAL // River deposits, very fertile -}; - -SoilType determineSoilType(const WorldTile& tile, int x, int y) { - float elevation = tile.getElevation(); - float temperature = tile.getTemperature(); - float humidity = tile.getHumidity(); - - // River deltas and floodplains - if (tile.getFlag(TileFlags::HAS_RIVER) && elevation < current_sea_level + 50.0f) { - return SoilType::ALLUVIAL; - } - - // Wetland areas - if (humidity > 0.8f && elevation < current_sea_level + 20.0f) { - return SoilType::PEAT; - } - - // Mountainous areas - if (elevation > current_sea_level + 1000.0f) { - return SoilType::ROCKY; - } - - // Climate-based soil formation - if (temperature > 20.0f && humidity < 0.3f) { - return SoilType::SAND; // Arid regions - } else if (temperature < 10.0f && humidity > 0.6f) { - return SoilType::CLAY; // Cold, wet regions - } else { - return SoilType::LOAM; // Temperate regions - } -} -``` - -**Final Climate Stabilization**: -```cpp -void stabilizeClimate() { - // Reduce climate variability and volcanic activity - volcanic_activity_level *= 0.8f; // 20% reduction per cycle - climate_stability += 0.1f; // Increase stability - - // Establish final climate zones - for (int y = 0; y < map_height; ++y) { - for (int x = 0; x < map_width; ++x) { - WorldTile tile = world_map->getTile(x, y); - - ClimateZone zone = determineClimateZone(tile, x, y); - applyClimateZone(tile, zone); - } - } -} - -enum class ClimateZone { - ARCTIC, // < -10°C, low precipitation - SUBARCTIC, // -10 to 0°C, moderate precipitation - TEMPERATE, // 0 to 20°C, variable precipitation - SUBTROPICAL, // 20 to 30°C, high precipitation - TROPICAL, // > 30°C, very high precipitation - ARID, // Any temperature, very low precipitation - MEDITERRANEAN // Warm, dry summers, mild wet winters -}; -``` - -**Final Geological State**: -```cpp -struct FinalGeologicalState { - // TERRAIN - ✅ stable_continents; // Continental masses established - ✅ ocean_basins; // Deep ocean basins - ✅ mountain_ranges; // Various ages, realistic erosion - ✅ river_networks; // Mature drainage systems - ✅ coastal_features; // Beaches, cliffs, deltas, fjords - - // RESOURCES - ✅ coal_deposits; // Continental basins, exposed seams - ✅ oil_fields; // Sedimentary basins, geological traps - ✅ natural_gas; // Associated with oil, separate fields - ✅ metal_deposits; // From meteorite impacts and volcanism - - // CLIMATE - ✅ climate_zones; // Stable temperature/precipitation patterns - ✅ soil_types; // Mature soil development - ✅ seasonal_patterns; // Established weather cycles - - // READY FOR INDUSTRIAL GAMEPLAY - ✅ resource_accessibility; // Surface coal, shallow oil, metal ores - ✅ transportation_routes; // Rivers, coastal access, terrain variety - ✅ strategic_locations; // Resource clusters, defensive positions - ✅ environmental_challenges; // Climate zones, terrain obstacles -}; -``` - -**Expected Results**: -- **Complete geological maturity**: All major processes stabilized -- **Industrial-ready resources**: Coal seams exposed, oil in accessible traps -- **Realistic geography**: Mountain ranges, river valleys, coastal plains -- **Climate diversity**: Multiple biomes and environmental conditions -- **Strategic complexity**: Resource distribution creates interesting gameplay choices -- **Historical coherence**: Geological features tell the story of planetary formation - -## Phase 6: Climate Simulation and Biome Generation - -### Overview -After geological stabilization, run advanced climate simulation using mobile WindRegions and Inter-Tropical Convergence Zones (ITCZ) to establish realistic temperature, humidity, and wind patterns. Creates emergent weather patterns through wind region interactions rather than predefined climate zones. - -**Key Innovation**: Revolutionary climate simulation using **mobile wind regions** that spawn, evolve, and interact to create emergent weather patterns. Solves the "Sahara vs Congo" problem through **Inter-Tropical Convergence Zones (ITCZ)** and **planetary rotation bands** without complex 3D atmospheric physics. - -### Climate Simulation Architecture - -**Phase 6.1: Landmass Analysis and ITCZ Generation** - -Uses existing TectonicRegions from Phase 2: -```cpp -// Analyze continental masses from existing tectonic data -std::vector continents = groupTectonicRegions(); - -// Generate water masses by inverse analysis -std::vector oceans = detectOceanBasins(continents); - -// Place ITCZ zones on qualifying equatorial landmasses -for (auto& continent : continents) { - if (continent.latitude >= 0.45 && continent.latitude <= 0.55 && - continent.area > MIN_LANDMASS_SIZE) { - createITCZ(continent.center, sqrt(continent.area)); - } -} -``` - -**ITCZ Requirements:** -- **Latitude Band**: 45-55% of map height (equatorial) -- **Minimum Landmass**: 10,000+ tiles -- **Ocean Proximity**: Within 800km for moisture source -- **Continental Heating**: Large thermal mass for convection - -**Phase 6.2: WindRegion Spawning System** - -Mobile WindRegions spawn from ocean masses: -```json -"wind_spawn_system": { - "spawn_locations": "ocean_masses_only", - "spawn_frequency": "water_mass_size / 1000", - "initial_strength": "water_temperature * evaporation_factor", - "spawn_distribution": "random_within_water_region_biased_toward_center" -} -``` - -**WindRegion Mobile Entities:** -```json -"wind_region": { - "position": [x, y], - "wind_strength": 1.0, // Base intensity (decays over time) - "wetness": 0.0, // Moisture content (gained over ocean) - "velocity": [vx, vy], // Movement vector - "wind_tokens": 100, // Distributed to tiles - "decay_per_move": 0.02, // -2% strength per movement - "decay_per_tile": 0.01 // -1% strength per tile crossed -} -``` - -**Phase 6.3: Movement and Planetary Circulation** - -Planetary rotation bands based on real atmospheric data: -```json -"planetary_circulation": { - "polar_jet_north": { - "latitude_range": [0.10, 0.25], - "direction": "west_to_east", - "strength": 1.8 - }, - "equatorial_trades": { - "latitude_range": [0.40, 0.60], - "direction": "east_to_west", - "strength": 1.5 - }, - "polar_jet_south": { - "latitude_range": [0.75, 0.95], - "direction": "west_to_east", - "strength": 1.8 - } -} -``` - -**Movement Calculation:** -```cpp -Vector2 movement = - planetary_rotation_band * 0.6 + // 60% planetary circulation - equator_to_pole_bias * 0.2 + // 20% thermal circulation - terrain_deflection * 0.1 + // 10% topographic influence - random_variation * 0.1; // 10% chaos -``` - -**Phase 6.4: WindRegion Evolution and Interactions** - -Dynamic evolution with ITCZ gravitational effects: -```cpp -void updateWindRegion(WindRegion& region) { - // Gain moisture over water - if (currentTile.isOcean()) { - region.wetness += OCEAN_MOISTURE_GAIN; - } - - // Repulsion from other regions = acceleration - // NOTE: Not physical repulsion - proxy for spatial competition and turbulence - // Prevents region stacking while creating realistic dispersion patterns - // CRITIQUE POINT: May cause "force field" effect around ITCZ zones where regions - // oscillate/scatter instead of converging due to attraction vs repulsion conflict. - // Alternative approaches: density-based drift, no interaction, or collision division. - // TODO: Implement as configurable algorithm options for empirical testing. - float repulsion = calculateRepulsionForce(region, nearbyRegions); - region.wind_strength += repulsion * ACCELERATION_FACTOR; - - // Movement decay - region.wind_strength *= (1.0 - DECAY_PER_MOVE); - - // Die when too weak - if (region.wind_strength < MINIMUM_THRESHOLD) { - destroyRegion(region); - } -} -``` - -**ITCZ Gravitational Effects:** -```cpp -void applyITCZGravity(WindRegion& region) { - for (auto& itcz : active_itcz_zones) { - float distance = calculateDistance(region.position, itcz.center); - - if (distance < itcz.gravitational_range) { - // Attraction force (inverse square law) - // NOTE: "Gravitational" metaphor for influence strength, not literal physics - // Like saying someone has "gravitas" - clear semantic meaning for developers - float attraction = itcz.mass / (distance * distance); - Vector2 pull_direction = normalize(itcz.center - region.position); - - // Apply attraction - region.velocity += pull_direction * attraction; - - // Amplification effect as region approaches - float proximity = (itcz.range - distance) / itcz.range; - float amplification = 1.0 + (itcz.max_amplification * proximity); - - region.wind_strength *= amplification; - region.wetness *= amplification; - } - } -} -``` - -**Phase 6.5: Token Distribution and Climate Zone Formation** - -Climate zone classification using token accumulation: -```cpp -void distributeTokens(WindRegion& region) { - // Basic climate tokens for all regions - int wind_tokens = static_cast(region.wind_strength * 10); - int rain_tokens = static_cast(region.wetness * 10); - - WorldTile& tile = world_map.getTile(region.position); - tile.addTokens("wind", wind_tokens); - tile.addTokens("rain", rain_tokens); - - // Special climate zone tokens for extreme weather - if (isHighWindZone(region)) { - tile.addTokens("highWind", 1); // Hostile to forests - } - if (isFloodZone(region)) { - tile.addTokens("flood", 1); // Forces wetlands/marshes - } - if (isHurricaneZone(region)) { - tile.addTokens("hurricane", 1); // Specialized hurricane biome - } -} -``` - -### Climate Zone Effects on Biome Generation - -**Token-Based Biome Classification:** -```cpp -BiomeType classifyBiome(const WorldTile& tile) { - int total_rain = tile.getAccumulatedTokens("rain"); - int total_wind = tile.getAccumulatedTokens("wind"); - int highWind_tokens = tile.getAccumulatedTokens("highWind"); - int flood_tokens = tile.getAccumulatedTokens("flood"); - int hurricane_tokens = tile.getAccumulatedTokens("hurricane"); - - // Special climate zones override normal biome classification - if (hurricane_tokens > 0) { - return BiomeType::HURRICANE_ZONE; // Specialized storm-resistant vegetation - } - if (flood_tokens > FLOOD_THRESHOLD) { - return BiomeType::WETLANDS; // Forced marshes/swamps - } - if (highWind_tokens > STORM_THRESHOLD) { - // High wind prevents forest growth - if (total_rain > 300) { - return BiomeType::STORM_PRAIRIE; // Grasslands that can handle wind - } else { - return BiomeType::BADLANDS; // Sparse, wind-resistant vegetation - } - } - - // Normal biome classification using basic rain/wind tokens - if (total_rain > 500) { - return BiomeType::TROPICAL_RAINFOREST; - } else if (total_rain < 50) { - return BiomeType::HOT_DESERT; - } - // ... additional normal biome logic -} -``` - -**Climate Zone Characteristics:** -- **Hurricane Zones** → Storm-resistant palms, specialized coastal vegetation -- **Flood Zones** → Wetlands, marshes, swamp vegetation mandatory -- **High Wind Zones** → No forests allowed, prairie/badlands only -- **Normal Zones** → Standard biome classification by rain/temperature - -### Geographic Climate Patterns - -**Realistic Climate Formation Examples:** - -**Congo Basin (Rainforest):** -``` -1. Large African landmass → Strong ITCZ at equator -2. Atlantic wind regions spawn → Move east via trade winds -3. ITCZ aspiration → Convergence at Congo → Amplification ×3 -4. Super-humid storms → Massive rain token distribution -5. Result: Dense rainforest biome -``` - -**Sahara Desert:** -``` -1. Sahara latitude (25-35°N) → Outside ITCZ band -2. No convergence zone → Wind regions pass through -3. Continental distance → Low initial moisture -4. Subtropical high pressure → Air descends (simulated via movement patterns) -5. Result: Minimal rain tokens → Desert biome -``` - -### Configuration Integration - -**Climate Configuration (Hot-Reloadable):** -```json -{ - "climate_simulation": { - "wind_spawn_system": { - "base_spawn_rate": 0.1, - "ocean_size_factor": 0.001, - "max_concurrent_regions": 200 - }, - "planetary_circulation": { - "trade_winds_strength": 1.5, - "jet_stream_strength": 1.8, - "calm_zone_chaos": 0.3 - }, - "itcz_system": { - "latitude_band": [0.45, 0.55], - "min_landmass_size": 10000, - "max_ocean_distance": 800, - "amplification_max": 3.0 - }, - "storm_thresholds": { - "high_wind_min": 2.0, - "flood_wetness_min": 1.5, - "hurricane_wind_min": 2.5, - "hurricane_rain_min": 2.0 - } - } -} -``` - -**Note**: All parameters are hot-reloadable via the modular configuration system. Magic numbers are intentionally externalizable for real-time tuning during development - adjust values, save config, see immediate results without recompilation. - -### Performance Characteristics - -**Computational Complexity:** -- **Wind Regions**: O(n) for n active regions (~50-200 simultaneously) -- **ITCZ Calculations**: O(m) for m convergence zones (~5-15 globally) -- **Token Distribution**: O(tiles_visited) per region movement -- **Total per cycle**: O(n × average_movement_distance) - -**Memory Usage:** -- **WindRegion**: 32 bytes per region -- **ITCZ Zone**: 24 bytes per zone -- **Token accumulation**: Uses existing tile data structure -- **Estimated total**: <5MB for global weather simulation - -**Generation Time:** -- **Landmass analysis**: 1-2 seconds (one-time setup) -- **Per simulation cycle**: 10-50ms for 100-200 wind regions -- **Full climate stabilization**: 100-500 cycles → 10-30 seconds total - -## Phase 7: Budget Assignment and Natural Features - -### Random Budget Assignment (Normal Distribution) - -After climate and hydrology stabilization, assign budget scores to each tile using a bell curve distribution: - -```cpp -void assignBudgetScores(GMap& map) { - std::random_device rd; - std::mt19937 gen(rd()); - std::normal_distribution budget_dist(0.0f, 3.0f); // Mean=0, σ=3 - - for (int y = 0; y < map.getHeight(); y++) { - for (int x = 0; x < map.getWidth(); x++) { - float budget_value = budget_dist(gen); - int8_t budget = static_cast(std::clamp(budget_value, -10.0f, 10.0f)); - - WorldTile tile = map.getTile(x, y); - tile.setTargetBudgetScore(budget); - } - } -} -``` - -**Budget Distribution:** -- **68%** of tiles: budget score -3 to +3 -- **95%** of tiles: budget score -6 to +6 -- **Rare extremes**: -10/-9 and +9/+10 scores for unique locations - -### Natural Features Placement (Uniform Random) - -Place natural geological features randomly across the map with uniform distribution: - -```cpp -void placeNaturalFeatures(GMap& map, FeatureManager& feature_manager) { - std::random_device rd; - std::mt19937 gen(rd()); - std::uniform_real_distribution prob_dist(0.0f, 1.0f); - - const float FEATURE_CHANCE = 0.05f; // 5% of tiles get features - - for (int y = 0; y < map.getHeight(); y++) { - for (int x = 0; x < map.getWidth(); x++) { - if (prob_dist(gen) < FEATURE_CHANCE) { - // Natural features from gameData configuration - std::vector available_features = { - "cave", "hot_spring", "canyon", "plateau", - "marsh", "oasis", "geyser", "cliff", "gorge", - "natural_bridge", "sinkhole", "spring" - }; - - std::uniform_int_distribution feature_dist(0, available_features.size() - 1); - std::string feature = available_features[feature_dist(gen)]; - - feature_manager.placeFeature(feature, x, y); - } - } - } -} -``` - -## Phase 8: Resource Region Conversion - -### Regional Influence to Resource Features - -Convert abstract regional influences from geological simulation into concrete resource features on the map: - -```cpp -void convertRegionsToFeatures(GMap& map, FeatureManager& feature_manager) { - std::random_device rd; - std::mt19937 gen(rd()); - - for (auto& region : map.getRegionalInfluences()) { - // Semi-random feature count per region (1-8 features) - std::uniform_int_distribution feature_count_dist(1, 8); - int feature_count = feature_count_dist(gen); - - for (int i = 0; i < feature_count; i++) { - // Random position within region radius - auto [x, y] = getRandomPositionInRegion(region); - - // Region influence strength determines feature quality - float distance = getDistanceFromCenter(region, x, y); - float influence_strength = region.getInfluenceAt(distance); - - // Place appropriate features based on region type - placeRegionalFeature(region, x, y, influence_strength, feature_manager); - } - } -} - -void placeRegionalFeature(const RegionalInfluence& region, int x, int y, - float strength, FeatureManager& feature_manager) { - - if (region.getType() == "tectonic_plate") { - // Tectonic regions: metal deposits - if (strength > 0.8f) { - feature_manager.placeFeature("rich_iron_ore", x, y); - } else if (strength > 0.6f) { - feature_manager.placeFeature("copper_deposit", x, y); - } else if (strength > 0.4f) { - feature_manager.placeFeature("tin_deposit", x, y); - } else { - feature_manager.placeFeature("stone_quarry", x, y); - } - } - - else if (region.getType() == "carbon_region") { - // Carbon regions: coal and oil deposits - if (strength > 0.7f) { - feature_manager.placeFeature("rich_coal_seam", x, y); - } else if (strength > 0.5f) { - feature_manager.placeFeature("oil_well", x, y); - } else if (strength > 0.3f) { - feature_manager.placeFeature("coal_outcrop", x, y); - } else { - feature_manager.placeFeature("peat_bog", x, y); - } - } - - else if (region.getType() == "volcanic_zone") { - // Volcanic regions: geothermal and rare minerals - if (strength > 0.8f) { - feature_manager.placeFeature("geothermal_vent", x, y); - } else if (strength > 0.6f) { - feature_manager.placeFeature("sulfur_deposit", x, y); - } else if (strength > 0.4f) { - feature_manager.placeFeature("obsidian_field", x, y); - } else { - feature_manager.placeFeature("hot_spring", x, y); - } - } - - else if (region.getType() == "recent_meteorite_crater") { - // Recent meteorite impacts: rare metals and exotic materials - // NOTE: Different from Phase 1 planetary accretion meteorites - if (strength > 0.9f) { - feature_manager.placeFeature("platinum_deposit", x, y); - } else if (strength > 0.7f) { - feature_manager.placeFeature("rare_earth_deposit", x, y); - } else if (strength > 0.5f) { - feature_manager.placeFeature("gold_vein", x, y); - } else { - feature_manager.placeFeature("impact_glass", x, y); - } - } -} - -std::pair getRandomPositionInRegion(const RegionalInfluence& region) { - std::random_device rd; - std::mt19937 gen(rd()); - - // Random angle and distance within region radius - std::uniform_real_distribution angle_dist(0.0f, 2.0f * M_PI); - std::uniform_real_distribution radius_dist(0.0f, region.getRadius()); - - float angle = angle_dist(gen); - float distance = radius_dist(gen); - - int x = static_cast(region.getCenterX() + distance * cos(angle)); - int y = static_cast(region.getCenterY() + distance * sin(angle)); - - return {x, y}; -} -``` - -### Resource Feature Characteristics - -**Influence Strength Distribution:** -- **0.8-1.0**: Premium resources (rich deposits, rare materials) -- **0.6-0.8**: High-quality resources (standard industrial deposits) -- **0.4-0.6**: Medium-quality resources (adequate for basic industry) -- **0.2-0.4**: Low-quality resources (marginal extraction) -- **0.0-0.2**: Minimal resources (trace amounts only) - -**Regional Resource Mapping:** -- **Tectonic Regions**: Iron, copper, tin, stone → Industrial base materials -- **Carbon Regions**: Coal, oil, peat → Energy resources -- **Volcanic Zones**: Geothermal, sulfur, obsidian → Specialized materials -- **Recent Meteorite Craters**: Platinum, rare earths, gold → Advanced technology materials - -**Feature Distribution:** -- **1-8 features per region** (semi-random count) -- **Position**: Random within region radius -- **Quality**: Determined by distance from region center (closer = better) -- **Type**: Fixed by region type, quality by influence strength - -## Planetary Mass Conservation System - -### Core-Based Mass Conservation - -To maintain realistic mass conservation throughout geological simulation, the system uses a planetary core that absorbs eroded material and releases it through volcanic activity: - -```cpp -struct PlanetaryCore { - float core_mass; // Accumulated eroded material - float surface_mass; // Current surface terrain mass - float max_core_capacity; // Core saturation threshold - float volcanic_overflow_rate; // Rate of volcanic material expulsion (0.1-0.3) - float total_planetary_mass; // Constant after Phase 1 (meteorite bombardment) - - // Derived values - float core_pressure_ratio; // core_mass / max_core_capacity - int pending_volcanic_events; // Queued volcanic eruptions -}; - -void updateMassConservation(PlanetaryCore& core) { - // Validation: Total mass conservation - assert(core.core_mass + core.surface_mass == core.total_planetary_mass); - - // Core overflow triggers volcanic activity - if (core.core_mass > core.max_core_capacity) { - float overflow = core.core_mass - core.max_core_capacity; - float volcanic_expulsion = overflow * core.volcanic_overflow_rate; - - // Transfer mass from core to pending volcanic events - core.core_mass -= volcanic_expulsion; - - // Queue volcanic events proportional to overflow - int new_volcanic_events = static_cast(volcanic_expulsion / volcanic_event_mass_threshold); - core.pending_volcanic_events += new_volcanic_events; - - // Store remaining material for future volcanism - core.pending_volcanic_material += volcanic_expulsion; - } -} -``` - -### Erosion to Core Transfer - -All erosion processes transfer material to the planetary core rather than redistributing on surface: - -```cpp -void erodeToCore(WorldTile& tile, float erosion_amount, PlanetaryCore& core) { - // Remove material from surface - float current_elevation = tile.getElevation(); - tile.setElevation(current_elevation - erosion_amount); - - // Transfer to planetary core - core.core_mass += erosion_amount; - core.surface_mass -= erosion_amount; - - // Track erosion for geological history - tile.addFlag(TileFlags::ERODED_THIS_CYCLE); -} - -// Apply to all erosion processes -void riverErosion(WorldTile& tile, float water_flow, PlanetaryCore& core) { - if (water_flow > erosion_threshold) { - float erosion_amount = water_flow * erosion_rate_factor; - erodeToCore(tile, erosion_amount, core); - } -} - -void glacialErosion(WorldTile& tile, float ice_thickness, PlanetaryCore& core) { - float erosion_amount = ice_thickness * glacial_erosion_factor; - erodeToCore(tile, erosion_amount, core); -} -``` - -### Volcanic Overflow System - -Core overflow creates realistic volcanic activity that returns material to surface: - -```cpp -void processVolcanicOverflow(GMap& map, PlanetaryCore& core) { - while (core.pending_volcanic_events > 0) { - // Select volcanic location based on geological factors - auto [x, y] = selectVolcanicLocation(map); - - // Calculate eruption magnitude - float eruption_material = core.pending_volcanic_material / core.pending_volcanic_events; - - // Create volcanic eruption - createVolcanicEruption(map, x, y, eruption_material); - - // Update core state - core.surface_mass += eruption_material; - core.pending_volcanic_material -= eruption_material; - core.pending_volcanic_events--; - } -} - -std::pair selectVolcanicLocation(const GMap& map) { - // Prefer locations with: - // - Active tectonic boundaries - // - Existing volcanic history - // - High core pressure influence - - std::vector> candidate_locations; - - for (auto& tectonic_region : map.getTectonicRegions()) { - if (tectonic_region.getActivity() > volcanic_activity_threshold) { - // Add boundary tiles as candidates - auto boundary_tiles = tectonic_region.getBoundaryTiles(); - candidate_locations.insert(candidate_locations.end(), - boundary_tiles.begin(), boundary_tiles.end()); - } - } - - // Weight by distance from core pressure points - return selectWeightedRandom(candidate_locations); -} - -void createVolcanicEruption(GMap& map, int center_x, int center_y, float material_amount) { - // Deposit material in volcanic pattern - int eruption_radius = static_cast(sqrt(material_amount / volcanic_density_factor)); - - for (int dy = -eruption_radius; dy <= eruption_radius; dy++) { - for (int dx = -eruption_radius; dx <= eruption_radius; dx++) { - float distance = sqrt(dx*dx + dy*dy); - if (distance <= eruption_radius) { - int x = center_x + dx; - int y = center_y + dy; - - if (map.isValidCoordinate(x, y)) { - // Volcanic deposition decreases with distance - float deposition_factor = 1.0f - (distance / eruption_radius); - float local_deposition = material_amount * deposition_factor / (M_PI * eruption_radius * eruption_radius); - - WorldTile tile = map.getTile(x, y); - tile.setElevation(tile.getElevation() + local_deposition); - - // Mark as volcanic terrain - tile.setFlag(TileFlags::VOLCANIC_DEPOSIT, true); - } - } - } - } -} -``` - -### Mass Conservation Benefits - -**Perfect Conservation:** -- Total planetary mass remains constant after Phase 1 -- All eroded material is accounted for in core -- Volcanic activity returns material to surface -- No material created or destroyed - -**Realistic Geological Activity:** -- Core pressure drives continuing volcanism -- Volcanic activity decreases as core pressure reduces -- Natural equilibrium between erosion and volcanic deposition -- Geological activity persists throughout simulation - -**Simplified Implementation:** -- No complex sediment transport calculations -- No surface redistribution algorithms -- Single mass conservation equation -- Volcanic activity emerges naturally from core overflow - -**Gameplay Benefits:** -- Ongoing geological activity creates dynamic world -- Volcanic regions provide unique resource opportunities -- Erosion/volcanism balance creates varied topography -- Long-term geological processes affect industrial planning - -## Technical Architecture - -### WorldTileData Structure (32 bytes) -```cpp -struct WorldTileData { - // Terrain (11 bytes) - Always accessed, geological simulation ready - uint16_t terrain_type_id; // 65k terrain types - uint16_t biome_type_id; // Biome classification - uint16_t elevation; // -11km to +32km range - int16_t temperature; // -3276°C to +3276°C (0.1°C precision) - uint8_t humidity; // 0-100% (0.4% precision) - uint8_t wind_data; // 4 bits direction + 4 bits intensity - uint8_t water_level; // Accumulated water for river formation - - // Metadata (21 bytes) - Generation and gameplay - int8_t target_budget_score; // -10 to +10 - uint32_t regional_influence_id; // → Regional influence data - uint8_t influence_strength; // 0-255 - uint32_t tile_flags; // State flags - uint32_t feature_set_id; // → Feature collection - uint8_t padding2[7]; // Future expansion space -}; -``` - -### RegionalInfluence System -- **TectonicRegions**: Mobile circular regions with physics -- **CarbonRegions**: Carbon deposit tracking with tectonic attachment -- **VolcanicZones**: Created dynamically at tectonic collisions -- **SeaLevelInfluence**: Global parameter affecting all processes - -### FeatureManager Integration -- Simple helper interface for placing geological features -- Handles feature set creation and tile updates automatically -- Used by generation algorithms, doesn't do generation itself - -## Performance Characteristics - -### Memory Usage -- **1M tiles**: 32MB core tile data (increased from 24MB for hydrology) -- **Feature sets**: Sparse, shared between similar tiles -- **Geological regions**: ~10-50 regions vs millions of tiles -- **Climate wind regions**: ~50-200 mobile regions during simulation -- **Total estimated**: <125MB for complete planetary geology + advanced climate simulation - -### Computational Complexity -- **Tectonic simulation**: O(nÂČ) for n regions (~25 regions = 625 operations) -- **Meteorite impacts**: O(k) for k impacts per wave -- **Sea level effects**: O(tiles) single pass -- **Carbon processes**: O(regions) sparse operations -- **Climate simulation**: O(n × movement_distance) for n wind regions (~50-200 regions) - -### Generation Time -- **Geological phases**: 10-20 seconds for complete 4.65 billion year simulation -- **Climate simulation**: 10-30 seconds for 100-500 climate cycles -- **Total estimated**: 20-50 seconds for complete world generation -- **Progressive**: Can display intermediate results during generation -- **Deterministic**: Same seed produces identical geology and climate - -## Implementation Priority - -### Phase 1: Core Architecture (1-2 weeks) -1. RegionalInfluence and RegionalInfluenceManager classes -2. TectonicRegion basic structure and physics -3. Simple meteorite impact system -4. Basic tile elevation/temperature updates - -### Phase 2: Full Geology (2-3 weeks) -1. Complete tectonic interaction system -2. Dynamic sea level integration -3. Carbon region formation and conversion -4. Volcanic zone creation - -### Phase 3: Polish (1-2 weeks) -1. Parameter tuning for realistic results -2. Performance optimization -3. Generation progress reporting -4. Validation and debugging tools - -## Scientific Accuracy vs Gameplay - -### Scientifically Inspired Elements -- ✅ Late Heavy Bombardment period -- ✅ Planetary differentiation (metals sink to core) -- ✅ Tectonic processes creating mountains/valleys -- ✅ Carboniferous period forest→coal formation -- ✅ Marine conditions for oil formation -- ✅ Sea level variations affecting geology -- ✅ ITCZ formation from continental heating -- ✅ Planetary circulation bands (trade winds, jet streams) -- ✅ Realistic climate differentiation (Congo vs Sahara) - -### Gameplay Simplifications -- ⚠ Tectonic regions as circles (not realistic plate shapes) -- ⚠ Fixed map size instead of planetary expansion -- ⚠ Simplified core-mantle dynamics -- ⚠ Compressed timescales for practical generation -- ⚠ 2D wind simulation instead of 3D atmospheric layers -- ⚠ Discrete token system instead of continuous climate fields -- ⚠ Mobile wind regions as simplified weather systems - -### Result -**Plausible geology and climate** that creates **interesting gameplay** with **emergent weather patterns** without requiring PhD in atmospheric science to understand or debug. - -## Integration Points - -### WorldGenerationModule -- Orchestrates all geological phases -- Manages simulation state and progression -- Provides query interface for generated geology - -### FeatureManager -- Places geological features based on simulation results -- Handles feature set optimization and tile updates -- Simple interface for placement algorithms - -### RegionalInfluenceManager -- Core system managing all regional effects -- Handles tectonic regions, carbon regions, volcanic zones -- Provides influence application to tiles - -### Future Extensions -- **Dynamic climate**: Real-time weather systems during gameplay -- **Mineral resource modeling**: Detailed ore deposit formation -- **Advanced erosion**: River network evolution during gameplay -- **Geological time compression**: Speed up/slow down specific phases -- **Seasonal climate**: Monthly/yearly climate variations -- **Climate change**: Long-term climate evolution from industrial activity - ---- - -**Status**: System designed and ready for implementation. All major components specified with clear interfaces and realistic performance targets. Scientific accuracy balanced with implementation complexity for practical game development. \ No newline at end of file diff --git a/docs/02-systems/HYBRID_SIZE_SYSTEM.md b/docs/02-systems/HYBRID_SIZE_SYSTEM.md deleted file mode 100644 index b1c29f3..0000000 --- a/docs/02-systems/HYBRID_SIZE_SYSTEM.md +++ /dev/null @@ -1,46 +0,0 @@ -# 🎯 **Hybrid Sizing System - Revolutionary UI Layout** - -## Overview - -The **Hybrid Sizing System** is a breakthrough UI layout approach that combines **responsive percentage targets** with **absolute pixel constraints** to achieve both flexible responsive design and guaranteed usability. - -## 💡 **Core Concept** - -Traditional UI systems force you to choose: -- **Percentages**: Responsive but can become unusable (too small/large) -- **Pixels**: Fixed size but not responsive - -**Hybrid System**: Target percentages, respect absolute constraints. - -## 📐 **Mathematical Formula** - -```cpp -float final_size = clamp(percentage_target, absolute_min, absolute_max); -``` - -Where: -- `percentage_target = (percentage / 100.0f) * parent_size` -- `absolute_min` = minimum usable size in pixels -- `absolute_max` = maximum reasonable size in pixels - -## 🎯 **Example in Action** - -### Configuration -```json -{ - "size": {"width": "20%"}, // Target 20% of parent - "min_size": {"width": 250}, // Never smaller than 250px - "max_size": {"width": 400} // Never larger than 400px -} -``` - -### Results Across Screen Sizes - -| Screen Width | 20% Target | Constraints | **Final Size** | Status | -|-------------|-----------|-------------|----------------|--------| -| 1000px | 200px | 250-400px | **250px** | ⚖ Clamped to minimum | -| 1400px | 280px | 250-400px | **280px** | ✅ Percentage achieved | -| 1800px | 360px | 250-400px | **360px** | ✅ Percentage achieved | -| 2500px | 500px | 250-400px | **400px** | ⚖ Clamped to maximum | - -This hybrid system represents a **fundamental advancement** in UI layout technology. diff --git a/docs/02-systems/SIZE_CONSTRAINTS_GUIDE.md b/docs/02-systems/SIZE_CONSTRAINTS_GUIDE.md deleted file mode 100644 index 627ec1c..0000000 --- a/docs/02-systems/SIZE_CONSTRAINTS_GUIDE.md +++ /dev/null @@ -1,166 +0,0 @@ -# 📏 Size Constraints Guide - -## Overview - -Le systĂšme IUI supporte maintenant les **contraintes de taille en pixels** pour tous les types de fenĂȘtres et docks. - -## ⚙ Types de contraintes - -### **min_size** - Taille minimum -```json -{ - "min_size": {"width": 200, "height": 150} -} -``` -- EmpĂȘche l'utilisateur de rendre la fenĂȘtre trop petite -- Garantit que le contenu reste utilisable -- **Obligatoire** pour les fenĂȘtres critiques (console, alerts) - -### **max_size** - Taille maximum -```json -{ - "max_size": {"width": 800, "height": 600} -} -``` -- EmpĂȘche les fenĂȘtres de dominer l'Ă©cran -- Maintient la cohĂ©rence de l'interface -- Utile pour les popups et dialogs - -### **size** - Taille initiale -```json -{ - "size": {"width": 400, "height": 300} -} -``` -- Taille au moment de la crĂ©ation -- Sera **clampĂ©e** entre min_size et max_size -- Si hors limites, ajustĂ©e automatiquement - -## đŸ—ïž Usage par type de fenĂȘtre - -### **Docks** -```cpp -ui->createDock("sidebar", DockType::TABBED, DockPosition::LEFT, { - {"size", {{"width", 300}}}, - {"min_size", {{"width", 200}, {"height", 300}}}, - {"max_size", {{"width", 500}, {"height", 1000}}}, - {"resizable", true} -}); -``` - -### **Splits** -```cpp -ui->createSplit("main_split", Orientation::HORIZONTAL, { - {"min_panel_size", 80}, // Chaque panel min 80px - {"min_size", {{"width", 600}, {"height", 400}}}, // Split total min 600x400 - {"split_ratio", 0.6} // 60% / 40% -}); -``` - -### **Content Windows** -```cpp -ui->showData(DataType::ECONOMY, { - {"content", {...}}, - {"window", { - {"id", "economy_dash"}, - {"size", {{"width", 350}, {"height", 250}}}, - {"min_size", {{"width", 300}, {"height", 200}}}, // LisibilitĂ© - {"max_size", {{"width", 600}, {"height", 400}}}, // Pas trop invasif - {"resizable", true} - }} -}); -``` - -### **Floating Windows** -```cpp -ui->showData(DataType::ALERTS, { - {"content", {...}}, - {"window", { - {"floating", true}, - {"size", {{"width", 400}, {"height", 200}}}, - {"min_size", {{"width", 320}, {"height", 150}}}, // Alert lisible - {"max_size", {{"width", 600}, {"height", 300}}}, // Pas trop grosse - {"closeable", true} - }} -}); -``` - -## 📋 Recommandations par usage - -### **Console/Log windows** -- **min_size**: `{"width": 400, "height": 100}` (au moins 3-4 lignes) -- **max_size**: `{"width": 2000, "height": 300}` (pas trop haute) - -### **Economy/Data tables** -- **min_size**: `{"width": 250, "height": 200}` (colonnes lisibles) -- **max_size**: `{"width": 500, "height": 600}` (pas trop large) - -### **Maps/Graphics** -- **min_size**: `{"width": 300, "height": 300}` (dĂ©tails visibles) -- **max_size**: `{"width": 1200, "height": 1200}` (performance) - -### **Inventory grids** -- **min_size**: `{"width": 200, "height": 150}` (grid 2x2 minimum) -- **max_size**: `{"width": 400, "height": 500}` (pas trop de scroll) - -### **Settings/Dialogs** -- **min_size**: `{"width": 320, "height": 240}` (tous contrĂŽles visibles) -- **max_size**: `{"width": 500, "height": 400}` (taille raisonnable) - -### **Alert popups** -- **min_size**: `{"width": 300, "height": 120}` (texte lisible) -- **max_size**: `{"width": 500, "height": 250}` (pas invasif) - -## 🔄 Comportement automatique - -### **Clamping** -Si `size` est hors des limites : -```cpp -// Taille demandĂ©e : 100x50 -// min_size : 200x150 -// max_size : 800x600 -// → RĂ©sultat : 200x150 (clampĂ©e au minimum) -``` - -### **Resize interactif** -- L'utilisateur ne peut **jamais** redimensionner en dessous de `min_size` -- L'utilisateur ne peut **jamais** redimensionner au-dessus de `max_size` -- Les **cursors de resize** changent quand les limites sont atteintes - -### **Split constraints** -```cpp -{ - "min_panel_size": 80, // Chaque panel minimum 80px - "split_ratio": 0.7 // Mais peut ĂȘtre ajustĂ© si ça viole min_panel_size -} -``` - -## ⚡ Performance - -- **Enums** pour types communs = comparaisons int rapides -- **JSON** pour config flexible = parse une fois Ă  la crĂ©ation -- **Pixel constraints** appliquĂ©es cĂŽtĂ© implĂ©mentation (ImGui, HTML, etc.) -- **Zero overhead** si pas de contraintes spĂ©cifiĂ©es - -## 🎯 Exemple complet - -```cpp -// CrĂ©er layout avec contraintes -ui->createDock("main_sidebar", DockType::TABBED, DockPosition::LEFT, { - {"min_size", {{"width", 250}, {"height", 400}}}, - {"max_size", {{"width", 500}, {"height", 1000}}} -}); - -// Ajouter contenu avec contraintes -ui->showData(DataType::ECONOMY, { - {"content", {{"prices", {...}}}}, - {"window", { - {"parent", "main_sidebar"}, - {"dock", "tab"}, - {"min_size", {{"width", 240}, {"height", 200}}}, - {"max_size", {{"width", 450}, {"height", 600}}} - }} -}); -``` - -**RĂ©sultat** : Interface qui reste **utilisable** Ă  toutes les tailles ! 🚀 \ No newline at end of file diff --git a/docs/02-systems/economie-logistique.md b/docs/02-systems/economie-logistique.md deleted file mode 100644 index 869d5cf..0000000 --- a/docs/02-systems/economie-logistique.md +++ /dev/null @@ -1,459 +0,0 @@ -# Économie et Logistique - -## Vue d'ensemble - -L'Ă©conomie de Warfactory est un systĂšme dynamique multi-acteurs oĂč companies et Ă©tats interagissent sur des marchĂ©s segmentĂ©s, avec une logistique automatisĂ©e intelligente qui supporte les opĂ©rations militaires et industrielles. - -## StratĂ©gies d'Inventaire - -### Niveaux de Stock et Comportements d'Achat -Les companies IA adaptent leur comportement commercial selon leurs niveaux de stock : - -**Desperate (<20% capacitĂ©)** : -- AchĂšte Ă  n'importe quel prix -- Accepte qualitĂ© infĂ©rieure -- Priorise livraison rapide sur coĂ»t -- Peut payer 2-3x prix marchĂ© - -**Normal (20-50% capacitĂ©)** : -- Comportement Ă©quilibrĂ© -- Prix marchĂ© standard acceptĂ© -- Trade-offs normaux qualitĂ©/prix/dĂ©lai - -**Cautious (50-80% capacitĂ©)** : -- SĂ©lectif sur prix -- Attend offres avantageuses -- Peut diffĂ©rer achats non-critiques -- Cherche optimisation coĂ»ts - -**Oversupplied (>80% capacitĂ©)** : -- Vente aggressive surplus -- Prix cassĂ©s pour libĂ©rer stockage -- Peut vendre sous coĂ»t production -- Cherche liquidation rapide - -### Impact Gameplay -- **OpportunitĂ©s trading** : Acheter Ă  oversupplied, vendre Ă  desperate -- **Cycles Ă©conomiques** : Alternance pĂ©nuries/surplus crĂ©ent volatilitĂ© -- **StratĂ©gie stockage** : Balance entre coĂ»ts inventory et opportunitĂ©s manquĂ©es - -### Consolidation Volume Émergente -**Effet Ă©conomique naturel** : Les constraints transport crĂ©ent collaboration forcĂ©e entre companies - -**MĂ©canisme Ă©conomique** : -- **Transport Cost Limits** : Buyers dĂ©finissent seuils acceptables (ex: "transport max 15% valeur goods") -- **Example pratique** : Iron 10€/kg → Transport max 1.50€/kg acceptable -- **Ship 0.10€/kg** ✅ viable, **Truck 5.00€/kg** ❌ rejetĂ© (trop cher) -- **Natural collaboration** : Consolidation ordres pour atteindre viabilitĂ© Ship transport - -**Strategic implications** : -- **Pas threshold hard-codĂ©** : Émergence via pure rationalitĂ© Ă©conomique -- **Collaboration competitive** : Concurrents forcĂ©s coopĂ©rer pour transport viable -- **Timing decisions** : Attendre consolidation (50x moins cher) vs urgence livraison -- **Market psychology** : Economic pressure crĂ©e coopĂ©ration naturelle - -### SpĂ©cialisation RĂ©gionale Émergente -**Progression Ă©conomique naturelle** : Extraction → Manufacturing → Trading → Consumer - -**Regional Economic Development Phases :** -1. **Coastal advantage phase** : Early transport cost benefits (Ship 0.10€/kg) -2. **Infrastructure investment phase** : Economic pressure drives development (ROI <15 ans) -3. **Economic equilibrium phase** : Costs equalize across regions via infrastructure -4. **Competitive specialization phase** : Regions find comparative advantages - -**Natural Geographic Specialization :** -- **Resource-based clustering** : Mining operations near natural deposits -- **Manufacturing optimization** : Production centers minimize transport costs -- **Trading hub emergence** : Infrastructure convergence creates commercial centers -- **Realistic urban development** : Economic forces drive settlement patterns - -**Market Forces driving specialization :** -- **Coastal rush** → **Land premiums** → **Congestion costs** → **Capacity bottlenecks** -- **Pure economic pressure** (no artificial forcing) -- **Infrastructure ROI** drives regional transformation -- **Regional competition** for transport access and advantages - -## Acteurs Économiques - -### Companies privĂ©es -- **Joueur** : Company initiale avec avantage technologique (Factorio-like) -- **Multinationales** : Thales, Dassault, Lockheed Martin, etc. -- **Concurrents IA** : Companies gĂ©nĂ©rĂ©es avec productions automatisĂ©es -- **CoĂ»ts opĂ©rationnels** : Workers + salaires pour companies IA vs Ă©lectricitĂ© seule joueur - -### SystĂšme de Features Company -**Principe** : Chaque company IA a 2-4 features qui dĂ©finissent ses capacitĂ©s et spĂ©cialisations - -#### Types de Features -**Domaines de production** : -- **Metal** : MĂ©tallurgie, alliages, structures mĂ©talliques -- **Electronic** : Circuits, capteurs, processeurs, systĂšmes avancĂ©s -- **Tank** : VĂ©hicules blindĂ©s, systĂšmes de combat terrestre -- **Plane** : AĂ©ronautique, avionique, systĂšmes volants -- **Wood** : Foresterie, produits bois, dĂ©rivĂ©s organiques -- **Food** : Agro-alimentaire, bio-ressources -- **Engine** : Moteurs, propulsion, systĂšmes mĂ©caniques -- **Cannon** : Armement direct, artillerie, systĂšmes balistiques -- **Missile** : Armement guidĂ©, roquettes, systĂšmes de navigation - -**Modificateurs de qualitĂ©** : -- **Quality** : Production haut de gamme, prĂ©cision, durabilitĂ© -- **Quantity** : Production de masse, efficacitĂ© volume -- **Speed** : Production rapide, dĂ©lais courts -- **Cost** : Production Ă©conomique, optimisation prix -- **Modularity** : Designs modulaires, adaptabilitĂ©, standardisation -- **Innovation** : R&D focus, breakthrough technologies, expĂ©rimentation - -**Autres propositions** : -- **Stealth** : FurtivitĂ©, signature rĂ©duite, camouflage -- **Repair** : Maintenance, reconstruction, durabilitĂ© terrain -- **Transport** : Logistique, mobilitĂ©, capacitĂ© transport -- **Communication** : RĂ©seaux, coordination, guerre Ă©lectronique - -#### Exemples de Companies -**Point 272 - "Metal, Plane, Quantity, Electronic"** : -- **Produit** : Mass metal aircraft with embedded electronics - Avions mĂ©talliques de masse avec Ă©lectronique embarquĂ©e - -**Point 273 - Avantages** : Volume, complete integration, optimized costs - Excelle production grandes quantitĂ©s systĂšmes intĂ©grĂ©s oĂč Ă©lectronique et structures optimalement combinĂ©es durant production masse, avantages coĂ»ts via volume maintenant intĂ©gration sophistiquĂ©e - -**Point 274 - Faiblesses** : Perhaps less refinement than quality specialist - Peut manquer prĂ©cision et raffinement des concurrents spĂ©cialisĂ©s Quality, produisant appareils capables mais pas cutting-edge en performance ou durabilitĂ© - -**Point 275 - "Tank, Quality"** : -- **Produit** : High-end tanks, precision assembly - VĂ©hicules blindĂ©s premium avec ingĂ©nierie prĂ©cision et caractĂ©ristiques performance supĂ©rieures commandant prix premium - -**Point 276 - Limites** : Must buy electronics on external markets - Manque capacitĂ©s Electronic internes, forcĂ© acheter composants Ă©lectroniques fournisseurs externes, augmente coĂ»ts, crĂ©e dĂ©pendances supply chain, limite intĂ©gration systĂšmes Ă©lectroniques avancĂ©s - -**Point 277 - DĂ©pendances** : Complex supply chain for non-mastered components - Manque capacitĂ©s internes force dĂ©velopper relations supply complexes pour composants hors expertise, crĂ©ant complexitĂ© logistique, problĂšmes contrĂŽle qualitĂ© potentiels, vulnĂ©rabilitĂ© disruption supply chain - -#### Dynamiques des Features - -**Influence sur recherche** : -- **Features → Research paths** : CapacitĂ©s influencent fortement directions R&D -- **Synergies via tech** : "Metal + Tank" unlock recherches blindage spĂ©cialisĂ©es -- **Pas d'exclusions strictes** : Features coexistent, synergies via recherche - -**Évolution des Companies** : - -**Point 281 - MortalitĂ©** : Company mortality: Companies can disappear (example: "Food + Tank" = fatal dispersion) - Companies avec combinaisons features mal synergiques ou Ă©chec compĂ©titif peuvent disparaĂźtre du jeu, exemples extrĂȘmes comme Food + Tank reprĂ©sentant dispersion stratĂ©gique fatale - -**Point 282 - Naissance** : Company birth: New companies according to contextual needs - Nouvelles companies Ă©mergent rĂ©ponse gaps marchĂ©, opportunitĂ©s technologiques, besoins rĂ©gionaux, features initiales dĂ©terminĂ©es par conditions marchĂ© spĂ©cifiques crĂ©ant demande nouvelles capacitĂ©s - -**Point 283 - Changement features** : Feature changes: Possible randomly during financial decline - Companies subissant stress financier peuvent subir changements features alĂ©atoires durant restructuration, pivot nouveaux marchĂ©s, perte capacitĂ©s contraintes budget, crĂ©ant Ă©volution dynamique capacitĂ©s - -**Point 284 - Acquisition** : Acquisition: Random events allow gaining new features - Companies peuvent gagner nouvelles features via Ă©vĂ©nements acquisition, opportunitĂ©s fusion, breakthroughs technologiques expandant capacitĂ©s et changeant position marchĂ© potentiellement - -**Point 285 - Perte (overflow)** : Loss: Events if >4 features (overflow) - Companies accumulant >4 features via acquisitions/expansion font face Ă©vĂ©nements overflow forçant perte features, reprĂ©sentant limitation rĂ©aliste companies ne peuvent maintenir capacitĂ©s diverses illimitĂ©es simultanĂ©ment - -#### Events AlĂ©atoires - -**Types d'events** : -- **Guerres** : DĂ©gradation/amĂ©lioration relations, gĂ©nĂ©ration companies militaires -- **Crises locales** : Peuvent dĂ©clencher crises globales en cascade -- **Breakthroughs technologiques** : Nouvelles capacitĂ©s, disruption marchĂ© -- **ProbabilitĂ©s Ă©gales** : Company "Quality" n'a pas plus de chances que "Cost" - -**Impacts contextuels** : -- **Guerre → Tank companies** : GĂ©nĂ©ration companies spĂ©cialisĂ©es combat -- **Blocus → Innovation locale** : DĂ©veloppement alternatives domestiques -- **Crisis → Consolidation** : Fusion/disparition companies faibles - -**Contexte GĂ©ographique** : -- **GĂ©nĂ©ration locale** : Features selon contexte (guerre → companies Tank) -- **Build-up progressif** : Nouvelles companies commencent basiques, s'amĂ©liorent -- **Adaptation Ă©tatique** : État sans Ă©lectronique → dev company Ă©lectronique mĂ©diocre - -#### CapacitĂ© Économique des États - -**Limitation companies** : -- **CapacitĂ© par Ă©tat** : Nombre companies selon Ă©conomie nationale -- **Ressources partagĂ©es** : Grosses companies consomment capacitĂ© Ă©conomique -- **Avantage Ă©mergents** : États faibles = innovation possible (pas de monopoles internes) - -**MĂ©caniques d'adaptation** : - -**Point 289 - Besoin critique** : Critical need: Lack of electronics → birth of Electronic company (poor quality) - Quand marchĂ©s manquent capacitĂ©s essentielles comme Ă©lectronique, nouvelles companies Ă©mergent pour combler gaps mĂȘme si qualitĂ© initiale pauvre, reprĂ©sentant rĂ©ponses marchĂ© dĂ©sespĂ©rĂ©es Ă  pĂ©nuries critiques - -- **Substitution** : Mieux que rien > dĂ©pendance externe totale -- **Prix explosion** : PĂ©nurie → dĂ©veloppement alternatifs locaux - -#### DĂ©gradation QualitĂ© et Adaptation - -**Composants infĂ©rieurs** : - -**Point 292 - Design constraints** : Local electronics = larger components on grid - Composants Ă©lectroniques domestiques de companies nouvelles/infĂ©rieures nĂ©cessitent typiquement plus espace physique grilles design vĂ©hicules comparĂ© alternatives avancĂ©es importĂ©es - -**Point 293 - Chaleur excessive** : Excessive heat: More overheating, additional radiators required - Composants Ă©lectroniques locaux infĂ©rieurs gĂ©nĂšrent typiquement plus chaleur perdue qu'alternatives avancĂ©es, nĂ©cessitant systĂšmes refroidissement et radiateurs additionnels consommant espace et poids vĂ©hicule - -- **Variations design** : Adaptation vĂ©hicules aux composants disponibles -- **Courbe apprentissage** : AmĂ©lioration progressive vers standards internationaux - -**Point 296 - Trade-offs** : Autonomy vs optimal performance - MarchĂ©s doivent Ă©quilibrer autonomie supply et sĂ©curitĂ© contre performance optimale, alternatives domestiques fournissant indĂ©pendance au coĂ»t efficacitĂ© technique - -#### Position du Joueur - -**LibertĂ© totale** : -- **Pas de features** : Joueur non-contraint par systĂšme company -- **Choix gameplay naturels** : SpĂ©cialisation Ă©merge des dĂ©cisions -- **Factorio advantage** : FlexibilitĂ© vs modĂšles figĂ©s IA -- **Concurrence efficacitĂ©** : "Tank, Quantity, Cost" = dĂ©fi mais surmontable - -#### RĂ©cupĂ©ration et Recyclage - -**DĂ©construction produits** : -- **Composants recovery** : DĂ©montage pour piĂšces dĂ©tachĂ©es -- **Économie circulaire** : RĂ©utilisation en cas de pĂ©nurie -- **StratĂ©gie backup** : Alternative aux supply chains rompues - -## SystĂšme de Conception IA - -### DĂ©fis d'ImplĂ©mentation - -**ProblĂ©matique conception** : -- **IA utilise grille** : MĂȘme systĂšme conception que joueur -- **ComplexitĂ© computationnelle** : GĂ©nĂ©ration designs = coĂ»teux -- **Performance temps rĂ©el** : Impossible si IA rĂ©flĂ©chit comme humain - -### Solutions d'ImplĂ©mentation - -**Distribution temporelle** : -- **1-2 designs par tick globalement** : Performance acceptable (total mondial, toutes companies confondues) -- **Milliers de ticks** : Designs Ă©mergent progressivement -- **Background invisible** : Processus conception non-visible joueur - -**Évolution vs CrĂ©ation** : -- **Modification designs existants** : T-72 → T-80 → T-90 (style russe) -- **Plus rapide et rĂ©aliste** : Companies IRL Ă©voluent designs -- **Historical accuracy** : Progression technologique authentique - -**SystĂšme de Validation** : -- **Features comme filtres** : Tank sans arme = design invalide -- **RĂšgles de base** : Guidelines pour IA (tank = chĂąssis + moteur + arme) -- **Validation cohĂ©rence** : Features influencent acceptation designs - -**ProbabilitĂ©s vs RigiditĂ©** : -- **"Innovation" = plus tentatives** : Pas timing fixe, plus d'essais -- **RĂ©activitĂ© rĂ©aliste** : Companies IRL prennent 6+ mois rĂ©agir -- **Market dynamics** : Joueur ne peut rĂ©pondre Ă  toutes demandes simultanĂ©ment - -### Doctrines Culturelles Nationales - -**SystĂšme de Doctrine** : -- **Influences multiples** : Companies, gĂ©nĂ©raux, tactiques et choix Ă©conomiques -- **Transmission** : Nouvelles entitĂ©s hĂ©ritent tendances nationales -- **ProbabilitĂ©s ajustĂ©es** : Bonus/malus selon affinitĂ© culturelle - -#### Exemple : États-Unis -**Features dominantes** : "Quality", "Electronic", "Innovation" -- **Companies** : +60% chance Quality/Electronic, -40% chance Speed/Cost -- **GĂ©nĂ©raux** : Tactiques tech-intensive, support aĂ©rien, logistique lourde -- **Économie** : PrĂ©fĂ©rence R&D, investissements long terme, high-tech - -#### Exemple : France -**Features dominantes** : "Speed", "Modularity", "Innovation" -- **Companies** : +50% chance Speed/Modularity, -30% chance Quantity -- **GĂ©nĂ©raux** : Doctrines flexibles, combined arms, mobilitĂ© -- **Économie** : Cycles courts, adaptabilitĂ©, export diversifiĂ© - -**MĂ©caniques d'Influence** : -- **GĂ©nĂ©ration companies** : ProbabilitĂ©s pondĂ©rĂ©es par doctrine nationale -- **Formation gĂ©nĂ©raux** : Schools nationales influencent styles command -- **DĂ©cisions Ă©tatiques** : Orientations Ă©conomiques selon culture -- **Adaptation** : Companies Ă©trangĂšres s'adaptent progressivement Ă  culture locale - -### Blueprints Culturels - -**HĂ©ritage par Company** : -- **Blueprints intĂ©grĂ©s** : Chaque company hĂ©rite culture design + doctrine nationale -- **Examples** : - - Company russe "Tank, Quantity" : T-34 style (low profile, sloped armor) - - Company allemande "Tank, Quality" : Leopard style (modular, precision) - - Company amĂ©ricaine "Tank, Electronic" : Abrams style (high-tech, digital) - -**IdentitĂ©s technologiques** : -- **Thales** : Blueprints Ă©lectronique française (intĂ©gration, miniaturisation) -- **Dassault** : Blueprints aĂ©ro français (Rafale DNA = agile, multirole) -- **Lockheed** : Blueprints US (stealth, high-tech, expensive) - -**Évolution culturelle** : -- **Regional influences** : Companies mĂȘme rĂ©gion partagent styles + doctrine -- **Feature evolution** : "Quality" amĂ©liore prĂ©cision blueprints existants -- **Acquisition heritage** : Racheter company = rĂ©cupĂ©rer blueprints + culture -- **Doctrine inheritance** : Nouvelles companies adoptent doctrine nationale - -**Émergence** : -- **Nouvelles companies** : HĂ©ritent blueprints rĂ©gionaux/culturels + doctrine -- **Innovation contextuelle** : "Tank, Innovation" japonaise → blueprints hyper-modulaires -- **Adaptation locale** : "Engine, Cost" chinoise → moteurs Ă©conomiques volumineux -- **Cultural drift** : Companies Ă©trangĂšres dĂ©veloppent hybrides doctrine/origine - -### États -- **Statut hybride** : États = companies spĂ©cialisĂ©es avec production propre -- **CapacitĂ©s** : Production, commandes, restrictions commerciales -- **Politique** : Sanctions, embargos, accords commerciaux -- **Exemple** : État ukrainien produit + commande mais ne rĂ©quisitionne pas - -## MarchĂ©s SegmentĂ©s - -### Types de marchĂ©s -- **National** : MarchĂ© par pays (ex: marchĂ© ukrainien) -- **Company-specific** : MarchĂ©s privĂ©s entre companies -- **Blocs multinationaux** : UE, OTAN, etc. -- **Mondial** : MarchĂ© global ouvert - -### Restrictions d'accĂšs -- **Doubles verrous** : Blocages possibles par companies ET Ă©tats -- **Exemples** : - - France bloque ventes Thales → joueur - - Thales bloque directement → joueur - - Ukraine bloque importations → concurrent -- **Scope** : MatĂ©riel industriel, biens production, consommation (Ă©lectricitĂ©, acier) - -## SystĂšme de Prix Dynamiques - -### Facteurs d'influence -- **Offre/Demande** : MĂ©caniques classiques d'Ă©conomie de marchĂ© -- **ÉvĂ©nements militaires** : Conflits modifient prix selon proximitĂ©/impact -- **PĂ©nuries** : Prix fonction durĂ©e estimĂ©e rĂ©solution ("2 mois" vs "5 ans") -- **Production adaptative** : Ajustement selon signaux marchĂ© - -### Exemples concrets -- **Bataille massive** → pĂ©nurie composants blindage → prix x3 -- **Victoire ukrainienne** → confiance Ă©conomique → investissements -- **Embargo russe** → raretĂ© mĂ©taux spĂ©cifiques → alternatives recherchĂ©es - -## SystĂšme Logistique - -### Transport Multi-Modal -**Moyens disponibles** : -- **Camions** : Flexibles, tous terrains, capacitĂ© limitĂ©e -- **Trains** : Grande capacitĂ©, nĂ©cessite infrastructure rails -- **Avions cargo** : Rapides, coĂ»teux en pĂ©trole, capacitĂ© moyenne -- **Drones** : Livraison prĂ©cise, capacitĂ© faible, autonomes -- **Navires** : TrĂšs grande capacitĂ©, lents, limitĂ©s aux cĂŽtes/riviĂšres - -**CaractĂ©ristiques** : -- **Poids max** : Limitation par vĂ©hicule -- **Volume** : Pour vĂ©hicules transportĂ©s (pas pour biens standards) -- **CoĂ»t indirect** : Consommation carburant (15 avions pour tables = inefficient) - -### HiĂ©rarchie des CoĂ»ts de Transport (Indicatif) -**Note** : Ces valeurs sont purement indicatives pour donner une Ă©chelle relative - -**Transport Maritime** : ~0.10€/kg -- Volume massif (>1000 tonnes minimum) -- Lent mais ultra-Ă©conomique -- LimitĂ© aux zones cĂŽtiĂšres/ports - -**Transport Ferroviaire** : ~0.50€/kg -- Grandes quantitĂ©s -- Efficace longue distance -- NĂ©cessite infrastructure rails - -**Transport AĂ©rien** : ~2.00€/kg -- Rapide mais coĂ»teux -- IdĂ©al urgences/haute valeur -- CapacitĂ© limitĂ©e - -**Transport Routier** : ~5.00€/kg -- Dernier kilomĂštre -- Flexible mais cher -- Tous terrains - -**Impact Économique** : -- Localisation critique pour compĂ©titivitĂ© -- Zones cĂŽtiĂšres = avantage massif (50x moins cher) -- Infrastructure dĂ©termine viabilitĂ© business models - -### Supply Chain Militaire - -**Architecture FOB** : -- **Forward Operating Bases** : Une ou plusieurs par armĂ©e -- **Stocks dĂ©centralisĂ©s** : Chaque FOB stocke Ă©quipements/munitions -- **Distribution autonome** : ArmĂ©es gĂšrent propre logistique finale - -**Ravitaillement Combat** : -- **Temps rĂ©el possible** : Livraison pendant batailles -- **Trade-off tactique** : UnitĂ© ravitaillĂ©e + ravitailleur immobilisĂ©es -- **DurĂ©e** : DĂ©finie par design ravitailleur ET ravitaillĂ© -- **VulnĂ©rabilitĂ©** : Moment critique exploitable par ennemi - -### Infrastructure et VulnĂ©rabilitĂ©s - -**Attaques possibles** : -- **Convois** : Cibles mobiles attaquables -- **Infrastructure** : Destruction ponts, rails, dĂ©pĂŽts -- **Pas d'espionnage** : Sabotage physique uniquement - -**Protection** : -- **Escortes** : DĂ©fense convois prioritaires -- **Redondance** : Routes alternatives prĂ©planifiĂ©es -- **RĂ©paration** : Reconstruction infrastructure critique - -## Ressources et Extraction - -### SystĂšme de PropriĂ©tĂ© -**HiĂ©rarchie ownership** : -- **États** : Master ownership des ressources territoriales -- **Companies** : Droits d'exploitation accordĂ©s/achetĂ©s -- **Joueur** : Doit obtenir droits pour exploiter -- **Revente droits** : Possible si non-rentable - -**Future** : SystĂšme rĂ©quisition Ă©tat en temps de guerre - -### GĂ©opolitique des Ressources -**Ressources stratĂ©giques** : -- **Titanium** : AĂ©rospatial, blindages avancĂ©s -- **Lithium** : Batteries, Ă©lectronique -- **Terres rares** : Processeurs, optiques avancĂ©es -- **ContrĂŽle = Pouvoir** : Monopole ressource = leverage diplomatique - -## MĂ©caniques de MarchĂ© - -### Information et Trading -**Transparence** : -- **Information parfaite** : Prix publics connus de tous -- **QualitĂ© nĂ©gociateur** : Influence commerce inter-entitĂ©s -- **MarchĂ© ouvert** : SystĂšme buy/sell orders (style hĂŽtel des ventes) - -### Manipulation Économique -**PĂ©nuries artificielles** : -- **Possible thĂ©oriquement** : Achat massif pour crĂ©er raretĂ© -- **Limites pratiques** : NĂ©cessite moyens immenses -- **Multi-marchĂ©s** : Difficile crĂ©er pĂ©nurie mondiale -- **Contre-mesures** : MarchĂ©s alternatifs, substituts - -### Dynamiques Prix -**Facteurs influençant** : -- **ProximitĂ© conflit** : Prix locaux augmentent prĂšs combats -- **DurĂ©e rĂ©solution** : "2 mois" vs "5 ans" = prix diffĂ©rents -- **Volume disponible** : Stocks mondiaux vs production -- **Routes commerciales** : Blocage routes = prix rĂ©gionaux explosent - -## Économie de Guerre - -### Changement de PrioritĂ©s Étatiques -**Principe** : États adaptent leurs commandes selon contexte -- **Temps de paix** : Nourriture, biens civils, infrastructure -- **Temps de guerre** : RĂ©duction tables civiles, augmentation tanks/munitions -- **Companies compliance** : Tentative d'adaptation aux nouvelles commandes Ă©tatiques -- **Limites culturelles** : Company bois ne peut pas faire tanks instantanĂ©ment - -### SystĂšme de Rationnement -**DĂ©clenchement** : En cas de pĂ©nuries critiques -- **PrioritĂ©s Ă©tatiques** : Garantie besoins essentiels (nourriture) -- **Malus production** : Effets nĂ©gatifs sur Ă©conomie gĂ©nĂ©rale -- **StratĂ©gie militaire** : Attaque infrastructure alimentaire = guerre totale -- **Ciblage intelligent** : DĂ©truire supply chains ennemies pour forcer rationnement - -### Finances et CrĂ©dit -**SystĂšme bancaire** : -- **Emprunts companies** : Financement expansion/reconversion -- **Taux variables** : Selon risque et contexte Ă©conomique -- **DĂ©fauts possibles** : Faillites en cas de mauvaise gestion - -### Supply Chain Vulnerabilities -**Effet cascade** : -- **Single point of failure** : Usine critique dĂ©truite → paralysie secteur -- **InterdĂ©pendances** : Composants → sous-assemblages → produits finis -- **Substituts** : Recherche alternatives en cas de rupture -- **Stockages stratĂ©giques** : Buffer contre disruptions temporaires \ No newline at end of file diff --git a/docs/02-systems/factory-architecture-post-player.md b/docs/02-systems/factory-architecture-post-player.md deleted file mode 100644 index a42e1d1..0000000 --- a/docs/02-systems/factory-architecture-post-player.md +++ /dev/null @@ -1,431 +0,0 @@ -# Rapport : Architecture Factory Game Post-IntĂ©gration Joueur - -## đŸ—ïž Factory Engine & Optimisation de Performance - -### Leçons Factorio (Analyse des Devlogs) - -L'analyse des devlogs de Factorio rĂ©vĂšle des optimisations cruciales pour les factory games : - -#### Transport Lines Revolution -- **Merger segments adjacents** : Fusionner les tapis roulants contigus en lignes logiques uniques -- **Gains de performance** : x50-100 amĂ©lioration via rĂ©duction complexitĂ© algorithmique -- **Principe** : Traiter une ligne de 100 segments comme 1 entitĂ© plutĂŽt que 100 entitĂ©s sĂ©parĂ©es - -#### Compression Caching Intelligent -- **Items "collĂ©s"** : Une fois optimisĂ©s, ils restent dans cet Ă©tat -- **Cache des gaps** : MĂ©moriser les espaces vides pour optimisation O(1) -- **Principe** : Éviter recalculation constante d'Ă©tats stables - -#### Bulk Inserters Strategy -- **Attendre main pleine** : DiffĂ©rer mouvement jusqu'Ă  stack optimal -- **Garantir efficacitĂ©** : Maximiser items par transfert -- **Principe** : Batch operations vs individual transfers - -#### SIMD & Vectorization -- **Processing parallĂšle** : 8+ items simultanĂ©ment avec AVX2 -- **Gains massifs** : Performance x4-8 sur opĂ©rations critiques -- **ComplexitĂ© Ă©levĂ©e** : Optimisation manuelle requise - -### DĂ©cision Architecture Performance - -**SIMD = Trop complexe pour Claude Code** - -**Analyse coĂ»t/bĂ©nĂ©fice** : -- ✅ **Gains** : Performance x4-8 sur boucles critiques -- ❌ **CoĂ»ts** : Code complexe, debugging difficile, contexte Claude Code explosĂ© - -**Solutions alternatives** : -- **Compiler auto-vectorization** : GCC/Clang optimisations automatiques -- **Abstraction layers** : Libraries tierces (Intel TBB, etc.) -- **GPU compute** : DĂ©lĂ©guer calculs lourds au GPU -- **PrivilĂ©gier simplicitĂ©** : Architecture maintenable vs optimisation prĂ©maturĂ©e - -## 🎯 Architecture Modulaire Factory - -### RĂšgle d'Or de Distribution - -**Performance-Based Module Distribution** : - -``` -Performance CRITIQUE → Same Module (belt+inserter+factory) -Performance IMPORTANTE → Same Process (logic, UI) -Performance MOYENNE → Same Machine (audio, debug) -Performance INDIFF → Network (analytics, telemetry) -``` - -### ProductionModule = Monolithe NĂ©cessaire - -**DĂ©cision architecturale clĂ©** : Belt + Inserter + Factory DOIVENT cohabiter - -#### Justification Technique -- **Interactions frame-perfect** : 60fps timing critique -- **InterdĂ©pendances serrĂ©es** : Item transfer nĂ©cessite coordination exacte -- **ISocket overhead** : Communication inter-module trop lente (>1ms inacceptable) -- **Performance native** : Appels directs vs sĂ©rialisation JSON - -#### Trade-off AcceptĂ© -- **ModularitĂ©** : SacrifiĂ©e pour ProductionModule -- **Performance** : PrioritĂ© absolue sur factory core -- **Claude Code** : Module plus gros (500-800 lignes) mais logique cohĂ©rente - -### Autres Modules Restent SĂ©parĂ©s - -Les systĂšmes non-critiques maintiennent la modularitĂ© : - -#### PowerModule (Distribution Énergie) -- **ResponsabilitĂ©s** : GĂ©nĂ©ration, distribution, stockage Ă©nergie -- **Performance** : Updates pĂ©riodiques (10Hz acceptable) -- **Communication** : Via IIO avec ProductionModule - -#### LogicModule (Automation) -- **ResponsabilitĂ©s** : Circuits, combinators, automation intelligente -- **Performance** : RĂ©actif mais pas frame-critical -- **Communication** : Signals vers ProductionModule - -#### LogisticModule (Transport Longue Distance) -- **ResponsabilitĂ©s** : Trains, robots, transport inter-bases -- **Performance** : Planification long-terme (1Hz acceptable) -- **Communication** : Coordination avec ProductionModule - -#### WarModule (Combat & StratĂ©gie) -- **ResponsabilitĂ©s** : Combat, dĂ©fense, stratĂ©gie militaire -- **Performance** : DĂ©cisions stratĂ©giques (0.1Hz acceptable) -- **Communication** : Isolation complĂšte avec ProductionModule - -## ⚔ War Module Architecture - -### Isolation Gameplay ComplĂšte - -**Principe fondamental** : Zero interaction directe ProductionModule ↔ WarModule - -#### SĂ©paration Stricte -- **Pas d'inserters vers turrets** : Logistique autonome pour war assets -- **Interface via LogisticModule** uniquement : Munitions, rĂ©parations transitent -- **Combat isolated** : War logic complĂštement indĂ©pendant de factory logic - -#### Avantages Architecture -- **Debugging isolĂ©** : Bug war ≠ crash factory -- **Performance sĂ©parĂ©e** : War optimization n'impacte pas factory FPS -- **Development parallĂšle** : Claude Code sur war logic sans comprendre factory - -### War = Orchestrateur Tactique - -**DĂ©composition en sous-systĂšmes spĂ©cialisĂ©s** : - -#### TargetingModule -- **ResponsabilitĂ©** : Acquisition et tracking cibles -- **Performance** : Real-time (60Hz) pour prĂ©cision combat -- **Algorithmes** : Line of sight, range calculation, target prioritization - -#### MovementModule -- **ResponsabilitĂ©** : Coordination et dĂ©placement unitĂ©s -- **Performance** : Smooth interpolation (30Hz) -- **Algorithmes** : Formation keeping, collision avoidance, unit coordination - -#### PathfindingModule -- **ResponsabilitĂ©** : Calcul routes optimales -- **Performance** : Async computation (background threads) -- **Algorithmes** : A*, hierarchical pathfinding, flow fields - -#### TacticalModule -- **ResponsabilitĂ©** : StratĂ©gie de bataille et dĂ©cisions -- **Performance** : Strategic thinking (1Hz) -- **Algorithmes** : Decision trees, strategy evaluation, resource allocation - -#### TacticalAnalyticsModule -- **ResponsabilitĂ©** : Intelligence et prĂ©dictions -- **Performance** : Deep analysis (0.1Hz) -- **Algorithmes** : Pattern recognition, threat assessment, predictive modeling - -### Distribution Network Friendly - -**War = DĂ©cisions stratĂ©giques** (Ă©chelle temps : secondes/minutes) -**Factory = Optimisation temps rĂ©el** (Ă©chelle temps : frames/millisecondes) - -#### Latency Tolerance -- **50-100ms acceptable** pour dĂ©cisions tactiques -- **Network distribution possible** pour tous sous-modules war -- **Load balancing** : Spread war computation across servers - -#### Scalability Natural -- **Solo game** : War modules local -- **Multiplayer** : War modules distribuĂ©s par faction -- **MMO** : War clusters par rĂ©gion gĂ©ographique - -## 🏭 Composition Factory Engine - -### ProductionModule Complet - -**Composants intĂ©grĂ©s pour performance optimale** : - -#### Production (Core Manufacturing) -- **Assemblers** : Recipe processing, input/output management -- **Mining** : Resource extraction, ore processing -- **Integration** : Direct memory access, zero-copy transfers - -#### Transport (Unified Movement System) -- **Belts** : Item transport, compression, line optimization -- **Underground** : Tunneling, space efficiency -- **Splitters** : Flow control, item routing -- **Pipes** : Fluid transport, pressure systems - -#### Logistics (Item Transfer) -- **Inserters** : Precise item movement, timing critical -- **Filters** : Item selection, routing logic -- **Stack optimization** : Bulk transfers, efficiency maximization - -#### Storage (Inventory Management) -- **Chests** : Static storage, capacity management -- **Buffers** : Flow smoothing, production decoupling -- **Inventaires** : Item tracking, slot management - -### Évolution Progressive Belts - -**ComplexitĂ© croissante pour maintenir Claude Code compatibility** : - -#### Phase 1 : Mono-item Belts (Claude Code Friendly) -- **1 item type par belt** : Logique simple, 200 lignes code -- **No lane splitting** : Éviter complexitĂ© algorithmique -- **Direct transfer** : Item A → Item A uniquement - -#### Phase 2 : Multi-item Belts -- **Mixed items** : Multiple types sur mĂȘme belt -- **Simple queuing** : FIFO sans optimisation -- **Claude Code** : 300 lignes, logique encore gĂ©rable - -#### Phase 3 : Dual-lane Belts -- **Left/right lanes** : IndĂ©pendance partielle -- **Lane preference** : Routing intelligent -- **Claude Code** : 400-500 lignes, limite complexity - -#### Phase 4 : Full Factorio Complexity (SIMD Optimized) -- **Advanced compression** : Gap elimination, chunk processing -- **Vector operations** : AVX2 parallel processing -- **Human Code** : Optimisation manuelle, SIMD intrinsics - -### Data Layout Future-Proof - -**Structure SOA (Structure of Arrays) dĂšs le dĂ©but** : - -```cpp -// SOA Layout pour SIMD readiness -struct BeltSystem { - std::vector positions_x; // [x0, x1, x2, x3, ...] - std::vector positions_y; // [y0, y1, y2, y3, ...] - std::vector item_types; // [t0, t1, t2, t3, ...] - std::vector speeds; // [s0, s1, s2, s3, ...] -}; - -// Future SIMD processing ready: -// __m256 pos_x = _mm256_load_ps(&positions_x[i]); -``` - -**Avantages** : -- **SIMD ready** : Pas de refactoring data layout futur -- **Cache efficient** : Memory access patterns optimaux -- **Claude Code compatible** : Simple vectors, pas de complex structs - -## 💰 Simulation Économique Complexe - -### Full Economic Simulation Vision - -**Objectif** : Victoria 3-level economic complexity dans factory game context - -#### PopulationModule (Demographics) -- **Classes dĂ©mographiques** : Workers, Engineers, Managers avec besoins diffĂ©rentiĂ©s -- **Population growth** : Birth/death rates, migration patterns -- **Social mobility** : Education, promotion, class transitions - -#### MarketModule (Price Discovery) -- **Supply/demand dynamics** : Real-time price adjustment -- **Market makers** : AI traders, liquidity provision -- **Price volatility** : Speculation, market shocks, bubbles - -#### MoneyModule (Monetary System) -- **Currency flow** : Money creation, circulation, destruction -- **Banking system** : Loans, interest rates, credit -- **Inflation modeling** : Money supply effects, price indexes - -#### TradeModule (International Commerce) -- **Import/export** : International trade flows -- **Exchange rates** : Currency valuation, forex markets -- **Trade policies** : Tariffs, quotas, trade agreements - -#### PolicyModule (Government Intervention) -- **Fiscal policy** : Taxation, government spending -- **Monetary policy** : Interest rates, money supply control -- **Regulation** : Industry oversight, market intervention - -### ComplexitĂ© Progressive - -**Start Simple → Scale Complex** : - -#### Phase 1 : Basic Economics -- **1 population class** : Generic workers -- **5 core goods** : Iron, copper, coal, steel, circuits -- **Simple supply/demand** : Linear price adjustment - -#### Phase 2 : Intermediate Economics -- **3 population classes** : Workers, engineers, managers -- **20 goods categories** : Expanded resource tree -- **Market dynamics** : Price volatility, speculation - -#### Phase 3 : Complex Economics -- **Full demographic model** : Age, education, skills -- **100+ goods** : Complete production chains -- **Advanced policies** : Government intervention, regulation - -#### Configuration-Driven Complexity -```json -{ - "economic_complexity": "intermediate", - "population_classes": 3, - "market_volatility": 0.15, - "government_intervention": true -} -``` - -### Emergent Behavior Objectif - -**Economic Events Cascade Through System** : - -#### Resource Discovery Chain -1. **New ore deposit found** → Increased supply -2. **Ore prices crash** → Mining companies struggle -3. **Workers migrate** → Regional population shift -4. **New markets emerge** → Economic boom in region - -#### War Economic Impact -1. **Military conflict** → Supply chain disruption -2. **Resource scarcity** → Price inflation -3. **War production** → Economic restructuring -4. **Post-war recession** → Market readjustment - -#### Technology Economic Impact -1. **Automation breakthrough** → Productivity gains -2. **Labor displacement** → Unemployment spike -3. **Wage pressure** → Social unrest -4. **Government intervention** → Economic policy changes - -#### Player Decision Ripples -- **Factory expansion** → Local job creation → Population growth -- **Resource hoarding** → Artificial scarcity → Price manipulation -- **Technology research** → Industry disruption → Economic transformation - -## 🔧 Architecture Finale OptimisĂ©e - -### Core Game (Local Performance) - -**Performance-critical systems remain local** : - -```cpp -ProductionModule { - // Monolithe nĂ©cessaire pour performance - Belt + Inserter + Factory + Storage - // 500-800 lignes, acceptable pour Claude Code - // Frame-perfect coordination, zero ISocket overhead -} - -LogicModule { - // Automation rĂ©active - Circuits + Combinators + Smart Automation - // 200-300 lignes, pure logic, Claude Code friendly -} -``` - -### Distributed Services (Network Tolerant) - -**Strategic systems leverage network distribution** : - -```cpp -PowerModule { - // Updates pĂ©riodiques (10Hz acceptable) - Generation + Distribution + Storage - // Network latency irrelevant for power planning -} - -LogisticModule { - // Planification long-terme (1Hz acceptable) - Trains + Robots + Inter-base Transport - // Route planning can handle 50-100ms latency -} - -WarModule { - // StratĂ©gie militaire (0.1-1Hz acceptable) - Targeting + Movement + Pathfinding + Tactical + Analytics - // Strategic decisions tolerant to network delays -} - -EconomicModule { - // Simulation complexe (0.01-0.1Hz acceptable) - Population + Market + Money + Trade + Policy - // Economic modeling happens on longer timescales -} -``` - -### Benefits Architecture Finale - -#### Performance Optimization -- **Critical systems local** : Zero network latency impact -- **Strategic systems distributed** : Horizontal scaling possible -- **Natural separation** : Performance requirements dictate architecture - -#### Development Efficiency -- **Claude Code** : Travaille sur modules simples (200-500 lignes) -- **Human optimization** : Focus sur performance kernels critiques -- **Parallel development** : Teams work on different performance tiers - -#### Scaling Flexibility -- **Solo laptop** : All modules local pour development -- **Multiplayer server** : Critical local, strategic distributed -- **MMO factory game** : Full distribution avec mĂȘme architecture - -#### Evolution Support -- **Progressive complexity** : Start simple, add sophistication -- **No architectural refactoring** : Module boundaries stable -- **Performance tuning** : Individual module optimization - -## 🎼 Gameplay Vision UnifiĂ©e - -**Factory Game avec Simulation Économique ComplĂšte** : - -### Gameplay Layers - -#### Production Layer (Real-time, Local) -- **Optimisation factory** : Belt throughput, inserter timing -- **Resource flow** : Efficient material processing -- **Performance critical** : 60fps responsive, frame-perfect - -#### Automation Layer (Reactive, Local) -- **Smart systems** : Circuits, combinators, adaptive logic -- **Responsive control** : React to production changes -- **Low latency** : Sub-second response times - -#### Strategic Layer (Planned, Distributed) -- **Military strategy** : Unit coordination, tactical planning -- **Long-term decisions** : Base expansion, technology research -- **Network tolerant** : Seconds to minutes decision cycles - -#### Economic Layer (Emergent, Distributed) -- **Market dynamics** : Supply/demand, price discovery -- **Complex simulation** : Population, policies, international trade -- **Deep computation** : Minutes to hours for complex economic modeling - -### Unified Experience - -**Chaque aspect du jeu optimisĂ© selon ses contraintes naturelles** : - -- **Factory optimization** → Immediate feedback, tactical decisions -- **Economic strategy** → Long-term planning, strategic thinking -- **Military coordination** → Medium-term tactics, resource allocation -- **Automation intelligence** → Reactive adaptation, efficiency optimization - -**RĂ©sultat** : Factory game qui Ă©volue naturellement vers simulation Ă©conomique complexe sans sacrifier performance core gameplay. - ---- - -## Conclusion - -L'architecture post-intĂ©gration joueur rĂ©vĂšle des trade-offs cruciaux entre modularitĂ© et performance. En acceptant un ProductionModule monolithique pour les systĂšmes critiques tout en maintenant la modularitĂ© pour les systĂšmes stratĂ©giques, nous obtenons le meilleur des deux mondes : - -**Performance native** oĂč nĂ©cessaire + **ModularitĂ© Claude Code** oĂč possible = **Factory game AAA avec dĂ©veloppement IA-optimized**. \ No newline at end of file diff --git a/docs/02-systems/gameplay-industriel.md b/docs/02-systems/gameplay-industriel.md deleted file mode 100644 index ac37ecf..0000000 --- a/docs/02-systems/gameplay-industriel.md +++ /dev/null @@ -1,210 +0,0 @@ -# Gameplay industriel - -## Progression des ressources - -### Ordre d'acquisition thĂ©orique - -**Ressources de base** : -- Bois → Coffre -- Pierre → Mur en pierre -- Scrap → ChaudiĂšre (alimentation vapeur dans un rayon de 1 case) - -**Machines de base** : -- Assembleur Ă  vapeur -- Four - -**ChaĂźne de production** : -- Charbon de bois < bois -- Fer < minerais de fer / scrap + charbon de bois -- Engrenage < Fer -- Cuivre < minerais de cuivre + charbon de bois -- Bobine de cuivre < cuivre -- Sable < pierre -- Verre < sable -- Circuit Ă©lectronique primitif < Bobine de cuivre + bois + verre - -## Gameloop par phases - -### Early -- Exploitation et production -- Scrap et bois -- Recherche -- ÉlectricitĂ© et commerce - -### Mid -- Charbon et fer/cuivre/silice -- Acide sulfurique/nitrique -- Explosifs basiques/munitions -- Électronique -- Roquettes -- Assemblage et diplomatie -- Licences civiles -- Combat -- Radar - -### Mid late -- PĂ©trole et alu/titane/gold -- Plastique/explosifs avancĂ©s -- Circuits avancĂ©s -- Licences militaires -- Tourelles de dĂ©fenses (AA, terrestre, gun) -- Missiles, C&C basique - -### Late game -- NuclĂ©aire et platine/composite -- Processeurs - -## Philosophie Bac Ă  Sable - -### LibertĂ© d'Échelle Joueur -Warfactory est conçu comme un **bac Ă  sable Ă©conomique** oĂč le joueur dĂ©finit sa propre Ă©chelle d'opĂ©ration selon ses prĂ©fĂ©rences : - -**Spectrum complet possible** : -- **Artisan local** : Production tables, meubles, objets du quotidien -- **PME spĂ©cialisĂ©e** : Focus niche (Ă©lectronique, composants spĂ©cifiques) -- **Industriel rĂ©gional** : Usines moyennes, marchĂ©s nationaux -- **GĂ©ant multinational** : Concurrent direct Thales/Lockheed Martin, marchĂ©s globaux - -**Principe fondamental** : **Aucune progression forcĂ©e**. Le joueur peut rester petit artisan toute la partie s'il le souhaite, ou scale selon ses ambitions. - -### Principe Skip vs Optimize - -**Philosophie design core** : **"Tous les systĂšmes du jeu doivent pouvoir ĂȘtre skippĂ©s"** - -Le joueur choisit son niveau d'engagement selon ses prĂ©fĂ©rences, compĂ©tences et temps disponible : - -**Spectrum d'engagement** : -- **Skip/CommoditĂ©** : Solutions automatisĂ©es, efficacitĂ© rĂ©duite mais accessibles -- **Partial engagement** : Hybride manuel/auto selon systĂšmes -- **Full optimization** : ContrĂŽle manuel complet, efficacitĂ© maximale - -**Exemples d'application** : -- **Production** : Factory tout-en-un (mĂ©diocre) vs layouts Factorio optimisĂ©s -- **Design vĂ©hicules** : Templates basiques vs design manuel prĂ©cis -- **Recherche** : Auto-tech vs chemins research focused -- **Commerce** : Auto-trade vs nĂ©gociation manuelle -- **Militaire** : Templates doctrinaux vs tactiques custom - -**Avantages** : -- **AccessibilitĂ©** : Nouveaux joueurs peuvent progresser sans frustration -- **Depth prĂ©servĂ©e** : Experts peuvent optimiser chaque aspect -- **RejouabilitĂ©** : MĂȘme joueur peut changer d'approche selon contexte -- **Respect du temps** : Adaptation aux contraintes personnelles - -### FlexibilitĂ© de Reconversion Industrielle - -#### MĂ©caniques de Switch Production -La difficultĂ© de reconversion dĂ©pend de la **similaritĂ© des processus industriels** : - -**Reconversion Facile** (mĂȘme ligne de production, ajustements mineurs) : -- **Tables fer → Blindages vĂ©hicules** : MĂȘme matĂ©riaux (acier), dĂ©coupe/soudage similaire -- **Électronique civile → Électronique militaire** : Composants proches, normes diffĂ©rentes -- **Moteurs civils → Moteurs militaires** : Base commune, specifications renforcĂ©es - -**Reconversion Complexe** (nouvelles machines, formation, supply chain) : -- **Tables fer → Canons d'artillerie** : PrĂ©cision usininage, alliages spĂ©ciaux, timing critique -- **Textile → Électronique** : Processus complĂštement diffĂ©rents -- **Alimentaire → Composites avancĂ©s** : MatĂ©riaux et techniques sans rapport - -**Reconversion Impossible** (reconstruction usine complĂšte) : -- **Menuiserie → Production hydrogĂšne** : ZĂ©ro overlap technologique -- **Pharmacie → Moteurs fusĂ©e** : Secteurs totalement disjoints - -#### Impact Gameplay -- **Diversification intelligente** : Choisir productions complĂ©mentaires -- **FlexibilitĂ© stratĂ©gique** : RĂ©agir aux Ă©vĂ©nements (guerre → switch civil→militaire) -- **SpĂ©cialisation vs GĂ©nĂ©ralisme** : Trade-off entre efficacitĂ© et adaptabilitĂ© - -## SystĂšmes de production - -### Factory -- **Extraction** -- **Minage** -- **Style** : Factorio-like - -### Agriculture -- Concept Ă  explorer - -### Production -- **Style** : Factorio-like -- **Assemblage** : Voir l'aspect conception avant - -#### Assemblage et qualitĂ© -L'idĂ©e est que puisque la conception se fait sur une grille, il faut placer les Ă©lĂ©ments sur une frame par des machines spĂ©ciales. Pour ce faire, il faut des bras spĂ©ciaux et placer dans un ordre correct. Si ce n'est pas respectĂ© parfaitement, on observera une rĂ©duction dans la qualitĂ© du matĂ©riel. - -**Exemple de placement** : -- Cases marron : Ă©lĂ©ments dĂ©jĂ  placĂ©s plus tĂŽt -- ÉlĂ©ment vert Ă  placer : bonne façon par la droite (flĂšche rouge) -- Placement par la gauche (flĂšche rose) : possible mais rĂ©duction qualitĂ© -- Composant bleu : 2 façons correctes (droite et arriĂšre, flĂšches jaunes) - -**ProblĂšme identifiĂ©** : -- "Chain des bras c'est pas ouf. MĂȘme si les machines changent de forme c'est clairement pas suffisant. Il faut plus. Visuellement c'est pauvre." - -### Logistique -- **Style** : Factorio-like -- **Évolution progressive des convoyeurs** (4 phases) - -#### Phases d'Ă©volution Belt System -**Phase 1 - Mono** : -- Convoyeur basique unidirectionnel -- Une seule voie, items espacĂ©s uniformĂ©ment -- SimplicitĂ© maximale pour MVP et early game - -**Phase 2 - Multi** : -- Multiple lanes par convoyeur (2-3 voies parallĂšles) -- Permet tri et routage plus sophistiquĂ© -- Introduction filtres et prioritĂ©s basiques - -**Phase 3 - Dual** : -- Convoyeurs bidirectionnels sur mĂȘme tile -- Optimisation espace avec flux retour -- ComplexitĂ© routing augmentĂ©e - -**Phase 4 - Full Factorio** : -- SystĂšme complet avec toute la complexitĂ© Factorio -- Splitters, underground belts, prioritĂ©s avancĂ©es -- Balancers, circuits logiques, filtres complexes -- Optimisations performance requises (segment merging, compression) - -### ÉlectricitĂ© -- **Principe** : TrĂšs simple pour gagner en performance par rapport Ă  Factorio -- **Pas de calcul dynamique** des consommations en entrĂ©e -- **Pas de balance** de consommation du rĂ©seau - -## SystĂšmes de Production - -### Dual Production System -**SystĂšme production brut** : -- Transforme ressources primaires en matĂ©riaux (minerai fer → plaques fer) -- Production de masse, standardisĂ©e -- Focus sur volume et efficacitĂ© - -**SystĂšme d'assemblage** : -- Prend matĂ©riaux et les place dans lignes d'assemblage -- CrĂ©ation produits finis (plaques acier → armure tank) -- Focus sur qualitĂ© et prĂ©cision - -### FlexibilitĂ© production (style Factorio) -**Reconfiguration selon complexitĂ©** : -- **Simple** : Tables → blindages bois (reconfiguration manufacturateurs, mĂȘme layout) -- **Complexe** : Tables fer → canons tank (refaire usines complĂštes - matĂ©riaux, timing, titane) -- **Radical** : Tables → hydrogĂšne (reconstruction totale usines) - -**DĂ©pendance recettes** : FacilitĂ© changement selon similaritĂ© matĂ©riaux/process - -### Avantage compĂ©titif joueur -**Joueur** : -- **Factorio-like** : Design optimisĂ©, consommation Ă©lectricitĂ© seule -- **EfficacitĂ© maximale** : Pas de workers, pas de salaires - -**IA Companies/États** : -- **BĂątiments simples** : Production sans design joueur -- **CoĂ»ts opĂ©rationnels** : Workers + salaires requis -- **Joueur peut accĂ©der** : Mais moins efficace que ses propres designs - -### Commandes et autonomie -- **Pas de suggestions IA** : Joueur gĂšre sa production seul -- **Commandes externes** : États/Companies peuvent commander au joueur -- **État ukrainien** : Company parmi d'autres (produit, commande, pas rĂ©quisition) - diff --git a/docs/02-systems/map-system.md b/docs/02-systems/map-system.md deleted file mode 100644 index 798e447..0000000 --- a/docs/02-systems/map-system.md +++ /dev/null @@ -1,1001 +0,0 @@ -# Map System - -## Vue d'ensemble - -Le systĂšme de carte de Warfactory utilise une architecture hybride combinant une **carte globale rĂ©elle Ă©ditable** avec des **cartes locales gĂ©nĂ©rĂ©es** pour optimiser performance et gameplay. - -## Architecture Multi-Niveaux - -### Zoom Discret - 2 Niveaux -**Large Map (Carte Globale)** : -- **Carte monde** : Scope planĂ©taire complet -- **V1 dĂ©veloppement** : Carte faite Ă  la main pour tests -- **Éditable** : Modifications possibles selon besoins gameplay -- **Navigation longue distance** : Node-based system -- **Scope** : Pays, rĂ©gions, logistique macro - -**Zoom Local (Tiles de Jeu)** : -- **Taille tiles** : 1m x 1m (prĂ©cision Factorio) -- **Chunks locaux** : 64x64 tiles (64m x 64m) [proposition] -- **Cartes gĂ©nĂ©rĂ©es** : CrĂ©Ă©es Ă  la demande par serveur -- **Style Factorio** : Placement prĂ©cis usines, bras, tapis roulants -- **Persistent** : GardĂ©es en mĂ©moire une fois gĂ©nĂ©rĂ©es -- **Scope** : Construction dĂ©taillĂ©e, combat local - -## SystĂšme de Navigation - -### Navigation Longue Distance -**Transport Terrestre** : -- **Node routier** : RĂ©seau routier principal -- **Node rail** : Infrastructure ferroviaire -- **Node maritime** : Ports et voies navigables - -**Transport AĂ©rien** : -- **Point A to Point B** : Navigation directe sans contraintes nodes -- **Pas de rĂ©seau** : Vol libre dans espace aĂ©rien - -### Chunks ImbriquĂ©s -**Optimisation logarithmique** : -- **HiĂ©rarchie chunks** : Structure imbriquĂ©e pour performance -- **Navigation intelligente** : Pathfinding optimisĂ© -- **Streaming efficace** : Chargement sĂ©lectif selon zoom - -## Gameplay et Construction - -### Échelles de Construction -**Niveau Local (Style Factorio)** : -- **Bras (inserter)** : Taille = taille joueur -- **Usines joueur** : 2x2, 3x3, 4x4, parfois plus grandes -- **Usines IA/personnel** : 40x30, 10x10, 15x30 (grandes installations) -- **Infrastructure** : Tapis roulants, rĂ©seaux Ă©lectriques - -**Niveau Global** : -- **Placement macro** : Positionnement bases, rĂ©gions industrielles -- **Infrastructure** : Routes, rails, ports -- **Effets cascade** : Modifications locales → impact global - -## Combat et IntĂ©gration - -### Combat Local sur Vraie Map -**Principe** : -- **Pas d'instances** : Combat sur cartes locales rĂ©elles -- **ContinuitĂ©** : MĂȘme terrain que construction -- **Persistance** : DĂ©gĂąts restent aprĂšs combat - -**IntĂ©gration Logistique** : -- **Routes visualisĂ©es** : Infrastructure visible sur map -- **Supply lines** : Convois suivent rĂ©seau routier/rail -- **VulnĂ©rabilitĂ©s** : Infrastructure attaquable - -## Streaming et Performance - -### SystĂšme de Chargement -**Client-Side** : -- **Streaming intelligent** : Charge zone selon zoom/position -- **Unload automatique** : LibĂšre mĂ©moire zones non-visitĂ©es -- **Performance optimale** : Affiche uniquement Ă©cran visible - -**Multi-joueur** : -- **Synchronisation serveur** : Redistribue changements aux joueurs en zone -- **Pas de conflit** : SystĂšme chunk rĂ©sout collisions - -### Transitions de Vue -**Zoom automatique** : -- **Seuil automatique** : Switch auto global→local selon niveau zoom -- **Boutons directs** : "Zoom on player" pour accĂšs rapide -- **Transition fluide** : Passage seamless entre niveaux - -**Isolation joueurs** : -- **Pas de notifications** : Connexion/dĂ©connexion autres joueurs invisible -- **Pas de chat** : Communication uniquement via systĂšme messages (futur) -- **Isolation totale** : 10 joueurs sur pays diffĂ©rents peuvent s'ignorer complĂštement - -### Optimisation Visuelle -**Rendu Local** : -- **Joueur voit** : Sa tile + tiles adjacentes -- **CamĂ©ras optionnelles** : AccĂšs distant aux usines du joueur -- **Performance** : Ultra-simple, affichage Ă©cran uniquement - -## Fog of War et Reconnaissance - -### SystĂšme de MĂ©moire -**FOW par Chunks** : -- **Full Black** : Zones jamais visitĂ©es -- **MĂ©moire persistante** : Client garde info zones explorĂ©es -- **GranularitĂ©** : Par chunk, pas de micro-FOW - -### Intel Gathering Progressif -**QualitĂ© reconnaissance** : -- **Satellite bas** : "BĂątiments ukrainiens en Ukraine" -- **Satellite high-end** : "Usines tanks Company X spĂ©cifique" -- **Progression dĂ©tail** : BĂątiment → Usine → Usine armement → Usine armement Company X - -### Persistance Intelligence -**MĂ©moire par Actor** : -- **Sauvegarde info** : État/Company garde intel collectĂ© -- **Expiration possible** : Info peut devenir obsolĂšte -- **Partage conditionnel** : Selon alliances/accords - -## Map Éditable et Modifications - -### Carte Globale RĂ©elle -**Base authentique** : -- **GĂ©ographie rĂ©elle** : Ukraine, Europe, monde selon scope -- **Modifiable** : Adaptations pour gameplay/Ă©quilibrage -- **Infrastructure rĂ©elle** : Routes, villes, ports existants - -### RĂ©percussions CroisĂ©es -**Local → Global** : -- **Destruction infrastructure** : Pont local → route globale coupĂ©e -- **Constructions majeures** : Nouvelle usine → impact Ă©conomique rĂ©gional - -**Global → Local** : -- **Artillerie longue portĂ©e** : DĂ©gĂąts route globale → terrain local -- **ÉvĂ©nements macro** : Bombe nuclĂ©aire → dĂ©gradation locale gĂ©nĂ©ralisĂ©e - -## Structures de DonnĂ©es Techniques - -### Architecture Chunks OptimisĂ©e - -**Tile Structure Principal (Terrain)** : -```cpp -struct Tile { - uint16_t terrain_type; // 2 bytes (65k types terrain possibles) - uint8_t elevation; // 1 byte (0-255 hauteur) - uint16_t building_id; // 2 bytes (ref vers building) - uint16_t flags; // 2 bytes (passable, destructible, etc.) - uint8_t padding; // 1 byte (alignment mĂ©moire) -}; // = 8 bytes par tile -``` - -**Chunk Principal 64x64** : -- **Taille** : 4096 tiles × 8 bytes = 32KB par chunk -- **Usage** : Terrain, navigation, construction, combat local -- **FrĂ©quence** : ChargĂ© souvent, dense - -**Combat Multi-Chunks** : -- **Batailles Ă©tendues** : Combat s'Ă©tend naturellement sur dizaines/centaines de chunks -- **Frontlines persistantes** : Guerre dure 1 an dans le monde (ex: base Bakhmut) -- **CapacitĂ© systĂšme** : "Milliers d'unitĂ©s" = rĂ©parties sur grande zone gĂ©ographique -- **Streaming intelligent** : Charge chunks actifs selon position unitĂ©s/player - -**SystĂšme Ressources par Patches (Factorio-like)** : -```cpp -// Patches alignĂ©s sur grille tiles, mais pas forcĂ©ment sur chunks -struct ResourcePatch { - uint16_t resourceId; // Fer, cuivre, pĂ©trole, uranium, etc. - uint64_t original_quantity; // QuantitĂ© initiale (future-proof) - uint64_t remaining_quantity; // Ce qui reste actuellement - uint8_t base_richness; // Richesse de base (items/sec/drill) - set tiles; // Grid de tiles occupĂ©es (ex: L-shape sur grille) - uint32_t active_drills; // Nombre de drills qui minent - BoundingBox bounds; // Zone couverte par le patch - - float getCurrentExtractionRate() { - if (remaining_quantity == 0) { - return 0.0f; // STOP NET - patch Ă©puisĂ© - } - - double depletion_ratio = (double)remaining_quantity / original_quantity; - // Formule diminishing returns : rate = base * (1 - (1-depletion)/2) - float efficiency = 1.0f - (1.0f - depletion_ratio) / 2.0f; - return base_richness * efficiency; - } - - float getTotalOutput() { - return getCurrentExtractionRate() * active_drills; - } - - bool isExhausted() { - return remaining_quantity == 0; - } -}; - -struct MiningDrill { - Point2D position; - uint8_t coverage_area; // 1-25 tiles selon tech - ResourcePatch* target_patch; // RĂ©fĂ©rence au patch minĂ© - - float getOutput() { - if (!target_patch || target_patch->isExhausted()) { - return 0.0f; // Drill inutile si patch Ă©puisĂ© - } - return target_patch->getCurrentExtractionRate(); - } -}; -``` - -**MĂ©caniques d'Extraction** : -- **Partage Ă©quitable** : N drills = N × extraction_rate du patch -- **Diminishing returns** : Plus le patch s'Ă©puise, moins il est efficace -- **ArrĂȘt brutal** : 0% restant = 0 extraction (pas de rĂ©siduel) -- **Exemple** : Patch 50% Ă©puisĂ© = 75% d'efficacitĂ© par drill - -**Exemples de CapacitĂ©** : -- **Patch fer standard** : 10 millions d'unitĂ©s -- **Gisement pĂ©trole** : 1 milliard d'unitĂ©s (quasi-infini) -- **Mine uranium** : 100 millions d'unitĂ©s (extraction trĂšs lente) - -**Avantages Architecture** : -- **SĂ©paration claire** : Terrain vs ressources = systĂšmes indĂ©pendants -- **Performance** : Terrain chargĂ© en continu, ressources Ă  la demande -- **ExtensibilitĂ©** : 65k terrain types = variantes urbain/rural/industriel -- **MĂ©moire optimisĂ©e** : Pas de ressources stockĂ©es dans chaque tile -- **Alignment CPU** : Padding assure performance mĂ©moire - -### Metadata Chunks -```cpp -struct ChunkMeta { - int32_t chunk_x, chunk_y; // Position globale - uint32_t generation_seed; // Pour reproduction terrain - bool is_dirty; // ModifiĂ© depuis last save - timestamp last_access; // Pour LRU unloading - uint16_t active_buildings; // Compteur optimisation - vector; // BĂątiments multi-tiles -}; // ~1-5KB selon buildings prĂ©sents -``` - -**Total Footprint par Chunk** : -- Terrain : 32KB (toujours chargĂ©) -- Ressources : 0-16KB (selon density, sparse) -- Metadata : 1-5KB (selon buildings) -- **Total** : 33-53KB par chunk = trĂšs raisonnable - -## GĂ©nĂ©ration et Persistance - -### Cartes Locales -**GĂ©nĂ©ration Ă  la demande** : -- **Serveur gĂ©nĂšre** : Selon besoins joueur/combat -- **Persistance** : Sauvegarde une fois crĂ©Ă©e avec seed -- **Reproduction** : MĂȘme seed = mĂȘme terrain gĂ©nĂ©rĂ© - -**Seed System** : -```cpp -// GĂ©nĂ©ration dĂ©terministe par chunk -uint32_t chunk_seed = global_seed ^ (chunk_x << 16) ^ chunk_y; -// Assure reproduction exacte du terrain -``` - -**DĂ©clencheurs gĂ©nĂ©ration** : -- **Joueur visite** : Zone explorĂ©e premiĂšre fois -- **Combat dĂ©clarĂ©** : Battlefield gĂ©nĂ©rĂ© automatiquement -- **Construction** : DĂ©veloppement industriel local - -## Architecture Modulaire de GĂ©nĂ©ration ProcĂ©durale - -### Principe de ModularitĂ© -**Design pour IA** : Chaque module = interface simple + logic testable + rĂšgles claires - -```cpp -class IGenerator { -public: - virtual void generate(ChunkData& chunk, GenerationContext& context) = 0; - virtual void validate(const ChunkData& chunk) = 0; - virtual bool canGenerate(const GenerationContext& context) = 0; -}; -``` - -### Modules de GĂ©nĂ©ration - -#### TerrainGenerator -```cpp -class TerrainGenerator : public IGenerator { -private: - PerlinNoiseGenerator elevation; - PerlinNoiseGenerator moisture; - BiomeClassifier biomes; - -public: - void generate(ChunkData& chunk, GenerationContext& context) override { - // GĂ©nĂšre elevation, biomes, terrain de base - // Input: chunk position, global seed - // Output: terrain_type pour chaque tile - } -}; -``` - -#### RoadNetworkGenerator -```cpp -class RoadNetworkGenerator : public IGenerator { -private: - DelaunayTriangulation connectivity; - MinimumSpanningTree optimizer; - -public: - void generate(ChunkData& chunk, GenerationContext& context) override { - // GĂ©nĂšre rĂ©seau routier cohĂ©rent - // Input: terrain, points d'intĂ©rĂȘt, chunks voisins - // Output: routes principales + secondaires - } -}; -``` - -#### BuildingLayoutGenerator -```cpp -class BuildingLayoutGenerator : public IGenerator { -private: - BSPTreePartitioner space_divider; - BuildingTemplateManager templates; - ZoningCalculator land_use; - -public: - void generate(ChunkData& chunk, GenerationContext& context) override { - // Place bĂątiments selon zoning et templates - // Input: terrain, routes, zone type (urbain/rural/industriel) - // Output: bĂątiments positionnĂ©s avec types - } -}; -``` - -#### DestructionSystem -```cpp -class DestructionSystem : public IGenerator { -private: - DamagePatternLibrary patterns; - HistoricalEventProcessor events; - -public: - void generate(ChunkData& chunk, GenerationContext& context) override { - // Applique destruction selon contexte historique - // Input: bĂątiments, Ă©vĂ©nements historiques (guerra, bombardements) - // Output: ruines, cratĂšres, infrastructures endommagĂ©es - } -}; -``` - -### Growth Engine Modulaire - -#### PopulationGrowthCalculator -```cpp -class PopulationGrowthCalculator { -private: - DemographicModel demographics; - EconomicFactors economy; - -public: - float calculateGrowthRate(const RegionData& region, float time_delta) { - // Calcule croissance population selon facteurs - // Input: population actuelle, Ă©conomie, sĂ©curitĂ© - // Output: taux de croissance (peut ĂȘtre nĂ©gatif) - } -}; -``` - -#### LandValueCalculator -```cpp -class LandValueCalculator { -private: - ProximityAnalyzer proximity; - InfrastructureEvaluator infrastructure; - SafetyAssessment security; - -public: - float calculateValue(const TileCoordinate& tile, const RegionContext& context) { - // Évalue valeur fonciĂšre d'une tile - // Input: position, infrastructure proche, sĂ©curitĂ© - // Output: valeur relative (0.0-1.0) - } -}; -``` - -#### DemandCalculator -```cpp -class DemandCalculator { -private: - ResidentialDemand residential; - CommercialDemand commercial; - IndustrialDemand industrial; - -public: - DemandProfile calculateDemand(const RegionData& region) { - // Calcule besoins en construction par type - // Input: population, Ă©conomie, infrastructure existante - // Output: demande rĂ©sidentiel/commercial/industriel - } -}; -``` - -#### ExpansionSiteFinder -```cpp -class ExpansionSiteFinder { -private: - SuitabilityAnalyzer suitability; - ConstraintChecker constraints; - -public: - vector findSites(const DemandProfile& demand, const RegionData& region) { - // Trouve emplacements optimaux pour expansion - // Input: demande calculĂ©e, terrain disponible - // Output: sites classĂ©s par prioritĂ© - } -}; -``` - -#### DevelopmentExecutor -```cpp -class DevelopmentExecutor { -private: - ConstructionPlanner planner; - ResourceRequirementCalculator resources; - -public: - bool executeDevelopment(const ExpansionSite& site, const DevelopmentPlan& plan) { - // ExĂ©cute construction selon plan et ressources - // Input: site choisi, plan de dĂ©veloppement - // Output: succĂšs/Ă©chec + modifications terrain - } -}; -``` - -### Pipeline de GĂ©nĂ©ration - -```cpp -class ChunkGenerationPipeline { -private: - vector> generators; - -public: - void generateChunk(ChunkData& chunk, const GenerationContext& context) { - // Pipeline sĂ©quentiel : - // 1. TerrainGenerator (base) - // 2. RoadNetworkGenerator (infrastructure) - // 3. BuildingLayoutGenerator (structures) - // 4. DestructionSystem (histoire) - - for (auto& generator : generators) { - if (generator->canGenerate(context)) { - generator->generate(chunk, context); - generator->validate(chunk); - } - } - } -}; -``` - -### Avantages Architecture - -**Pour l'IA** : -- **Interfaces claires** : Chaque module a input/output dĂ©finis -- **TestabilitĂ©** : Chaque gĂ©nĂ©rateur testable indĂ©pendamment -- **Évolution** : Nouveaux gĂ©nĂ©rateurs ajoutables facilement -- **Debug** : Isolation des problĂšmes par module - -**Pour le Gameplay** : -- **CohĂ©rence** : RĂšgles de gĂ©nĂ©ration explicites -- **FlexibilitĂ©** : Modules activables selon contexte -- **Performance** : GĂ©nĂ©ration Ă  la demande par module -- **ContinuitĂ©** : Coordination entre chunks via GenerationContext - -### Contexte de GĂ©nĂ©ration - -```cpp -struct GenerationContext { - uint32_t global_seed; - ChunkCoordinate position; - RegionType region_type; // Urbain, rural, industriel - HistoricalEvents events; // Guerres, bombardements passĂ©s - NeighborChunkData neighbors; // Chunks dĂ©jĂ  gĂ©nĂ©rĂ©s - CompanyInfluences companies; // Companies dominantes rĂ©gion - StatePolicy policies; // Politiques Ă©tat local - GeographicalBias bias; // Modificateurs rĂ©gion (+montagne, -marĂ©cage) - FixedZones fixed_zones; // Zones prĂ©dĂ©finies (Tchernobyl, etc.) -}; -``` - -## SystĂšme de GĂ©nĂ©ration ProcĂ©durale par Points avec Tendances RĂ©gionales - -### Vision Globale - -#### Principe Fondamental -Chaque tile de la carte mondiale est gĂ©nĂ©rĂ©e selon un **budget de points** qui dĂ©termine ce qui s'y trouve. Les Ă©lĂ©ments ont des valeurs positives (ressources, opportunitĂ©s) ou nĂ©gatives (dangers, contraintes). La gĂ©nĂ©ration combine des Ă©lĂ©ments pour atteindre exactement le score cible, crĂ©ant automatiquement un Ă©quilibre risque/rĂ©compense. - -#### Innovation ClĂ© : Tendances RĂ©gionales -Au-dessus du systĂšme de points, des **zones gĂ©ographiques** influencent la probabilitĂ© d'apparition de certains Ă©lĂ©ments, crĂ©ant des rĂ©gions spĂ©cialisĂ©es rĂ©alistes : bassins pĂ©troliers, zones miniĂšres historiques, rĂ©gions forestiĂšres, zones post-industrielles. - -### Anatomie d'une Tile - -#### Budget de Points -Chaque tile reçoit un **score cible** (-10 Ă  +10) qui dĂ©termine son "potentiel" : -- **Scores positifs** : Zones riches mais souvent avec contraintes -- **Score zĂ©ro** : Terrain Ă©quilibrĂ© ou neutre -- **Scores nĂ©gatifs** : Zones dangereuses ou difficiles - -#### Philosophie de Design -- **Équilibre automatique** : Richesse compensĂ©e par contraintes -- **VariĂ©tĂ© Ă©mergente** : MĂȘmes Ă©lĂ©ments, contextes diffĂ©rents -- **CohĂ©rence gĂ©ographique** : ÉlĂ©ments appropriĂ©s aux rĂ©gions via tendances rĂ©gionales -- **DĂ©couverte progressive** : Certains Ă©lĂ©ments cachĂ©s nĂ©cessitent exploration -- **SpĂ©cialisation territoriale** : RĂ©gions dĂ©veloppent identitĂ©s distinctes - -## Typologie des ÉlĂ©ments - -### Ressources Naturelles (Positives) -**Minerais de Base** -- Fer = +1 point -- Cuivre = +1 point -- Charbon = +1 point -- Plomb = +1 point - -**Minerais PrĂ©cieux** -- Bauxite = +2 points -- Étain = +2 points -- Titane = +3 points -- MagnĂ©sium = +2 points -- TungstĂšne = +3 points -- Chrome = +2 points -- Antimoine = +2 points - -**MĂ©taux PrĂ©cieux** -- Gold = +4 points -- Platine = +5 points -- Silver = +3 points -- Iridium = +6 points - -**Ressources ÉnergĂ©tiques & Chimiques** -- Lithium = +4 points -- Thorium = +3 points -- Soufre = +1 point -- Phosphore = +1 point -- Natron = +1 point - -**Ressources Organiques** -- Bois dur = +1 point -- Terre noire = +1 point -- Zinc = +2 points - -**Ressources ÉnergĂ©tiques** -- PĂ©trole = +3 points -- Gaz naturel = +2 points -- Uranium = +5 points - -**Ressources Organiques** -- ForĂȘt dense = +1 point -- Zone de chasse = +1 point -- Eau douce = +1 point - -### Vestiges et Structures (Variables) -**Vestiges Anciens** -- Ruines antiques = +1 point (matĂ©riaux rĂ©cupĂ©rables) -- Ruines mĂ©diĂ©vales = +1 point -- Vestiges industriels = +1 point (scrap mĂ©tallique) - -**Ruines Inutiles** -- Ruines effondrĂ©es = -1 point (obstruction) -- DĂ©combres = -1 point -- Structures instables = -2 points - -### Contraintes GĂ©ologiques (NĂ©gatives) -**Terrain Difficile** -- MarĂ©cages = -1 point -- Terrain rocailleux = -1 point -- Pentes abruptes = -2 points -- InstabilitĂ© gĂ©ologique = -3 points - -**Contaminations Historiques** -- Pollution miniĂšre ancienne = -2 points -- Contamination chimique = -2 points -- Pollution radioactive = -3 points -- Radiations intenses = -5 points - -### Features GĂ©ologiques SpĂ©ciales -**Formations Naturelles** -- Grottes = +1 point (abri, ressources cachĂ©es) -- Sources thermales = +1 point -- Gisements de sel = +1 point -- MĂ©tĂ©orite = +5 points (mĂ©taux rares et prĂ©cieux concentrĂ©s) -- ForĂȘt pĂ©trifiĂ©e = +2 points (silice, attraction gĂ©ologique) -- Geysers d'eau chaude = +2 points (Ă©nergie, tourisme thermal) -- CheminĂ©es de fĂ©es = +1 point (formation Ă©rosive unique) -- Arche naturelle = +1 point (pont rocheux, point de repĂšre) -- Pilier rocheux isolĂ© = +1 point (formation Ă©rosive, nidification) -- Mesa = +1 point (plateau isolĂ©, position dĂ©fensive) - -**Features GĂ©ographiques Aquatiques** -- Lac = +1 point (eau douce, transport) -- Lac avec Ăźle centrale = +2 points (position dĂ©fensive, mystĂšre) -- Étang = +1 point (ressource eau locale) -- MarĂ©cage = 0 points (ressources +2, difficultĂ©s terrain -2) -- Delta fluvial = +2 points (terres fertiles, voies navigation) -- Fjord = +1 point (port naturel protĂ©gĂ©) -- Cascade = +1 point (Ă©nergie hydraulique) -- Geyser = +2 points (Ă©nergie gĂ©othermique, attraction) -- Source de riviĂšre = +2 points (eau pure, position stratĂ©gique) -- Île fluviale = +1 point (position dĂ©fensive sur cours d'eau) -- Archipel = +3 points (multiple positions dĂ©fensives, pĂȘche) -- Atoll = +2 points (lagon protĂ©gĂ©, rĂ©cif corallien) -- Crique isolĂ©e = +2 points (port cachĂ©, protection tempĂȘtes) -- Crique avec Ăźlot = +3 points (mouillage protĂ©gĂ©, mystĂšre) -- Skerry = +1 point (Ăźlot rocheux, navigation difficile) -- Tombolo = +2 points (Ăźle reliĂ©e par banc de sable) -- Lac assĂ©chĂ© = 0 points (sel +2, ariditĂ© -2) - -**Features GĂ©ographiques Terrestres** -- Canyon = 0 points (protection +2, accĂšs difficile -2) -- Plateau Ă©levĂ© = +1 point (position dominante, vents) -- VallĂ©e encaissĂ©e = +1 point (protection, microclimat) -- Plaine fertile = +2 points (agriculture excellente) -- Steppe = 0 points (pĂąturages +1, ariditĂ© -1) -- Dunes mobiles = -1 point (instabilitĂ© terrain) -- Oasis = +3 points (eau prĂ©cieuse en zone aride) -- Col de montagne = +1 point (passage stratĂ©gique) -- Cirque glaciaire = +1 point (amphithĂ©Ăątre naturel) -- Gorge = 0 points (passage Ă©troit +1, accĂšs limitĂ© -1) -- Glacier = +1 point (rĂ©serve d'eau douce, terrain difficile) -- Colline marĂ©cageuse = 0 points (position Ă©levĂ©e +1, humiditĂ© -1) -- Caldeira = +3 points (sol volcanique fertile, gĂ©othermie) -- Isthme = +2 points (contrĂŽle liaison terrestre) -- VallĂ©e isolĂ©e = +2 points (protection totale, autarcie) -- Montagne isolĂ©e = +1 point (point de repĂšre, position dominante) -- CratĂšre gĂ©ant = +4 points (formation spectaculaire, minerais) -- Plateau dĂ©sertique = 0 points (position Ă©levĂ©e +1, ariditĂ© -1) -- Badlands = -1 point (Ă©rosion sĂ©vĂšre, sol pauvre) -- Oasis de glace = +2 points (eau en zone arctique) -- Gouffre = -2 points (danger naturel, accĂšs souterrain) - -**Features GĂ©ographiques CĂŽtiĂšres** -- Baie protĂ©gĂ©e = +2 points (port naturel excellent) -- Falaises = 0 points (dĂ©fense +2, accĂšs -2) -- Plage de sable = +1 point (dĂ©barquement, tourisme) -- RĂ©cif corallien = +1 point (protection naturelle) -- Estuaire = +2 points (commerce fluvial-maritime) -- Presqu'Ăźle = +1 point (position dĂ©fensive) -- DĂ©troit = +2 points (contrĂŽle passage maritime) -- Île cĂŽtiĂšre = +2 points (avant-poste maritime, dĂ©fense) -- Falaises cĂŽtiĂšres = +1 point (dĂ©fense naturelle, position Ă©levĂ©e) -- Rift cĂŽtier = +1 point (formation gĂ©ologique, accĂšs limitĂ©) - -**Features Industrielles Historiques** -- Terikon = 0 points (pollution -2, scrap +2) [voir exemple dĂ©taillĂ© section Score -1] -- Ville fantĂŽme = -1 point (infrastructure +2, dangers -3) -- Usine textile abandonnĂ©e = 0 points (machinerie +2, amiante -2) -- Centrale thermique dĂ©saffectĂ©e = -1 point (infrastructure +3, pollution -4) -- AciĂ©rie en ruines = +1 point (scrap mĂ©tallique massif +3, contamination -2) -- Raffinerie abandonnĂ©e = -2 points (infrastructure +2, pollution toxique -4) -- Complexe chimique = -3 points (Ă©quipements +3, contamination sĂ©vĂšre -6) -- Moulin industriel = +1 point (machinerie +2, roue hydraulique +1, dĂ©labrement -2) -- Briqueterie abandonnĂ©e = +1 point (argile locale +2, fours +1, fumĂ©es -2) -- Verrerie en ruines = +1 point (sable siliceux +2, Ă©quipements +1, dĂ©bris -2) -- Papeterie dĂ©saffectĂ©e = 0 points (machinerie +2, pollution riviĂšre -2) -- Distillerie illĂ©gale = +1 point (Ă©quipements cuivre +2, isolation +1, rĂ©putation -2) -- Scierie abandonnĂ©e = +1 point (outillage +3, bois stockĂ© +1, rouille -3) - -**CimetiĂšres de VĂ©hicules** -- CimetiĂšre de tanks = +2 points (scrap mĂ©tallique militaire) -- CimetiĂšre de voitures = +1 point (scrap mĂ©tallique civil) -- CimetiĂšre d'avions = +3 points (alliages aviation rares) -- DĂ©chĂšterie Ă  ciel ouvert = -1 point (pollution -3, scrap +2) -- Épave de train = +2 points (acier massif +3, accident historique -1) -- CimetiĂšre de bateaux = +2 points (acier naval +3, corrosion -1) -- DĂ©potoir Ă©lectronique = +1 point (mĂ©taux rares +3, toxicitĂ© -2) -- Station-service abandonnĂ©e = 0 points (cuves enterrĂ©es +1, contamination sol -1) - -**Sites Militaires AbandonnĂ©s** -- Base Cold War abandonnĂ©e = +1 point (bunkers +3, contamination -2) -- Zone de guerre ancienne (WW1) = 0 points (munitions dangereuses -2, scrap +2) -- Bunker Nazi enterrĂ© = +2 points (fortifications +3, histoire -1) -- Site de lancement de missiles = +3 points (infrastructure +4, contamination -1) -- Champ de mines inactif = -2 points (danger rĂ©siduel -3, dĂ©minage +1) -- Base navale abandonnĂ©e = +2 points (installations portuaires +3, rouille -1) -- AĂ©rodrome militaire = +2 points (piste +3, hangars +1, carburant rĂ©siduel -2) -- DĂ©pĂŽt de munitions = -1 point (explosifs dangereux -4, mĂ©taux +3) -- Radar abandonnĂ© = +1 point (Ă©quipements Ă©lectroniques +2, position Ă©levĂ©e +1, obsolescence -2) - -**Sites Culturels & Naturels** -- Tribu indigĂšne = +2 points (connaissances locales, guides) -- Village abandonnĂ© = 0 points (bĂątiments +1, isolement -1) -- MonastĂšre en ruines = +1 point (archives historiques, position Ă©levĂ©e) -- Site archĂ©ologique = +2 points (artefacts, valeur scientifique) -- Phare abandonnĂ© = +1 point (position cĂŽtiĂšre stratĂ©gique) -- ChĂąteau fort = +2 points (position dĂ©fensive, pierre de taille) -- Observatoire astronomique = +1 point (optiques prĂ©cises, site isolĂ©) -- CimetiĂšre historique = +1 point (patrimoine, position centrale) -- UniversitĂ© abandonnĂ©e = +2 points (laboratoires +3, bibliothĂšques +1, dĂ©labrement -2) -- HĂŽpital en ruines = 0 points (Ă©quipements mĂ©dicaux +2, contamination -2) -- Prison dĂ©saffectĂ©e = +1 point (sĂ©curitĂ© +3, rĂ©putation -2) -- CathĂ©drale gothique = +2 points (architecture +3, tourisme +1, entretien -2) -- Moulin Ă  vent historique = +1 point (mĂ©canique ancienne +2, position ventĂ©e +1, obsolescence -2) -- Ferme collective abandonnĂ©e = 0 points (hangars +2, terres +1, dĂ©labrement -3) - -**Anomalies GĂ©ologiques** -- Formations cristallines = +2 points -- DĂ©pĂŽts d'argile rare = +2 points -- Sables siliceux = +1 point -- Gisements de quartz = +2 points (pour optiques laser) -- Filons de diamant = +4 points (outils de prĂ©cision, optiques industrielles) -- Pierres prĂ©cieuses diverses = +2 points (technologie laser, Ă©lectronique) -- Geysers de mĂ©thane = +2 points (Ă©nergie, mais risque d'explosion) -- DĂŽme de sel = +3 points (stockage souterrain, ressource chimique) -- TourbiĂšre = +1 point (combustible organique, prĂ©servation) -- CoulĂ©e de lave ancienne = +2 points (roches volcaniques, terres fertiles) -- CratĂšre d'impact = +4 points (mĂ©taux rares, formation gĂ©ologique unique) -- Faille gĂ©ologique active = -1 point (instabilitĂ© +0, minerais exposĂ©s +1) -- Karst = 0 points (grottes +2, effondrements -2) -- Gisement d'ambre = +3 points (rĂ©sine fossile, inclusions scientifiques) -- Schiste bitumineux = +2 points (hydrocarbures non-conventionnels) -- Doline = -1 point (effondrement naturel, accĂšs souterrain) -- EntrĂ©e de grotte = +2 points (exploration, abri naturel) -- Grotte de surface = +1 point (abri visible, stockage) -- Puits de l'enfer = -3 points (gouffre profond, Ă©manations dangereuses) - -**Biomes & ÉcosystĂšmes** -- ForĂȘt tempĂ©rĂ©e = +1 point (bois, biodiversitĂ©) -- ForĂȘt borĂ©ale = +1 point (conifĂšres, sols acides) -- ForĂȘt tropicale = +2 points (biodiversitĂ©, bois exotiques) -- Prairie = +1 point (agriculture, Ă©levage) -- Savane = 0 points (pĂąturages +1, sĂ©cheresse -1) -- Toundra = 0 points (permafrost +0, froid extrĂȘme -1, isolation +1) -- TaĂŻga = +1 point (bois massif, fourrures) -- Mangrove = +2 points (protection cĂŽtiĂšre, Ă©cosystĂšme unique) -- DĂ©sert chaud = -1 point (ariditĂ© -2, minĂ©raux exposĂ©s +1) -- DĂ©sert froid = -1 point (froid -1, isolation +0) -- Zone alpine = 0 points (position Ă©levĂ©e +2, accĂšs difficile -2) -- Marais salant = +1 point (sel naturel, difficultĂ©s terrain) -- Lande = 0 points (sol pauvre -1, tourbe +1) -- Maquis mĂ©diterranĂ©en = +1 point (plantes aromatiques, feux -1) -- Steppe herbacĂ©e = 0 points (Ă©levage +1, vents forts -1) -- Zone humide = +1 point (filtration naturelle, biodiversitĂ©) -- Plaine inondable = 0 points (fertilitĂ© +2, inondations -2) -- Plateau continental = +1 point (pĂȘche, position maritime) -- ForĂȘt mixte = +1 point (diversitĂ© bois, Ă©quilibre Ă©cologique) -- Chaparral = 0 points (rĂ©sistance feu +1, broussailles -1) -- Pampa = +1 point (terres fertiles, vents constants) -- Jungle Ă©quatoriale = +2 points (ressources exotiques +3, accessibilitĂ© -1) -- ForĂȘt de nuages = +2 points (humiditĂ© constante, espĂšces rares) -- DĂ©sert de sel = -1 point (hostile -3, extraction sel +2) -- Banquise = -2 points (isolation extrĂȘme -3, pĂȘche arctique +1) -- RĂ©cif barriĂšre = +3 points (protection +2, biodiversitĂ© marine +2, navigation -1) -- Oasis de montagne = +3 points (eau rare +2, position stratĂ©gique +2, accĂšs -1) -- VallĂ©e glaciaire = +1 point (sol fertile +2, climat rigoureux -1) - -**ÉlĂ©ments Climatiques & MĂ©tĂ©orologiques** -- Zone de tornades = -2 points (danger -3, Ă©nergie Ă©olienne +1) -- Couloir de vents = +1 point (Ă©nergie Ă©olienne constante) -- Zone de brouillards = -1 point (visibilitĂ© rĂ©duite -2, humiditĂ© +1) -- Micro-climat chaud = +1 point (agriculture prolongĂ©e) -- Poche de froid = -1 point (gel permanent, prĂ©servation naturelle) -- Zone de calme plat = 0 points (navigation difficile -1, tranquillitĂ© +1) - -**ÉlĂ©ments Anthropiques Modernes** -- Autoroute abandonnĂ©e = +1 point (bitume +2, pollution -1) -- Pont autoroutier = +2 points (passage stratĂ©gique +3, entretien -1) -- Tunnel ferroviaire = +2 points (passage montagne +3, maintenance -1) -- Ligne haute tension = +1 point (infrastructure Ă©lectrique +2, danger -1) -- Éolienne cassĂ©e = 0 points (piĂšces mĂ©caniques +2, encombrement -2) -- Antenne relais = +1 point (communication +2, position Ă©levĂ©e +1, obsolescence -2) -- Pipeline enterrĂ© = +1 point (infrastructure +2, risque fuite -1) -- DĂ©charge contrĂŽlĂ©e = -1 point (rĂ©cupĂ©ration +2, pollution -3) - -**ÉlĂ©ments MystĂ©rieux & Rares** -- Cercle de pierres = +2 points (mystĂšre historique, point de repĂšre) -- Monolithe isolĂ© = +3 points (formation inexpliquĂ©e, attraction) -- Zone de silence radio = -1 point (phĂ©nomĂšne inexpliquĂ© -2, isolation +1) -- Anomalie magnĂ©tique = +2 points (minerais rares +3, instruments perturbĂ©s -1) -- Source radioactive naturelle = -2 points (danger -4, recherche scientifique +2) - -## SystĂšme de DĂ©couverte - -### ÉlĂ©ments Visibles -DĂ©tectables lors de la gĂ©nĂ©ration du chunk : - -**GĂ©ologiques Apparents** -- Relief et formations rocheuses -- Cours d'eau et sources -- Couverture forestiĂšre -- Ruines en surface - -**Indices Subtils** -- VĂ©gĂ©tation anormale (contamination) -- Coloration du sol (minerais) -- Formations gĂ©ologiques particuliĂšres - -### ÉlĂ©ments CachĂ©s -NĂ©cessitent exploration spĂ©cialisĂ©e : - -**Niveau 1 - Prospection GĂ©ologique** -- Gisements souterrains (fer, cuivre, charbon) -- Nappes d'hydrocarbures -- Eaux souterraines -- CavitĂ©s souterraines - -**Niveau 2 - Exploration MagnĂ©tomĂ©trique** -- Structures mĂ©talliques enfouies -- Monolithes et anomalies magnĂ©tiques -- Épaves enterrĂ©es profondĂ©ment -- Formations mĂ©talliques naturelles - -**Niveau 3 - Analyse Chimique/Radiologique** -- Contaminations invisibles -- Gisements radioactifs -- Pollutions chimiques anciennes -- Zones de dĂ©contamination nĂ©cessaire - -### SystĂšme de DĂ©couverte StratifiĂ© - -#### Couche Visible -**Reconnaissance Standard** : Relief, vĂ©gĂ©tation, structures en surface, cours d'eau -**Indices Subtils** : VĂ©gĂ©tation anormale suggĂ©rant contamination, coloration du sol indiquant minerais - -#### Couche CachĂ©e - Niveau 1 -**VĂ©hicule GĂ©ologique** : RĂ©vĂšle gisements souterrains, nappes d'hydrocarbures, eaux profondes -- PortĂ©e : 3×3 chunks depuis position -- Temps : 2-5 minutes selon profondeur - -#### Couche CachĂ©e - Niveau 2 -**VĂ©hicule MagnĂ©tomĂ©trique** : DĂ©tecte anomalies magnĂ©tiques, structures mĂ©talliques enfouies, monolithes -- PortĂ©e : 1×1 chunk haute prĂ©cision -- Temps : 1-3 minutes - -#### Couche CachĂ©e - Niveau 3 -**VĂ©hicule NRBC** : RĂ©vĂšle contaminations invisibles, radiations, pollutions chimiques -- SĂ©curitĂ© : Protection Ă©quipage -- Temps : 3-8 minutes selon danger - -## Tendances RĂ©gionales - -### Concept de SpĂ©cialisation GĂ©ographique -Des **zones d'influence** superposĂ©es Ă  la carte modifient les probabilitĂ©s d'apparition des Ă©lĂ©ments, crĂ©ant des rĂ©gions avec des "personnalitĂ©s" distinctes basĂ©es sur la gĂ©ographie et l'histoire rĂ©elles. - -### Types de RĂ©gions - -#### Bassins PĂ©troliers (Golfe Persique, Mer du Nord) -- PĂ©trole : probabilitĂ© ×5 -- Gaz naturel : probabilitĂ© ×3 -- Terrains marĂ©cageux : ×2 -- AccĂšs maritime naturel - -#### Zones MiniĂšres Historiques (Ruhr, Donbass, Oural) -- Fer et charbon : probabilitĂ© ×3-4 -- Teritons : probabilitĂ© ×8 (trĂšs caractĂ©ristique) -- Vestiges industriels : ×2 -- Pollution miniĂšre hĂ©ritĂ©e : ×3 - -#### RĂ©gions ForestiĂšres/Montagneuses (Alpes, Carpates, TaĂŻga) -- ForĂȘt dense et chasse : probabilitĂ© ×3-4 -- Grottes et sources : ×2-3 -- Pentes abruptes : ×2 -- InstabilitĂ© gĂ©ologique : ×1.5 - -#### Zones Post-NuclĂ©aires (Tchernobyl Ă©largi, sites d'essais) -- Pollution radioactive : probabilitĂ© ×10 -- Uranium accessible : ×3 -- Structures abandonnĂ©es : ×3 -- VĂ©gĂ©tation mutante caractĂ©ristique - -#### RĂ©gions CĂŽtiĂšres (Littoraux, deltas) -- AccĂšs maritime : bonus naturel -- SĂ©diments et argiles : ×2 -- Zones humides : ×1.5 -- Érosion cĂŽtiĂšre : contrainte spĂ©cifique - -### Zones de Transition -**Transition Progressive** : L'influence rĂ©gionale diminue avec la distance du centre, crĂ©ant des zones mixtes rĂ©alistes -**Superposition** : Plusieurs influences peuvent se combiner (montagne + ancien bassin minier = mĂ©taux prĂ©cieux en terrain difficile) - -## Distribution et Équilibrage - -### RĂ©partition des Scores (Distribution en Cloche) -- **30%** des tiles Ă  score 0 (terrain neutre de base) -- **40%** des tiles Ă  scores ±1 Ă  ±3 (variations courantes) -- **20%** des tiles Ă  scores ±4 Ă  ±6 (zones remarquables) -- **8%** des tiles Ă  scores ±7 Ă  ±8 (zones exceptionnelles) -- **2%** des tiles Ă  scores extrĂȘmes ±9 Ă  ±10 (zones lĂ©gendaires) - -### Biais GĂ©ographiques Globaux -- **Zones montagneuses** : +1 point (concentration minĂ©rale naturelle) -- **Zones cĂŽtiĂšres** : +0.5 point (accĂšs et sĂ©diments) -- **Zones industrielles historiques** : -1 point (pollution hĂ©ritĂ©e) - -### Sites Fixes Historiques -**Lieux EmblĂ©matiques** conservent leurs caractĂ©ristiques rĂ©elles : -- Tchernobyl : Score fixe -10 (radiations massives, zone morte) -- Golfe Persique : Score fixe +8 (pĂ©trole abondant, infrastructure) -- SibĂ©rie diamantifĂšre : Score fixe +9 (diamants + or + difficultĂ©s extrĂȘmes) -- DĂ©sert d'Atacama : Score fixe -7 (ariditĂ© extrĂȘme, minerais rares) -- RĂ©gion Ruhr : Score fixe +3 (richesse industrielle) - -## Exemples de GĂ©nĂ©ration - -### Tile Score +3 -**Combinaisons Possibles :** -- PĂ©trole (+3) = Gisement pur -- Fer (+1) + Bauxite (+2) = Double gisement -- Cuivre (+1) + Grottes (+1) + Ruines antiques (+1) = Complexe minier ancien -- Uranium (+5) + Contamination (-2) = Gisement dangereux - -### Tile Score 0 -**Combinaisons Possibles :** -- Rien = Terrain neutre standard -- Fer (+1) + Ruines effondrĂ©es (-1) = Gisement obstruĂ© -- ForĂȘt (+1) + MarĂ©cages (-1) = ForĂȘt marĂ©cageuse -- Vestiges industriels (+1) + Pollution miniĂšre (-1) = Friche industrielle - -### Tile Score -3 -**Combinaisons Possibles :** -- Pollution radioactive (-3) = Zone contaminĂ©e simple -- InstabilitĂ© gĂ©ologique (-3) = Zone dangereuse -- Contamination (-2) + Ruines effondrĂ©es (-1) = Site industriel polluĂ© -- Uranium (+5) + Radiations (-5) + Pentes abruptes (-2) + Grottes (+1) = Mine uranium abandonnĂ©e - -## Features de Chunk IntĂ©grĂ©es - -### Features GĂ©ologiques Majeures - -#### Terikon (Score -1) -- **Composition** : Vestiges industriels (+1) + Pollution miniĂšre (-2) -- **Visible** : Colline artificielle caractĂ©ristique -- **CachĂ©** : Traces de mĂ©taux rares dans les dĂ©blais -- **RĂ©gional** : ×8 probabilitĂ© en zones ex-miniĂšres -- **Gameplay** : DĂ©blaiement rĂ©vĂšle ressources enfouies - -#### VallĂ©e Fluviale (Score +2) -- **Composition** : Eau douce (+1) + SĂ©diments (+1) -- **Visible** : Relief et Ă©coulement Ă©vidents -- **CachĂ©** : DĂ©pĂŽts alluvionnaires prĂ©cieux -- **Gameplay** : Dragage rĂ©vĂšle minerais transportĂ©s - -### Features de Vestiges - -#### Complexe Industriel AbandonnĂ© (Score 0) -- **Composition** : Scrap (+1) + Pollution (-2) + Fer rĂ©siduel (+1) -- **Visible** : Structures industrielles en ruine -- **CachĂ©** : Filons non exploitĂ©s, Ă©quipement enterrĂ© -- **RĂ©gional** : FrĂ©quent dans zones ex-industrielles -- **Gameplay** : DĂ©contamination + fouilles rĂ©vĂšlent trĂ©sors - -### Features d'Anomalies - -#### Site d'Anomalie MagnĂ©tique (Score +2) -- **Composition** : Monolithe mystĂ©rieux (+3) + InstabilitĂ© (-1) -- **Visible** : Formations gĂ©ologiques Ă©tranges -- **CachĂ©** : Structure mĂ©tallique d'origine inconnue -- **RĂ©gional** : TrĂšs rare, distribution alĂ©atoire -- **Gameplay** : Exploration magnĂ©tomĂ©trique rĂ©vĂšle secrets - -## Évolution Temporelle - -### Actions Joueur Modifient Scores -- **DĂ©contamination** : -2 → +1 avec technologie appropriĂ©e -- **Exploitation** : +3 → +1 aprĂšs Ă©puisement partiel -- **Pollution industrielle** : +2 → -1 aprĂšs accident -- **Nettoyage ruines** : -1 → 0 aprĂšs dĂ©blaiement - -### Processus Naturels -- **RĂ©gĂ©nĂ©ration forestiĂšre** : +0.1 point/an en zone tempĂ©rĂ©e -- **Érosion contamination** : -0.05 point/an (trĂšs lent) -- **SĂ©dimentation fluviale** : Peut rĂ©vĂ©ler/cacher ressources -- **InstabilitĂ© gĂ©ologique** : Évolution selon activitĂ© sismique - -## Gameplay Émergent - -### SpĂ©cialisation Économique Naturelle -**Bassins PĂ©troliers** deviennent naturellement centres Ă©nergĂ©tiques -**Anciennes Zones MiniĂšres** Ă©voluent vers centres sidĂ©rurgiques -**RĂ©gions ForestiĂšres** se spĂ©cialisent dans construction bois et chasse - -### StratĂ©gie Territoriale -**ContrĂŽle RĂ©gional** : Certaines rĂ©gions deviennent stratĂ©giquement vitales -**Exploration CiblĂ©e** : "Je cherche du fer → direction les montagnes ex-miniĂšres" -**DĂ©fis SpĂ©cialisĂ©s** : Chaque rĂ©gion impose ses contraintes techniques - -### Reconnaissance et Apprentissage -**Patterns Visuels** : Joueurs apprennent Ă  reconnaĂźtre les indices rĂ©gionaux -**Teritons** = Zone ex-miniĂšre probable = Fer mais pollution -**VĂ©gĂ©tation anormale** = Contamination = Danger mais ressources rares potentielles - -### Équilibre Risque/RĂ©compense Automatique -**Zones Riches** compensĂ©es par contraintes proportionnelles -**Zones SĂ»res** moins rewarding mais accessibles -**Zones ExtrĂȘmes** trĂšs dangereuses mais trĂšs lucratives - -## CohĂ©rence et RĂ©alisme - -### GĂ©ographie Logique -Reproduit les patterns gĂ©ologiques et historiques rĂ©els : les bassins pĂ©troliers sont oĂč ils devraient ĂȘtre, les zones miniĂšres correspondent aux vraies formations gĂ©ologiques. - -### Histoire IntĂ©grĂ©e -Chaque rĂ©gion raconte son histoire through les Ă©lĂ©ments prĂ©sents : pollution industrielle hĂ©ritĂ©e, vestiges d'exploitation, contaminations d'accidents passĂ©s. - -### Évolution Temporelle -Actions du joueur modifient progressivement les caractĂ©ristiques locales : dĂ©contamination, Ă©puisement de gisements, accidents industriels. - -**Objectif Final** : CrĂ©er un monde oĂč chaque tile a une identitĂ© unique dĂ©terminĂ©e par sa gĂ©ographie, son histoire et son Ă©quilibre naturel risque/rĂ©compense, gĂ©nĂ©rant organiquement des choix stratĂ©giques et des opportunitĂ©s d'exploration meaningfuls. \ No newline at end of file diff --git a/docs/02-systems/message-communication-system.md b/docs/02-systems/message-communication-system.md deleted file mode 100644 index 2cdb660..0000000 --- a/docs/02-systems/message-communication-system.md +++ /dev/null @@ -1,419 +0,0 @@ -# Message Communication System - -## Vue d'ensemble - -Le systĂšme de communication inter-modules utilise des **classes de messages typĂ©es** au lieu de JSON brut pour garantir la fiabilitĂ© et la maintenabilitĂ©. - -## Concept fondamental - -**Une classe = un type de message** -**Une instance = un message individuel** - -Exemple: La classe `TankMovedMessage` dĂ©finit le type "mouvement de tank". Chaque fois qu'un tank bouge, on crĂ©e une nouvelle instance de cette classe. - -## Pourquoi des classes? - -### ProblĂšme avec JSON brut -- Erreurs dĂ©couvertes uniquement au runtime -- Pas de validation automatique -- Typos dans les clĂ©s non dĂ©tectĂ©es -- Difficile Ă  maintenir et refactoriser - -### Solution avec classes -- Validation au compile-time -- Contrat clair entre modules -- IDE autocomplĂ©tion et refactoring -- Hot-reload friendly (petites classes isolĂ©es) -- Évolutif (ajout de champs sans casser l'existant) - -## Architecture - -### IMessage - Interface de base - -Interface pure dĂ©finissant le contrat minimal pour tous les messages: - -- **Type identification**: Chaque message dĂ©clare son type via enum -- **Serialization**: Conversion vers JSON pour transport via IIO -- **Deserialization**: Reconstruction depuis JSON reçu - -### AMessage - Classe abstraite avec mĂ©tadata - -Classe abstraite obligatoire fournissant l'implĂ©mentation partielle commune Ă  tous les messages. - -**MĂ©tadata immutables (enforced):** -- `timestamp` - Horodatage de crĂ©ation (const) -- `sender` - Module Ă©metteur (const) -- `messageId` - ID unique pour tracking et reassemblage fragments (const) -- `partId` - ID de fragment pour messages multi-parts (const) - -**CaractĂ©ristiques:** -- Constructeur protĂ©gĂ© force passage par classes enfants -- MĂ©tadata initialisĂ©es automatiquement Ă  la construction -- Impossible de modifier mĂ©tadata aprĂšs crĂ©ation -- Tous messages garantis d'avoir timestamp/sender/messageId - -### MessageType - Enum central - -Enum listant tous les types de messages du systĂšme: -- `TANK_MOVED`, `TANK_FIRED`, `TANK_DESTROYED` -- `PRICE_UPDATED`, `TRADE_EXECUTED` -- `ITEM_PRODUCED`, `BELT_CONGESTION` -- etc. - -**Pourquoi enum plutĂŽt que strings?** -- Performance (comparaison d'entiers) -- Type safety (typos dĂ©tectĂ©es au compile) -- Centralisation (tous les types visibles) - -### Messages concrets - -Chaque type de message est une classe dĂ©diĂ©e hĂ©ritant de `AMessage`: - -**TankMovedMessage**: Position, vitesse, ID tank -**PriceUpdatedMessage**: Item, ancien prix, nouveau prix -**ItemProducedMessage**: Item type, quantitĂ©, factory ID - -Chaque classe: -- HĂ©rite obligatoirement de `AMessage` -- Appelle constructeur `AMessage(senderModule)` -- Stocke ses donnĂ©es spĂ©cifiques -- Valide Ă  la construction -- SĂ©rialise/dĂ©sĂ©rialise son propre format - -## Flow de communication - -### Publication - -**Exemple complet:** -```cpp -void TankModule::process(const json& input) { - // 1. Calculer nouvelle position - Vector2 newPos = calculatePosition(); - float currentSpeed = getSpeed(); - - // 2. CrĂ©er message (validation automatique Ă  la construction) - TankMovedMessage msg(newPos, currentSpeed, tankId); - - // 3. SĂ©rialiser en JSON - json serialized = msg.serialize(); - - // 4. Publier via IIO - io->publish("tank:" + std::to_string(tankId), serialized); -} -``` - -**Étapes:** -1. Module crĂ©e instance de message (validation Ă  la construction) -2. Message sĂ©rialisĂ© en JSON via `serialize()` -3. PubliĂ© via `IIO::publish(topic, json)` -4. IIO route vers subscribers du topic - -### RĂ©ception - -**MĂ©thode 1: Type-safe template helper (recommandĂ©)** -```cpp -// Clean syntax avec type safety automatique -auto tankMsg = io->pullMessageAs(); - -if (tankMsg) { // nullptr si type mismatch ou queue vide - Vector2 pos = tankMsg->getPosition(); - float speed = tankMsg->getSpeed(); -} -``` - -**MĂ©thode 2: Manuelle (si besoin de flexibilitĂ©)** -```cpp -// RĂ©cupĂšre message brut -Message rawMsg = io->pullMessage(); - -// DĂ©sĂ©rialise vers base -std::unique_ptr baseMsg = IMessage::deserialize(rawMsg.data); - -// Cast vers type concret -if (TankMovedMessage* tankMsg = dynamic_cast(baseMsg.get())) { - // AccĂšs type-safe -} -``` - -**Template helper implementation:** -```cpp -class IIO { - // Template helper inline (zero overhead) - template - std::unique_ptr pullMessageAs() { - if (!hasMessages()) return nullptr; - - Message raw = pullMessage(); - std::unique_ptr base = IMessage::deserialize(raw.data); - - T* casted = dynamic_cast(base.get()); - if (!casted) return nullptr; // Type mismatch - - base.release(); - return std::unique_ptr(casted); - } -}; -``` - -**Performance:** -- Template inlined = zero function call overhead -- `dynamic_cast` = ~5-10ns (nĂ©gligeable vs JSON parsing) -- Bottleneck rĂ©el = JSON serialization, pas le cast - -### DĂ©sĂ©rialisation centralisĂ©e - -**Factory pattern avec routing par type:** -```cpp -// IMessage base class -std::unique_ptr IMessage::deserialize(const json& data) { - // Extract type from JSON - int typeInt = data.value("type", -1); - MessageType type = static_cast(typeInt); - - // Route to concrete deserializer - switch (type) { - case MessageType::TANK_MOVED: - return TankMovedMessage::deserialize(data); - - case MessageType::PRICE_UPDATED: - return PriceUpdatedMessage::deserialize(data); - - case MessageType::ITEM_PRODUCED: - return ItemProducedMessage::deserialize(data); - - // Add new messages here - - default: - return nullptr; // Unknown type - } -} -``` - -**Chaque message implĂ©mente sa propre dĂ©sĂ©rialisation:** -```cpp -class TankMovedMessage : public AMessage { - static std::unique_ptr deserialize(const json& data) { - try { - Vector2 pos{data["position"]["x"], data["position"]["y"]}; - float speed = data["speed"]; - int tankId = data["tankId"]; - - return std::make_unique(pos, speed, tankId); - } catch (const json::exception& e) { - return nullptr; // Malformed JSON - } - } -}; -``` - -**Gestion des erreurs:** -- JSON malformĂ© → retourne `nullptr` -- Type inconnu → retourne `nullptr` -- Validation Ă©choue → exception Ă  la construction -- Modules doivent vĂ©rifier `if (msg != nullptr)` - -## Organisation du code - -### Location des messages -``` -modules/shared/messages/ -├── IMessage.h # Interface pure -├── AMessage.h # Classe abstraite avec mĂ©tadata -├── MessageType.h # Enum des types -├── TankMovedMessage.h -├── PriceUpdatedMessage.h -└── ... -``` - -**Rationale:** -- Single source of truth (pas de duplication) -- Contrat partagĂ© entre Ă©metteur et rĂ©cepteur -- Facile Ă  trouver et maintenir - -### Validation - -**À la construction**: Invariants validĂ©s immĂ©diatement -- Vitesse nĂ©gative → exception -- ID invalide → exception -- Fail fast pour dĂ©tecter bugs tĂŽt - -**À la dĂ©sĂ©rialisation**: DonnĂ©es rĂ©seau/externes validĂ©es -- JSON malformĂ© → retourne nullptr -- Champs manquants → retourne nullptr -- ProtĂšge contre donnĂ©es corrompues - -## DĂ©cisions de design finalisĂ©es - -### Versioning - Breaking changes assumĂ©es - -**DĂ©cision:** Types versionnĂ©s avec breaking changes strictes - -Changement de format = nouveau type + nouvelle classe: -- `TANK_MOVED_V1` → `TANK_MOVED_V2` = types diffĂ©rents -- Pas de backward compatibility -- Pas de forward compatibility -- Migration forcĂ©e de tous les modules - -**Rationale:** -- ZĂ©ro ambiguĂŻtĂ© sur le format attendu -- Pas de logique conditionnelle complexe -- Hot-reload force mise Ă  jour synchronisĂ©e -- DĂ©tection immĂ©diate des incompatibilitĂ©s -- Code simple et clair - -**ConsĂ©quence:** -- Format change → tous modules doivent migrer -- Ancien code ne compile plus → migration manuelle obligatoire -- Breaking changes explicites et visibles - -### Message inheritance - AMessage obligatoire - -**DĂ©cision:** Classe abstraite `AMessage` avec mĂ©tadata immutables enforced - -Architecture: -``` -IMessage (interface pure) - ↓ -AMessage (classe abstraite - mĂ©tadata immutables) - ↓ -TankMovedMessage, PriceUpdatedMessage... (classes concrĂštes) -``` - -**Enforcement:** -- Constructeur `AMessage` protĂ©gĂ© → impossible de crĂ©er message sans passer par enfant -- MĂ©tadata const → immutables aprĂšs construction -- Tous messages garantis d'avoir timestamp/sender/messageId -- Format uniforme pour tous messages du systĂšme - -**Rationale:** -- Pas de duplication (mĂ©tadata dans AMessage) -- Impossible d'oublier mĂ©tadata -- Contrat strict et enforced au compile-time -- SimplicitĂ© pour messages concrets (mĂ©tadata automatique) - -## DĂ©cisions de design finalisĂ©es (suite) - -### Size limits - Fragmentation automatique par IO - -**DĂ©cision:** Pas de limite au niveau message, fragmentation automatique par couche transport - -**Architecture:** -- **Modules**: Publient/reçoivent messages complets (transparence totale) -- **IIO**: GĂšre fragmentation/dĂ©fragmentation automatiquement -- **Transport adaptatif**: Fragmentation si nĂ©cessaire selon type IO - -**Fragmentation par type:** -- **IntraIO**: Pas de fragmentation (copie mĂ©moire directe) -- **LocalIO**: Fragmentation si > seuil (ex: 64KB chunks) -- **NetworkIO**: Fragmentation si > MTU (~1500 bytes) - -**MĂ©canisme:** -1. Module publie message → sĂ©rialisĂ© en JSON -2. IO dĂ©tecte si taille > seuil transport -3. Si oui: dĂ©coupe en fragments avec `messageId` + `partId` -4. Transport des fragments -5. IO destination reassemble via `messageId` (collect tous `partId`) -6. Module reçoit message complet via `pullMessage()` - -**Robustesse:** -- **Packet loss**: Timeout si fragments incomplets (ex: 30s) -- **Ordering**: `partId` garantit ordre de reassemblage -- **Monitoring**: Log warning si message > 100KB (design smell probable) - -**ConsĂ©quence:** -- Messages peuvent ĂȘtre arbitrairement gros -- ComplexitĂ© cachĂ©e dans couche IO -- Performance optimisĂ©e par type de transport - -### Async handling - DĂ©lĂ©gation au module - -**DĂ©cision:** Pas de gestion async spĂ©ciale au niveau messages - -**Rationale:** -- Messages = transport de donnĂ©es uniquement -- `ITaskScheduler` existe dĂ©jĂ  pour opĂ©rations coĂ»teuses -- Module dĂ©cide si dĂ©lĂ©guer ou traiter directement -- Keep messages simple et stupid - -**ResponsabilitĂ©:** -- **Message**: Transport de donnĂ©es (aucune intelligence) -- **Module**: DĂ©cide de dĂ©lĂ©guer opĂ©rations coĂ»teuses au scheduler -- **ITaskScheduler**: GĂšre threading et async - -**Exemple:** -```cpp -// Module reçoit message dĂ©clenchant opĂ©ration coĂ»teuse -if (PathfindingRequestMessage* req = dynamic_cast<...>) { - // Module dĂ©lĂšgue au TaskScheduler - scheduler->scheduleTask(PATHFINDING_TASK, req->serialize()); - // Continue traitement autres messages -} - -// Plus tard, rĂ©cupĂšre rĂ©sultat -if (scheduler->hasCompletedTasks() > 0) { - TaskResult result = scheduler->getCompletedTask(); - // Publie rĂ©sultat via message -} -``` - -### Message ordering - Pas de garantie + Messages remplaçables - -**DĂ©cision:** Pas de garantie d'ordre, modules gĂšrent via timestamp si critique - -**Approche:** -- **Pas de FIFO enforced**: Messages peuvent arriver dans ordre arbitraire -- **Messages remplaçables par dĂ©faut**: `SubscriptionConfig.replaceable = true` pour majoritĂ© -- **Timestamp disponible**: `msg->getTimestamp()` permet tri manuel si nĂ©cessaire -- **UtilitĂ© questionnable**: Architecture modulaire rend ordre moins critique - -**Rationale:** -- Performance maximale (pas de garanties coĂ»teuses) -- Messages remplaçables optimisent bandwidth (garde juste dernier) -- Timestamp dans `AMessage` permet tri si vraiment nĂ©cessaire -- Architecture dĂ©couple les dĂ©pendances temporelles - -**Exemples d'usage:** -```cpp -// Prix - remplaçable (derniĂšre valeur suffit) -io->subscribeLowFreq("economy:*", {.replaceable = true}); - -// Tank position - remplaçable (position actuelle suffit) -io->subscribe("tank:*", {.replaceable = true}); - -// Events critiques - non remplaçable + tri si nĂ©cessaire -io->subscribe("combat:*", {.replaceable = false}); - -// Si ordre vraiment critique (rare) -std::vector messages = collectAllMessages(); -std::sort(messages.begin(), messages.end(), - [](const Message& a, const Message& b) { - return a.getTimestamp() < b.getTimestamp(); - }); -``` - -**ConsĂ©quence:** -- Modules ne doivent pas assumer ordre de rĂ©ception -- Messages remplaçables = derniĂšre valeur seulement -- Tri par timestamp disponible mais rarement nĂ©cessaire - -## Questions ouvertes - -Aucune question ouverte restante. Toutes les dĂ©cisions de design ont Ă©tĂ© finalisĂ©es. - -## Statut d'implĂ©mentation - -**Phase actuelle:** Design et documentation - -**Prochaines Ă©tapes:** -1. CrĂ©er interface `IMessage.h` -2. CrĂ©er classe abstraite `AMessage.h` avec mĂ©tadata immutables -3. CrĂ©er enum `MessageType.h` -4. ImplĂ©menter 5-10 messages d'exemple -5. Tester avec modules existants -6. ItĂ©rer selon usage rĂ©el - -## RĂ©fĂ©rences - -- `src/core/include/warfactory/IIO.h` - Couche pub/sub -- `docs/01-architecture/architecture-technique.md` - Patterns de communication -- `docs/03-implementation/CLAUDE-HOT-RELOAD-GUIDE.md` - Impact sur design messages diff --git a/docs/02-systems/systeme-militaire.md b/docs/02-systems/systeme-militaire.md deleted file mode 100644 index 7ff669a..0000000 --- a/docs/02-systems/systeme-militaire.md +++ /dev/null @@ -1,884 +0,0 @@ -# SystĂšme militaire - -## Conception de vĂ©hicules - -### SystĂšme de Frames -Une frame est une base sur laquelle on vient ajouter des composants dans une grille. Les frames ont des formes variĂ©es, rarement rectangulaires, avec des zones mortes et des emplacements d'overload spĂ©cifiques. - -#### Interface de Design -**Placement des Composants** : -- **Pick & Place** : Clic sur composant dans inventaire latĂ©ral, drag vers grille, clic pour placer -- **Snap automatique** : Alignement automatique sur grille avec feedback visuel -- **Rotations** : A/E pour tourner composants (standard PC gaming) -- **Snap toggle** : R pour dĂ©sactiver/activer l'alignement grille -- **Zones interdites** : Feedback visuel rouge pour placements impossibles -- **Templates** : Designs prĂ©-faits et patterns recommandĂ©s -- **Validation temps rĂ©el** : Contraintes (poids, Ă©nergie, etc.) vĂ©rifiĂ©es durant placement - -#### Anatomie d'un ChĂąssis -``` -Exemple: ChĂąssis "Griffon" (chenillĂ© moyen) - [X][O][O][O][O][X] X = Zone morte (non utilisable) - [X][●][●][●][●][●][●][X] ● = Zone standard - [●][●][●][●][●][●][●][●] ○ = Zone overload possible - [●][●][●][●][●][●][●][●] â–Č = Zone centrale (critique) - [●][●][â–Č][â–Č][â–Č][â–Č][●][●] ■ = Zone flanc (vulnĂ©rable) - [■][■][â–Č][â–Č][â–Č][â–Č][■][■] ╬ = Zone dĂ©connectĂ©e - [○][○][●][●][●][●][○][○] - [○][●][●][●][●][○] - -Exemple: ChĂąssis "Viper" modulaire (roues) - [●][●][●] [●][●][●] Zones dĂ©connectĂ©es - [●][â–Č][●] [●][â–Č][●] → Composants 3x3+ impossibles - [○][○][○] [○][○][○] → Chaque bloc autonome -``` - -**Zones spĂ©ciales** : -- **Zone centrale** : Composants critiques (moteur, IA principale) -- **Zones flanc** : +50% dĂ©gĂąts si touchĂ©es, Ă©viter composants vitaux -- **Zones mortes** : Cases bloquĂ©es par forme du chĂąssis -- **Zones overload** : Seuls endroits oĂč overload possible -- **Zones dĂ©connectĂ©es** : Blocs isolĂ©s, limitent taille composants - -### GĂ©nĂ©rations et Styles de ChĂąssis - -#### Concept de GĂ©nĂ©rations -- **Gen 1 (1960-1980)** : Robustes, simples, rĂ©parables sur le terrain -- **Gen 2 (1980-2000)** : Électronique basique, modularitĂ© Ă©mergente -- **Gen 3 (2000-2020)** : NumĂ©risation, composites, furtivitĂ© -- **Gen 4 (2020+)** : IA intĂ©grĂ©e, matĂ©riaux avancĂ©s, hybride/Ă©lectrique - -#### Styles Alternatifs & Originaux - -**ChĂąssis "Sloped" (inspirĂ© soviĂ©tique)** -- **Grille en losange** : 7x10 mais forme inclinĂ©e -- **Bonus** : -20% chance d'ĂȘtre touchĂ©, +15% ricochet -- **Malus** : Espace intĂ©rieur rĂ©duit, ergonomie difficile -- **Exemple** : ChĂąssis chenillĂ© sloped Gen2 - -**ChĂąssis "Boxy" (inspirĂ© occidental)** -- **Grille rectangulaire standard** : 8x12 optimisĂ© -- **Bonus** : +20% espace utilisable, maintenance facile -- **Malus** : Profile plus Ă©levĂ©, angles morts -- **Exemple** : ChĂąssis roues boxy Gen3 - -**ChĂąssis "Hexagonal" (expĂ©rimental)** -- **Grille hexagonale** : placement alternatif des composants -- **Bonus** : Synergies Ă  6 faces, rĂ©partition dĂ©gĂąts optimale -- **Malus** : CoĂ»t production +30%, complexitĂ© assemblage -- **Breakthrough requis** : "Advanced Geometry Manufacturing" - -**ChĂąssis "Modular Block" (futuriste)** -- **Grille segmentĂ©e** : 4 blocs de 3x3 non-connectĂ©s -- **Bonus** : Reconfiguration rapide sur le terrain -- **Malus** : Points faibles aux jonctions, composants >2x2 impossibles -- **Contrainte** : Chaque bloc isolĂ© → composants doivent tenir dans un bloc -- **SpĂ©cial** : Peut changer configuration selon mission mais perd cohĂ©sion - -**ChĂąssis "Organic" (bio-inspirĂ©)** -- **Grille courbe** : forme irrĂ©guliĂšre naturelle -- **Bonus** : Auto-rĂ©paration partielle, adaptation terrain -- **Malus** : Incompatible composants standards -- **Breakthrough requis** : "Biomimetic Engineering" - -#### ChĂąssis Terrestres NommĂ©s - -**Roues** -- **"Fennec"** (ultra-lĂ©ger Gen3) : Forme triangulaire 2x3, overload arriĂšre uniquement -- **"Coyote"** (lĂ©ger Gen2) : Forme hexagonale allongĂ©e, zones mortes avant -- **"Bison"** (moyen Gen3) : Rectangle avec coins coupĂ©s, flancs exposĂ©s -- **"Rhino"** (lourd Gen4) : Forme trapĂ©zoĂŻdale, zone centrale renforcĂ©e -- **"Viper"** (Desert Runner) : Profil serpentin, 3 zones overload isolĂ©es - -**Chenilles** -- **"Lynx"** (lĂ©ger Gen3) : Forme diamant, excellente rĂ©partition -- **"Griffon"** (moyen Gen2) : Octogone irrĂ©gulier, zones mortes avant/arriĂšre -- **"Mammoth"** (lourd Gen4) : Massif hexagonal, 8 zones overload pĂ©riphĂ©riques -- **"Badger"** (Gen1 Vintage) : Rectangle simple, pas de zones mortes -- **"Crocodile"** (Low Profile) : TrĂšs allongĂ©, zone centrale Ă©troite -- **"Otter"** (Amphibie) : Forme hydrodynamique, zones mortes latĂ©rales - -**Rails** -- **ChĂąssis locomotive** : 4x20 grille (moteur obligatoire) -- **ChĂąssis wagon lĂ©ger** : 4x12 grille -- **ChĂąssis wagon lourd** : 6x15 grille -- **ChĂąssis wagon plateforme** : 5x18 grille - -#### ChĂąssis AĂ©riens NommĂ©s - -**Volants lĂ©gers** -- **"Sparrow"** (quadcopter Gen3) : Croix parfaite, 4 moteurs aux extrĂ©mitĂ©s -- **"Wasp"** (hexacopter Gen4) : Forme Ă©toile, zones overload entre rotors -- **"Kestrel"** (lĂ©ger Gen2) : Forme T inversĂ©, zone centrale large -- **"Osprey"** (Tilt-Rotor) : Forme H, zones mortes centrales -- **"Raven"** (Stealth Copter) : Triangle noir, overload pointe avant uniquement - -**Volants moyens** -- **"Falcon"** (moyen Gen3) : Fusiforme classique, flancs vulnĂ©rables -- **"Eagle"** (Delta Wing) : Triangle parfait, pas de zones mortes -- **"Condor"** (Canard) : Forme X, 4 zones overload aux extrĂ©mitĂ©s -- **"Phantom"** (Flying Wing) : Aile pure, zone centrale minimale - -**Volants lourds** -- **"Albatross"** (lourd Gen3) : Forme cruciforme, soute centrale massive -- **"Pelican"** (transport Gen2) : Rectangle avec protubĂ©rance avant -- **"Vulture"** (trĂšs lourd Gen4) : Forme W, 6 zones overload rĂ©parties -- **"Leviathan"** (Ekranoplan) : Forme aplatie, zones mortes latĂ©rales massives -- **"Manta"** (Blended Body) : Ovale parfait, overload pĂ©riphĂ©rique uniquement - -#### ChĂąssis Navals NommĂ©s - -**Surface** -- **"Barracuda"** (ultra-lĂ©ger Gen3) : Forme effilĂ©e, overload proue uniquement -- **"Hammerhead"** (lĂ©ger Gen2) : Forme T, zone centrale Ă©largie avant -- **"Orca"** (moyen Gen3) : Fusiforme avec renflement central -- **"Neptune"** (Trimaran) : 3 coques parallĂšles, zones mortes entre coques -- **"Skimmer"** (Hydrofoil) : Forme V inversĂ©, zone centrale surĂ©levĂ©e -- **"Poseidon"** (SWATH) : Double coque immergĂ©e, pont Ă©troit -- **"Kraken"** (lourd Gen4) : Forme tentaculaire, 8 zones overload -- **"Behemoth"** (trĂšs lourd Gen3) : Hexagone massif, flancs exposĂ©s -- **"Atlas"** (plateforme Gen2) : Rectangle avec dĂ©coupes pour piste - -**Submersibles** -- **"Piranha"** (ultra-lĂ©ger Gen4) : Forme torpille pure -- **"Stingray"** (lĂ©ger Gen3) : Forme diamant aplati -- **"Nautilus"** (Teardrop) : Goutte parfaite, pas de zones mortes -- **"Typhoon"** (Double Hull) : Rectangulaire avec double paroi -- **"Triton"** (moyen Gen2) : Cylindrique classique, zones mortes avant/arriĂšre -- **"Abyss"** (lourd Gen3) : Forme bulbeuse, rĂ©sistance pression -- **"Mariana"** (Deep Dive) : SphĂšre allongĂ©e, overload minimal -- **"Colossus"** (trĂšs lourd Gen4) : Multi-segments, zones overload entre sections - -#### ChĂąssis Breakthrough Uniques - -**"Metamaterial Frame"** (tous domaines) -- **Grille adaptive** : Change de forme selon besoins -- **Breakthrough requis** : "Programmable Matter" -- **Bonus** : Reconfiguration temps rĂ©el -- **Malus** : CoĂ»t astronomique - -**"Plasma Shield Chassis"** (terrestre/naval) -- **Grille standard** + champ plasma -- **Breakthrough requis** : "Plasma Containment" -- **Bonus** : ImmunitĂ© projectiles cinĂ©tiques -- **Malus** : Consommation Ă©nergie massive - -**"Quantum Tunneling Frame"** (submersible uniquement) -- **Grille quantique** : 4x4 mais espace infini -- **Breakthrough requis** : "Applied Quantum Mechanics" -- **Bonus** : CapacitĂ© interne illimitĂ©e -- **Malus** : InstabilitĂ© dimensionnelle - -## Layers - -Les frames sont les bases de chaque layer d'un matĂ©riel. Cela peut varier en fonction de la base d'un matĂ©riel : le chĂąssis. - -**Ce qu'on peut construire avec les chĂąssis** : - -Le mĂȘme chĂąssis peut servir Ă  diffĂ©rents rĂŽles selon ce qu'on y installe : - -**ChĂąssis terrestre lĂ©ger Ă  roues** : -- Avec IA autonome → drone terrestre UGV -- Avec cabine pilote → camion de transport -- Avec blindage + mitrailleuse → vĂ©hicule de reconnaissance -- Avec compartiment personnel → transport de troupe lĂ©ger - -**ChĂąssis chenillĂ© moyen** : -- Avec canon 30mm + compartiment → IFV -- Avec blindage renforcĂ© + mitrailleuses → APC -- Avec canon 120mm → char lĂ©ger -- Avec Ă©quipement gĂ©nie → vĂ©hicule du gĂ©nie - -**ChĂąssis volant lĂ©ger** : -- Avec IA + camĂ©ra → drone de surveillance -- Avec cabine pilote → hĂ©licoptĂšre lĂ©ger -- Avec armement guidĂ© → drone kamikaze -- Avec compartiment mĂ©dical → Ă©vacuation sanitaire - -**ChĂąssis volant lourd** : -- Avec soute Ă  bombes → bombardier -- Avec compartiment cargo → transport -- Avec radar + missiles → intercepteur -- Avec Ă©quipement guerre Ă©lectronique → AWACS - -**ChĂąssis naval moyen** : -- Avec hĂ©lipad → frĂ©gate ASW -- Avec VLS → destroyer -- Avec canons → croiseur lĂ©ger -- Avec IA autonome → drone naval USV - -**ChĂąssis submersible** : -- Avec torpilles → sous-marin d'attaque -- Avec missiles balistiques → SSBN -- Avec compartiment cargo → transport furtif -- Avec IA + capteurs → UUV de reconnaissance - -### 3 Layers principaux -1. **ChĂąssis** (mobilitĂ©, armure, structure) -2. **SystĂšmes** (IA, transmetteurs, radiateurs, Ă©lectronique) -3. **Armes & Capteurs** (optiques, canons, radars, ERA) - -## Composants - -Les composants sont les Ă©lĂ©ments qui sont placĂ©s dans les frames. Ils ont des formes variĂ©es, rarement carrĂ©es et jamais 1x1. - -### DiversitĂ© Massive de Composants - -**Principe** : Des centaines de composants uniques, chacun avec forme, taille et caractĂ©ristiques propres. - -#### Exemples Layer ChĂąssis -``` -Moteur Diesel Compact Moteur V8 Racing Turbine Jet - [█][█] [█] [█] [█][█][█] - [█] [█][█][█] [█][█][█] - [█] [█] - -Suspension Active RĂ©servoir Principal Transmission CVT -[█] [█] [█][█][█][█] [█] - [█] [█][█][█][█] [█][█][█] -[█] [█] [█][█][█][█] [█] - -Blindage NERA Cage Survie Flotteurs Amphibie -[█][█][█][█][█] [█] [█] [█][█] [█][█] -[█][█][█][█][█] [█][█] [█] [█] -``` - -#### Exemples Layer SystĂšmes -``` -CPU Basique IA Tactique v3 Quantum Processor -[█][█] [█][█][█] [█] - [█][█][█] [█][█][█] - [█] [█] - -Radio HF SystĂšme AEGIS ECM Suite -[█] [█] [█][█][█][█] -[█] [█][█][█] [█][█][█][█] -[█] [█][█][█] - -Cooling Liquid Heat Pump Radiateur GraphĂšne -[█][█][█] [█][█] [█] [█] - [█] [█] [█] -``` - -#### Exemples Layer Armes & Capteurs -``` -Canon 30mm Missile VLS Railgun Exp. -[█] [█][█] [█] -[█] [█][█] [█] -[█] [█][█] [█] - [█][█] [█] - [█] - -Optique x10 Radar AESA Sonar Passif -[█] [█][█][█][█] [█][█] - [█] [█][█] - -ERA Block Trophy APS Laser CIWS -[█] [█] [█] [█][█] - [█][█] [█][█] - [█] [█] [█][█] -``` - -**Formes communes** : -- **Forme L** : Radiateurs, tuyaux cooling (2x2 en L) -- **Forme T** : SystĂšmes de distribution Ă©nergie (3x2 en T) -- **Forme I** : Canons, missiles (1x3, 1x4, 1x5) -- **Forme Z** : Composants Ă©lectroniques complexes -- **Forme +** : Hubs de connexion, joints universels -- **Forme Rectangle** : Blindage, batteries (2x3, 2x4, jamais carrĂ©) - -**Tailles minimales** : -- **Exceptions 1x1** : ERA blocks, capteurs basiques (seuls composants 1x1) -- **Plus petit standard** : 1x2 (optiques simples) -- **Standard petit** : 2x2 en forme L ou 1x3 -- **Standard moyen** : 2x3, 3x2, formes irrĂ©guliĂšres -- **Gros composants** : 3x4+, souvent formes complexes - -### Explosion de Variantes par Technologie - -**Principe** : Une seule tech dĂ©bloque 5-15 variantes adaptĂ©es aux diffĂ©rents usages - -#### Exemple : Tech "Autocannon Gen3" dĂ©bloque : -``` -25mm Chain Gun 30mm Bushmaster 35mm Oerlikon -[█] [█] [█][█] -[█] [█] [█][█] -[█] [█] [█][█] - [█] - -40mm Bofors CT 20mm Gatling 30mm Coaxial -[█][█] [█][█][█] [█] -[█][█] [█] [█] -[█][█] -``` -- **25mm** : LĂ©ger pour IFV rapides (forme I mince) -- **30mm** : Standard IFV/APC (forme I standard) -- **35mm** : Anti-aĂ©rien (forme rectangle) -- **40mm** : Support lourd (forme L) -- **20mm Gatling** : Haute cadence (forme T) -- **30mm Coaxial** : Compact pour tourelle (forme courte) - -#### Exemple : Tech "Composite Armor v2" dĂ©bloque : -``` -NERA Light (IFV) Chobham Standard Dorchester Heavy -[█][█][█] [█][█][█][█] [█][█][█][█][█] - [█][█][█][█] [█][█][█][█][█] - [█][█][█][█][█] - -Cage Armor Slat Kit AppliquĂ© Module -[█] [█] [█] ═══════ [█][█] -[█] [█] [█] ═══════ [█][█] - ═══════ [█] -``` - -#### Variations par GĂ©nĂ©ration - -**Gen 1 (1960s)** : Formes simples, robustes -- Canon 105mm L7 → 3 variantes (standard, court, long) -- Moteur diesel basique → 2 variantes (truck, tank) - -**Gen 2 (1980s)** : Diversification -- Canon 120mm smoothbore → 6 variantes (L44, L55, compact, etc.) -- Moteur turbodiesel → 5 variantes (power/efficiency trade-offs) - -**Gen 3 (2000s)** : SpĂ©cialisation -- Canon 120mm advanced → 10 variantes (urban, long-range, autoloader, etc.) -- Moteur hybride → 8 variantes (diesel-electric, turbine-electric, etc.) - -**Gen 4 (2020s)** : Explosion des options -- Railgun experimental → 12 variantes (energy levels, sizes, cooling) -- Moteur full-electric → 15 variantes (battery types, power outputs) - -#### Impact sur le Gameplay - -**Pour le Joueur** : -- Une tech = choix stratĂ©giques multiples -- Optimisation selon doctrine (speed vs armor vs firepower) -- Mix & match pour designs uniques - -**Pour l'IA** : -- Companies dĂ©veloppent prĂ©fĂ©rences (Rheinmetall → gros canons) -- Évolution designs selon retours terrain -- Émergence de "schools of thought" rĂ©gionales - -**Total avec variations** : -- ~100 technologies principales -- × 5-15 variantes chacune -- = **1000-1500 composants rĂ©els dans le jeu** - -**RĂšgles d'exclusivitĂ©** : -- Composants gĂ©nĂ©ralement exclusifs par layer -- **Exception** : Certains composants de protection peuvent ĂȘtre partagĂ©s entre layers - -### SystĂšme d'AmĂ©lioration GĂ©nĂ©rique - -**Principe** : AmĂ©liorations universelles applicables Ă  toute catĂ©gorie d'Ă©quipement, stackables Ă  l'infini avec rendements dĂ©croissants. - -#### AmĂ©liorations Universelles par CatĂ©gorie - -**Pour TOUTES les Armes** : -- **High ROF** : Cadence de tir +X%, chaleur +40% (non rĂ©duit) -- **High Velocity** : Vitesse projectile +X%, recul +30% -- **Match Grade** : PrĂ©cision +X%, temps production +50% -- **Extended Barrel** : PortĂ©e +X%, poids +20% -- **Reliability** : MTBF +X%, coĂ»t maintenance -30% - -**Pour TOUS les Moteurs** : -- **Turbo** : Puissance +X%, conso fuel +50%, chaleur +40% -- **Efficiency** : Conso fuel -X%, puissance -15% -- **High Torque** : Couple +X%, vitesse max -20% -- **Reliability** : DurabilitĂ© +X%, performance -10% - -**Pour TOUS les SystĂšmes** : -- **Overclocking** : Performance +X%, Ă©lec +60%, chaleur +50% -- **Efficiency** : Conso Ă©lec -X%, performance -20% -- **Redundancy** : FiabilitĂ© +X%, poids +30% -- **Miniaturization** : Poids -X%, coĂ»t +40% - -#### Formule de Stacking - -``` -Bonus effectif = Bonus_base × (1/2)^(n-1) -oĂč n = nombre de fois appliquĂ© - -Exemple High ROF: -1er: +20% ROF (120% total) -2e: +10% ROF (130% total) -3e: +5% ROF (135% total) -4e: +2.5% ROF (137.5% total) - -Malus: TOUJOURS COMPLET -1er: +40% chaleur -2e: +40% chaleur (80% total!) -3e: +40% chaleur (120% total!!) -4e: +40% chaleur (160% total!!!) - -CoĂ»t: Exponentiel modĂ©rĂ© -CoĂ»t_final = CoĂ»t_base × 1.25^n -1 amĂ©lio: ×1.25 -2 amĂ©lios: ×1.56 -3 amĂ©lios: ×1.95 -4 amĂ©lios: ×2.44 -``` - -**SpĂ©cialisation** (bonus contextuel): -- **Arctic Package** : Fonctionne Ă  -60°C, +15% coĂ»t -- **Desert Sealing** : ImmunitĂ© sable, +20% coĂ»t -- **Urban Kit** : +30% rotation tourelle, -10% armure top -- **Naval Coating** : Anti-corrosion marine, +25% coĂ»t - -#### Exemple Concret : Canon 30mm avec Multi-Stack - -**Base** : -- 30mm Autocannon : 600 RPM, 100 damage, chaleur 50 - -**Application de 3× High ROF** : -``` -Stack 1: +20% ROF → 720 RPM, chaleur +40% (70 total) -Stack 2: +10% ROF → 792 RPM, chaleur +40% (90 total) -Stack 3: +5% ROF → 831 RPM, chaleur +40% (110 total) - -CoĂ»t: 100 × 1.25Âł = 195 unitĂ©s -RĂ©sultat: 831 RPM mais chaleur ×2.2! -``` - -**Application mixte (ROF + Velocity + Reliability)** : -``` -High ROF: +20% cadence, +40% chaleur -High Velocity: +20% dĂ©gĂąts, +30% recul -Reliability ×2: +20% MTBF puis +10% MTBF - -CoĂ»t: 100 × 1.25⁎ = 244 unitĂ©s -RĂ©sultat: Arme polyvalente mais trĂšs chĂšre -``` - -#### Exemples ExtrĂȘmes de Stacking - -**"Chaingun of Doom" (6× High ROF)** : -``` -Base: 600 RPM, 50 chaleur -Final: 945 RPM, 290 chaleur (!!) -CoĂ»t: ×3.81 -→ NĂ©cessite systĂšme cooling dĂ©diĂ© Ă©norme -``` - -**"Eco Motor" (4× Efficiency)** : -``` -Base: 50L/100km, 300hp -Final: 31L/100km, 195hp (-35% perf totale!) -CoĂ»t: ×2.44 -→ Autonomie excellente, performance mĂ©diocre -``` - -**"Glass Cannon Railgun" (ROF×3 + Velocity×3)** : -``` -Base: 1000 damage, 10s reload, 500kW -Final: 1350 damage, 6.5s reload -Chaleur: +120%, Recul: +90%, Élec: 500kW -CoĂ»t: ×4.77 -→ DPS massif mais ingĂ©rable sans support -``` - -#### RĂšgles de Stacking - -**Pas de limite** au nombre d'amĂ©liorations : -- Stack mĂȘme amĂ©lioration = rendements dĂ©croissants -- Mix diffĂ©rentes amĂ©lios = synergie ou conflits -- **Forme reste IDENTIQUE** peu importe le stack -- Malus s'accumulent linĂ©airement (danger!) - -### AmĂ©lioration de ChĂąssis - -**Principe** : Les chĂąssis peuvent aussi ĂȘtre amĂ©liorĂ©s mais avec coĂ»ts exponentiels et nouvelles ressources requises. - -#### AmĂ©liorations ChĂąssis SpĂ©cifiques - -**ChĂąssis "Griffon" Gen2 (base)** : -``` -Base: 100 Steel -Forme: Octogone 8x14, zones mortes standard - -+1 amĂ©lio: 125 Steel + 20 Composite -+2 amĂ©lios: 156 Steel + 40 Composite + 15 Titanium -+3 amĂ©lios: 195 Steel + 80 Composite + 35 Titanium -+4 amĂ©lios: 244 Steel + 160 Composite + 65 Titanium + 10 Ceramics -+5 amĂ©lios: 305 Steel + 320 Composite + 120 Titanium + 25 Ceramics -``` - -**Types d'amĂ©liorations chĂąssis** : -- **Reinforced Structure** : +30% HP, +20% poids -- **Lightweight Frame** : -25% poids, -15% protection, +coĂ»t -- **Extended Grid** : +2 cases overload possibles -- **Improved Geometry** : -1 zone morte, +coĂ»t massif -- **Modular Mounting** : +1 zone centrale (critique → standard) -- **Composite Upgrade** : +20% rĂ©sistance, +nouvelles ressources - -#### Exemples Concrets - -**"Griffon" Enhanced (3 amĂ©lios)** : -``` -Base form: [X]●●●●[X] - ●●●●●●●● - ●â–Čâ–Čâ–Čâ–Č●● - ■■â–Čâ–Čâ–Čâ–Č■■ - -Enhanced: [O]●●●●[O] (+Extended Grid) - ●●●●●●●● - ●â–Čâ–Čâ–Čâ–Čâ–Č●● (+Modular Mounting) - ■●â–Čâ–Čâ–Čâ–Č●■ (+Improved Geometry) - -CoĂ»t: 195 Steel + 80 Composite + 35 Titanium -Bonus: +2 overload zones, +1 centrale, -2 zones mortes -``` - -**"Lynx" Ultra-Light (4 amĂ©lios)** : -``` -4× Lightweight Frame stacked: --25%, -12.5%, -6.25%, -3.125% = -43% poids total --15%, -15%, -15%, -15% = -60% protection!! - -CoĂ»t: 244 Steel + 160 Composite + 65 Titanium + 10 Ceramics -RĂ©sultat: ChĂąssis papier mais ultra-rapide -``` - -#### Ressources AvancĂ©es Requises - -**Composite Materials** : -- Requis pour amĂ©liorations chĂąssis moyennes -- Production complexe (Carbon + Resin + Pressure) - -**Titanium** : -- ChĂąssis haute performance -- Ressource rare, extraction difficile - -**Ceramics** : -- AmĂ©liorations extrĂȘmes (5+ stacks) -- Tech trĂšs avancĂ©e requise - -**Metamaterials** : -- AmĂ©liorations breakthrough uniquement -- CoĂ»ts astronomiques - -#### Impact Économique - -**Escalade des coĂ»ts** : -- ChĂąssis Gen1 amĂ©liorĂ© peut coĂ»ter plus qu'un Gen4 standard -- Nouvelles supply chains requises (Titanium, Ceramics) -- Choix stratĂ©gique : few super-chĂąssis vs many standard - -**Trade-offs** : -- ChĂąssis perfect = 90% du budget vĂ©hicule -- Reste peu pour composants advanced -- Peut valoir le coup pour designs spĂ©cialisĂ©s - -**Impact StratĂ©gique** : -- Components peuvent devenir **ultra-spĂ©cialisĂ©s** -- ChĂąssis custom = signature builds -- Stack moderĂ© = optimal, stack extrĂȘme = niche -- NĂ©cessite blueprints pour gĂ©rer complexitĂ© -- **Ressources tier-2** deviennent critiques - -#### ConsĂ©quences SystĂšme - -**ProblĂšmes en cascade** : -- Canon overclocked → +80% chaleur → besoin 2x radiateurs -- Moteur racing → +100% fuel → rĂ©servoirs plus gros ou autonomie divisĂ©e -- IA overclocked → +60% Ă©lec → gĂ©nĂ©rateur supplĂ©mentaire requis -- Tout overclock → systĂšme cooling peut saturer → shutdown combat - -**Choix tactiques** : -- Full performance = logistique cauchemar (fuel, maintenance) -- EfficacitĂ© max = performance mĂ©diocre mais autonomie -- Balance = compromis selon doctrine - -#### Impact sur le Meta - -**Designs uniques** : -- MĂȘme avec composants identiques, deux vĂ©hicules jamais pareils -- Companies IA ont prĂ©fĂ©rences d'amĂ©lioration selon features -- Joueur peut crĂ©er designs signature - -**Trade-offs stratĂ©giques** : -- Performance maximale vs coĂ»t raisonnable -- SpĂ©cialisation vs polyvalence -- Production rapide vs qualitĂ© optimale - -**Total possibilitĂ©s** : -- 1500 composants de base -- × 5-10 amĂ©liorations possibles chacun -- × Combinaisons de 1-3 amĂ©liorations -- = **Millions de variantes possibles** - -### SystĂšme de Blueprints Multi-Échelles - -**Principe** : Sauvegarder et rĂ©utiliser des designs Ă  toutes les Ă©chelles, du composant au vĂ©hicule complet. - -#### Niveaux de Blueprints - -**1. Micro-Blueprints (Arrangements de composants)** -``` -"Power Module v3" (4x3 sauvegardĂ©) -[Motor][Motor][Radiator] -[Motor][Motor][Battery ] -[Trans][Trans][Battery ] -[Trans][Trans][Generator] - -→ RĂ©utilisable dans tous mes designs futurs -``` - -**2. Layer Blueprints (Layer complet)** -``` -"ChĂąssis Standard IFV" (Layer 1 complet) -- Arrangement moteur/transmission testĂ© -- Blindage optimisĂ© zones critiques -- Suspension Ă©quilibrĂ©e -→ Compatible avec chĂąssis "Lynx", "Griffon", etc. -``` - -**3. SystĂšme Blueprints (3 layers combinĂ©s)** -``` -"Urban Fighter Mk2" (SystĂšme complet) -- Layer 1: ChĂąssis mobilitĂ© urbaine -- Layer 2: SystĂšmes com/cooling optimisĂ©s -- Layer 3: Armes courte portĂ©e + APS -→ Adaptable Ă  diffĂ©rents chĂąssis de mĂȘme classe -``` - -**4. VĂ©hicule Blueprint (Design final)** -``` -"Viper AT-4" (VĂ©hicule complet) -- ChĂąssis: "Desert Runner" Gen3 -- SystĂšme: "Tank Hunter v5" -- AmĂ©liorations: Tous les overclocks -→ Production directe en usine -``` - -#### Gestion et Partage - -**Organisation personnelle** : -``` -Mes Blueprints/ -├── Micro/ -│ ├── Power/ -│ │ ├── Compact_Power_2x3.bp -│ │ └── Racing_Power_4x3.bp -│ ├── Weapons/ -│ │ └── AT_Combo_3x4.bp -│ └── Cooling/ -│ └── Max_Cool_2x4.bp -├── Layers/ -│ ├── ChĂąssis_Speed.bp -│ └── SystĂšme_Overclocked.bp -├── SystĂšmes/ -│ └── Glass_Cannon_Full.bp -└── VĂ©hicules/ - ├── MBT_Fortress.bp - └── IFV_Swarm.bp -``` - -**Partage communautaire** : -- **Export/Import** : Fichiers .bp partageables -- **Workshop** : Blueprints notĂ©s par la communautĂ© -- **Company Blueprints** : IA companies ont leurs propres bibliothĂšques -- **Évolution** : Blueprints peuvent ĂȘtre fork et modifiĂ©s - -#### Adaptation et CompatibilitĂ© - -**Micro → Universel** : -- Module 4x3 fonctionne dans tout chĂąssis avec 4x3 libre -- Rotation/miroir automatique possible -- Alerte si incompatible (forme/taille) - -**Layer → Semi-flexible** : -- AdaptĂ© aux chĂąssis de mĂȘme gĂ©nĂ©ration/style -- Ajustements mineurs automatiques possibles -- Warning si sub-optimal - -**SystĂšme → Contraintes** : -- Besoin chĂąssis compatible (taille/forme similaire) -- Peut nĂ©cessiter adaptations manuelles -- Preview montre conflits potentiels - -#### Interface de Blueprint - -``` -[Conception VĂ©hicule] -┌─────────────────────┬────────────────┐ -│ Grille Active │ Blueprints │ -│ │ ┌Favoris──────┐│ -│ [Current Design] │ │☆ Power v3 ││ -│ │ │☆ AT Combo ││ -│ [Drag Blueprint→] │ │☆ Cool Max ││ -│ │ └──────────────┘│ -│ │ ┌Recent───────┐│ -│ │ │ IFV Urban ││ -│ [Drop Zone] │ │ Tank Rush ││ -│ │ └──────────────┘│ -└─────────────────────┮────────────────┘ - -[Save Current as Blueprint] -Type: [Micro|Layer|System|Vehicle] -Name: [_________________] -Tags: [Urban][Speed][Gen3] -``` - -#### MĂ©ta-Évolution - -**ItĂ©ration rapide** : -1. Design initial → test combat -2. Identifier module problĂ©matique -3. Remplacer juste ce module via micro-blueprint -4. Re-test → save nouvelle version - -**LignĂ©es de designs** : -``` -MBT_Heavy_v1 (original) -├── MBT_Heavy_v2 (cooling fix) -├── MBT_Heavy_Urban (fork urbain) -│ └── MBT_Heavy_Urban_ERA (+ protection) -└── MBT_Heavy_Desert (fork dĂ©sert) - └── MBT_Heavy_Desert_Eco (- conso) -``` - -**Impact stratĂ©gique** : -- Designs Ă©prouvĂ©s deviennent "meta" -- Companies dĂ©veloppent styles signature -- Joueur accumule bibliothĂšque personnelle -- Transfert de savoir entre parties - -### Synergies -Il est important de mettre en place une synergie entre certains composants pour que leur contact dans la grille les rende plus efficaces. - -**Types de synergies** : -1. **Synergie existentielle** : composants simplement prĂ©sents dans la mĂȘme frame -2. **Synergie couplĂ©e** : composants se touchent au moins une fois en un point -3. **Synergie de contact Ă©tendue** : composants se touchent le plus possible pour obtenir le plus gros bonus - - Calcul par nombre de faces adjacentes - - Visualisation : highlight des faces en contact avec micro-animation brillante - -### SystĂšmes spĂ©ciaux - -**TempĂ©rature** : -- **Sources de chaleur** : Puces IA dans layer systĂšmes, armes (railgun, canons) -- **Gestion** : Radiateurs dans layer systĂšmes pour refroidissement -- **SystĂšme dynamique** : Heat accumulation en temps rĂ©el selon utilisation -- **Overload system** : PossibilitĂ© de dĂ©passer seuil thermique contre dĂ©gĂąts -- **Gestion IA** : IA combat gĂšre automatiquement la tempĂ©rature (pas le joueur) -- **Balance** : Avantage joueur contrebalancĂ© par contraintes thermiques - -**QualitĂ© d'assemblage** : -- **Conception** : Design "parfait" dans l'interface de conception -- **Production** : RĂ©duction qualitĂ© lors de l'assemblage automatique si placement non-optimal -- **SystĂšmes optimisables** : Chaque systĂšme peut ĂȘtre optimisĂ© (pas de plan unique) -- **Designs OP** : Existence de designs/assemblages optimaux dĂ©couvrables -- **Erreurs placement** : RĂ©duisent qualitĂ© du systĂšme final -- **Upgrades bras** : Bras meilleure prĂ©cision + bras de "lob" pour composants -- **RĂšgle** : Penser Ă  l'assemblage dĂšs la conception pour Ă©viter pĂ©nalitĂ©s - -**ChĂąssis Overload** : -- **Principe** : PossibilitĂ© d'ajouter cases de conception au-delĂ  des limites initiales -- **Limites** : Nombre max de cases d'overload dĂ©fini par chĂąssis + tech dĂ©blocables -- **ChĂąssis diffĂ©renciĂ©s** : Certains chĂąssis plus "overload-friendly" que d'autres -- **PĂ©nalitĂ©s linĂ©aires** par chĂąssis : malus % sur fiabilitĂ©, vitesse, cooling, poids -- **ConsĂ©quences cascade** : - - Poids Ă©levĂ© → terrains impraticables, trains solides requis - - Cooling rĂ©duit → surchauffe plus rapide - - FiabilitĂ© rĂ©duite → maintenance accrue -- **Timing** : Overload recommandĂ© lors des refits (pas conception initiale) -- **IA tactique** : SĂ©lection vĂ©hicules selon mission (haut risque = overloadĂ©s) -- **CoĂ»t rĂ©el** : Prix production des composants avancĂ©s (recherche) -- **Compensation** : Nouveaux composants tech compensent partiellement malus -- **Encouragement cycle armes** : Armes Ă©voluent petit→moyen→gros, forçant overload ou chĂąssis lourds - -**Maintenance & Refit** : -- **Usure progressive** : Barrels d'armes deviennent inutilisables aprĂšs usage intensif -- **Maintenance prĂ©ventive** : Remplacement composants usĂ©s avant panne -- **Refit modifications** : Ajouter ERA, changer canon, upgrade composants -- **Usine obligatoire** : retour en usine pour modifications majeures -- **Usines de terrain** : maintenance basique et rĂ©parations d'urgence -- **PiĂšces de rechange** : Stock et logistique des composants critiques - -## Valeurs des vĂ©hicules - -### Valeurs par Ă©lĂ©ment -- **Armure** (int) -- **HP** (int) -- **Profile** (int) - -### Valeurs globales -- **HP** (int) -- **Multidmg aĂ©rien** (double) - armure du toit -- **Multidmg rear** (double) - armure arriĂšre -- **Multiatk flank** (double) -- **Turret down is vehicule down** (bool) -- **Vmax** (int) -- **AccĂ©lĂ©ration** (int) -- **PrĂ©cision de tir** (double) -- **PrĂ©cision de visĂ©e** (double) -- **Profile total** (int) -- **Reliability** (int %) - -## Techniques de l'armĂ©e - -### CatĂ©gories d'unitĂ©s -*Tous les aspects doivent ĂȘtre applicables Ă  toutes les factions* - -**Infanterie** : -- UnitĂ© d'occupation de terrain -- Puissante par ses capacitĂ©s polyvalentes et sa discrĂ©tion naturelle - -**VĂ©hicule de transport** : -- Transport de troupe, transport logistique, medevac -- Gamme : camion → M113 - -**IFV** : -- Doit ĂȘtre capable de transporter du personnel -- Exemple : Merkava comme IFV - -**MBT** : Char de bataille principal - -**Missiles** : -- Munition capable de se diriger -- Inclut artillerie guidĂ©e -- Missiles stratĂ©giques : SCALP, Tomahawk -- Drones kamikaze stratĂ©giques : Shahed -- Drones FPV ukrainiens - -**Drone copter** - -**HĂ©licoptĂšre** : moteur "unique" mais lourd - -**Jet lĂ©ger** : un moteur - -**Jet lourd** : deux moteurs - -**Transport aĂ©rien** - -**Bombardier lourd** : 3+ moteurs - -## IA militaire - -### PrĂ©vention des glitches -Il vaut mieux Ă©viter qu'on puisse glitcher l'IA, et surtout de maniĂšre Ă©ternelle. - -**Exemple de timeout sur pathfinding** : -1. IASystem give : "Soldat go to B (point A vers B)" -2. GameServer : "copy timeout is 30tick" -3. GameServer in 30ticks fails to move to the point -4. GameServer : "Soldat pathfinding failed from A to B" -5. IASystem : "Soldat go to C" (position de C totalement diffĂ©rente) - -**ProblĂšme** : Si le soldat est bloquĂ© de tous les cĂŽtĂ©s → proposer la destruction des obstacles ? - -## Performance Combat Server - -### Gestion de milliers d'unitĂ©s -- **Adaptive tick rate** : 60→15 TPS sous charge -- **Simulation temps rĂ©el** complexe -- **Batailles massives** : 10k unitĂ©s = 30 secondes de traitement -- **Background processing** : player continue autres tĂąches pendant combats - -### Architecture performance -- **Langages** : C++/C/ASM pour calculs critiques -- **Scope Ă©tendu** : Infantry, vĂ©hicules, aviation, missiles, logistique militaire -- **Actions normales** intĂ©grĂ©es : assaut, reconnaissance, soutien, etc. \ No newline at end of file diff --git a/docs/03-implementation/configuration/transport-economic-system.md b/docs/03-implementation/configuration/transport-economic-system.md deleted file mode 100644 index 9783e42..0000000 --- a/docs/03-implementation/configuration/transport-economic-system.md +++ /dev/null @@ -1,549 +0,0 @@ -# Rapport : SystĂšme Transport & Économique - -## 🚛 Architecture Transport System - -### Transport Mode Hierarchy - -**Selection Cascade basĂ©e sur optimisation Ă©conomique pure** : - -``` -Decision Tree (Cost Optimization) - Points 90-95: -1. Volume ≄ 1000t + Port Access → Ship (0.10€/kg) -2. Else + Rail Access → Train (0.50€/kg) -3. Else + Airport Access → Air (2.00€/kg) -4. Else → Truck (5.00€/kg) - -Storage Cost: €0.02/kg/day -Delivery Times: Ship 14j, Train 3j, Air 1j, Truck 2j -Ship Volume Threshold: ≄1000 tonnes minimum - -Pas de facteur urgency - pure economic optimization -``` - -#### Justification Économique -- **CoĂ»t maritime** : 50x moins cher que camion (Ă©conomies d'Ă©chelle massives) -- **Seuil volume** : 1000 tonnes nĂ©cessaire pour rentabiliser navire -- **Infrastructure binaire** : Access ou pas access, pas de gradients -- **Simplification dĂ©cisionnelle** : Arbre de dĂ©cision clair pour IA - -### Infrastructure Access Binary - -**PropriĂ©tĂ©s gĂ©ographiques des entreprises** : - -```cpp -struct CompanyLocation { - bool hasPortAccess = false; // Access maritime - bool hasRailAccess = false; // Access ferroviaire - bool hasAirportAccess = false; // Access aĂ©rien - bool alwaysTruckAccess = true; // Camion toujours disponible - - float transportMultiplier() { - // Geographic competitive advantage - return hasPortAccess ? 0.10f : - hasRailAccess ? 0.50f : - hasAirportAccess ? 2.00f : 5.00f; - } -}; -``` - -#### Avantage Concurrentiel GĂ©ographique -- **Coastal locations** : Avantage Ă©conomique structurel -- **Inland accessible par rail** : Compromis coĂ»t/accessibilitĂ© -- **Remote locations** : CoĂ»t transport Ă©levĂ© = premium prices -- **Strategic positioning** : Infrastructure access = competitive moat - -## 📊 Market Mechanics - -### Order System (Passes Économiques) - -**Phases Ă©conomiques sĂ©quentielles** : - -``` -Economic Cycle (24h): -1. Offer Phase (6h): Producers submit sell orders -2. Demand Phase (6h): Consumers submit buy orders -3. Market Clearing (1h): Price discovery & matching -4. Transport Assignment (1h): Mode selection per transaction -5. Execution Phase (10h): Delivery + payment processing - -Order Stacking Strategy: -├─ Multiple sellers combine orders during Offer Phase -├─ Volume aggregation unlock ship transport thresholds -├─ Waiting mechanism incentivizes collaboration -├─ Economic pressure creates natural cooperation -``` - -#### Benefits SystĂšme Passes -- **Price discovery efficient** : Concentration temporelle des Ă©changes -- **Volume optimization** : Incitation Ă  collaboration pour seuils -- **Market transparency** : Informations disponibles pour tous -- **Strategic timing** : Players peuvent anticiper cycles - -### Dynamic Pricing Mechanism - -**Formation des prix multi-facteurs** : - -```cpp -class PriceFormation { - float calculatePrice(Good good, Region region) { - float basePrice = supplyDemandEquilibrium(good); - float transportPremium = calculateTransportCosts(region); - float scarcityMultiplier = getScarcityPressure(good, region); - float regionGradient = getRegionalPriceGradient(good, region); - - return basePrice * (1 + transportPremium + scarcityMultiplier + regionGradient); - } -}; -``` - -#### Price Formation Components - -##### Base Price (Supply/Demand Equilibrium) -- **Market clearing price** : Intersection offre/demande -- **Global reference** : Prix de base mondial -- **Volatility buffer** : MĂ©canismes anti-manipulation - -##### Transport Cost Limits (Buyer-Defined) -- **Maximum transport %** : Buyers set acceptable transport cost ratio -- **Example** : "Transport max 15% of goods value" -- **Market filtering** : Orders rejected if transport too expensive -- **Geographic arbitrage limits** : Natural price convergence mechanism - -##### Scarcity Premium (Desperation Bidding) -- **Stock depletion** : Companies with low inventory bid premium -- **Regional shortages** : Isolated regions pay survival premiums -- **Urgent orders** : Rush delivery commands price multipliers -- **Market psychology** : Fear of shortage drives irrational bidding - -##### Regional Price Gradients (Geographic Arbitrage) -``` -Price Examples (Iron): -├─ Coastal Region: 10€/kg (baseline + ship transport) -├─ Rail Accessible: 11€/kg (baseline + rail premium) -├─ Airport Only: 20€/kg (baseline + air premium) -├─ Remote Truck: 50€/kg (baseline + truck premium + scarcity) -``` - -## đŸ—ïž Storage & Inventory System - -### Company Storage Strategy - -**Adaptive Inventory Management basĂ©e sur niveaux de stock** : - -```cpp -enum InventoryStrategy { - DESPERATE, // Stock < 20% → Premium bidding - NORMAL, // Stock 20-50% → Market price buying - CAUTIOUS, // Stock 50-80% → Opportunistic buying only - OVERSUPPLIED // Stock > 80% → Stop purchasing -}; - -class InventoryManager { - PurchaseDecision evaluate(float stockLevel, float marketPrice) { - if(stockLevel < 0.20f) return {true, marketPrice * 1.5f}; // Desperate - if(stockLevel < 0.50f) return {true, marketPrice}; // Normal - if(stockLevel < 0.80f) return {false, marketPrice * 0.8f}; // Opportunistic - return {false, 0.0f}; // Stop buying - } -}; -``` - -#### Inventory Trade-offs -- **Large inventory** : Security vs storage costs (€0.02/kg/day) -- **Small inventory** : Lower costs vs supply chain risk -- **Timing optimization** : Buy during market oversupply -- **Geographic arbitrage** : Coastal storage → Inland distribution - -### Bulk Purchase Cycles - -**Natural market pulse patterns** : - -``` -Market Cycle Pattern: -1. Multiple companies hit 20% stock simultaneously -2. Competing desperate bids create price spikes -3. Large combined volumes enable ship transport unlock -4. Price normalization as inventory restored -5. Market oversupply as orders arrive simultaneously -6. Price correction downward -7. Cycle repeats with natural frequency -``` - -#### Emergent Behavior -- **Synchronized depletion** : Similar consumption patterns -- **Bidding wars** : Scarcity-driven competition -- **Transport optimization** : Volume consolidation benefits -- **Natural cycles** : Self-organizing market rhythms - -## đŸ’Œ Trading Companies - -### Business Models Emergents - -#### Pure Arbitrage Strategy -```cpp -class ArbitrageTrader { - Strategy coastalToInland() { - // 1. Buy coastal (cheap ship transport access) - // 2. Store in strategic inland locations - // 3. Sell to remote regions (premium prices) - // Profit = Price differential - storage - transport - return {buyCoastal, storeStrategic, sellRemote}; - } -}; -``` - -#### Transport Optimization Strategy -```cpp -class TransportOptimizer { - Strategy aggregateSmallProducers() { - // 1. Aggregate small producer outputs - // 2. Combine orders to unlock ship thresholds - // 3. Share transport savings with producers - // Profit = Transport efficiency gains - return {aggregateOrders, unlockShipping, shareGains}; - } -}; -``` - -#### Market Making Strategy -```cpp -class MarketMaker { - Strategy stabilizeSupply() { - // 1. Buffer supply volatility with inventory - // 2. Provide reliable supply to consumers - // 3. Smooth price fluctuations - // Profit = Stability service premium - return {bufferVolatility, guaranteeSupply, chargePremium}; - } -}; -``` - -### Specialization Types - -#### Geographic Specialists -- **Regional expertise** : Deep knowledge specific areas -- **Infrastructure relationships** : Port/rail access deals -- **Local market intelligence** : Cultural/regulatory knowledge -- **Logistics optimization** : Region-specific transport solutions - -#### Commodity Specialists -- **Deep vertical knowledge** : Single commodity expertise -- **Quality assessment** : Grading, certification, standards -- **Technical logistics** : Specialized handling, storage -- **Market prediction** : Supply/demand pattern expertise - -#### Logistics Specialists -- **Transport optimization** : Multi-modal route planning -- **Volume consolidation** : Order aggregation expertise -- **Infrastructure leverage** : Maximum transport efficiency -- **Timing coordination** : Economic cycle optimization - -#### Financial Specialists -- **Risk management** : Hedging, insurance, derivatives -- **Futures markets** : Long-term contract management -- **Credit facilities** : Financing for trade operations -- **Currency hedging** : International trade protection - -## 🌍 Geographic Economics - -### Natural Economic Geography Evolution - -#### Coastal Concentration Dynamics -``` -Market Forces Sequence: -1. Initial coastal rush (transport cost advantages) -2. Land price premiums develop (scarcity) -3. Congestion costs emerge (infrastructure limits) -4. Port capacity bottlenecks (throughput limits) -5. Labor shortage premiums (competition) -6. Economic equilibrium reached (cost parity) -``` - -#### Regional Specialization Patterns -```cpp -enum RegionType { - RESOURCE_EXTRACTION, // Fixed by geological deposits - MANUFACTURING_HUB, // Transport cost optimization - TRADING_CENTER, // Infrastructure convergence - CONSUMER_MARKET // Population concentration -}; - -class RegionalSpecialization { - RegionType determineOptimalFocus(Region region) { - if(hasNaturalResources(region)) return RESOURCE_EXTRACTION; - if(hasTransportHub(region)) return TRADING_CENTER; - if(hasManufacturingCosts(region)) return MANUFACTURING_HUB; - return CONSUMER_MARKET; - } -}; -``` - -### Infrastructure Investment Economics - -#### Economic Justification Model -```cpp -class InfrastructureROI { - bool justifyRailInvestment(Region region) { - float currentTransportCosts = calculateTruckCosts(region); - float projectedVolume = estimateTradeVolume(region); - float railConstructionCost = calculateRailCost(region); - float railOperatingCost = calculateRailOperations(region); - - float savings = (currentTransportCosts - railOperatingCost) * projectedVolume; - float paybackPeriod = railConstructionCost / savings; - - return paybackPeriod < MAX_PAYBACK_YEARS; - } -}; -``` - -#### Investment Triggers -- **Sustained high transport costs** : Market signals infrastructure need -- **Volume thresholds reached** : Economies of scale justify investment -- **Regional economic pressure** : Political/social demand for development -- **Competitive necessity** : Rival regions gaining advantages - -### Infrastructure Impact Simulation -``` -Pre-Rail Region: -├─ Truck transport only (5.00€/kg) -├─ High consumer prices -├─ Limited economic activity -├─ Population outmigration - -Post-Rail Region: -├─ Rail transport available (0.50€/kg) -├─ 90% transport cost reduction -├─ Economic boom, new businesses -├─ Population influx, urbanization -``` - -## ⚙ Implementation Details - -### Economic Agents (Player-Agnostic Design) - -**Tous les entitĂ©s = agents Ă©conomiques** : - -```cpp -class EconomicAgent { -public: - virtual void submitOrders() = 0; - virtual void processTransactions() = 0; - virtual void updateStrategy() = 0; - - // No special player privileges - // Pure economic simulation -}; - -class ProductionCompany : public EconomicAgent { ... }; -class ConsumptionCompany : public EconomicAgent { ... }; -class TransportCompany : public EconomicAgent { ... }; -class TradingCompany : public EconomicAgent { ... }; -class InfrastructureInvestor : public EconomicAgent { ... }; -``` - -#### Agent Equality Principle -- **No player privileges** : Tous agents soumis aux mĂȘmes rĂšgles -- **Pure simulation** : Économie Ă©mergente sans intervention arbitraire -- **Fair competition** : Success basĂ© sur strategy, pas status -- **Realistic behavior** : AI agents comportement Ă©conomique rationnel - -### Market Clearing Algorithm - -**Order Matching Process** : - -```cpp -class MarketClearingEngine { - void processMarketCycle() { - // 1. Collect all orders from economic phases - auto sellOrders = collectSellOrders(); - auto buyOrders = collectBuyOrders(); - - // 2. Sort for optimal matching - std::sort(sellOrders.begin(), sellOrders.end(), priceAscending); - std::sort(buyOrders.begin(), buyOrders.end(), priceDescending); - - // 3. Match orders within transport cost limits - auto matches = matchOrdersWithTransportLimits(sellOrders, buyOrders); - - // 4. Apply volume consolidation for shipping - auto consolidatedMatches = applyVolumeConsolidation(matches); - - // 5. Calculate optimal transport modes - for(auto& match : consolidatedMatches) { - match.transportMode = selectOptimalTransport(match); - } - - // 6. Execute deliveries with realistic time delays - scheduleDeliveries(consolidatedMatches); - } -}; -``` - -#### Algorithm Benefits -- **Economic efficiency** : Optimal price discovery -- **Transport optimization** : Automatic mode selection -- **Volume benefits** : Consolidation incentives -- **Realistic timing** : Delivery delays based on transport mode - -### Configuration Parameters - -**SystĂšme de configuration Ă©conomique** : - -```json -{ - "transport": { - "ship_threshold_tonnes": 1000, - "ship_cost_per_kg": 0.10, - "train_cost_per_kg": 0.50, - "air_cost_per_kg": 2.00, - "truck_cost_per_kg": 5.00, - "delivery_time_ship_days": 14, - "delivery_time_train_days": 3, - "delivery_time_air_days": 1, - "delivery_time_truck_days": 2 - }, - "storage": { - "cost_per_kg_per_day": 0.02, - "urgent_stock_threshold": 0.20, - "normal_stock_threshold": 0.50, - "oversupplied_threshold": 0.80, - "max_storage_capacity_multiplier": 10.0 - }, - "market": { - "transport_cost_limit_percentage": 0.15, - "order_stacking_wait_days": 7, - "economic_phase_duration_hours": 6, - "price_volatility_damping": 0.1, - "scarcity_premium_multiplier": 2.0 - }, - "infrastructure": { - "rail_construction_cost_per_km": 1000000, - "port_construction_cost": 50000000, - "airport_construction_cost": 100000000, - "max_infrastructure_payback_years": 15 - } -} -``` - -#### Configuration Benefits -- **Tunable economics** : Adjust economic parameters for gameplay -- **Progressive complexity** : Start simple, add sophistication -- **A/B testing** : Compare different economic models -- **Regional variation** : Different parameters per geographic region - -## 🎯 System Benefits & Integration - -### Economic Realism Achievements - -#### Natural Geographic Specialization -- **Resource-based clustering** : Mining near deposits -- **Manufacturing optimization** : Transport cost minimization -- **Trading hub emergence** : Infrastructure convergence points -- **Realistic urban development** : Economic forces drive settlement patterns - -#### Infrastructure ROI Modeling -- **Investment justification** : Economic case for infrastructure -- **Regional transformation** : Infrastructure changes economic landscape -- **Competitive dynamics** : Regions compete for transport access -- **Long-term planning** : Infrastructure decisions have lasting impact - -#### Market Cycle Emergence -- **Natural rhythms** : Supply/demand cycles self-organize -- **Price discovery** : Efficient market mechanisms -- **Arbitrage opportunities** : Geographic and temporal price differences -- **Risk/reward balance** : Higher profits require higher risks - -### Emergent Complexity Demonstration - -#### Trading Company Evolution -- **Business model innovation** : New strategies emerge from economic pressure -- **Specialization development** : Companies find profitable niches -- **Market efficiency improvement** : Traders reduce transaction costs -- **Economic ecosystem richness** : Multiple business models coexist - -#### Regional Economic Development -- **Coastal advantage phase** : Early transport cost benefits -- **Infrastructure investment phase** : Economic pressure drives development -- **Economic equilibrium phase** : Costs equalize across regions -- **Competitive specialization phase** : Regions find comparative advantages - -#### Supply Chain Sophistication -- **Simple direct trade** → **Multi-hop arbitrage** → **Complex logistics networks** -- **Individual transactions** → **Volume consolidation** → **Integrated supply chains** -- **Local markets** → **Regional trade** → **Global economic integration** - -### Simple Implementation Strategy - -#### Clear Decision Trees -```cpp -TransportMode selectTransport(Order order, Route route) { - if(order.volume >= 1000 && route.hasPortAccess()) return SHIP; - if(route.hasRailAccess()) return TRAIN; - if(route.hasAirportAccess()) return AIR; - return TRUCK; -} -``` - -#### Binary Infrastructure Access -- **No gradients** : Access or no access, simple boolean -- **Clear competitive advantage** : Infrastructure = economic moat -- **Easy AI reasoning** : Simple rules for AI decision-making -- **Scalable complexity** : Add infrastructure types without algorithm changes - -#### Modular Economic Components -```cpp -// Easy integration with existing architecture -class TransportModule : public IModule { ... }; -class TradingModule : public IModule { ... }; -class InfrastructureModule : public IModule { ... }; -class MarketModule : public IModule { ... }; -``` - -### Scalability Architecture - -#### Progressive Sophistication -- **Phase 1** : Basic transport cost differences -- **Phase 2** : Order stacking and volume optimization -- **Phase 3** : Trading companies and arbitrage -- **Phase 4** : Infrastructure investment and regional development -- **Phase 5** : Complex economic simulation (Victoria 3-level) - -#### Performance Scaling -- **Local decisions** : Transport mode selection (real-time) -- **Regional coordination** : Market clearing (hourly) -- **Economic simulation** : Complex modeling (daily) -- **Infrastructure planning** : Long-term investment (monthly) - -### Player-Agnostic Benefits - -#### Pure Economic Simulation -- **No artificial advantages** : Players compete on equal terms -- **Emergent strategies** : Success comes from economic insight -- **Educational value** : Players learn real economic principles -- **Sandbox flexibility** : Multiple valid approaches to success - -#### AI Agent Integration -- **Consistent behavior** : All agents follow same economic rules -- **Realistic competition** : AI competitors use rational strategies -- **Market depth** : Many agents create liquid markets -- **Economic ecosystem** : Rich environment for player interaction - ---- - -## Conclusion - -Le systĂšme transport & Ă©conomique crĂ©e une **simulation Ă©conomique rĂ©aliste** oĂč : - -- **Geographic advantages** Ă©mergent naturellement des coĂ»ts de transport -- **Business models sophistiquĂ©s** Ă©voluent des pressions Ă©conomiques -- **Infrastructure investment** suit la logique Ă©conomique ROI -- **Market dynamics** crĂ©ent cycles et opportunitĂ©s rĂ©alistes - -**Ready for integration** dans l'architecture modulaire : -- **ProductionModule** : Interface avec transport costs -- **TradingModule** : Business logic des trading companies -- **InfrastructureModule** : Investment et construction logic -- **MarketModule** : Economic phases et price discovery - -**RĂ©sultat** : **Economic simulation depth** comparable aux meilleurs strategy games, avec **implementation simplicity** compatible Claude Code development ! đŸš›đŸ’°đŸ—ïž \ No newline at end of file diff --git a/docs/03-implementation/systemes-techniques.md b/docs/03-implementation/systemes-techniques.md deleted file mode 100644 index 2f9cc6a..0000000 --- a/docs/03-implementation/systemes-techniques.md +++ /dev/null @@ -1,98 +0,0 @@ -# SystĂšmes techniques - -## Tile System - -### Superficies -- **OcĂ©an** : 362 000 000 000 mÂČ -- **Total** : 510 000 000 000 mÂČ -- **Terre** : 148 000 000 000 mÂČ (118.4 Go) -- **Urbain** : 4 440 000 000 mÂČ (3.552 Go) - -### RĂ©fĂ©rence Minecraft -- MC 256x256 = 3 540 ko - -## Gestion mĂ©moire - -### Game Chunk max DD Absolue pire cas (256x256) -- **Land** : 131 ko -- **Ressources** : 393 ko -- **Build** : 459 ko -- **Roof** : 131 ko -- **Effect** : 131 ko -- **Total** : 1 245 ko - -### Game Chunk RAM (256x256) -- **Land** : 131 ko -- **Ressources** : 655 ko -- **Build** : 720 ko -- **Roof** : 131 ko -- **Effect** : 131 ko -- **Total** : 1 768 ko - -## Architecture Multi-Échelle des Chunks - -### Principe de Design -DiffĂ©rents types de donnĂ©es utilisent diffĂ©rentes rĂ©solutions de chunks selon leur granularitĂ© naturelle et leurs besoins de performance. - -### HiĂ©rarchie des Échelles - -#### Chunk 512x512 - Terrain de Base -**Usage** : DonnĂ©es homogĂšnes sur grandes zones -- **landId** : 16b - Texture de la tile (potentiel modificateur) DD/Ram -- **roofId** : 16b - Identification toitures/couverture sol -- **Justification** : Terrain change peu, grandes zones homogĂšnes -- **MĂ©moire** : Toujours en RAM (donnĂ©es de base) - -#### Chunk 256x256 - Structures et BĂątiments -**Usage** : BĂątiments et constructions moyennes/grandes -- **buildingPtr** : 32b "DD"/Ram -```cpp -{ - BuildingId : 32b DD/Ram - Collision : 4b Ram - PV : 20b DD(24b)/Ram -} -``` -- **Justification** : BĂątiments ont taille intermĂ©diaire, besoin rĂ©solution moyenne -- **MĂ©moire** : Chargement Ă  la demande - -#### Chunk 128x128 - Effets et DĂ©tails Fins -**Usage** : Effets visuels, particules, dĂ©tails haute frĂ©quence -- **effectId** : 16b -- **Justification** : Effets nĂ©cessitent granularitĂ© fine pour prĂ©cision -- **MĂ©moire** : Streaming selon proximitĂ© joueur - -#### Chunk 64x64 - Gameplay Principal -**Usage** : Simulation de base, FOW, navigation (documentĂ© dans map-system.md) -- **Justification** : Échelle optimale pour mĂ©canique Factorio-like -- **MĂ©moire** : Core gameplay, chargement prioritaire - -### SystĂšme Ressources (IndĂ©pendant) -**ResourcePatches** : Formes libres non-alignĂ©es sur chunks (78x53 exemple) -- **Justification** : Gisements naturels ne respectent pas grilles artificielles -- **Documentation** : DĂ©tails complets dans map-system.md -- **MĂ©moire** : Chargement selon exploration et exploitation - -### Avantages Architecture Multi-Échelle -- **Performance optimisĂ©e** : Chaque donnĂ©e Ă  sa rĂ©solution naturelle -- **MĂ©moire efficace** : GranularitĂ© adaptĂ©e aux besoins d'accĂšs -- **Scaling intelligent** : Pas de sur-Ă©chantillonnage ni sous-Ă©chantillonnage -- **Maintenance** : SystĂšmes indĂ©pendants, modifications isolĂ©es - -## Stack technique - -### Langages de performance -- **C++ / C / ASM** pour performance critique -- **Justification** : Simulation temps rĂ©el complexe + milliers d'unitĂ©s -- **Compromise** : ComplexitĂ© dev acceptable vs performance requirements - -### Optimisations performance - -#### Adaptive Tick Rate -- **Normal** : 60 TPS -- **Sous charge** : 15 TPS -- **Principe** : DĂ©gradation gracieuse selon la charge - -#### Queue Systems -- Batch processing pour opĂ©rations coĂ»teuses -- Future scaling : clustering dynamique per module \ No newline at end of file diff --git a/docs/03-implementation/testing-strategy.md b/docs/03-implementation/testing-strategy.md deleted file mode 100644 index ac4df4f..0000000 --- a/docs/03-implementation/testing-strategy.md +++ /dev/null @@ -1,214 +0,0 @@ -# Testing Strategy - Warfactory - -**Philosophy** : Testing optimisĂ© pour dĂ©veloppement Claude Code avec modules autonomes - -## Points 42-44 : Testing & Validation Strategy - -### Point 42 : Unit Tests IntĂ©grĂ©s (`#ifdef TESTING`) - -**Validation autonome intĂ©grĂ©e aux modules :** - -```cpp -class TankModule : public IModule { - json process(const json& input) override { - // Core tank logic - auto result = processTankBehavior(input); - - #ifdef TESTING - // Validation autonome intĂ©grĂ©e - validateInputs(input); - validateState(); - validateOutputs(result); - #endif - - return result; - } - - #ifdef TESTING - void runSelfTests() { - // Tests unitaires intĂ©grĂ©s au module - testMovement(); - testTargeting(); - testCombat(); - } - -private: - void validateInputs(const json& input) { - assert(input.contains("position")); - assert(input.contains("target")); - assert(input["health"].get() >= 0.0f); - } - - void validateState() { - assert(currentHealth >= 0.0f); - assert(position.isValid()); - assert(ammunition >= 0); - } - - void validateOutputs(const json& output) { - assert(output.contains("status")); - assert(output.contains("position")); - assert(output.contains("actions")); - } - #endif -}; -``` - -**Build integration :** -```cmake -# Debug builds enable testing -if(CMAKE_BUILD_TYPE STREQUAL "Debug") - target_compile_definitions(tank PRIVATE TESTING) -endif() - -# Test executable -add_executable(tank-test tests/tank_test.cpp src/TankModule.cpp) -target_compile_definitions(tank-test PRIVATE TESTING) -``` - -### Point 43 : Standalone Testing - -**Test modules sans engine complet :** - -```cpp -// tests/tank_test.cpp -#include "../src/TankModule.h" - -int main() { - TankModule tank; - - // Initialize with test config - json config = { - {"health", 100}, - {"ammunition", 50}, - {"position", {10, 20}} - }; - tank.initialize(config); - - // Run self-tests - #ifdef TESTING - tank.runSelfTests(); - #endif - - // Test specific behaviors - json input = { - {"command", "move"}, - {"target_position", {15, 25}}, - {"health", 100} - }; - - auto result = tank.process(input); - - // Verify output - assert(result["status"] == "moving"); - assert(result.contains("position")); - - std::cout << "✅ All tank tests passed!" << std::endl; - return 0; -} -``` - -**Execution autonome :** -```bash -cd modules/tank/ -cmake . && make tank-test -./tank-test # ExĂ©cute tests sans infrastructure -``` - -### Point 44 : Testing Strategy AI-Optimized - -**Philosophy Claude Code-friendly :** - -#### Simple Tests Philosophy -- **No complex infrastructure** : Tests sans setup lourd -- **Minimal dependencies** : JSON in/out uniquement -- **Quick feedback** : <5 secondes pour iteration loops Claude -- **Readable by AI** : Code test comprĂ©hensible par IA - -#### Module Isolation Testing -```cpp -// ✅ GOOD - Simple, isolated test -void testTankMovement() { - TankModule tank; - json input = {{"command", "move"}, {"target", {10, 10}}}; - auto result = tank.process(input); - assert(result["status"] == "moving"); -} - -// ❌ BAD - Complex infrastructure required -void testTankInCompleteGameWorld() { - GameEngine engine; - MapSystem map; - NetworkManager network; - // 100+ lines setup... -} -``` - -#### AI Development Workflow -```bash -# Claude Code workflow optimized -1. Edit module → Save -2. Run tests → Instant feedback -3. Iterate → 5-second cycles - -# Traditional workflow (avoid) -1. Edit code → Rebuild entire project → Setup test environment → Run tests → 5-10 minutes -``` - -#### Testing Patterns Claude-Friendly - -**Input/Output Testing :** -```cpp -struct TestCase { - std::string name; - json input; - json expected_output; -}; - -std::vector tankTests = { - {"movement", {{"cmd", "move"}}, {{"status", "moving"}}}, - {"combat", {{"cmd", "fire"}}, {{"status", "firing"}}}, - {"damaged", {{"health", 10}}, {{"status", "critical"}}} -}; - -void runAllTests() { - for(auto& test : tankTests) { - auto result = tank.process(test.input); - assert(result == test.expected_output); - std::cout << "✅ " << test.name << " passed" << std::endl; - } -} -``` - -**Configuration-Driven Testing :** -```json -// tests/tank_test_config.json -{ - "test_cases": [ - { - "name": "basic_movement", - "input": {"command": "move", "target": [10, 10]}, - "expected": {"status": "moving", "eta": 5} - }, - { - "name": "low_health_behavior", - "input": {"health": 15, "command": "attack"}, - "expected": {"status": "retreating"} - } - ] -} -``` - -## Architecture Benefits - -**Development Velocity :** -- **5-second iteration** : Edit → Test → Feedback -- **Claude optimization** : IA comprend tests facilement -- **Zero infrastructure** : Pas setup complexe -- **Parallel development** : Multiple modules testĂ©s simultanĂ©ment - -**Quality Assurance :** -- **Module isolation** : Bugs localisĂ©s, pas cascade -- **Autonomous validation** : Modules self-validate via `#ifdef TESTING` -- **Quick regression detection** : Tests rapides dĂ©tectent rĂ©gressions -- **AI-readable failures** : Error messages clairs pour Claude Code \ No newline at end of file diff --git a/docs/04-reference/INTEGRATION-MASTER-LIST.md b/docs/04-reference/INTEGRATION-MASTER-LIST.md deleted file mode 100644 index 68ba3db..0000000 --- a/docs/04-reference/INTEGRATION-MASTER-LIST.md +++ /dev/null @@ -1,395 +0,0 @@ -# INTEGRATION MASTER LIST - -Complete technical specifications catalog for the Warfactory project. - -## Global Architecture Overview - -### System Orchestration Flow -``` -MainServer Process: -├── CoordinationModule (Global Orchestrator) -│ ├── Loads gameconfig.json via IDataTree -│ ├── Launches local IEngine + modules -│ └── Launches remote servers + engines -├── Local IEngine (manages local modules) -│ ├── IModuleSystem (execution strategy) -│ └── Local Modules (.so files) -└── Remote Servers (launched by coordination) - ├── Remote IEngine (manages remote modules) - ├── IModuleSystem (execution strategy) - └── Remote Modules (.so files) -``` - -### Startup Sequence -1. **MainServer** starts and launches **CoordinationModule** -2. **CoordinationModule** calls `startNewGame("gameconfig.json")` -3. **Config Loading**: IDataTree loads and parses gameconfig.json -4. **Deployment Analysis**: Parse deployment section to determine module topology -5. **Local Deployment**: Deploy modules with `target: "local"` to local IEngine -6. **Remote Deployment**: Launch remote servers and deploy modules with `target: "server:IP"` -7. **Synchronization**: All modules receive their configuration via `setConfiguration()` -8. **Game Ready**: Return control to user interface - -### Module Lifecycle with New Configuration System -```cpp -// Old way (DEPRECATED) -module->initialize(json_config, io, scheduler); - -// New way (CURRENT) -const IDataNode& config = configTree->getNode("modules/production"); -module->setConfiguration(config, io, scheduler); // const ref, no copies - -// Health monitoring -json health = module->getHealthStatus(); -// Returns: {"status": "healthy", "last_process_time_ms": 1.2, "memory_usage_mb": 45} -``` - -## Core Interface System - -### Engine Interfaces (IMMUTABLE) -- **IEngine**: Engine orchestration, module loading, client/coordinator socket management -- **IModuleSystem**: Execution strategy + task scheduling (inherits ITaskScheduler) -- **IModule**: Pure business logic + pub/sub communication + task delegation (**BREAKING CHANGES**) -- **IIO**: Pull-based pub/sub with low-frequency batching and health monitoring -- **ITaskScheduler**: Task delegation interface for module → execution system - -### Configuration System (IMMUTABLE) -- **IDataTree**: Configuration tree container with manual hot-reload capabilities -- **IDataNode**: Hierarchical data nodes with pattern matching and property queries (**const methods**) -- **DataTreeFactory**: Factory pattern for flexible data source creation - -### Coordination System (NEW) -- **ICoordinationModule**: Global system orchestrator and main game lifecycle manager - -## GameConfig.json Architecture - -### Central Configuration System -The entire game system is configured through a single **`gameconfig.json`** file that serves as the master configuration: - -```json -{ - "game": { - "name": "Warfactory Game Session", - "version": "1.0.0", - "save_path": "./saves/game_001" - }, - "deployment": { - "modules": [ - { - "id": "production_main", - "type": "ProductionModule", - "path": "./modules/production.so", - "target": "local", - "config_path": "modules/production" - }, - { - "id": "economy_central", - "type": "EconomyModule", - "path": "./modules/economy.so", - "target": "server:192.168.1.100:8080", - "config_path": "modules/economy" - }, - { - "id": "tank_combat", - "type": "TankModule", - "path": "./modules/tank.so", - "target": "cluster:combat_nodes", - "config_path": "modules/tank" - } - ] - }, - "modules": { - "production": { - "frequency": "60Hz", - "belt_speed": 2.5, - "inserter_capacity": 12 - }, - "economy": { - "frequency": "0.1Hz", - "inflation_rate": 0.02, - "market_volatility": 0.15 - }, - "tank": { - "targeting_frequency": "60Hz", - "movement_frequency": "30Hz", - "tactical_frequency": "1Hz" - } - } -} -``` - -### Configuration Flow -1. **CoordinationModule** loads `gameconfig.json` via IDataTree -2. **Deployment section** defines module topology and distribution -3. **Modules section** contains hierarchical configuration for each module type -4. **Hot-reload** updates propagated to all deployed modules automatically - -### CoordinationModule Deployment Logic -```cpp -// Example deployment process -void CoordinationModule::deployModule(const std::string& moduleInstanceId) { - // 1. Get module configuration from gameconfig.json - const IDataNode& deployConfig = configTree->getNode("deployment/modules"); - const IDataNode* moduleConfig = deployConfig.getFirstChildByName(moduleInstanceId); - - // 2. Determine deployment target - std::string target = moduleConfig->getString("target"); - std::string modulePath = moduleConfig->getString("path"); - std::string configPath = moduleConfig->getString("config_path"); - - // 3. Get module-specific configuration - const IDataNode& moduleSettings = configTree->getNode("modules/" + configPath); - - // 4. Deploy based on target - if (target == "local") { - localEngine->getModuleSystem()->loadModule(modulePath, moduleSettings); - } else if (target.startswith("server:")) { - deployToRemoteServer(target, modulePath, moduleSettings); - } -} -``` - -## IDataTree Configuration System Specifications - -### Core Architecture -```cpp -namespace warfactory { - class IDataTree { - // Tree access - virtual std::unique_ptr getRoot() = 0; - virtual std::unique_ptr getNode(const std::string& path) = 0; - - // Manual hot-reload - virtual bool checkForChanges() = 0; - virtual bool reloadIfChanged() = 0; - virtual void onTreeReloaded(std::function callback) = 0; - - // Metadata - virtual std::string getType() = 0; - }; -} -``` - -### IDataNode Capabilities -```cpp -namespace warfactory { - class IDataNode { - // Tree navigation - virtual std::unique_ptr getChild(const std::string& name) = 0; - virtual std::vector getChildNames() = 0; - virtual bool hasChildren() = 0; - - // Exact search in children - virtual std::vector getChildrenByName(const std::string& name) = 0; - virtual bool hasChildrenByName(const std::string& name) const = 0; - virtual IDataNode* getFirstChildByName(const std::string& name) = 0; - - // Pattern matching search (deep search in whole subtree) - virtual std::vector getChildrenByNameMatch(const std::string& pattern) = 0; - virtual bool hasChildrenByNameMatch(const std::string& pattern) const = 0; - virtual IDataNode* getFirstChildByNameMatch(const std::string& pattern) = 0; - - // Query by properties - virtual std::vector queryByProperty(const std::string& propName, - const std::function& predicate) = 0; - - // Node's own data - virtual json getData() = 0; - virtual bool hasData() = 0; - virtual void setData(const json& data) = 0; - - // Typed data access by property name - virtual std::string getString(const std::string& name, const std::string& defaultValue = "") = 0; - virtual int getInt(const std::string& name, int defaultValue = 0) = 0; - virtual double getDouble(const std::string& name, double defaultValue = 0.0) = 0; - virtual bool getBool(const std::string& name, bool defaultValue = false) = 0; - virtual bool hasProperty(const std::string& name) = 0; - - // Hash system for validation & synchro - virtual std::string getDataHash() = 0; - virtual std::string getTreeHash() = 0; - virtual std::string getSubtreeHash(const std::string& childPath) = 0; - - // Metadata - virtual std::string getPath() = 0; - virtual std::string getName() = 0; - virtual std::string getNodeType() = 0; - }; -} -``` - -### Configuration Usage Patterns - -#### Hierarchical Data Access -```cpp -// Access nested configuration -std::unique_ptr tree = DataTreeFactory::create("json", "config/vehicles.json"); -std::unique_ptr tank = tree->getNode("vehicles/tanks/heavy/model5"); - -// Get properties with type safety -int armor = tank->getInt("armor", 100); -double speed = tank->getDouble("speed", 30.0); -std::string name = tank->getString("display_name", "Unknown Tank"); -``` - -#### Pattern Matching Search -```cpp -// Find all components -std::vector components = root->getChildrenByNameMatch("component*"); - -// Find all heavy variants -std::vector heavyUnits = root->getChildrenByNameMatch("*heavy*"); - -// Find specific models -std::vector models = root->getChildrenByNameMatch("model_*"); -``` - -#### Property-Based Queries -```cpp -// Find all tanks with armor > 150 -std::vector heavyTanks = root->queryByProperty("armor", [](const json& val) { - return val.is_number() && val.get() > 150; -}); - -// Find all vehicles with specific role -std::vector scouts = root->queryByProperty("role", [](const json& val) { - return val.is_string() && val.get() == "scout"; -}); -``` - -#### Hot-Reload Workflow -```cpp -// Manual hot-reload check -if (tree->checkForChanges()) { - if (tree->reloadIfChanged()) { - // Tree was reloaded - update dependent systems - updateGameContent(); - } -} - -// Register reload callback -tree->onTreeReloaded([]() { - std::cout << "Configuration reloaded - updating systems\n"; - notifyAllModules(); -}); -``` - -### Hash-Based Validation -```cpp -// Validate specific data integrity -std::string nodeHash = node->getDataHash(); -std::string previousHash = loadStoredHash(); -if (nodeHash != previousHash) { - // Data has changed - trigger update - synchronizeWithServer(nodeHash); -} - -// Validate entire subtree -std::string treeHash = node->getTreeHash(); -if (treeHash != expectedTreeHash) { - // Subtree structure or data has changed - performFullValidation(); -} -``` - -### Factory Pattern Usage -```cpp -// JSON configuration -std::unique_ptr jsonTree = DataTreeFactory::create("json", "config/vehicles.json"); - -// Future: Database configuration -std::unique_ptr dbTree = DataTreeFactory::create("database", "postgresql://config_db"); - -// Future: Network configuration -std::unique_ptr netTree = DataTreeFactory::create("network", "https://api.example.com/config"); -``` - -## UI Interface System (COMPLETED) - -### IUI Architecture -- **Data-Agnostic Design**: Generic interface supporting all content types -- **Type-Safe Enums**: DataType::ECONOMY, RequestType::GET_PRICES for performance -- **Hierarchical Windowing**: Parent → Dock → Split → Tab → Window structure -- **Hybrid Sizing System**: Percentage targets with absolute pixel constraints - -### ImGuiUI Implementation -- **Complete Rendering Pipeline**: All DataType content renderers implemented -- **Interactive Callbacks**: Request/response system with onRequest() + custom events -- **Professional Layout**: Economic topbar + companies panel + strategic map + console -- **State Management**: Window persistence, docking configuration, layout serialization - -## Module System Specifications - -### BREAKING CHANGES in IModule Interface -```cpp -// OLD Interface (DEPRECATED) -class IModule { - virtual void initialize(const json& config, IIO* io, ITaskScheduler* scheduler) = 0; - virtual bool isHealthy() = 0; // Simple boolean -}; - -// NEW Interface (CURRENT) -class IModule { - virtual void setConfiguration(const IDataNode& configNode, IIO* io, ITaskScheduler* scheduler) = 0; - virtual const IDataNode& getConfiguration() = 0; - virtual json getHealthStatus() = 0; // Detailed JSON report - // initialize() method REMOVED -}; -``` - -### Configuration Immutability Pattern -```cpp -// Modules receive const references - cannot modify configuration -const IDataNode& config = coordinationModule->getConfigurationTree()->getNode("modules/production"); - -// All getter methods are const to enforce read-only access -int frequency = config.getInt("frequency", 60); // const method -std::string mode = config.getString("mode", "auto"); // const method - -// Modifications only possible through CoordinationModule -coordinationModule->syncConfiguration(); // Reloads entire tree -``` - -### Module Health Monitoring -```cpp -// Detailed health status example -json healthStatus = { - "status": "healthy|degraded|critical|offline", - "last_process_time_ms": 1.2, - "memory_usage_mb": 45, - "error_count": 0, - "warnings": ["High memory usage detected"], - "details": "All subsystems operational", - "uptime_seconds": 3600, - "processed_messages": 15420 -}; -``` - -### Module Frequencies & Isolation -- **ProductionModule**: 60Hz (frame-perfect factory operations) -- **TankModule**: 0.1-60Hz (Targeting 60Hz → Movement 30Hz → Tactical 1Hz → Analytics 0.1Hz) -- **EconomyModule**: 0.01-0.1Hz (economic cycles) -- **War Isolation**: ZERO interaction ProductionModule ↔ WarModule -- **Supply Chain**: Factory → LogisticModule → War (unidirectional flow) - -### Performance Targets -- **V1 Client**: 30+ fps -- **V2 Client**: 60+ fps -- **V1 Server**: 10+ players -- **V2 Server**: 100+ players - -## Development Constraints - -### Code Restrictions -- **AUTO KEYWORD PROHIBITED**: Explicit types required throughout codebase -- **Interface Immutability**: Core interfaces NEVER modified once finalized -- **Module Isolation**: No `#include "../"` or parent directory references -- **PUB/SUB Communication**: Module communication via IIO only - -### Build System -- **Autonomous Builds**: Each module builds independently -- **Hot-Reload**: 0.4ms average reload time achieved -- **Cross-Platform**: Linux development → Windows .exe automated -- **Debug Tools**: AddressSanitizer + UndefinedBehaviorSanitizer by default - -This document serves as the authoritative reference for all technical specifications in the Warfactory project. \ No newline at end of file diff --git a/docs/04-reference/arbre-technologique.md b/docs/04-reference/arbre-technologique.md deleted file mode 100644 index f320afc..0000000 --- a/docs/04-reference/arbre-technologique.md +++ /dev/null @@ -1,973 +0,0 @@ -# Arbre Technologique - -## Vue d'ensemble - -**Volume technologique** : 2000-3000 technologies organisĂ©es en **domaines interconnectĂ©s** - -**Principe des passerelles** : Expertise dans un domaine dĂ©bloque des "prototypes" dans d'autres domaines, permettant de court-circuiter les progressions linĂ©aires et d'ouvrir de nouvelles branches. - -## Philosophie Discovery & RejouabilitĂ© - -### Design Core -**Le player n'est PAS censĂ© rechercher toutes les 3000 technologies** ! Le systĂšme est conçu pour la **dĂ©couverte organique** et la **rejouabilitĂ©** : - -#### Discovery Progressive -- **Breakthrough system** : Technologies dĂ©bloquĂ©es par gameplay naturel (construction, production, combat) -- **Prerequisites gating** : Seules ~10-50 techs eligible simultanĂ©ment, jamais 3000 -- **Random element** : Chaque run = dĂ©couvertes diffĂ©rentes selon actions player -- **Organic emergence** : "Je construis → je dĂ©couvre" vs "je regarde un arbre" - -#### RejouabilitĂ© Infinie -- **3000 techs = content pool** pour expĂ©riences variĂ©es -- **Run spĂ©cialisĂ©** : Focus mĂ©tallurgie vs Ă©lectronique = paths complĂštement diffĂ©rents -- **Combinaisons nouvelles** : Passerelles crĂ©ent synergies inattendues entre runs -- **Surprises constantes** : "Wow ! Cette tech existe ?" mĂȘme aprĂšs 100h - -#### Performance & Scaling -- **Prerequisites check** : Validation ponctuelle quand conditions remplies, pas polling -- **Ticker optimisĂ©** : VĂ©rification breakthrough toutes les minutes, pas 60fps -- **Interface proven** : Similar Ă  Factorio qui gĂšre 100+ techs sans problĂšme -- **Design for scale** : Standard industrie pour gros content pools - -## MĂ©caniques des Passerelles - -### Principe Fondamental -- Chaque arbre a sa **progression linĂ©aire classique** -- Des techs d'autres arbres dĂ©bloquent des **[PROTOTYPE]** qui court-circuitent la progression -- Ces prototypes ouvrent de **nouvelles branches** dans l'arbre de destination -- **Évite le grind linĂ©aire** : Player spĂ©cialisĂ© peut accĂ©der Ă  d'autres domaines sans tout refaire - -### Types de DĂ©blocages -1. **Court-circuit** : Saute 1-3 techs de la progression linĂ©aire -2. **Nouvelle branche** : Ouvre une ligne technologique alternative -3. **Hybridation** : Combine deux domaines pour crĂ©er des technologies uniques -4. **SpĂ©cialisation** : Versions spĂ©cialisĂ©es de technologies existantes - -### Exemple Concret : ChĂąssis -**Progression classique** : -``` -ChĂąssis LĂ©ger → ChĂąssis Moyen → ChĂąssis Lourd → ChĂąssis BlindĂ© -``` - -**Passerelles depuis autres arbres** : -``` -MĂ©tallurgie AvancĂ©e → [PROTOTYPE] ChĂąssis Composite (saute ChĂąssis Moyen) - → Ouvre branche : ChĂąssis Composite → ChĂąssis Modulaire → ChĂąssis Ultra-LĂ©ger - -Électronique → [PROTOTYPE] ChĂąssis Smart (saute ChĂąssis Lourd) - → Ouvre branche : ChĂąssis Smart → ChĂąssis Adaptatif → ChĂąssis Morphing - -Moteur → [PROTOTYPE] ChĂąssis Performance - → Ouvre branche : ChĂąssis Performance → ChĂąssis Racing → ChĂąssis HypervĂ©loce -``` - -## Domaines Technologiques Principaux - -### 0. Technologies Civiles - ARBRE MASTER (~800 techs) - -**RĂŽle central** : L'arbre civil est le **backbone technologique** qui nourrit TOUS les autres domaines. Il reprĂ©sente la base industrielle, scientifique et sociale qui permet le dĂ©veloppement militaire. - -#### Structure de l'Arbre Civil - -**A. Infrastructure & Industrie de Base (~150 techs)** -``` -Outils Manuels → Machines Simples → Automation Basique → Industrie Lourde → Complexes Industriels → MĂ©ga-Usines -``` -Sous-branches : -- **Extraction** : Mines → Foreuses → Extraction AutomatisĂ©e → Mining Complexes -- **SidĂ©rurgie** : Forges → Hauts Fourneaux → AciĂ©ries → Complexes MĂ©tallurgiques -- **Chimie** : Laboratoires → Usines Chimiques → PĂ©trochimie → Nanotechnologie - -**Passerelles offertes** : -- → **MĂ©tallurgie** : [PROTOTYPE] Alliages Industriels (court-circuite Aciers SpĂ©ciaux) -- → **Production** : [PROTOTYPE] Assembly Lines (court-circuite Automation) -- → **Énergie** : [PROTOTYPE] GĂ©nĂ©rateurs Industriels - -**B. Sciences Fondamentales (~120 techs)** -``` -MathĂ©matiques → Physique → Chimie → Biologie → Sciences AvancĂ©es → Recherche Fondamentale → ThĂ©ories UnifiĂ©es -``` -Sous-branches dĂ©taillĂ©es : -- **MathĂ©matiques** : ArithmĂ©tique → AlgĂšbre → Calcul → Statistiques → Topologie → ThĂ©orie des Groupes -- **Physique** : MĂ©canique → Thermodynamique → ÉlectromagnĂ©tisme → Quantique → RelativitĂ© → Physique Exotique -- **Chimie** : Chimie de Base → Organique → PolymĂšres → Catalyse → SupramolĂ©culaire -- **Biologie** : Cellulaire → GĂ©nĂ©tique → Biotechnologie → IngĂ©nierie GĂ©nĂ©tique - -**Passerelles offertes** : -- → **Électronique** : [PROTOTYPE] Semi-Conducteurs AvancĂ©s -- → **MatĂ©riaux** : [PROTOTYPE] MatĂ©riaux Quantiques -- → **MĂ©decine** : [PROTOTYPE] Biotechnologies Militaires -- → **Énergie** : [PROTOTYPE] RĂ©acteurs AvancĂ©s - -**C. Technologies de l'Information (~100 techs)** -``` -Écriture → Imprimerie → TĂ©lĂ©graphe → TĂ©lĂ©phone → Ordinateurs → Internet → IA Civile → SingularitĂ© Info -``` -Sous-branches : -- **Calcul** : Abaque → Calculatrices → Ordinateurs → Superordinateurs → Quantique -- **RĂ©seaux** : TĂ©lĂ©graphe → TĂ©lĂ©phone → Internet → RĂ©seaux AvancĂ©s → Neural Networks -- **Stockage** : Papier → MagnĂ©tique → Optique → Quantique → MolĂ©culaire - -**Passerelles offertes** : -- → **Électronique** : [PROTOTYPE] Processeurs Civils → branch militaire -- → **Communication** : [PROTOTYPE] RĂ©seaux SĂ©curisĂ©s -- → **Capteurs** : [PROTOTYPE] Surveillance Civile - -**D. Transport & Logistique Civile (~80 techs)** -``` -Marche → Roue → Animaux → Vapeur → Moteur → Aviation → Spatial → TĂ©lĂ©portation -``` -Sous-branches : -- **Terrestre** : Pieds → VĂ©lo → Automobile → Trains → Transport de Masse -- **Maritime** : Radeaux → Voiliers → Vapeur → Cargo → Porte-Conteneurs -- **AĂ©rien** : Ballons → Avions → Jets → Supersonique → Spatial -- **Logistique** : EntrepĂŽts → Supply Chains → Automation → Distribution - -**Passerelles offertes** : -- → **Moteurs** : [PROTOTYPE] Moteurs Haute Performance -- → **ChĂąssis** : [PROTOTYPE] VĂ©hicules Civils AdaptĂ©s -- → **Logistic Engine** : [PROTOTYPE] SystĂšmes de Distribution - -**E. Énergie & Ressources (~90 techs)** -``` -Muscle → Eau → Vapeur → ÉlectricitĂ© → Fossiles → NuclĂ©aire → Renouvelables → Fusion → Exotique -``` -Sous-branches massives : -- **Renouvelables** : Éolien → Solaire → HydroĂ©lectrique → GĂ©othermique → Biomasse -- **Fossiles** : Charbon → PĂ©trole → Gaz → Raffinerie → PĂ©trochimie -- **NuclĂ©aire** : Fission → RĂ©acteurs → SĂ©curitĂ© → Fusion → RĂ©acteurs AvancĂ©s -- **Stockage** : Batteries → Supercondensateurs → Stockage Massif - -**Passerelles offertes** : -- → **Moteurs** : [PROTOTYPE] Propulsion Alternative -- → **Électronique** : [PROTOTYPE] Alimentation AvancĂ©e -- → **Armes** : [PROTOTYPE] Armes ÉnergĂ©tiques - -**F. Agriculture & Biotechnologie (~70 techs)** -``` -Cueillette → Agriculture → Élevage → SĂ©lection → MĂ©canisation → OGM → Agriculture Verticale → Bio-usines -``` -Sous-branches : -- **Crops** : CĂ©rĂ©ales → LĂ©gumes → Fruits → Plantes Industrielles → OGM -- **Élevage** : Domestication → SĂ©lection → Élevage Intensif → Clonage -- **Bio-industrie** : Fermentation → Biocarburants → Pharmaceutiques → BiomatĂ©riaux - -**Passerelles offertes** : -- → **MĂ©decine** : [PROTOTYPE] Pharmacologie Militaire -- → **MatĂ©riaux** : [PROTOTYPE] BiomatĂ©riaux -- → **Énergie** : [PROTOTYPE] Biocarburants AvancĂ©s - -**G. MĂ©decine & Sciences de la Vie (~60 techs)** -``` -Herboristerie → Anatomie → Chirurgie → Antibiotiques → MĂ©decine Moderne → GĂ©nĂ©tique → Augmentation -``` -Sous-branches : -- **Diagnostics** : Observation → Rayons X → Scanners → Diagnostics MolĂ©culaires -- **Traitements** : Chirurgie → MĂ©dicaments → ThĂ©rapie GĂ©nique → Nanotechnologie MĂ©dicale -- **Augmentation** : ProthĂšses → Implants → CybernĂ©tique → Enhancement GĂ©nĂ©tique - -**Passerelles offertes** : -- → **Électronique** : [PROTOTYPE] Biocapteurs -- → **MatĂ©riaux** : [PROTOTYPE] MatĂ©riaux Biocompatibles -- → **IA** : [PROTOTYPE] IA MĂ©dicale → IA Militaire - -**H. Sciences Sociales & Organisation (~80 techs)** -``` -Tribus → Villages → CitĂ©s → États → Organisations → Corporations → Gouvernance Mondiale -``` -Sous-branches : -- **Gouvernance** : Monarchie → DĂ©mocratie → Bureaucratie → E-gouvernement -- **Économie** : Troc → Monnaie → Banques → MarchĂ©s → Économie NumĂ©rique -- **Education** : Oral → Écrit → UniversitĂ©s → Recherche → Education de Masse -- **MĂ©dia** : Oral → Écrit → ImprimĂ© → Radio/TV → Internet → RĂ©alitĂ© Virtuelle - -**Passerelles offertes** : -- → **Communication** : [PROTOTYPE] Propagande Moderne -- → **IA** : [PROTOTYPE] IA Sociale -- → **Capteurs** : [PROTOTYPE] Surveillance Sociale - -#### MĂ©caniques SpĂ©ciales de l'Arbre Civil - -**1. DĂ©blocage en Cascade** -Une tech civile peut dĂ©bloquer des passerelles dans **MULTIPLES domaines** : -``` -"Internet" → [PROTOTYPE] RĂ©seaux Militaires (Communication) - → [PROTOTYPE] Guerre Électronique (EW) - → [PROTOTYPE] IA DistribuĂ©e (Électronique) - → [PROTOTYPE] Logistique Intelligente (Transport) -``` - -**2. PrĂ©requis Civils Obligatoires** -Certaines techs militaires **EXIGENT** des bases civiles : -- Armes GuidĂ©es → NĂ©cessite "Électronique Civile" -- VĂ©hicules Autonomes → NĂ©cessite "IA Civile" -- MatĂ©riaux AvancĂ©s → NĂ©cessite "Sciences des MatĂ©riaux" - -**3. Synergie Économie-Recherche** -- Techs civiles influencent la **capacitĂ© Ă©conomique** de production -- Plus de tech civile = plus de **research points** gĂ©nĂ©rĂ©s -- Certaines techs civiles dĂ©bloquent des **bĂątiments de recherche** spĂ©cialisĂ©s - -**4. ÉvĂšnements de Tech-Transfer** -- Events alĂ©atoires : "DĂ©couverte civile" → breakthrough militaire inattendu -- "Dual-use technology" : Tech civile automatiquement adaptĂ©e au militaire -- "Brain-drain" : Scientifiques civils → boost recherche militaire - -#### Exemples Concrets de Passerelles Civile → Militaire - -**Chimie Agricole → Explosifs** : -``` -Agriculture : Engrais AzotĂ©s → [PROTOTYPE] Explosifs Artisanaux - → [PROTOTYPE] Nitrate d'Ammonium → Explosifs Industriels - → [PROTOTYPE] Pesticides → Armes Chimiques - → [PROTOTYPE] Fertilisants → Propergols Roquettes - -PĂ©trochimie : Plastiques → [PROTOTYPE] Explosifs Plastiques - → [PROTOTYPE] PolymĂšres → Propergols Solides - → [PROTOTYPE] Solvants → Carburants Militaires -``` - -**MĂ©decine → Applications Militaires** : -``` -Pharmacologie : AnesthĂ©siques → [PROTOTYPE] Gaz Incapacitants - → [PROTOTYPE] Stimulants → Drogues de Combat - → [PROTOTYPE] Antibiotiques → Protection NBC - -Chirurgie : Traumatologie → [PROTOTYPE] MĂ©decine de Guerre - → [PROTOTYPE] ProthĂšses → Augmentations Militaires - → [PROTOTYPE] AnalgĂ©siques → Stims de Combat -``` - -**Électronique Civile → Militaire** : -``` -TĂ©lĂ©communications : GPS Civil → [PROTOTYPE] Navigation Militaire - → [PROTOTYPE] Satellites → Reconnaissance Spatiale - → [PROTOTYPE] Internet → Cyberguerre - -Gaming : Processeurs Graphiques → [PROTOTYPE] Simulation Balistique - → [PROTOTYPE] RĂ©alitĂ© Virtuelle → EntraĂźnement Militaire - → [PROTOTYPE] IA de Jeu → IA Tactique -``` - -**Transport Civil → Applications Militaires** : -``` -Aviation Civile : Moteurs Civils → [PROTOTYPE] Moteurs Militaires - → [PROTOTYPE] Navigation AĂ©rienne → SystĂšmes Guidage - → [PROTOTYPE] Drones Livraison → Drones Militaires - -Automobile : Moteurs Performance → [PROTOTYPE] VĂ©hicules BlindĂ©s - → [PROTOTYPE] SystĂšmes Hybrides → VĂ©hicules Furtifs - → [PROTOTYPE] Autonomous Cars → VĂ©hicules Autonomes Militaires -``` - -**Sciences des MatĂ©riaux → Applications Militaires** : -``` -Industrie : Alliages LĂ©gers → [PROTOTYPE] Blindages Composites - → [PROTOTYPE] CĂ©ramiques → Plaques Balistiques - → [PROTOTYPE] Fibres Carbone → Casques AvancĂ©s - → [PROTOTYPE] NanomatĂ©riaux → FurtivitĂ© AvancĂ©e - -Construction : BĂ©ton Haute RĂ©sistance → [PROTOTYPE] Bunkers AvancĂ©s - → [PROTOTYPE] Aciers SpĂ©ciaux → Blindages RĂ©actifs -``` - -**Énergie Civile → Applications Militaires** : -``` -NuclĂ©aire Civil : RĂ©acteurs → [PROTOTYPE] Propulsion NuclĂ©aire - → [PROTOTYPE] Isotopes → Armes Radiologiques - → [PROTOTYPE] Fusion ContrĂŽlĂ©e → Armes ThermonuclĂ©aires - -Renouvelables : Panneaux Solaires → [PROTOTYPE] Alimentation Terrain - → [PROTOTYPE] Batteries → SystĂšmes Autonomes - → [PROTOTYPE] Supercondensateurs → Armes ÉnergĂ©tiques -``` - -**Agriculture → Applications Militaires** : -``` -Biotechnologie : GĂ©nĂ©tique VĂ©gĂ©tale → [PROTOTYPE] Bioarmes - → [PROTOTYPE] Fermentation → Production Explosifs - → [PROTOTYPE] Enzymes → DĂ©contamination NBC - -MĂ©canisation : Tracteurs → [PROTOTYPE] VĂ©hicules Logistiques - → [PROTOTYPE] GPS Agricole → Navigation Militaire - → [PROTOTYPE] Drones Agricoles → Surveillance/Attack Drones -``` - -**Total Passerelles Civile → Militaire** : ~40-50 prototypes -- Chaque domaine civil offre 5-8 passerelles militaires -- Certaines techs civiles dĂ©bloquent dans PLUSIEURS domaines militaires -- Progression naturelle : applications civiles → adaptations militaires - -### 1. MĂ©tallurgie & MatĂ©riaux (~300 techs) - -#### Progression Principale Étendue -``` -MĂ©taux de Base → Alliages Simples → Aciers SpĂ©ciaux → MĂ©taux LĂ©gers → Composites → Superalliages → MatĂ©riaux Quantiques → MatĂ©riaux Exotiques -``` - -#### Sous-branches DĂ©taillĂ©es - -**A. MatĂ©riaux Traditionnels & Naturels (70 techs)** -- **MĂ©taux de Base** : Fer → Cuivre → Bronze → Acier → Acier Carbone → Fonte → Acier Doux (10 techs) -- **Alliages Simples** : Laiton → Acier Inox → Chrome → Nickel → Cobalt → Zinc → Étain (10 techs) -- **Aciers SpĂ©ciaux** : Haute RĂ©sistance → Rapide → Inoxydable → Outillage → Ressorts → Maraging (10 techs) -- **Traitements MĂ©talliques** : Trempe → Recuit → CĂ©mentation → Nitruration → Chromage → Galvanisation (10 techs) -- **Bois & DĂ©rivĂ©s** : Bois Massif → ContreplaquĂ© → AgglomĂ©rĂ© → Bois PressĂ© → Bois LamellĂ© → MDF → OSB → Bois TraitĂ© → Bois DensifiĂ© → Bois Composite (15 techs) -- **BĂ©tons & Ciments** : Mortier → BĂ©ton Simple → BĂ©ton ArmĂ© → BĂ©ton PrĂ©contraint → BĂ©ton Romain (Auto-RĂ©parant) → BĂ©ton FibrĂ© → BĂ©ton Ultra-Haute Performance → BĂ©ton Translucide → BĂ©ton Auto-Plaçant → GĂ©opolymĂšres → BĂ©ton LĂ©ger → BĂ©ton Lourd (15 techs) - -**B. MĂ©taux LĂ©gers & AvancĂ©s (40 techs)** -- **Aluminium** : Pur → Alliages 2xxx → 6xxx → 7xxx → AĂ©ronautique → Ultra-LĂ©ger (12 techs) -- **Titane** : Grade 1 → Grade 2 → Ti-6Al-4V → AĂ©rospatial → Bio-compatible → Beta-Titane (12 techs) -- **MagnĂ©sium** : Pur → AZ Series → AM Series → Structural → Ignifuge → Ultra-LĂ©ger (10 techs) -- **Lithium & Rares** : Lithium → BĂ©ryllium → Terres Rares → Scandium → MĂ©taux Exotiques (6 techs) - -**C. MatĂ©riaux Composites (55 techs)** -- **Fibres de Base** : Verre E → Verre S → Carbone T300 → T700 → T800 → Aramide → Basalte → Lin (15 techs) -- **Matrices** : Époxy → Polyester → Vinylester → Thermoplastiques → PEEK → Bio-rĂ©sines (12 techs) -- **Composites AvancĂ©s** : Sandwich → Tissage 3D → Nanotubes → GraphĂšne → Fibres Hybrides → RTM (18 techs) -- **Composites MĂ©talliques** : MĂ©tal-Matrice → CĂ©ramique-MĂ©tal → Hybrides → MMC Aluminium (10 techs) - -**D. MatĂ©riaux Intelligents & Programmables (45 techs)** -- **Smart Materials** : MĂ©moire de Forme → PiĂ©zoĂ©lectriques → MagnĂ©torhĂ©ologiques → ÉlectrorhĂ©ologiques → Thermochromiques (15 techs) -- **NanomatĂ©riaux** : Nanoparticules → Nanotubes → GraphĂšne → FullerĂšnes → Quantum Dots → Nanocomposites (15 techs) -- **MatĂ©riaux Programmables** : Auto-Assemblage → Reconfigurables → Adaptatifs → Morphing → 4D Printing (10 techs) -- **Bio-matĂ©riaux** : Bio-inspirĂ©s → Vivants → Auto-RĂ©parants → Évolutifs → Biocompatibles (5 techs) - -**E. Blindages & Protection (35 techs)** -- **Blindages Passifs** : HomogĂšne → Composite → EspacĂ© → Modulaire → LaminĂ© → Multi-Couches (12 techs) -- **Blindages RĂ©actifs** : ERA → NERA → Smart Armor → Adaptatif → Électrique → MagnĂ©tique (12 techs) -- **Protection AvancĂ©e** : FurtivitĂ© → Multi-Spectral → CamĂ©lĂ©on → Phase-Change → Plasma (11 techs) - -**F. MatĂ©riaux Exotiques & Quantiques (25 techs)** -- **Supraconducteurs** : Haute TempĂ©rature → Ambiants → Quantiques → Organiques → Cuprates (8 techs) -- **MĂ©tamatĂ©riaux** : Optiques → RF → Acoustiques → MĂ©caniques → Plasmoniques → Photoniques (10 techs) -- **MatĂ©riaux Quantiques** : Cristaux Temporels → Topologiques → Plasma → AntimatiĂšre → MatiĂšre Noire → Dimensions SupĂ©rieures → SingularitĂ©s ContrĂŽlĂ©es (7 techs) - -#### Passerelles Offertes Étendues -- → **ChĂąssis** : [PROTOTYPE] ChĂąssis Composite (court-circuite ChĂąssis Moyen) -- → **ChĂąssis** : [PROTOTYPE] ChĂąssis Ultra-LĂ©ger (court-circuite ChĂąssis Lourd) -- → **Armement** : [PROTOTYPE] Canon LĂ©ger (court-circuite Artillerie de Base) -- → **Armement** : [PROTOTYPE] Blindage RĂ©actif (court-circuite Protection Passive) -- → **Électronique** : [PROTOTYPE] Dissipateurs AvancĂ©s -- → **Électronique** : [PROTOTYPE] Supraconducteurs (court-circuite Refroidissement) -- → **Transport** : [PROTOTYPE] VĂ©hicules Ultra-LĂ©gers -- → **Énergie** : [PROTOTYPE] Stockage Supraconducteur -- → **Capteurs** : [PROTOTYPE] Optiques AvancĂ©es - -### 2. ChĂąssis & Structures (~100 techs) - -#### Progression Principale -``` -ChĂąssis LĂ©ger → ChĂąssis Moyen → ChĂąssis Lourd → ChĂąssis BlindĂ© → ChĂąssis Modulaire -``` - -#### Branches Classiques Focus -- **LĂ©gers** : ChĂąssis Scout → ChĂąssis Reconnaissance → ChĂąssis Infiltration (20 techs) -- **Moyens** : ChĂąssis Transport → ChĂąssis Polyvalent → ChĂąssis Support (20 techs) -- **Lourds** : ChĂąssis Bataille → ChĂąssis Assault → ChĂąssis Forteresse (20 techs) - -#### Branches DĂ©bloquĂ©es par Passerelles (40 techs) -- **MĂ©tallurgie** → [PROTOTYPE] ChĂąssis Composite → ChĂąssis Ultra-LĂ©ger → ChĂąssis Furtif -- **Électronique** → [PROTOTYPE] ChĂąssis Smart → ChĂąssis Adaptatif → ChĂąssis IA -- **Moteurs** → [PROTOTYPE] ChĂąssis Performance → ChĂąssis Racing → ChĂąssis HypervĂ©loce - -#### Passerelles Offertes -- → **Armement** : [PROTOTYPE] Tourelles StabilisĂ©es -- → **Capteurs** : [PROTOTYPE] Plateformes Sensorielles - -### 3. Électronique & Informatique (~400 techs) - -#### Progression Principale Étendue -``` -Circuits de Base → Processeurs → IA Basique → IA AvancĂ©e → IA Militaire → IA Autonome → IA Symbiotique → Conscience Artificielle -``` - -#### Sous-branches Massives -- **Processeurs** : CPU → GPU → Quantique → Neuromorphique → Bio-processeurs (80 techs) -- **Capteurs Électroniques** : Optiques → Thermiques → Radars → Multi-spectraux → Quantiques (60 techs) -- **IA & Machine Learning** : Expert Systems → ML → Neural Networks → Deep Learning → AGI (100 techs) -- **MicroĂ©lectronique** : Circuits IntĂ©grĂ©s → Nanopuces → Quantique → MolĂ©culaire (80 techs) -- **SystĂšmes EmbarquĂ©s** : ContrĂŽleurs → Temps RĂ©el → DistribuĂ©s → Autonomes (80 techs) - -#### Passerelles Offertes -- → **Armement** : [PROTOTYPE] Viseurs Intelligents -- → **ChĂąssis** : [PROTOTYPE] ChĂąssis Smart -- → **Communication** : [PROTOTYPE] Guerre Électronique -- → **Capteurs** : [PROTOTYPE] Radars Adaptatifs -- → **Transport** : [PROTOTYPE] VĂ©hicules Autonomes - -### 4. Moteurs & Propulsion (~150 techs) - -#### Progression Principale ResserrĂ©e -``` -Moteurs Diesel → Moteurs Turbo → Moteurs Hybrides → Moteurs Électriques → Propulsion Alternative -``` - -#### Sous-branches Focus -- **Thermiques** : Diesel → Essence → Turbine → Fusion (40 techs) -- **Électriques** : Batteries → Supercondensateurs → Pile Ă  Combustible (35 techs) -- **Hybrides** : SĂ©rie → ParallĂšle → Plug-in → Intelligent (25 techs) -- **Exotiques** : Ionique → Plasma → AntigravitĂ© → Propulsion Spatiale (50 techs) - -#### Passerelles Offertes -- → **ChĂąssis** : [PROTOTYPE] ChĂąssis Performance -- → **Transport** : [PROTOTYPE] Transport Rapide -- → **Aviation** : [PROTOTYPE] Moteurs AĂ©ro -- → **Naval** : [PROTOTYPE] Propulsion Marine - -### 5. Armement & Munitions (~400 techs) - -#### Progression Principale Massive -``` -Armes LĂ©gĂšres → Artillerie → Missiles → Armes GuidĂ©es → Armes Intelligentes → Armes ÉnergĂ©tiques → Armes Exotiques -``` - -#### Sous-branches Ultra-DĂ©taillĂ©es -- **Armes LĂ©gĂšres** : Fusils → Mitrailleuses → Armes SpĂ©cialisĂ©es → Smart Weapons (80 techs) -- **Artillerie** : Canons → Mortiers → Artillery Guided → Railguns → Plasma Cannons (100 techs) -- **Missiles** : Roquettes → Missiles GuidĂ©s → Missiles Intelligents → Essaims → Hypersoniques (120 techs) -- **Armes ÉnergĂ©tiques** : Lasers → Plasma → Particle Beams → Weapons Exotiques (100 techs) - -#### Branches DĂ©bloquĂ©es par Passerelles -- **MĂ©tallurgie** → [PROTOTYPE] Canon LĂ©ger → Artillerie Composite → Canons ElectromagnĂ©tiques -- **Électronique** → [PROTOTYPE] Viseurs Intelligents → Armes Autonomes → Essaims de Combat -- **Moteurs** → [PROTOTYPE] Missiles Hypersoniques → Projectiles CinĂ©tiques - -### 6. Capteurs & Reconnaissance (~200 techs) - -#### Progression Principale -``` -Optiques de Base → Radars → Capteurs Multispectraux → Reconnaissance Satellite → Intel Fusion → Omniscience -``` - -#### Exemple DĂ©taillĂ© : Évolution Radar -- **Proto radar** : Composant 6x6, 2kw, fiabilitĂ© 50% -- **Recherche radar 1** : Composant 5x5, 2kw, fiabilitĂ© 60% + sous-composant Ă©lectronique 4x4, 500w, fiabilitĂ© 20% -- **Recherche radar 2** : Composant 8x3, 1.5kw, fiabilitĂ© 80% -- **Radar AvancĂ©** : Composant 6x2, 1kw, fiabilitĂ© 95% + mode stealth -- **Radar Quantique** : Composant 4x2, 500w, fiabilitĂ© 99% + pĂ©nĂ©tration furtivitĂ© - -### 7. Communication & Guerre Électronique (~100 techs) - -#### Progression Principale Focus -``` -Radio → Communications SĂ©curisĂ©es → RĂ©seaux Tactiques → Guerre Électronique → Cyber Warfare -``` - -#### Sous-branches ConcentrĂ©es -- **Communications** : Radio → CryptĂ© → Satellites → RĂ©seaux Mesh (30 techs) -- **Guerre Électronique** : Jamming → SIGINT → ELINT → Cyber Ops (40 techs) -- **RĂ©seaux** : P2P → Tactiques → StratĂ©giques → Quantiques (30 techs) - -### 8. Transport & Logistique (~60 techs) - -#### Progression Principale Streamline -``` -VĂ©hicules de Base → Transport Lourd → Rail → Transport Maritime → Hyperloop -``` - -#### Sous-branches Essentielles -- **Terrestre** : Camions → Convois → Trains → Hyperloop (20 techs) -- **Maritime** : Cargos → Porte-Conteneurs → Transport Rapide (15 techs) -- **AĂ©rien** : Cargo → Transport StratĂ©gique → Orbital (15 techs) -- **Logistique** : Supply Chains → Distribution → Automation (10 techs) - -### 9. Production & Assembly (~100 techs) - -#### Progression Principale Efficace -``` -Assembly Manuel → Automation → Robotique → Nano-Assembly → Fabrication MolĂ©culaire -``` - -#### Sous-branches Focus -- **Automation** : ChaĂźnes → Robots → IA Production (30 techs) -- **QualitĂ©** : ContrĂŽle → PrĂ©cision → Perfectionnement (25 techs) -- **Vitesse** : Optimisation → ParallĂ©lisation → InstantanĂ© (25 techs) -- **FlexibilitĂ©** : Modulaire → Adaptatif → Reconfigurable (20 techs) - -### 10. Énergie & Alimentation (~100 techs) - -#### Progression Principale CondensĂ©e -``` -GĂ©nĂ©rateurs de Base → Énergie Renouvelable → Batteries AvancĂ©es → Fusion → Anti-matiĂšre -``` - -#### Sous-branches ConcentrĂ©es -- **GĂ©nĂ©ration** : Fossiles → NuclĂ©aire → Fusion → Exotique (35 techs) -- **Renouvelables** : Solaire → Éolien → GĂ©othermique → Bio (25 techs) -- **Stockage** : Batteries → Supercaps → Stockage Massif (25 techs) -- **Distribution** : RĂ©seaux → Smart Grids → Sans-fil (15 techs) - -## MĂ©caniques AvancĂ©es des Passerelles - -### Passerelles Multi-Domaines -Certains prototypes nĂ©cessitent expertise dans **plusieurs domaines** : - -``` -MĂ©tallurgie AvancĂ©e + Électronique → [PROTOTYPE] Armure RĂ©active - → Nouvelle branche : DĂ©fenses Adaptatives - -Moteurs + Communication → [PROTOTYPE] VĂ©hicules CoordinĂ©s - → Branche : Essaims Terrestres - -IA + Capteurs + Armement → [PROTOTYPE] Tourelles Autonomes - → Branche : DĂ©fenses Intelligentes - -MatĂ©riaux + Moteurs + IA → [PROTOTYPE] VĂ©hicules Morphing - → Branche : Technologie Adaptive -``` - -### Profondeur et Distribution Finale -- **Technologies Civiles** : 800 techs (backbone) -- **MĂ©tallurgie & MatĂ©riaux** : 300 techs -- **ChĂąssis & Structures** : 100 techs -- **Électronique & Informatique** : 400 techs -- **Moteurs & Propulsion** : 150 techs -- **Armement & Munitions** : 400 techs -- **Capteurs & Reconnaissance** : 200 techs -- **Communication & Guerre Électronique** : 100 techs -- **Transport & Logistique** : 60 techs -- **Production & Assembly** : 100 techs -- **Énergie & Alimentation** : 100 techs - -**Total estimĂ©** : 2710 technologies + ~300 passerelles inter-domaines = **~3000 technologies** avec progression non-linĂ©aire ultra-riche - -## Interface Utilisateur - Vues Modulaires - -### Principe des Vues FocalisĂ©es -Pour Ă©viter l'overwhelm des 3000 technologies, l'interface propose des **vues modulaires** permettant de se concentrer sur des progressions spĂ©cifiques. - -### Vue "Arbre LinĂ©aire" - -**Fonctionnement** : -1. Player **sĂ©lectionne une tech racine** (ex: "MĂ©taux de Base", "Circuits de Base", "Moteurs Diesel") -2. L'interface affiche **uniquement l'arbre de progression linĂ©aire** Ă  partir de cette racine -3. **Pas de passerelles** affichĂ©es → focus sur la progression naturelle du domaine -4. **SystĂšme Discovery** : Les techs sans breakthrough ne sont **JAMAIS** visibles (principe Ymir) - -### Exemples Concrets - -**Exemple 1 : Tech Racine "MĂ©taux de Base"** -``` -MĂ©taux de Base -├── Fer [RECHERCHÉ] ✅ -├── Cuivre [RECHERCHÉ] ✅ -├── Bronze [DISPONIBLE] 🔓 -├── Acier [DISPONIBLE] 🔓 -├── Acier Carbone [VERROUILLÉ] 🔒 -└── Fonte [INCONNU] ❓ (si toggle OFF) -``` - -**Exemple 2 : Discovery Progressive "Radar"** - -**Run 1 - Player dĂ©butant** : -``` -Proto Radar -├── [RECHERCHÉ] Proto radar (6x6, 2kw, 50% fiabilitĂ©) ✅ -└── [DISPONIBLE] Recherche radar 1 (5x5, 2kw, 60% fiabilitĂ©) 🔓 - -?? Plus de techs radar disponibles ?? -``` - -**Run 2 - Player a fait breakthrough "Scrap Radar Militaire"** : -``` -Proto Radar -├── [RECHERCHÉ] Proto radar ✅ -├── [RECHERCHÉ] Recherche radar 1 ✅ -├── [DISPONIBLE] Recherche radar 2 (8x3, 1.5kw, 80% fiabilitĂ©) 🔓 -└── [BREAKTHROUGH] Radar Militaire (4x4, 1kw, 70% fiabilitĂ©, mode furtif) đŸ”„ - -💡 "Wow ! Je ne savais pas que ça existait !" -``` - -**Run 5 - Player expĂ©rimentĂ©** : -``` -Proto Radar -├── [RECHERCHÉ] Proto radar ✅ -├── [RECHERCHÉ] Recherche radar 1 ✅ -├── [RECHERCHÉ] Recherche radar 2 ✅ -├── [BREAKTHROUGH] Radar Militaire ✅ -├── [BREAKTHROUGH] Radar Adaptatif (dĂ©couvert via scrap drone) đŸ”„ -├── [AVAILABLE] Radar Quantique (dĂ©bloquĂ© par Radar Adaptatif) 🔓 -└── [BREAKTHROUGH] Radar Multispectral (dĂ©couvert via capture satellite) đŸ”„ -``` - -### États des Technologies - -**Couleurs/IcĂŽnes** : -- ✅ **RECHERCHÉ** : Vert, disponible pour utilisation -- 🔓 **DISPONIBLE** : Jaune, peut ĂȘtre recherchĂ© maintenant -- 🔒 **VERROUILLÉ** : Rouge, prĂ©requis manquants -- đŸ”„ **BREAKTHROUGH** : Orange, dĂ©couvert via scrap/capture/Ă©vĂ©nement -- 🔗 **PASSERELLE** : Bleu, accessible via autre domaine (vue sĂ©parĂ©e) - -### ContrĂŽles Interface - -**SĂ©lecteur Tech Racine** : -``` -Domaine: [MĂ©tallurgie â–Œ] -Tech Racine: [MĂ©taux de Base â–Œ] [Alliages Simples â–Œ] [Aciers SpĂ©ciaux â–Œ] -``` - -**Options d'Affichage** : -``` -☑ Montrer prĂ©requis dĂ©taillĂ©s -☑ Montrer coĂ»ts de recherche -☐ Mode compact -``` - -## Breakthrough Tech System (À la Ymir) - -### Principe Fondamental -**TOUTE** technologie nĂ©cessite un **breakthrough** avant d'ĂȘtre recherchable. Pas de tech tree visible - systĂšme de dĂ©couverte organique basĂ© sur l'expĂ©rience de jeu. - -### MĂ©caniques Core - -#### 1. Conditions de Breakthrough -Chaque tech a des **conditions de dĂ©couverte** variĂ©es : - -#### State-Based vs Historic Validation - -**State-Based Conditions (PrĂ©fĂ©rĂ©es)** : -- **Avoir** 5 radars actifs → breakthrough "Radar AvancĂ©" -- **Avoir** 10 usines simultanĂ©ment → breakthrough "Automation Industrielle" -- **Avoir** 20 tourelles dĂ©ployĂ©es → breakthrough "DĂ©fenses IntĂ©grĂ©es" -- **Avoir** 1M€ en banque → breakthrough "Capital Industriel" - -**Historic + Counters (Minimales)** : -- **Total produit** : 1000t acier (compteur cumulatif simple) -- **Designs crĂ©Ă©s** : 50 vĂ©hicules (compteur simple) -- **Ventes cumulĂ©es** : 100k€ sur marchĂ© (compteur simple) - -**Triggers ÉvĂ©nementiels (Pas de stockage)** : -- **Concevoir vĂ©hicule** avec 5+ composants Ă©lectroniques → check immĂ©diat -- **Exporter vers nouveau pays** → check immĂ©diat -- **Rechercher tech** → check dĂ©pendances immĂ©diat - -### Optimisation MĂ©moire - System Design - -#### DonnĂ©es State Actuelles (Toujours en RAM) -```cpp -struct PlayerState { - // Installations actives - int active_radars = 0; - int active_factories = 0; - int deployed_turrets = 0; - - // Finances actuelles - long current_money = 0; - - // Technologies recherchĂ©es (BitSet) - bitset<3000> researched_techs; - - // Pays d'export actifs (Set) - set export_countries; -} -``` - -#### Compteurs Cumulatifs (Minimal Historic) -```cpp -struct LifetimeCounters { - // Production totale (compteurs simples) - long total_steel_produced = 0; - long total_vehicles_designed = 0; - long total_revenue = 0; - - // ÉvĂ©nements majeurs (flags) - bool designed_composite_vehicle = false; - bool designed_autonomous_system = false; - bool exported_to_5_countries = false; -} -``` - -#### Validation en Temps RĂ©el -```cpp -// Trigger immĂ©diat lors d'Ă©vĂ©nements -void OnVehicleDesigned(Design vehicle) { - if (vehicle.hasComponentType(ELECTRONIC) >= 5) { - TriggerBreakthroughCheck("Electronic_Embedded"); - } - - if (vehicle.hasComposite()) { - counters.designed_composite_vehicle = true; - TriggerBreakthroughCheck("Advanced_Protection"); - } -} - -void OnRadarBuilt() { - state.active_radars++; - if (state.active_radars >= 5) { - TriggerBreakthroughCheck("Advanced_Radar"); - } -} -``` - -#### Exemples OptimisĂ©s - -**Breakthrough "Radar AvancĂ©"** : -``` -Conditions: -✅ State: active_radars >= 5 (check continu) -✅ State: researched_techs[RADAR_BASIC] == true -❌ Pas: "avoir dĂ©tectĂ© 100 unitĂ©s" (trop coĂ»teux Ă  tracker) -``` - -**Breakthrough "Automation Industrielle"** : -``` -Conditions: -✅ State: active_factories >= 10 -✅ Counter: total_vehicles_designed >= 100 -✅ Event: designed_autonomous_system == true -``` - -**Breakthrough "Commerce International"** : -``` -Conditions: -✅ State: export_countries.size() >= 5 -✅ Counter: total_revenue >= 1000000 -❌ Pas: "historique des ventes dĂ©taillĂ©" (trop coĂ»teux) -``` - -#### 2. Random Ticker System -- Condition remplie → **random chance** chaque tick de dĂ©couvrir le breakthrough -- ProbabilitĂ© augmente avec le temps (Ă©vite frustration) -- **Pas instantanĂ©** → crĂ©e suspense et anticipation - -#### 3. MĂ©thodes de Force -**Scrap Analysis** : -- Étudier Ă©quipement ennemi → breakthrough garanti (mais coĂ»teux) -- "Tu Ă©tudies ce radar captured → dĂ©couvres Radar Militaire" - -**Reverse Engineering** : -- Acheter produit sur marchĂ© → dĂ©composer → breakthrough -- ConsĂ©quences diplomatiques mais accĂšs garanti - -**Design Study** : -- Analyser designs capturĂ©s → breakthrough composants spĂ©cifiques - -#### 4. Trading de Breakthroughs -**MarchĂ© des connaissances** : -- **Breakthrough ≠ tech researched** → breakthrough = accĂšs Ă  la recherche -- Companies peuvent vendre/acheter l'accĂšs aux recherches -- Prix selon raretĂ© et demande -- CrĂ©Ă© Ă©conomie de l'innovation - -### Exemples Concrets - -#### Progression "Radar" -``` -Base: Proto Radar (toujours disponible) - -Breakthrough "Radar 1": -├── Condition A: Avoir 3 radars opĂ©rationnels pendant 10 jours -├── Condition B: DĂ©tecter 100 unitĂ©s ennemies -└── Force: Scrap "Radar militaire ukrainien" - -Breakthrough "Radar Adaptatif": -├── Condition A: Avoir recherchĂ© Radar 1 + IA Basique -├── Condition B: Concevoir vĂ©hicule avec radar + 3 capteurs -└── Force: Reverse engineer "Radar AESA commercial" - -Breakthrough "Radar Quantique": -├── Condition A: RecherchĂ© Radar Adaptatif + Physique Quantique -├── Condition B: Avoir 50M€ investis en R&D -└── Event: "DĂ©couverte scientifique" (rare, 1-2 niveaux max) -``` - -#### Progression "MĂ©tallurgie" -``` -Base: MĂ©taux de Base (toujours disponible) - -Breakthrough "Aciers SpĂ©ciaux": -├── Condition A: Produire 1000t d'acier standard -├── Condition B: Construire 5 hauts fourneaux -└── Force: Scrap "Blindage de tank" - -Breakthrough "Alliages LĂ©gers": -├── Condition A: Avoir Aciers SpĂ©ciaux + exporter 500t mĂ©tal -├── Condition B: Designer vĂ©hicule nĂ©cessitant poids rĂ©duit -└── Force: Purchase "Alliage aĂ©ronautique" - -Breakthrough "MatĂ©riaux Composites": -├── Condition A: 3 techs mĂ©tallurgie + 2 techs chimie -├── Condition B: Commande client "vĂ©hicule ultra-lĂ©ger" -└── Multiple forces: Scrap composite, reverse engineer, etc. -``` - -### Impacts Gameplay - -#### Discovery Organique -- **Pas de tech tree** → player dĂ©couvre par expĂ©rience -- **Gameplay naturel** → "Je produis → je dĂ©couvre" -- **Surprise constante** → "Oh ! Nouvelle tech disponible !" -- **Emergent progression** → chaque partie unique - -#### Companies IA -- **MĂȘme systĂšme** → IA dĂ©couvre par leurs actions -- **SpĂ©cialisations naturelles** → Company "Metal" dĂ©couvre mĂ©tal faster -- **CompĂ©tition rĂ©aliste** → Qui dĂ©couvre en premier ? -- **Tech transfer** → IA peut vendre breakthroughs au player - -#### Event System -- **Breakthrough events** → dĂ©couvertes alĂ©atoires limitĂ©es (1-2 niveaux max) -- **Scientific conferences** → Ă©change breakthroughs -- **Industrial espionage** → voler breakthroughs competitors -- **Government funding** → accĂ©lĂšre dĂ©couvertes civiles - -### Interface AdaptĂ©e - -#### Vue "Recherches Disponibles" -``` -🔬 RECHERCHES DISPONIBLES -├── Acier SpĂ©cial (MĂ©tallurgie) - 100 unitĂ©s fer + 50 charbon - 3 jours -├── Radar 1 (Capteurs) - 200 composants Ă©lectroniques - 5 jours -└── Moteur Hybride (Propulsion) - 50 batteries + 2 moteurs - 7 jours - -🎯 BREAKTHROUGHS PROCHES (conditions presque remplies) -├── MatĂ©riaux Composites - Recherche 1 tech chimie de plus (2/3) -├── IA Tactique - Construis 3 vĂ©hicules autonomes de plus (2/5) -└── DĂ©fenses AvancĂ©es - Produis 200 tourelles de plus (150/350) - -💡 BREAKTHROUGH FORCÉ -├── Analyse Scrap: Tank T-72 → "Blindage RĂ©actif" (coĂ»t: 5000€) -├── Reverse Engineer: GPS Civil → "Navigation PrĂ©cise" (coĂ»t: 2000€) -└── Achat Intel: Thales → "Radar AESA" (coĂ»t: 50000€) -``` - -#### DĂ©couverte en Jeu -``` -🎉 BREAKTHROUGH DÉCOUVERT ! -"MatĂ©riaux Composites" - -DĂ©bloquĂ© grĂące Ă : Production de 1000t d'acier + 3 techs chimie - -Nouvelles recherches disponibles: -‱ Blindage Composite (15 jours, matĂ©riaux avancĂ©s) -‱ ChĂąssis Ultra-LĂ©ger (10 jours, fibres carbone) -‱ Structures Adaptatives (20 jours, smart materials) -``` - -### Avantages SystĂšme - -✅ **DĂ©couverte naturelle** : Tech emerge du gameplay -✅ **Pas d'overwhelm** : Seules techs pertinentes visibles -✅ **RejouabilitĂ© infinie** : Chaque run = dĂ©couvertes diffĂ©rentes -✅ **Économie innovation** : MarchĂ© des breakthroughs -✅ **Emergent strategy** : SpĂ©cialisations naturelles -✅ **Surprise constante** : Toujours de nouvelles possibilitĂ©s -✅ **Realistic progression** : Comme vraie R&D industrielle - -**C'est EXACTEMENT le systĂšme qu'il faut pour 3000 techs !** đŸ”„ - -### Vue "Passerelles" (SĂ©parĂ©e) - -**But** : Montrer les **court-circuits possibles** depuis autres domaines -``` -Tech Cible: "ChĂąssis Composite" - -Passerelles disponibles: -← MĂ©tallurgie : "Composites AvancĂ©s" → [PROTOTYPE] ChĂąssis Composite -← Civil : "MatĂ©riaux Industriels" → [PROTOTYPE] ChĂąssis Composite -← Énergie : "MatĂ©riaux LĂ©gers" → [PROTOTYPE] ChĂąssis Composite - -Status: 2/3 passerelles dĂ©bloquĂ©es ✅ -``` - -### Navigation Inter-Domaines - -**Links intelligents** : -- Tech montre ses **dĂ©pendances externes** : "NĂ©cessite: Électronique de Base" -- **Click** → switch automatique vers vue Électronique > Circuits de Base -- **Breadcrumb** : MĂ©tallurgie > MĂ©taux de Base ← **Électronique > Circuits de Base** - -### Vue "Action ImmĂ©diate" (Style Factorio) - -**Focus** : "**QU'EST-CE QUE JE PEUX FAIRE MAINTENANT ?**" - -**Structure verticale** : -``` -🚀 RECHERCHES DISPONIBLES (Clique pour lancer) -├── Acier (MĂ©tallurgie) - 50 points tech - 2min -├── Radar 1 (Capteurs) - 75 points tech - 3min -├── Moteur Hybride (Propulsion) - 100 points tech - 5min -└── BĂ©ton ArmĂ© (Civil) - 25 points tech - 1min - -🔬 BREAKTHROUGHS POSSIBLES (Via scrap/capture) -├── Explosifs Plastiques ← Scrap: RPG-7 (x3 disponible) -├── Blindage Composite ← Capture: Bradley M2 -└── IA Tactique ← Scrap: Drone FPV (x12 disponible) - -📚 DÉJÀ RECHERCHÉ (Masquer/Montrer) -├── ✅ MĂ©taux de Base, Fer, Cuivre, Bronze... -├── ✅ Circuits de Base, Transistors, Processeurs... -├── ✅ Moteurs Diesel, Essence, Turbo... -└── [147 technologies researched] [Voir toutes â–Œ] - -🔒 PAS ENCORE ACCESSIBLE -├── Radar 2 → NĂ©cessite: Radar 1 -├── Missiles GuidĂ©s → NĂ©cessite: Électronique AvancĂ©e -└── ChĂąssis Composite → NĂ©cessite: MatĂ©riaux Composites - (ou PASSERELLE via MĂ©tallurgie AvancĂ©e) -``` - -**PrioritĂ© visuelle** : -- **ÉNORME** : Recherches disponibles (ce qu'il peut faire NOW) -- **Moyen** : Breakthroughs (opportunitĂ©s spĂ©ciales) -- **Petit/CollapsĂ©** : DĂ©jĂ  recherchĂ© (juste pour rĂ©fĂ©rence) -- **Gris** : Pas accessible (avec hints sur comment dĂ©bloquer) - -### Vue "Dashboard Personnel" - -**RĂ©sumĂ© progression** : -``` -Domaines actifs: -🔬 MĂ©tallurgie [●●●○○] 12/20 techs recherchĂ©es -⚡ Électronique [●●○○○] 8/25 techs recherchĂ©es -đŸ—ïž ChĂąssis [●○○○○] 3/15 techs recherchĂ©es - -Prochaines recommandations: -🎯 Acier (complĂšte ta ligne MĂ©taux) -🎯 Radar 1 (amĂ©liore tes drones) -🎯 Moteur Hybride (unlock ChĂąssis Performance) -``` - -### Interface Principale : 2 Onglets - -**🎯 Onglet "ACTION"** (Vue Action ImmĂ©diate) -- **Utilisation** : 80% du temps → "Qu'est-ce que je peux faire ?" -- **Layout** : Vertical, prioritĂ© visuelle sur le disponible -- **Click & Go** : Lancer recherche directement - -**🌳 Onglet "EXPLORATION"** (Vue Arbre LinĂ©aire) -- **Utilisation** : 20% du temps → "OĂč est-ce que je vais ?" -- **Layout** : Horizontal, focus sur progression -- **Planning** : Voir les chemins futurs - -### Workflow Player Typique - -1. **Ouvre l'onglet ACTION** → voit 4-6 recherches disponibles -2. **Lance une recherche** → continue Ă  jouer -3. **Research terminĂ©e** → notification + retour onglet ACTION -4. **Nouvelles options** apparaissent → cycle continue - -Occasionnellement : -- **Switch vers EXPLORATION** → "Hmm, comment j'arrive aux missiles ?" -- **SĂ©lectionne racine "Armement"** → voit le chemin -- **Retour ACTION** → focus sur les Ă©tapes immĂ©diates - -### Avantages SystĂšme - -✅ **No overwhelm** : Player voit 5-15 techs max par vue -✅ **Focus** : Progression claire dans un domaine -✅ **Discovery** : Nouvelles techs rĂ©vĂ©lĂ©es progressivement -✅ **FlexibilitĂ©** : Peut explorer diffĂ©rentes racines -✅ **Passerelles** : Vue sĂ©parĂ©e pour les court-circuits -✅ **Context** : Toujours savoir oĂč on en est -✅ **Action immĂ©diate** : 1 click = lancer recherche -✅ **Style Factorio** : Interface familiĂšre et efficace - -**C'est exactement l'UX qu'il faut pour 3000 techs !** 🎯 - ---- - -*Ce document sera complĂ©tĂ© avec les dĂ©tails de chaque domaine technologique* \ No newline at end of file diff --git a/docs/04-reference/coherence-problem.md b/docs/04-reference/coherence-problem.md deleted file mode 100644 index a48fc54..0000000 --- a/docs/04-reference/coherence-problem.md +++ /dev/null @@ -1,486 +0,0 @@ -# ProblĂšmes de CohĂ©rence - Documentation Warfactory - -*Analyse mĂ©thodique des incohĂ©rences et contradictions dans la documentation* - -## Contradictions Techniques Majeures - -### 1. **Architecture vs Performance Claims** ✅ RÉSOLU -**ProblĂšme original** : L'architecture dĂ©crit 10 engines sĂ©parĂ©s communiquant via Redis pub/sub et HTTP, mais revendique simultanĂ©ment des performances C++/C/ASM pour "simulation temps rĂ©el complexe + milliers d'unitĂ©s." - -**Solution clarifiĂ©e** : -- **War Engine self-contained** : Auto-battler avec stocks embarquĂ©s, ~500 unitĂ©s actives simultanĂ©es -- **Communication par waves** : Pulls non temps rĂ©el, Ă©vite spam messages Redis -- **Latence assumĂ©e comme feature** : DĂ©lais logistiques intĂ©grĂ©s au gameplay pour rĂ©alisme -- **Autonomie engines** : Continuent avec derniĂšres donnĂ©es si communication coupĂ©e - -**CohĂ©rence restaurĂ©e** : Performance temps rĂ©el pour combat local + communication distribuĂ©e pour coordination macro = architecture viable. - -### 2. **Factory Benchmarking System - ImplĂ©mentĂ© vs SpĂ©culatif** ✅ RÉSOLU -**ProblĂšme original** : L'architecture prĂ©sente le factory benchmarking comme une fonctionnalitĂ© implĂ©mentĂ©e, tandis que gameplay-industriel le dĂ©crit comme spĂ©culatif. - -**Solution adoptĂ©e** : FonctionnalitĂ© entiĂšre reportĂ©e en long-term update -- Status uniforme : "Long-term Update" dans tous les documents -- Justification : Optimisation prĂ©maturĂ©e, focus sur gameplay core d'abord -- Concept conservĂ© pour dĂ©veloppement futur - -**CohĂ©rence restaurĂ©e** : Plus de contradiction entre documents sur le status d'implĂ©mentation. - -### 3. **DĂ©finitions de Taille de Chunk et Resource Patches** ✅ RÉSOLU -**ProblĂšme original** : Contradiction entre resource chunks 64x64 (systemes-techniques) et resource patches de forme libre (map-system). - -**Solution adoptĂ©e** : -- **Resource chunks supprimĂ©s** de systemes-techniques.md -- **Resource patches uniquement** : SystĂšme Factorio-like avec formes libres non-alignĂ©es -- **Architecture chunks clarifiĂ©e** : Multi-Ă©chelle pour diffĂ©rents types de donnĂ©es - - 512x512 : landId (terrain) - - 256x256 : buildingPtr (bĂątiments) - - 128x128 : effectId (effets) - - 64x64 : Chunk principal gameplay (map-system) - -**CohĂ©rence restaurĂ©e** : Plus de contradiction resource chunks vs patches, architecture multi-Ă©chelle documentĂ©e. - -## ProblĂšmes d'Échelle et de Scope - -### 4. **Crise de DĂ©couvrabilitĂ© de l'Arbre Technologique** ✅ INVALIDÉ -**ProblĂšme original** : Revendique 3000+ technologies avec dĂ©couverte gatĂ©e par breakthrough, crĂ©ant une courbe d'apprentissage impossible. - -**Analyse erronĂ©e** : La critique Ă©tait basĂ©e sur incomprĂ©hension du systĂšme breakthrough "Natural" - -**Documentation existante** : -- **metriques-joueur.md** : "Sources de dĂ©couverte : Ratio Scrap vs Natural vs Events vs Purchase" -- **arbre-technologique.md** : "dĂ©couvert via scrap/capture/Ă©vĂ©nement" + "Trigger immĂ©diat lors d'Ă©vĂ©nements" -- **architecture-technique.md** : Event Engine gĂšre "breakthrough_event → Designer, Economy" - -**SystĂšme rĂ©el** : Breakthroughs "Natural" = Ă©vĂ©nement-driven automatiques -- Combat → breakthrough armor automatique ("Better Tank Armor" se dĂ©bloque naturellement quand tanks prennent dĂ©gĂąts) -- Production → breakthrough efficiency automatique -- Observation → breakthrough reverse engineering automatique - -**CohĂ©rence confirmĂ©e** : 3000 techs accessibles via gameplay naturel, pas de courbe d'apprentissage impossible. - -### 5. **ComplexitĂ© Design Militaire vs FaisabilitĂ© Gameplay** ✅ INVALIDÉ -**ProblĂšme original** : Le systĂšme de design de vĂ©hicules est si complexe qu'il serait injouable. - -**Analyse erronĂ©e** : Critique basĂ©e sur lecture superficielle ignorant les mĂ©caniques d'accessibilitĂ© - -**ÉlĂ©ments ratĂ©s dans l'analyse initiale** : -- **SystĂšme 2D** : Plus simple et lisible que design 3D -- **Progression tech-gated** : Commence avec composants simples (Gen1), complexitĂ© progressive -- **Premier vĂ©hicule** : Moteur + cargo + siĂšge = 10-20min, pas 1500 composants -- **Blueprints multi-Ă©chelles** : 4 niveaux (Micro/Layer/System/Vehicle) avec drag&drop -- **Workshop communautaire** : Blueprints partagĂ©s, systĂšme optionnel -- **Assistance IA** : Designer Engine peut crĂ©er vĂ©hicules automatiquement - -**Documentation complĂšte existante** : -- Gen1 "simples, rĂ©parables" vs Gen4 complexes -- Interface blueprints avec drag&drop documentĂ©e -- Exemples visuels progression (rectangle simple → formes complexes) -- SystĂšme amĂ©lioration avec diminishing returns clairement expliquĂ© - -**Comparaison corrigĂ©e** : MĂȘme principe que Factorio (simple → complexe progressif) - -**CohĂ©rence confirmĂ©e** : SystĂšme accessible dĂ©butants + profond experts, dĂ©veloppement itĂ©ratif par Ă©quipe (Claudes đŸ€–). - -### 6. **InadĂ©quation d'Échelle Économique** ✅ RÉSOLU -**ProblĂšme original** : L'Ă©chelle de production ne correspond pas Ă  l'Ă©chelle Ă©conomique. - -**Solution clarifiĂ©e** : Le jeu est un bac Ă  sable oĂč le joueur choisit librement son Ă©chelle d'opĂ©ration -- **Spectrum complet** : Du petit artisan local au gĂ©ant multinational concurrent de Thales/Lockheed Martin -- **Aucune progression forcĂ©e** : Le joueur peut rester petit artisan toute la partie s'il le souhaite -- **Reconversion industrielle** : DifficultĂ© basĂ©e sur similaritĂ© des processus (tables→blindages facile, tables→canons complexe) -- **FlexibilitĂ© par design** : Le joueur dĂ©finit ses ambitions selon ses prĂ©fĂ©rences - -**Documentation mise Ă  jour** : Section "Philosophie Bac Ă  Sable" ajoutĂ©e Ă  gameplay-industriel.md - -**CohĂ©rence restaurĂ©e** : L'exemple "tables fer" illustrait la flexibilitĂ© de reconversion, pas une incohĂ©rence d'Ă©chelle. - -## IntĂ©grations Critiques Manquantes - -### 7. **ResponsabilitĂ©s des Engines IndĂ©finies** -**ProblĂšme** : Pas de mapping clair entre les engines architecturaux et les systĂšmes de gameplay actuels. - -**Fichiers** : `architecture-technique.md`, tous les docs gameplay - -**Pourquoi c'est un problĂšme** : L'architecture dĂ©crit 10 engines mais n'explique pas comment les systĂšmes de gameplay complexes (comme les features company, design vĂ©hicules, ou breakthroughs technologiques) mappent sur ces engines. - -### 8. **Isolation du SystĂšme de Points d'Administration** ✅ RÉSOLU -**ProblĂšme original** : Le systĂšme complexe de points d'administration n'apparaĂźt que dans un seul document. - -**Solution clarifiĂ©e** : MacroEntity Engine gĂšre entiĂšrement le systĂšme d'administration -- **Architecture intĂ©grĂ©e** : MacroEntity Engine responsable companies/Ă©tats + pools administration -- **Communication** : Autres engines consultent admin via API, actions refusĂ©es si exhaustĂ© -- **Isolation assumĂ©e** : SystĂšme admin isolĂ© par design, seul MacroEntity Engine l'utilise -- **Performance** : Calculs lĂ©gers, batch processing, rythme bas adaptĂ© gameplay macro -- **Joueur exempt** : Pas de contraintes administration pour le joueur -- **Équilibrage** : CoĂ»ts admin recherche faibles pour ne pas freiner progression tech - -**Documentation mise Ă  jour** : Architecture-technique.md et questions-ouvertes.md - -**CohĂ©rence restaurĂ©e** : SystĂšme administration correctement intĂ©grĂ© dans l'architecture multi-engines. - -### 9. **Conflit Designer Engine vs Design Joueur** ✅ RÉSOLU -**ProblĂšme original** : Peu clair comment le design IA de vĂ©hicules (Designer Engine) coexiste avec le design manuel joueur. - -**Solution clarifiĂ©e** : -- **MĂȘme systĂšme** : IA et joueur utilisent le Designer Engine identique -- **ProcĂ©dural vs Manuel** : IA utilise random generation + evaluate, joueur design manuellement -- **Assistance joueur** : Joueur peut utiliser l'IA design du Designer Engine -- **Blueprints doctrinaux** : Grilles efficaces (dev, captures, retex) guident gĂ©nĂ©ration IA -- **Company features** : Influencent choix procĂ©duraux IA (modify vs nouveau design) -- **Évaluation viabilitĂ©** : Check automatique "design viable ?" (tank 1km/h = reject) - -**CohĂ©rence restaurĂ©e** : Designer Engine unifiĂ© sert joueur ET IA avec mĂ©thodes diffĂ©rentes mais systĂšme commun. - -## ImpossibilitĂ©s Architecturales - -### 10. **Terminaux Idiots vs Streaming Carte Complexe** ✅ RÉSOLU -**ProblĂšme original** : Les clients dĂ©crits Ă  la fois comme "terminaux idiots" et gĂ©rant un streaming carte complexe. - -**Solution clarifiĂ©e** : Architecture Smart Client / Authoritative Server -- **Client Smart** : Interface complexe, rendu 2D optimisĂ©, streaming carte intelligent, cache local -- **Client Dumb** : Aucune simulation gameplay, pas de logique mĂ©tier, pas d'Ă©tat de jeu -- **ResponsabilitĂ©s claires** : UI/rendu cĂŽtĂ© client, simulation cĂŽtĂ© serveur -- **Anti-cheat naturel** : Server authoritative pour toute logique mĂ©tier -- **Performance** : Cache client pour UI rĂ©active, LOD et culling cĂŽtĂ© client - -**Documentation mise Ă  jour** : Architecture-technique.md et questions-ouvertes.md - -**CohĂ©rence restaurĂ©e** : Terminologie prĂ©cise remplace "dumb terminal" rĂ©ducteur. - -### 11. **Engines Autonomes vs Coordination Centrale** ✅ RÉSOLU -**ProblĂšme original** : Les engines dĂ©crits comme autonomes mais nĂ©cessitant coordination centrale. - -**Solution clarifiĂ©e** : Central Coordinator est un Meta Orchestrator aveugle au gameplay -- **Engines 100% autonomes** : Toute logique gameplay, communication directe Redis -- **Coordinator ultra-limitĂ©** : Bootstrap, health ping, time sync, shutdown -- **Aveugle total** : Ne connaĂźt rien des mĂ©caniques de jeu, pure infrastructure -- **Post-bootstrap** : Coordinator passif, engines communiquent directement -- **Crash-safe** : Coordinator down = invisible pour gameplay, engines continuent -- **Lifecycle only** : Start/stop, unload map (quit partie), rien d'autre - -**Documentation mise Ă  jour** : Architecture-technique.md clarifiĂ©e - -**CohĂ©rence restaurĂ©e** : Pas de contradiction - engines autonomes + orchestrator infrastructure dumb. - -### 12. **Performance Temps RĂ©el vs Architecture DistribuĂ©e** ✅ RÉSOLU - Voir P1 -**ProblĂšme original** : Exigences temps rĂ©el incompatibles avec l'architecture distribuĂ©e proposĂ©e. - -**Solution** : ProblĂšme dĂ©jĂ  rĂ©solu dans P1 - Architecture vs Performance Claims -- **War Engine self-contained** : Auto-battler autonome, ~500 unitĂ©s actives simultanĂ©es -- **Communication async** : Pulls par waves, pas de coordination temps rĂ©el requise -- **Performance isolĂ©e** : War Engine indĂ©pendant = pas de bottleneck rĂ©seau -- **Distribution pour le reste** : Economy, Operation, etc. peuvent ĂȘtre async - -**CohĂ©rence confirmĂ©e** : P12 Ă©tait un doublon de P1 sous angle diffĂ©rent. - -## InadĂ©quation Narrative vs Scope Technique - -### 13. **Focus Ukraine vs MĂ©caniques Globales** ✅ INVALIDÉ -**ProblĂšme supposĂ©** : Le contexte narratif est entiĂšrement focalisĂ© Ukraine tandis que les mĂ©caniques de jeu sont globales. - -**Analyse erronĂ©e** : Aucune contradiction rĂ©elle identifiĂ©e - -**SystĂšme rĂ©el** : Richesse gĂ©ographique comme feature majeure -- **Ukraine dense/Ă©pique** : "Slava Ukraini" - high stakes, rĂ©sistance hĂ©roĂŻque, complexitĂ© diplomatique -- **Congo/Sahara dĂ©tente** : Mad Max warlords, contrĂŽle ressources miniĂšres, sandbox pur -- **MĂȘme systĂšme unifiĂ©** : Supporte expĂ©riences totalement diffĂ©rentes selon mood joueur -- **Hommage renforcĂ©** : Choisir Ukraine = respect, pas limitation technique - -**Richesse du design** : Player peut alterner entre intensitĂ© Ukraine et dĂ©tente sahĂ©lienne - -**CohĂ©rence confirmĂ©e** : SystĂšme global enrichit l'expĂ©rience, pas de contradiction narrative. - -## Lacunes Logiques - -### 14. **Lacune Logique Stabilisation Factory** ✅ RÉSOLU -**ProblĂšme original** : Les systĂšmes factory sensibles Ă  la qualitĂ© ne peuvent pas devenir de simples lookup tables. - -**Solution clarifiĂ©e** : Skip vs Optimize Trade-off par design -- **Factory tout-en-un** : Lookup tables disponibles mais efficacitĂ© mĂ©diocre -- **Factory Factorio** : Placement prĂ©cis, qualitĂ©, thermique pour efficacitĂ© maximale -- **Player choice** : CommoditĂ© vs performance selon mood/skill/temps -- **Principe gĂ©nĂ©ral** : "Tous les systĂšmes du jeu doivent pouvoir ĂȘtre skippĂ©s" -- **AccessibilitĂ© + Depth** : Noobs peuvent skip, pros peuvent optimiser - -**Design philosophy** : Trade-off intentionnel, pas contradiction logique - -**CohĂ©rence restaurĂ©e** : Coexistence lookup tables et depth gameplay via player choice. - -### 15. **Lacune Logique SystĂšme de Recherche** ✅ OBSOLÈTE -**ProblĂšme supposĂ©** : Le systĂšme de recherche dual (points vs XP+scrap) crĂ©e des chevauchements confus. - -**SystĂšme actuel** : Plus d'actualitĂ© - Ă©volution design -- **Breakthrough system** : Event-driven, scrap analysis, recherche avancĂ©e -- **Conversion 50% XP** : Artefact documentation, systĂšme abandonnĂ© -- **Restrictions domaines** : Plus dans design final -- **Research paths** : SystĂšme simplifiĂ© et cohĂ©rent - -**CohĂ©rence confirmĂ©e** : ProblĂšme rĂ©solu par Ă©volution du design, plus de contradiction. - -## Nouveaux ProblĂšmes IdentifiĂ©s (Analyse DĂ©cembre 2024) - -### 16. **Contradiction MĂ©triques vs Architecture DistribuĂ©e** ✅ RÉSOLU -**ProblĂšme original** : Le systĂšme de mĂ©triques nĂ©cessite une collecte centralisĂ©e massive qui contredit l'architecture distribuĂ©e autonome. - -**Solution clarifiĂ©e** : Intelligence Engine collecte les mĂ©triques Ă©conomiques -- **Intelligence Engine Ă©tendu** : Reconnaissance militaire + mĂ©triques Ă©conomiques/industrielles -- **Volume gĂ©rable** : 7.75 MB/heure pour engine d'analyse spĂ©cialisĂ© -- **Pull-based** : Intelligence Engine interroge autres engines via HTTP GET /metrics -- **Engines autonomes** : RĂ©pondent aux queries metrics mais s'en foutent du collecteur -- **CohĂ©rence thĂ©matique** : Intel militaire + analyse Ă©conomique = mĂȘme domaine data analysis -- **Pas de SPOF critique** : Si Intelligence Engine crash, gameplay continue - -**Documentation Ă  mettre Ă  jour** : Architecture-technique.md et metriques-joueur.md - -**CohĂ©rence restaurĂ©e** : Collection mĂ©triques intĂ©grĂ©e dans architecture distribuĂ©e sans casser autonomie. - -### 17. **IncohĂ©rence SystĂšme Administration vs Performance Temps RĂ©el** ✅ INVALIDÉ -**ProblĂšme supposĂ©** : Points d'administration avec calculs complexes contredisent performances temps rĂ©el C++/ASM. - -**Analyse erronĂ©e** : Malentendu sur la frĂ©quence rĂ©elle des actions - -**SystĂšme rĂ©el clarifiĂ©** : -- **Rythme macro** : ~1 action tous les 3-5 jours par company (pas frĂ©nĂ©tique) -- **Volume computational** : ~0.33 actions/seconde pour 1000 companies = dĂ©risoire -- **Performance impact** : 20 vĂ©rifications/minute = nĂ©gligeable vs temps rĂ©el -- **1 jour = 10 minutes rĂ©elles** : Administration suit rythme stratĂ©gique lent - -**Documentation mise Ă  jour** : FrĂ©quence actions clarifiĂ©e dans mecaniques-jeu.md - -**CohĂ©rence confirmĂ©e** : SystĂšme administration compatible avec performance temps rĂ©el. - -### 18. **Scope Mismatch: Arbre Technologique vs SystĂšme Breakthrough** ✅ INVALIDÉ -**ProblĂšme supposĂ©** : 3000 technologies annoncĂ©es vs systĂšme breakthrough organique qui ne peut supporter ce volume. - -**Analyse erronĂ©e** : Assumptions techniques incorrectes sur scaling - -**SystĂšme rĂ©el** : Breakthrough system peut scaler Ă  3000 techs -- **Prerequisites gating** : Seulement ~10-50 techs eligible simultanĂ©ment, pas 3000 -- **Ticker optimisĂ©** : Check conditions toutes les minutes, pas 60fps -- **Conditions on-demand** : Query engines ponctuellement, pas polling constant -- **Scrap analysis** : Utile early game uniquement (rattrapage tech), mid/late = autres sources -- **Interface proven** : Factorio gĂšre 100+ techs, design for scale = standard practice -- **Design philosophy** : Player ne recherche PAS tout - chaque run = dĂ©couvertes diffĂ©rentes, combinaisons nouvelles, rejouabilitĂ© - -**CohĂ©rence confirmĂ©e** : Breakthrough system compatible avec 3000 technologies via design appropriĂ©. - -### 19. **Contradiction Gameplay Skip vs SystĂšme de QualitĂ©** ✅ INVALIDÉ -**ProblĂšme supposĂ©** : Philosophie "tous systĂšmes skippables" contredit mĂ©caniques qualitĂ© militaire obligatoires. - -**Analyse erronĂ©e** : Ignorait l'Ă©conomie comme solution de skip - -**SystĂšme rĂ©el** : Skip disponible via marketplace Ă©conomique -- **Player skip** : AchĂšte vĂ©hicules aux IA companies (Thales, Lockheed, etc.) -- **Templates prĂ©conçus** : IA a rĂ©solu placement/synergies/thermique selon mĂȘmes rĂšgles -- **Player optimize** : Design manuel pour performance supĂ©rieure avec skill/temps -- **MĂȘme contraintes** : IA doit respecter rĂšgles qualitĂ©, player peut faire mieux -- **Player choice** : CommoditĂ© (achat IA) vs performance (design manuel) selon prĂ©fĂ©rences - -**CohĂ©rence confirmĂ©e** : Principe skip vs optimize s'applique au militaire via Ă©conomie. - -### 20. **IncohĂ©rence Map System Local vs Global Combat** ✅ INVALIDÉ -**ProblĂšme supposĂ©** : Chunks 64x64 pour combat local vs promesse batailles "milliers d'unitĂ©s". - -**Analyse erronĂ©e** : Assumait 1 bataille = 1 chunk, ignorait systĂšme global - -**SystĂšme rĂ©el** : Batailles multi-chunks et guerre persistante -- **Frontlines Ă©tendues** : Batailles s'Ă©tendent sur dizaines/centaines de chunks simultanĂ©ment -- **Guerre persistante** : Bataille dure 1 an dans le monde (ex: player base Bakhmut = 1 an combat) -- **SystĂšme total** : "Milliers d'unitĂ©s" = capacitĂ© systĂšme global, pas bataille locale -- **RĂ©partition rĂ©aliste** : ~500 unitĂ©s War Engine dispersĂ©es sur grande zone gĂ©ographique -- **Chunk 64x64** = unitĂ© streaming/gameplay, pas limite bataille - -**CohĂ©rence confirmĂ©e** : Échelle map locale compatible avec systĂšme combat global Ă©tendu. - -### 21. **Contradiction Ressources Patches vs Infrastructure Processing** ✅ INVALIDÉ -**ProblĂšme supposĂ©** : Resource patches formes libres contredisent infrastructure Factorio-like qui nĂ©cessite alignement grille. - -**Analyse erronĂ©e** : ProblĂšme de formulation dans documentation - -**SystĂšme rĂ©el clarifiĂ©** : Patches alignĂ©s sur grille tiles, pas sur chunks -- **Grid-aligned** : Patches alignĂ©s sur grille tiles 1x1 (mining drills compatible) -- **Forme libre** : Shape non-rectangulaire (L, C, etc.) mais toujours sur grille -- **Infrastructure standard** : Belts, drills, pipelines fonctionnent normalement -- **Pas chunk-aligned** : Patches peuvent dĂ©border sur plusieurs chunks (pas problĂšme) -- **Placement optimal** : Calculs gĂ©omĂ©triques standard sur grille rĂ©guliĂšre - -**Documentation mise Ă  jour** : Clarification grid-aligned vs chunk-aligned dans map-system.md - -**CohĂ©rence confirmĂ©e** : Infrastructure Factorio-like compatible avec patches organiques grid-aligned. - -### 22. **Volume DonnĂ©es MĂ©triques vs Architecture Multi-Joueur** ✅ RÉSOLU -**ProblĂšme original** : 3.1GB mĂ©triques par partie incompatible avec multijoueur. - -**Solution implĂ©mentĂ©e** : Scaling adaptatif et data sharing intelligent -- **Joueurs mĂȘme company** : Data partagĂ©e - 1 seul dataset 3.1GB pour toute la company -- **Free-for-all scaling** : Points rĂ©duits proportionnellement au nombre de companies - - **1 company** : 2 points/min (granularitĂ© fine) - - **5 companies** : 0.4 points/min (granularitĂ© rĂ©duite) - - **Minimum** : 0.25 points/min (seuil qualitĂ© acceptable) -- **Volume constant** : ~3.1GB total mĂȘme avec 10 joueurs/companies -- **Intelligence Engine** : Collecte adaptĂ©e selon configuration multijoueur - -**Architecture supportĂ©e** : Redis/network gĂšre volume constant via scaling intelligent - -**CohĂ©rence restaurĂ©e** : SystĂšme mĂ©triques compatible multijoueur via adaptation granularitĂ©. - -### 23. **Contradiction Points Budget GĂ©nĂ©ration vs VariabilitĂ© Infinie Promise** ✅ RÉSOLU -**ProblĂšme original** : GĂ©nĂ©ration procĂ©durale promettait scores -6 Ă  +6 (13 valeurs) avec ~40 Ă©lĂ©ments = quelques milliers de combinaisons, pas millions. - -**Solution implĂ©mentĂ©e** : Expansion massive du systĂšme de gĂ©nĂ©ration -- **Budget Ă©tendu** : -10 Ă  +10 (21 valeurs cibles) avec distribution en cloche -- **218 Ă©lĂ©ments** : 6 catĂ©gories complĂštes (gĂ©ologiques, aquatiques, terrestres, cĂŽtiĂšres, industrielles, militaires, culturelles, biomes, climatiques, anthropiques, mystĂ©rieux) -- **Combinatoire explosive** : C(218,2-4) × 21 scores = **~2 milliards de configurations uniques** -- **Distribution rĂ©aliste** : 30% neutre, 40% commun (±1-3), 20% remarquable (±4-6), 8% exceptionnel (±7-8), 2% lĂ©gendaire (±9-10) - -**RĂ©sultat** : Promesse "millions de combinaisons" largement dĂ©passĂ©e avec plusieurs milliards de variantes possibles. - -**CohĂ©rence restaurĂ©e** : SystĂšme procĂ©dural supporte variabilitĂ© massive promise. - -### 24. **IncohĂ©rence Designer Engine Time-Budget vs Performance Temps RĂ©el** ❌ INVALIDÉ -**ProblĂšme original** : Mauvaise interprĂ©tation - "1-2 tetris par tick" Ă©tait supposĂ© ĂȘtre × 1000 companies = 120k opĂ©rations/seconde. - -**Clarification** : -- **"1-2 design/tick"** = performance globale du systĂšme, pas par company -- **Total mondial** : 1-2 nouveaux designs crĂ©Ă©s dans le monde entier par tick -- **Charge rĂ©elle** : 1-2 opĂ©rations/tick Ă  60fps = 60-120 opĂ©rations/seconde maximum -- **Parfaitement viable** : Volume trivial pour architecture C++/ASM moderne - -**ProblĂšme basĂ© sur mauvaise lecture** de la spĂ©cification technique. - -**Statut** : Pas de problĂšme de cohĂ©rence rĂ©el. - -### 25. **Contradiction Multi-Échelle Chunk vs Single Chunk Combat** ❌ INVALIDÉ -**ProblĂšme supposĂ©** : Architecture 4 Ă©chelles contredit War Engine utilisant chunks 64x64 pour 500 unitĂ©s. - -**Doublon de P20** : MĂȘme problĂ©matique dĂ©jĂ  rĂ©solue - -**SystĂšme rĂ©el dĂ©jĂ  documentĂ©** : -- **Combat multi-chunks** : Batailles s'Ă©tendent sur dizaines/centaines de chunks -- **Frontlines persistantes** : Guerre peut durer 1 an (ex: Bakhmut) -- **500 unitĂ©s dispersĂ©es** : Sur grande zone gĂ©ographique, pas concentrĂ©es sur 4096mÂČ -- **Chunk 64x64** : UnitĂ© de streaming/gameplay, pas limite de bataille - -**Statut** : Doublon de problĂšme dĂ©jĂ  rĂ©solu en P20. - -### 26. **ImpossibilitĂ© Logique Interface Blueprint vs Grille Component VariĂ©e** ❌ INVALIDÉ -**ProblĂšme supposĂ©** : Drag & drop + formes irrĂ©guliĂšres + rotations = complexitĂ© UI insurmontable. - -**Interface standard parfaitement viable** : -- **Pick/Place** : Clic pour sĂ©lectionner, drag, clic pour placer avec snap automatique -- **Rotations** : A/E (standard jeux PC) -- **Snap toggle** : R pour dĂ©sactiver/activer grille -- **Templates** : Designs prĂ©-faits, guides visuels -- **Zone staging** : Inventaire latĂ©ral pour composants temporaires - -**PrĂ©cĂ©dents fonctionnels** : -- **Escape from Tarkov** : Inventaire tetris plus complexe, joueurs adorent optimiser -- **Factorio** : MĂȘme systĂšme exact de placement sur grille -- **Space Engineers** : Grille 3D + contraintes + physique, interface viable -- **Satisfactory** : Placement 3D encore plus complexe - -**Faux problĂšme** : Les joueurs aiment optimiser leurs designs. C'est le gameplay, pas un obstacle. - -### 27. **Contradiction Volume MĂ©triques vs Background Processing Promise** ❌ INVALIDÉ -**ProblĂšme supposĂ©** : 3.1GB mĂ©triques nĂ©cessitent processing constant en RAM, impossible pendant combats. - -**Mauvaise comprĂ©hension architecture** : -- **3.1GB = stockage database**, pas donnĂ©es en RAM -- **Push/Pull ponctuel** : Écriture periodique vers DB, lecture Ă  la demande -- **RAM footprint minimal** : Quelques valeurs courantes en mĂ©moire (~KB) -- **Processing lĂ©ger** : AgrĂ©gation simple lors push/pull, pas compute continu -- **Background viable** : DB operations asynchrones, impact CPU nĂ©gligeable - -**Architecture rĂ©elle** : -- Intelligence Engine Ă©crit mĂ©triques vers DB pĂ©riodiquement -- Interface mĂ©triques lit DB Ă  la demande (pas streaming continu) -- Combat et mĂ©triques complĂštement dĂ©couplĂ©s - -**Statut** : Mauvaise comprĂ©hension du stockage vs processing. - -### 28. **IncohĂ©rence SystĂšme TempĂ©rature vs Auto-battler Promise** ❌ INVALIDÉ -**ProblĂšme supposĂ©** : Gestion thermique trop complexe pour auto-battler. - -**Gestion automatique standard** : -- **Comme les munitions** : Quand ressource (tempĂ©rature/munitions) s'Ă©puise → retrait automatique -- **Fire & scoot automatique** : IA gĂšre cycles tir/refroidissement comme tanks rĂ©els -- **RĂšgles simples** : - - Surchauffe proche → retraite temporaire - - TempĂ©rature OK → reprise combat - - Comme gestion carburant/munitions dans RTS classiques - -**PrĂ©cĂ©dents viables** : -- **World in Conflict** : Gestion automatique munitions/carburant -- **Steel Division** : Stress/fatigue gĂ©rĂ©s par IA -- **Command & Conquer** : Auto-retreat quand low health - -**Faux problĂšme** : TempĂ©rature = une ressource comme les autres, facilement automatisable. - -### 29. **Architecture Smart Client vs Volume Data Streaming Impossible** ❌ INVALIDÉ -**ProblĂšme supposĂ©** : Client smart ne peut gĂ©rer volume data streaming 4 Ă©chelles + patches + FOW + historical data. - -**Architecture rĂ©elle - Pas de streaming continu** : -- **Historical data** : Pas streamĂ©es, stockage local/DB -- **Chunks** : Demande ponctuelle selon besoin (pas streaming continu) -- **FOW granularitĂ© chunk** : Ultra lĂ©ger, juste visibility flags -- **4 Ă©chelles** : Chargement Ă  la demande selon zoom, pas simultanĂ© -- **Patches** : Metadata lĂ©gĂšre, pas gĂ©omĂ©tries complĂštes - -**Volume rĂ©el minimal** : -- **FOW** : ~1 bit par chunk = nĂ©gligeable -- **Chunk request** : Ponctuel, quelques KB par demande -- **Pas de streaming** : Simple request/response pattern - -**Faux problĂšme** : Confond streaming continu vs requests ponctuels lĂ©gers. - -### 30. **Contradiction Arbre Tech 3000 vs UI Discovery System** ❌ INVALIDÉ -**ProblĂšme supposĂ©** : Interface "5-15 techs visibles max" vs breakthrough dĂ©bloqueant 20+ techs simultanĂ©ment. - -**Doublon de P18** : MĂȘme problĂ©matique dĂ©jĂ  rĂ©solue - -**SystĂšme rĂ©el dĂ©jĂ  documentĂ©** : -- **Prerequisites gating** : Seules 10-50 techs Ă©ligibles simultanĂ©ment (pas 3000) -- **Player pas censĂ© tout rechercher** : Focus spĂ©cialisations comme dans jeux rĂ©els -- **Interface proven** : Factorio gĂšre 100+ techs successfully -- **Design adaptatif** : UI peut temporairement montrer plus lors breakthroughs majeurs - -**Statut** : Doublon de problĂšme dĂ©jĂ  rĂ©solu en P18. - -## Conclusions - -### Analyse ComplĂšte TerminĂ©e -**30 problĂšmes identifiĂ©s** analysĂ©s et rĂ©solus : -- **8 problĂšmes rĂ©els rĂ©solus** (P7, P8, P10, P16, P17, P18, P21, P22, P23) -- **11 problĂšmes invalidĂ©s** par clarifications (P1, P2, P3, P4, P5, P6, P9, P11, P12, P13, P14, P15, P19, P20, P24, P26, P27, P28, P29, P30) -- **3 doublons Ă©liminĂ©s** (P25=P20, P30=P18) - -### État de CohĂ©rence Actuel -**Documentation cohĂ©rente** : La majoritĂ© des "problĂšmes" provenaient de : -- **Mauvaises lectures** de spĂ©cifications techniques -- **Assumptions incorrectes** sur l'architecture -- **IncomprĂ©hensions** des systĂšmes de jeu -- **Manque de contextualisation** cross-systĂšme - -### AmĂ©liorations ApportĂ©es -- **Clarifications architecturales** : Engines, autonomie, performance -- **Expansion gĂ©nĂ©ration procĂ©durale** : 218 Ă©lĂ©ments, budget -10/+10 -- **PrĂ©cisions timing** : Administration, mĂ©triques, breakthrough -- **Interface design** : SpĂ©cifications UI complĂ©tĂ©es -- **Cross-rĂ©fĂ©rences** : Liens entre systĂšmes Ă©tablis - -**Verdict final** : **Projet techniquement viable** avec documentation maintenant cohĂ©rente. - -## Actions de Suivi - -### ProblĂšmes Restants Ă  Traiter -**P7** : ResponsabilitĂ©s engines → Continuer analyse architecture (identifiĂ© comme rĂ©el) - -### Prochaines Étapes Documentation -1. **Validation technique** : Review implĂ©mentation faisabilitĂ© -2. **Tests cohĂ©rence** : VĂ©rification cross-systĂšme -3. **Mise Ă  jour rĂ©fĂ©rences** : Synchronisation entre docs - -### Recommandations -- **Documentation technique** : Maintenant solide et cohĂ©rente -- **ImplĂ©mentation** : Aucun blocage majeur identifiĂ© -- **Design** : SystĂšmes compatibles et rĂ©alisables \ No newline at end of file diff --git a/docs/04-reference/content-integrated.md b/docs/04-reference/content-integrated.md deleted file mode 100644 index d4efd35..0000000 --- a/docs/04-reference/content-integrated.md +++ /dev/null @@ -1,122 +0,0 @@ -# Points IntĂ©grĂ©s - Content Integrated - -## Points 1-10 - Architecture Fondamentale INTÉGRÉS - -### đŸ”„ Architecture Core (CRITICAL) - INTÉGRÉS -**1. Triple Interface Pattern** - IEngine → IModuleSystem → IModule → IIO pour sĂ©paration complĂšte responsabilitĂ©s -- ✅ **IntĂ©grĂ©** : CLAUDE.md ligne 42 - -**2. Évolution Progressive Architecture** - Debug → Production → DataOriented avec hot-swappable infrastructure -- ✅ **IntĂ©grĂ©** : CLAUDE.md architecture modulaire - -**3. Claude Code Micro-Context** - Modules 200-300 lignes max pour efficacitĂ© IA dĂ©veloppement -- ✅ **IntĂ©grĂ©** : CLAUDE.md ligne 44 - -**4. Client/Server Modulaire** - V1 Thin Client validation → V2 Shared Logic prediction -- ✅ **IntĂ©grĂ©** : CLAUDE.md ligne 42 - -**5. Distribution Performance-Based** - Critical locale, Strategic distribuĂ©e selon tolĂ©rance latence -- ✅ **IntĂ©grĂ©** : CLAUDE.md ligne 45 - -### ⚡ Workflow DĂ©veloppement (HIGH) - INTÉGRÉS -**6. Build Autonome** - `cmake .` par module, zĂ©ro dĂ©pendance parent -- ✅ **IntĂ©grĂ©** : CLAUDE.md lignes 99-101 - -**7. Hot-Reload Infrastructure** - Remplacement temps rĂ©el modules avec sauvegarde Ă©tat -- ✅ **IntĂ©grĂ©** : docs/architecture-technique.md section Hot-Reload Infrastructure - -**8. DĂ©veloppement ParallĂšle** - Multiple instances Claude Code simultanĂ©es sans conflits -- ✅ **IntĂ©grĂ©** : docs/toCheck/claude-code-integration.md lignes 80-100 -- ✅ **IntĂ©grĂ©** : docs/toCheck/AddToClaudemd.md Point 8 - -**9. CLAUDE.md SpĂ©cialisĂ©s** - Instructions contextuelles limitĂ©es par module -- ✅ **IntĂ©grĂ©** : docs/toCheck/claude-code-integration.md lignes 102-147 -- ✅ **IntĂ©grĂ©** : docs/toCheck/AddToClaudemd.md Point 9 - -**10. Migration V1→V2** - Évolution sans risque architecture client/server -- ✅ **IntĂ©grĂ©** : docs/architecture-technique.md lignes 568-585 -- ✅ **IntĂ©grĂ©** : docs/toCheck/AddToClaudemd.md Point 10 - -## Statut IntĂ©gration -- **Points 1-10** : ✅ **COMPLÈTEMENT INTÉGRÉS** -- **Points 86-89** : ✅ **INTÉGRÉS** - Contraintes CRITICAL dans CLAUDE.md -- **Points 90-95** : ✅ **INTÉGRÉS** - Transport costs dans transport-economic-system.md -- **Point 131** : ✅ **INTÉGRÉ** - ProductionModule exception dans CLAUDE.md -- **Point 166** : ✅ **INTÉGRÉ** - IModule interface dans CLAUDE.md -- **Points 126-130, 135, 42-44** : ✅ **INTÉGRÉS** - Diverses contraintes - -## Nouveaux Points IntĂ©grĂ©s (98-104) -**98. V1 Client Target** - 30+ fps stable -- ✅ **IntĂ©grĂ©** : docs/architecture-technique.md section V1 - -**99. V2 Client Target** - 60+ fps avec prediction -- ✅ **IntĂ©grĂ©** : docs/architecture-technique.md section V2 - -**100. V1 Server Capacity** - 10+ concurrent players -- ✅ **IntĂ©grĂ©** : docs/architecture-technique.md section V1 - -**101. V2 Server Capacity** - 100+ concurrent players -- ✅ **IntĂ©grĂ©** : docs/architecture-technique.md section V2 - -**102. V1 Latency** - <150ms validation acceptable -- ✅ **IntĂ©grĂ©** : docs/architecture-technique.md section V1 - -**103. V2 Network** - 30ms server, 0ms perceived client -- ✅ **IntĂ©grĂ©** : docs/architecture-technique.md section V2 - -**104. ISocket Overhead** - >1ms INACCEPTABLE ProductionModule -- ✅ **IntĂ©grĂ©** : CLAUDE.md Module Constraints - -## Points 251-350 IntĂ©grĂ©s - Configuration, Error Handling, Security & Deployment -**251-290. Configuration Parameters** - Transport thresholds, costs, times, storage, stock levels, construction costs -- ✅ **IntĂ©grĂ©** : docs/configuration/ (transport-economic-system.md + module-configuration.md) - -**291-310. Error Handling** - Anti-cheat validation, input responses, module failures, network issues -- ✅ **IntĂ©grĂ©** : docs/configuration/error-handling.md - -**311-330. Security Measures** - Server authority, anti-cheat, client prediction, psychological warfare -- ✅ **IntĂ©grĂ©** : docs/configuration/security-measures.md - -**331-350. Deployment Strategies** - Progressive V1→V2, hot-reload production, A/B testing -- ✅ **IntĂ©grĂ©** : docs/configuration/deployment-strategies.md -- ✅ **OrganisĂ©** : Dossier configuration complet avec README - -## Points 351-390 IntĂ©grĂ©s - Claude Code Development Practices -**351-390. Development Practices** - Claude Code limits, parallel development, build patterns, testing -- ✅ **IntĂ©grĂ©** : CLAUDE.md section "Claude Code Development Practices (Points 351-390)" - -## Points 391-430 DĂ©jĂ  IntĂ©grĂ©s - Integration Patterns -**391-430. Integration Patterns** - Module communication, engine coordination, client-server sync -- ✅ **DĂ©jĂ  intĂ©grĂ©** : architecture-technique.md (Triple Interface, JSON, hot-reload) -- ✅ **DĂ©jĂ  intĂ©grĂ©** : architecture-modulaire.md (IEngine/IModuleSystem/IModule/IIO) -- ✅ **DĂ©jĂ  intĂ©grĂ©** : claude-code-integration.md (Module coordination, builds) -- ✅ **DĂ©jĂ  intĂ©grĂ©** : player-integration.md (Client-server sync) - -## Points 431-470 DĂ©jĂ  IntĂ©grĂ©s - User Experience -**431-470. User Experience** - Latency targets, hot-reload UX, config modification, multiplayer sync -- ✅ **DĂ©jĂ  intĂ©grĂ©** : architecture-technique.md (Performance targets V1/V2, latency specs) -- ✅ **DĂ©jĂ  intĂ©grĂ©** : player-integration.md (30+fps/60+fps, 150ms/0ms latency) -- ✅ **DĂ©jĂ  intĂ©grĂ©** : docs/configuration/ (Hot-reload UX, config modification) -- ✅ **DĂ©jĂ  intĂ©grĂ©** : factory-architecture-post-player.md (Frame-perfect 60fps) - -## Points 471-570 DĂ©jĂ  IntĂ©grĂ©s - Business Logic & Build System -**471-510. Business Logic Rules** - Transport hierarchy, volume thresholds, economic cycles, pricing -- ✅ **DĂ©jĂ  intĂ©grĂ©** : docs/configuration/transport-economic-system.md (Ship 0.10€/kg → Truck 5.00€/kg) - -**511-530. File Structure** - Module directories, client/server/shared, naming conventions -- ✅ **DĂ©jĂ  intĂ©grĂ©** : architecture-technique.md (modules/ structure, CLAUDE.md pattern) -- ✅ **DĂ©jĂ  intĂ©grĂ©** : README.md (Development workflow, file organization) - -**531-570. Build System Details** - Commands, CMake structure, dependencies, libraries -- ✅ **DĂ©jĂ  intĂ©grĂ©** : architecture-technique.md (cmake ., NEVER/ALWAYS patterns) -- ✅ **DĂ©jĂ  intĂ©grĂ©** : CLAUDE.md (Build commands, project structure) - -## Points 136-142 DĂ©jĂ  IntĂ©grĂ©s - Interface Contracts -**136-142. Interface Contracts** - JSON in/out, pure functions, pas side effects -- ✅ **DĂ©jĂ  intĂ©grĂ©** : architecture-technique.md (JSON in/out uniquement, logic mĂ©tier pure) -- ✅ **DĂ©jĂ  intĂ©grĂ©** : architecture-modulaire.md (JSON communication, aucune dĂ©pendance infrastructure) -- ✅ **DĂ©jĂ  intĂ©grĂ©** : claude-code-integration.md (Pure logic only, JSON messages) - -## Total IntĂ©grĂ© : 357 points sur 570 -- **Localisation** : CLAUDE.md, architecture-technique.md, claude-code-integration.md, docs/configuration/ -- **Restant** : 131 points spĂ©cifiĂ©s + 82 non-spĂ©cifiĂ©s Ă  traiter \ No newline at end of file diff --git a/docs/04-reference/effets-attendus.md b/docs/04-reference/effets-attendus.md deleted file mode 100644 index 4662696..0000000 --- a/docs/04-reference/effets-attendus.md +++ /dev/null @@ -1,89 +0,0 @@ -# Effets Attendus du SystĂšme Économique - -Ce document compile les **effets Ă©mergents prĂ©dits** du systĂšme Ă©conomique de Warfactory. Ces comportements ne sont **PAS** implĂ©mentĂ©s directement mais devraient Ă©merger naturellement des mĂ©caniques Ă©conomiques de base. - -## Point 30 : Dynamiques CĂŽtiĂšres - -**Cycle auto-rĂ©gulateur prĂ©dit** rĂ©sultant des avantages gĂ©ographiques (Point 27) : - -### Phase 1 - Rush Initial -- **Coastal advantage** : Ship transport 0.10€/kg (50x moins cher que truck 5.00€/kg) -- **Mass migration** : Companies rush vers locations cĂŽtiĂšres -- **Early profits** : Massive competitive advantage pour first-movers - -### Phase 2 - DĂ©veloppement RaretĂ© -- **Land scarcity** : Prix foncier cĂŽtier augmente via demande -- **Premium costs** : CoĂ»ts location/acquisition deviennent prohibitifs -- **Resource competition** : Lutte intense pour emplacements cĂŽtiers optimaux - -### Phase 3 - Limites Infrastructure -- **Congestion costs** : Infrastructure portuaire saturĂ©e -- **Throughput limits** : Ports atteignent capacitĂ© maximum -- **Efficiency decrease** : Performance dĂ©gradĂ©e via embouteillages - -### Phase 4 - Equilibrium Naturel -- **Cost parity** : Total costs cĂŽtier = inland (aprĂšs factorisation tous coĂ»ts) -- **Labor premiums** : Salaires cĂŽtiers augmentent vs rĂ©gions isolĂ©es -- **Economic balance** : Avantage transport neutralisĂ© par coĂ»ts indirects - -## MĂ©canisme Sous-Jacent - -**Pas d'implĂ©mentation spĂ©cifique requise** - Ă©merge naturellement de : -- Transport costs hierarchy (Ship→Rail→Air→Truck) -- Infrastructure access binary (hasPortAccess boolean) -- Market-driven pricing (supply/demand) -- ROI infrastructure calculations - -**PrĂ©diction** : Le systĂšme crĂ©era automatiquement ce cycle sans scripting explicite. - -## Point 38 : Cascades Économiques - -**SystĂšme de propagation automatique** : Events → Impact direct → Ripple effects → Cascades macro - -### Resource Discovery Economic Cascades -**DĂ©couverte nouvelle ressource dĂ©clenche cascades prĂ©dictibles :** - -**SĂ©quence automatique :** -1. **Immediate local effects** : Land value increase, investment attraction -2. **Regional economic shifts** : Trade route realignment, competitor responses -3. **Market adjustments** : Global pricing changes, supply chain redistribution -4. **New markets emerge** : Regional economic boom, infrastructure development - -**MĂ©canisme sous-jacent :** Economic agents rational response → Market rebalancing - -### War Economic Impact Cascades -**Conflits militaires gĂ©nĂšrent disruptions Ă©conomiques systĂ©miques :** - -**Propagation sĂ©quentielle :** -1. **Military conflict** → Supply chain disruption (transport routes affected) -2. **Resource scarcity** → Price inflation (artificial scarcity effects) -3. **War production** → Economic restructuring (civilian→military production shift) -4. **Post-war recession** → Market readjustment (return to civilian economy) - -### Technology Economic Disruption -**Breakthroughs technologiques crĂ©ent social & economic upheaval :** - -**Cascade sociale :** -1. **Automation breakthrough** → Productivity gains (industry efficiency) -2. **Labor displacement** → Unemployment spike (job obsolescence) -3. **Wage pressure** → Social unrest (economic inequality) -4. **Government intervention** → Economic policy changes (regulatory response) - -### Player Decision Ripples -**Actions player gĂ©nĂšrent effets macro non-intentionnels :** - -- **Factory expansion** → Local job creation → Population growth → Market demand increase -- **Resource hoarding** → Artificial scarcity → Price manipulation → Competitor response -- **Technology research** → Industry disruption → Economic transformation → Social change - -## SystĂšme Technique Sous-Jacent - -**Pas d'implĂ©mentation spĂ©cifique requise** - Ă©mergence naturelle via : -- MarketModule price discovery automatique -- Supply/demand dynamics existing -- Economic agent rational behavior (Point 36) -- Transport cost optimization (Points 24-26) - -**Event propagation** : Economic modules communiquent via existing architecture → Cascades Ă©mergent naturellement - -**PrĂ©diction** : L'interaction des systĂšmes Ă©conomiques existants crĂ©era automatiquement ces cascades complexes sans programmation explicite. \ No newline at end of file diff --git a/docs/04-reference/mecaniques-jeu.md b/docs/04-reference/mecaniques-jeu.md deleted file mode 100644 index 4b10518..0000000 --- a/docs/04-reference/mecaniques-jeu.md +++ /dev/null @@ -1,525 +0,0 @@ -# MĂ©caniques de jeu - -## Recherche et progression - -### SystĂšme de recherche -Recherche Ă  la Factorio pour : -- Moyens d'extraction -- Production -- Assembly -- Communication -- ChĂąssis civil -- Recherche -- Transport (rail, hyperloop) -- Diplomatie -- Électronique -- Prototype militaire -- Prototype IA -- Prototype composants -- Proto radar - - -**Exemple Proto radar** : -- Composant Ă©quipement taille 6x6, 2kw, fiabilitĂ© 50% - -**Recherche radar 1** : -- Composant Ă©quipement taille 5x5, 2kw, fiabilitĂ© 60% -- Composant Ă©lectronique taille 4x4, 500w, fiabilitĂ© 20% - -**Recherche radar 2** : -- Composant Ă©quipement taille 8x3, 1.5kw, fiabilitĂ© 80% - -## SystĂšme de Recherche Dual - -### 1. Recherche GĂ©nĂ©rique (Points de Tech) -- **Points de recherche standard** : SystĂšme classique d'accumulation points -- **Usage** : Recherches civiles, technologies de base, progressions linĂ©aires -- **Source** : Production continue, investissement R&D, temps - -### 2. Recherche SpĂ©cifique (Scrap Analysis) -- **Scrap Analysis** : Reverse engineering matĂ©riel ennemi -- **DĂ©couvertes alĂ©atoires** : T-72 → ERA, blindage, canon (random) -- **Analyse ciblĂ©e** : Étude composants spĂ©cifiques pour breakthroughs -- **EfficacitĂ© variable** : Selon qualitĂ© et Ă©tat du matĂ©riel rĂ©cupĂ©rĂ© - -## SystĂšme de Breakthroughs - -### Verrous technologiques -- **Recherches bloquĂ©es** : Certaines technologies inaccessibles sans breakthrough -- **Exemple** : "Armor Javelin-Proof" impossible sans analyse Javelin -- **Gating stratĂ©gique** : Force acquisition d'Ă©chantillons spĂ©cifiques - -### Prerequisites Gating & Performance -**Scaling technique** : Le systĂšme breakthrough peut gĂ©rer 3000 technologies grĂące au gating intelligent : - -#### Prerequisites Chain -- **~10-50 techs eligible** simultanĂ©ment pour un player donnĂ© (pas 3000) -- **Tech dependencies** : Nouvelle tech nĂ©cessite prĂ©requis recherchĂ©s -- **Progressive unlock** : Chaque breakthrough dĂ©bloque quelques nouvelles possibilitĂ©s -- **Organic discovery** : Player dĂ©couvre par gameplay naturel, pas par browsing - -#### Validation Performance -- **On-demand checks** : Conditions vĂ©rifiĂ©es quand Ă©vĂ©nement trigger (construction, production, etc.) -- **State-based** : Validation sur Ă©tat actuel (avoir 5 radars), pas historique complexe -- **Ticker optimisĂ©** : VĂ©rifications breakthrough toutes les minutes, pas 60fps -- **Cache results** : Évite recalculs conditions identiques - -### 3 Sources de Breakthroughs - -**1. Scrap Analysis** -- **MĂ©thode primaire** : Reverse engineering matĂ©riel ennemi -- **SimplicitĂ©** : Scrap = scrap (pas d'Ă©tat, pas de fraĂźcheur) -- **EfficacitĂ©** : MĂ©thode la plus directe et Ă©conomique - -**2. Points de Recherche AvancĂ©s** -- **Alternative coĂ»teuse** : Breakthrough sans scrap -- **CaractĂ©ristiques** : Cher et lent -- **Usage** : Quand scrap spĂ©cifique inaccessible/rare - -**3. Reverse Engineering Produits** -- **SystĂšmes capturĂ©s** : Équipement intact rĂ©cupĂ©rĂ© (1-3 breakthroughs) -- **Achat commercial** : Produits achetĂ©s sur marchĂ© (produit final seul) -- **ConsĂ©quences diplomatiques** : Relations gravement affectĂ©es avec company/Ă©tat vendeur -- **Limites** : Produit accessible mais pas ses composants/ingrĂ©dients - -### EfficacitĂ© par source -- **Scrap** : 0-1 breakthrough (alĂ©atoire, Ă©conomique) -- **Capture** : 1-3 breakthroughs (risquĂ©, trĂšs efficace) -- **Achat** : 1 breakthrough produit (cher, consĂ©quences diplomatiques) -- **Recherche avancĂ©e** : Garantie breakthrough (trĂšs cher et lent) - -## Économie des Technologies - -### Vente de technologies -- **MarchĂ© tech** : Breakthroughs dĂ©blocables vendables sur marchĂ© -- **Revenus additionnels** : MonĂ©tisation des dĂ©couvertes R&D -- **Concurrence** : Autres actors peuvent acquĂ©rir vos innovations - -### Contenu long terme (future) -- **Espionnage industriel** : Vol de breakthroughs entre companies -- **Protection IP** : MĂ©caniques de sĂ©curisation des technologies - -## Actions normales militaires - -L'idĂ©e c'est qu'une action normale est un dĂ©roulement : - -**Exemples de dĂ©roulements** : -- **Établir Position AA** = dĂ©placement → dĂ©ploiement → attente d'engagement -- **Assaut** = dĂ©placement opĂ©rationnel → engagement tactique → attaque CQC → Prise de position de dĂ©fense → attente d'engagement - -### Mise en place -- Établissement de FOB, dĂ©pĂŽt de munitions -- Établissement d'AP -- Établir Position radar -- Établir Position AA (point defense, area defense) -- Établir Position static Artillerie -- Établir Trench network -- Defense tempo (retrenchment) - -### Ravitaillement -- Ravitaillement de convois -- Ravitaillement lĂ©ger (drone) -- Ravitaillement classique (mono camion) - -### Action de combat -- **Assaut** (prise de position ennemie) -- **Reconnaissance** (discrĂšte) -- **Reconnaissance in force** (lĂ©gĂšre ou blindĂ©e) -- **Infiltration** -- **Raid** (logistique, anti-AA, anti-artillerie, JSP) -- **Attaque** (char → boum boum boum → retrait → recommencer) (dĂ©truire l'ennemi) - -### Long range -On inclut ici l'artillerie, les missiles, le support aĂ©rien au sol : - -- **Frappe destructive** -- **Contre frappe** (contre batterie) -- **Saturation artillerie** -- **Support des troupes** -- **Obscuration** -- **Suppression** - -### ContrĂŽle aĂ©rien -- **SEAD** -- **DEAD** -- **Interception** -- **SupĂ©rioritĂ© aĂ©rienne** → patrouille -- **Escorte** -- **Reconnaissance aĂ©rienne** -- **Identification** -- **Alerte** (warn non hostile) - -## IA stratĂ©gique - -### DĂ©fis de l'IA -Pas facile hein
 - -DĂ©jĂ  l'IA doit ĂȘtre capable d'implĂ©menter toutes les "actions normales" ci-dessus. - -Pour ce qui est de la dĂ©cision de quelle action implĂ©menter et oĂč, c'est une vraie difficultĂ© et c'est ce qui doit ĂȘtre rĂ©flĂ©chi. - -### Doctrines diffĂ©renciĂ©es -DĂ©jĂ  il faut comprendre que toutes les IA ne feront pas la mĂȘme chose (doctrine tactique et opĂ©rationnelle) et cela en fonction d'objectifs stratĂ©giques, donc dĂ©cidĂ©s par l'IA stratĂ©gique. - -**Proposition** : Donner un set de prĂ©fĂ©rences (par action) pour dĂ©finir une doctrine, avec sĂ»rement un concept de phases opĂ©rationnelles. - -**Exemple doctrine US** : -Campagne aĂ©rienne → SEAD → DEAD → C&C target → CAS → Ground assault - -### Concept de recette -Concept de recette avec un coĂ»t Ă  trois composantes : -- **Raid** → **AA pos** → **125e compagnie d'inf moto** -- **Quoi ?** / **Qui/oĂč ?** / **Comment/avec qui ?** - -## MĂ©caniques de combat - -### AOE (str) -Ça doit ĂȘtre possible mais bon Ă  Ă©viter. - -### Tacops (tactique/4x) -Ce qu'est censĂ© ĂȘtre le combat mid-late game. Une gestion des unitĂ©s sur une carte de campagne et les unitĂ©s qui se dĂ©merdent sur l'aspect combat IA. Il est important de pouvoir contempler les combats. - -### RĂ©paration/logistique -*À dĂ©velopper* - -### RPG -*À dĂ©velopper* - -## Simulation de monde - -### Factions -IntĂ©gration de factions qui, souvent seront les Ă©tats et avec lesquels l'interaction doit ĂȘtre possible (Ă©conomie, diplomatie). - -### Économique -SystĂšme Ă©conomique avec lequel le joueur peut interagir, notamment par l'intermĂ©diaire de la vente ou l'achat de ressources. SpĂ©culation ? - -Celle-ci doit ĂȘtre dynamique et intĂ©grer un systĂšme d'Ă©conomie d'Ă©chelle permettant une spĂ©cialisation Ă©conomique des factions. Pour autant, les enjeux stratĂ©giques (bouffe, armes etc.) doivent ĂȘtre pris en compte et intĂ©grĂ©s Ă  la production Ă©conomique des factions. - -### StratĂ©gique -ComprĂ©hension des enjeux stratĂ©giques liĂ©s aux ressources, aux positions gĂ©ographiques. - -### Politique -IntĂ©gration de l'ordre public et des courants politiques. - -## SystĂšme d'Administration - -### Principe Fondamental -Chaque **company** et **Ă©tat** dispose de points d'**Administration** qui limitent leurs actions quotidiennes, reprĂ©sentant leur capacitĂ© organisationnelle et bureaucratique. - -### MĂ©caniques Core - -#### Points Administration Base -- **Companies** : 1000 points/jour de base (1 jour = 10 minutes rĂ©elles) -- **États** : Variable selon taille/dĂ©veloppement (Ă  dĂ©finir) -- **RĂ©gĂ©nĂ©ration** : Reset quotidien complet des points -- **FrĂ©quence actions** : ~1 action tous les 3-5 jours par company (rythme macro stratĂ©gique) - -#### Actions CoĂ»tant Administration - -**Recherche & DĂ©veloppement** : -- Lancer nouvelle recherche : 100-500 points (selon complexitĂ©) -- Breakthrough forcĂ© (scrap analysis) : 200-800 points -- Achat technology sur marchĂ© : 150 points - -**Commerce & Économie** : -- NĂ©gocier nouveau contrat : 50-200 points -- Changer prix produits : 25 points -- Ouvrir nouveau marchĂ© d'export : 300 points -- Merger/acquisition : 500+ points - -**Diplomatie** : -- Proposer accord commercial : 200 points -- Sanctions Ă©conomiques : 400 points -- NĂ©gociation traitĂ© : 600+ points - -**Production & Infrastructure** : -- Construire nouvelle usine : 300 points -- Changer ligne de production : 100 points -- Optimisation processus : 150 points -- Expansion facilities : 250 points - -**OpĂ©rations Militaires** (États principalement) : -- Lancer opĂ©ration militaire : 500+ points -- Coordination multi-forces : 300 points -- Changement doctrine : 400 points - -### Facteurs Modifiant Administration - -#### Company Features Impact - -**Features RĂ©duisant Admin** : -- **Quality** : -10% coĂ»ts admin (organisation efficace) -- **Administration** : +50% points admin de base (spĂ©cialisation bureaucratique) - -**Features Neutres** : -- **Innovation** : Pas de bonus admin (crĂ©ativitĂ© ≠ organisation) -- **Cost** : Pas d'impact admin -- **Speed** : Pas d'impact admin - -#### Investissements Infrastructure - -**Bureaux & Management** : -- **Bureaux modernes** : +200 points admin/jour -- **SystĂšmes ERP** : +150 points admin/jour -- **Managers expĂ©rimentĂ©s** : +100 points admin/jour -- **Automation administrative** : +300 points admin/jour - -#### Modificateurs Contextuels - -**État de Guerre** : -- **Companies** : +200 points admin/jour (Ă©conomie de guerre = urgence) -- **États** : +500 points admin/jour (mobilisation totale) -- **Justification** : Urgence permet dĂ©cisions rapides, bypass bureaucratie - -**État de Paix** : -- **Administration normale** : Valeurs de base -- **Bureaucratie standard** : Processus normaux - -**Stress Économique** : -- **RĂ©cession** : -100 points admin/jour (ressources rĂ©duites) -- **Croissance** : +50 points admin/jour (expansion capabilities) - -### StratĂ©gies Administration - -#### Optimisation Resource Management -- **Priorisation actions** : Quelles dĂ©cisions sont critiques ? -- **Timing operations** : Grouper actions similaires -- **Investment planning** : ROI bureaux vs production - -#### SpĂ©cialisations Companies -- **Company "Administration"** : Devient sous-traitant admin pour autres -- **Outsourcing** : DĂ©lĂ©guer certaines tĂąches vs faire internal -- **Efficiency focus** : Quality companies = moins de waste admin - -### Examples Concrets - -#### Company JournĂ©e Type -``` -Thales (Company "Electronic, Quality, Administration"): -├── Administration disponible: 1000 + 500 (Admin feature) + 200 (bureaux) = 1700/jour -├── CoĂ»ts journĂ©e: -│ ├── Recherche "Radar AESA": -400 points -│ ├── NĂ©gociation contrat Ukraine: -150 points -│ ├── Optimisation ligne production: -120 points (Quality = -10%) -│ └── Total utilisĂ©: 670/1700 -└── Surplus: 1030 points (peut faire plus d'actions) -``` - -#### Company LimitĂ©e -``` -StartupCorp (Company "Innovation"): -├── Administration disponible: 1000/jour (base seulement) -├── CoĂ»ts journĂ©e: -│ ├── Recherche breakthrough: -500 points -│ ├── NĂ©gociation financement: -300 points -│ ├── Changement production: -250 points -│ └── Total: 1050 points -└── LIMITE ATTEINTE: Doit choisir prioritĂ©s ! -``` - -### Impact Gameplay - -#### Pour l'IA -- **Performance naturellement limitĂ©e** : Pas d'actions infinies par tick -- **Comportements rĂ©alistes** : Companies choisissent prioritĂ©s selon pools admin -- **Rythme macro** : ~1000 companies × 1 action/3-5 jours = ~0.33 actions/seconde systĂšme -- **SpĂ©cialisations Ă©mergentes** : Features influencent strategies - -#### Pour le Joueur -- **Companies IA prĂ©visibles** : Limitation actions = patterns plus lisibles -- **OpportunitĂ©s timing** : Profiter quand competitors "admin-locked" -- **Market dynamics** : Administration shortage = prix changes moins frĂ©quents - -### Balance Considerations - -#### Éviter Frustration -- **Actions critiques** : Survie company ne doit jamais ĂȘtre bloquĂ©e par admin -- **Emergency actions** : Certaines actions bypass admin en crisis -- **Learning curve** : Interface claire sur coĂ»ts admin - -#### Maintain Dynamism -- **Baseline sufficient** : 1000 points permet gameplay de base -- **Scaling rewards** : Investment admin = exponential returns -- **Variety strategies** : Multiple paths pour optimiser admin - -## Terrain de combat PMC - -### Zones d'opĂ©ration -- AmĂ©rique du Sud dans les zones peu peuplĂ©es -- Madagascar -- Afrique -- Ouest de la Chine -- Russie -- Moyen-Orient - -## Meta Game Design - -### Philosophie de difficultĂ© -"Aucune satisfaction parce que le jeu est fait pour ĂȘtre gagnĂ©. Quel intĂ©rĂȘt de gagner alors ?" - -**Objectif** : Faire un jeu oĂč le but de l'IA contre le joueur est bel et bien de gagner, pas de perdre. - -## SystĂšme d'ExpĂ©rience VĂ©hicules - -### ExpĂ©rience Combat -- **Gain expĂ©rience** : Combat, missions rĂ©ussies, survie prolongĂ©e -- **Effets** : AmĂ©lioration fiabilitĂ©, prĂ©cision, temps de rĂ©action IA -- **VĂ©tĂ©rans** : VĂ©hicules expĂ©rimentĂ©s plus efficaces, moins de pannes - -### SystĂšme de GĂ©nĂ©raux et ArmĂ©es - -#### Structure de commandement -- **Composition automatique** : Joueur assigne types/nombres ("20 chars lourds"), gestion automatique -- **Types de vĂ©hicules** : Classification par rĂŽles (char lourd, IFV, drone, etc.) -- **Logistique intĂ©grĂ©e** : Assignement, maintenance, ravitaillement gĂ©rĂ©s automatiquement -- **HiĂ©rarchie** : GĂ©nĂ©ral en chef donne objectifs Ă  subalternes qui planifient opĂ©rations -- **Limite par expĂ©rience** : CapacitĂ© de commandement croĂźt linĂ©airement avec expĂ©rience -- **Malus surcharge** : ArmĂ©e trop grosse → rĂ©serves, opĂ©rations limitĂ©es, qualitĂ© dĂ©gradĂ©e - -#### Modes de planification -1. **Plans proposĂ©s** : GĂ©nĂ©ral propose plans que joueur valide/modifie -2. **Plans joueur** : Joueur conçoit plans dĂ©taillĂ©s, gĂ©nĂ©ral exĂ©cute -3. **Objectifs gĂ©nĂ©raux** : Joueur donne objectifs, gĂ©nĂ©ral gĂ©nĂšre dĂ©tails opĂ©rationnels -4. **Ordre simple** : Ordre "attaque", IA choisit mĂ©thodes et tactiques - -#### SpĂ©cialisations et IA des gĂ©nĂ©raux -- **Machine Learning** : Adaptation tactique selon rĂ©sultats (Ă©checs → Ă©vitement progressif) -- **PersonnalitĂ© & Traits** : Influencent probabilitĂ© d'usage de certaines tactiques -- **Exemple adaptatif** : GĂ©nĂ©ral blindĂ© Ă©chec urban → reste blindĂ© mais tactiques adaptĂ©es -- **Apprentissage spĂ©cialisĂ©** : Usage vĂ©hicules overloadĂ©s → amĂ©lioration overload dynamique - -#### Cycle d'apprentissage overload dynamique - -**Phase Planning** : -1. **Analyse menace** : Blindage insuffisant estimĂ© pour mission -2. **Recherche solutions** : Liste options (Spaced armor, ERA, etc.) -3. **Check logistique** : DisponibilitĂ© Ă©quipements (ERA disponible) -4. **Commande automatique** : Order passĂ© au rĂ©seau logistique - -**Phase PrĂ©-mission** : -- **Workshop preparation** : Équipement ERA sur vĂ©hicules compatibles -- **Validation configuration** : VĂ©rification intĂ©gritĂ© overload - -**Phase Mid-mission** : -- **Observation dĂ©taillĂ©e** : Monitoring performance en temps rĂ©el -- **Data collection** : Impact sur vitesse, Ă©lectronique, capteurs - -**Phase Post-analyse** : -- **EfficacitĂ© ERA** : RĂ©duction dĂ©gĂąts mesurĂ©e vs prĂ©diction -- **Ajustement valeurs** : Calibrage algorithmes d'Ă©valuation -- **Impact systĂ©mique** : Analyse systĂšmes ennemis, contre-mesures -- **DĂ©cision adaptative** : Mise Ă  jour probabilitĂ©s d'usage futur - -**CaractĂ©ristiques gĂ©nĂ©rales** : -- **Templates flexibles** : Style HOI4 + contrĂŽle fin possible -- **Influence principale** : Tactiques et opĂ©rations privilĂ©giĂ©es -- **Influence secondaire** : LĂ©gers bonus stats selon expertise - -#### SystĂšme logistique intĂ©grĂ© -- **Orders automatiques** : ArmĂ©es placent commandes logistiques automatiquement -- **Équipement dynamique** : Blocs ERA commandĂ©s via rĂ©seau logistique -- **Delivery system** : Logistique tente de livrer selon capacitĂ©s/prioritĂ©s - -#### ContrĂŽle joueur et politiques -**SĂ©paration des rĂŽles** : -- **Joueur** : LĂ©go industriel + ordres stratĂ©giques + planning optionnel -- **GĂ©nĂ©raux** : ExĂ©cution autonome selon designs et stocks disponibles - -**Gestion des stocks** : -- **Stocks spĂ©ciaux** : Joueur contrĂŽle mise Ă  disposition (ERA, Ă©quipements rares) -- **Premier arrivĂ©, premier servi** : Pas de systĂšme de prioritĂ©s complexe -- **ContrĂŽle indirect** : ArrĂȘt production = fin disponibilitĂ© pour gĂ©nĂ©raux - -**Politiques par design** : -- **Design constraints** : Espace disponible pour overload ou interdiction -- **Pas de budgets gĂ©nĂ©raux** : Pas d'autorisation ni limite financiĂšre -- **ContrĂŽle passif** : IA utilise ce qui est disponible selon designs autorisĂ©s - -#### Interface de planification -- **Plans sĂ©quentiels** : Phases avec objectifs et timeline -- **Visualisation carte** : Zone d'opĂ©ration avec numĂ©ros, flĂšches, positions -- **DĂ©tails drill-down** : AccĂšs effectifs prĂ©vus par phase/objectif -- **Validation joueur** : Approbation/modification des plans proposĂ©s - -## Cycle Technologique des Armes - -### Évolution forcĂ©e : Petit → Moyen → Gros -- **Recherche naturelle** : Nouvelles armes plus puissantes mais plus grosses -- **Dilemme chĂąssis** : Armes avancĂ©es ne logent plus sur chĂąssis existants -- **Solutions forcĂ©es** : - - Overload chĂąssis existants (malus mais moins cher) - - DĂ©velopper chĂąssis super-lourds (coĂ»teux, spĂ©cialisĂ©s, limitĂ©s) -- **Équilibrage** : ChĂąssis super-lourds pas OP (style HOI4) - lents, chers, vulnĂ©rables - -## Architecture serveur - -### Economy Server - -#### MarchĂ© global dynamique -- **Fonction** : Ressources globales, commerce, spĂ©culation, Ă©conomie d'Ă©chelle -- **Trade dynamique** : Prix fluctuants selon offre/demande et Ă©vĂ©nements -- **RĂ©activitĂ© militaire** : Économie rĂ©agit aux conflits et batailles - -#### Acteurs Ă©conomiques -- **Companies** : Entreprises privĂ©es (Thales, Dassault, joueur initial) -- **États** : Nations avec politiques et relations diplomatiques -- **Relations croisĂ©es** : Companies dĂ©pendent des Ă©tats mais ont relations propres -- **Restrictions multi-niveaux** : Blocages possibles par companies ET Ă©tats -- **MatiĂšres et services** : Restrictions sur industriel, production, consommation (Ă©lectricitĂ©, acier) - -#### SystĂšme de marchĂ©s -- **MarchĂ©s segmentĂ©s** : Par pays, par company, par bloc multinational, mondial -- **ExclusivitĂ©s** : Joueur peut vendre exclusivement sur certains marchĂ©s -- **Designs concurrents** : Companies gĂ©nĂšrent designs procĂ©duraux, reverse engineering possible -- **Commandes nationales** : États passent commandes directes selon besoins - -#### Early game - Économie de guerre Ukraine -- **Scrap russe** : RĂ©cupĂ©ration tanks dĂ©truits comme ressource de base -- **Transformation** : Recyclage et revente sur marchĂ© ukrainien -- **Bootstrap Ă©conomique** : Revenus initiaux via scrap → Ă©quipement → export - -#### Dynamiques de pĂ©nurie et production -- **PĂ©nuries temporaires** : Prix augmentent selon durĂ©e estimĂ©e de rĂ©solution -- **DiffĂ©rentiation temporelle** : "RĂ©glĂ© dans 2 mois" vs "rĂ©glĂ© dans 5 ans" -- **Adaptation marchĂ©** : Production s'ajuste selon signaux prix et demande - -#### SystĂšme de menaces (style AI War) -- **BasĂ© sur capacitĂ© production** : Volume de production brute = menace principale -- **Impact indirect** : Tank company X dĂ©truit matos → menace pour company X -- **Escalade naturelle** : SuccĂšs militaire → attention ennemie → frappes ciblĂ©es -- **Exemple concret** : Anti-tank rĂ©volutionnaire dĂ©truit masses de vĂ©hicules → strikes russes - -#### MĂ©canismes de protection -- **DĂ©fense personnelle** : Investissement dĂ©fenses propres autorisĂ© -- **Protection Ă©tatique** : État hĂŽte (Ukraine) dĂ©fend companies importantes -- **Dispersion gĂ©ographique** : Étalement production pour rĂ©duire vulnĂ©rabilitĂ© -- **NĂ©gociation neutralitĂ©** : Accords diplomatiques possibles avec hostiles -- **Équilibrage mutuel** : État protĂšge company → company contribue dĂ©fense nationale - -#### Expansion gĂ©ographique -- **DĂ©localisation** : Possible si pays hĂŽte accepte l'implantation -- **Changement nationalitĂ©** : Possible mais exclusif (pas de multi-nationalitĂ©) -- **Pas de filiales** : Structure company unifiĂ©e sous une seule nationalitĂ© -- **Approbation Ă©tatique** : Accord gouvernemental requis pour implantation - -#### SystĂšme de renseignement -- **Fog of War** : Reconnaissance obligatoire pour informations prĂ©cises -- **Identification progressive** : BĂątiments → Usines → Usines d'armement → Usine d'arme de X -- **Stats Ă©conomiques publiques** : Menace calculĂ©e sur donnĂ©es ouvertes -- **Paradoxe info** : Menace omnisciente mais localisation floue - -#### RĂŽle du joueur dans le monde -- **Échelle variable** : Du massif Ă  l'insignifiant selon choix joueur -- **Joueur secondaire** : Le monde tourne indĂ©pendamment du joueur -- **Impact optionnel** : Joueur peut influencer mais n'est pas nĂ©cessaire Ă  l'Ă©conomie globale - -### World Server -- **Fonction** : Factions, diplomatie, gĂ©opolitique, Ă©vĂ©nements macro -- **Scope** : Relations internationales, politique interne, crises globales -- **Features** : 3 endgames (zombies, aliens, dĂ©mons) -- **IntĂ©gration** : Ordre public et courants politiques - -### Gameplay asynchrone -- **Principe** : Combat peut avoir latency, player gĂšre autre chose -- **ImplĂ©mentation** : Background processing pendant diplo/Ă©conomie -- **Avantage** : Bataille 10k unitĂ©s = 30 secondes → player continue production \ No newline at end of file diff --git a/docs/04-reference/metriques-joueur.md b/docs/04-reference/metriques-joueur.md deleted file mode 100644 index c93129a..0000000 --- a/docs/04-reference/metriques-joueur.md +++ /dev/null @@ -1,269 +0,0 @@ -# MĂ©triques Joueur - -## Vue d'ensemble - -Le systĂšme de mĂ©triques de Warfactory fournit aux joueurs des **statistiques dĂ©taillĂ©es** avec graphiques complets de performance, permettant l'analyse fine de leur progression industrielle et militaire. - -## Architecture DonnĂ©es - -### Distinction Breakthrough vs MĂ©triques - -**Breakthrough System** : DonnĂ©es minimales (~KB par company) -- State actuel uniquement -- Compteurs cumulatifs simples -- Focus : Performance et dĂ©clenchement conditions - -**SystĂšme MĂ©triques** : DonnĂ©es historiques complĂštes (~MB par entitĂ©) -- Historique dĂ©taillĂ© production -- Graphiques temporels complets -- Focus : Analyse et visualisation - -### Volume de DonnĂ©es par Partie (300-400h) - -#### Companies IA (1000) -- **FrĂ©quence** : 1 point toutes les 10min -- **Ressources** : 10 produits trackĂ©s par company -- **Volume** : 1000 × 10 × (400h × 6 points/h) × 8 bytes = **192MB par partie** - -#### États (50) -- **FrĂ©quence** : 1 point toutes les 10min -- **Ressources** : 3000 ressources par Ă©tat -- **Volume** : 50 × 3000 × (400h × 6 points/h) × 8 bytes = **2.9GB par partie** - -#### Joueurs (Scaling Adaptatif Multijoueur) -- **Solo/Company partagĂ©e** : 1 point toutes les 30sec = 120 points/h -- **Multijoueur adaptatif** : FrĂ©quence rĂ©duite selon nombre de companies - - **1 company** : 2 points/min (120 points/h) - - **5 companies** : 0.4 points/min (24 points/h) - - **10+ companies** : 0.25 points/min minimum (15 points/h) -- **Ressources** : 40 produits trackĂ©s -- **Volume variable** : 1 × 40 × (400h × points/h) × 8 bytes = **15MB Ă  3MB selon config** - -**Total par partie** : ~3.1GB constant (data sharing + scaling adaptatif) -- **Joueurs mĂȘme company** : Dataset partagĂ© (pas de duplication) -- **Free-for-all** : GranularitĂ© rĂ©duite maintient volume total stable - -## Types de MĂ©triques - -### 1. Production & Économie - -#### MĂ©triques de Production -- **Production par ressource** : Steel/h, Electronic components/h, VĂ©hicules/jour -- **EfficacitĂ© usines** : % utilisation, downtime, bottlenecks identifiĂ©s -- **Évolution capacitĂ©s** : Courbes de croissance industrielle -- **Ratios production** : Input/Output, waste, efficiency metrics - -#### MĂ©triques Économiques -- **Revenus/DĂ©penses** : Graphiques dĂ©taillĂ©s par source et destination -- **Flux financiers** : Cash flow, profit margins, ROI investissements -- **Commerce international** : Exports/imports par pays et ressource -- **CoĂ»ts opĂ©rationnels** : Breakdown par type (Ă©nergie, main d'Ɠuvre, matiĂšres premiĂšres) - -### 2. Recherche & DĂ©veloppement - -#### Progression Technologique -- **Timeline breakthroughs** : Chronologie dĂ©couvertes avec sources -- **Sources de dĂ©couverte** : Ratio Scrap vs Natural vs Events vs Purchase -- **Domaines expertise** : Radar de spĂ©cialisations technologiques -- **Investissements R&D** : Allocations budget et ROI par domaine - -#### Innovation Metrics -- **Taux dĂ©couverte** : Breakthroughs/mois in-game -- **EfficacitĂ© R&D** : CoĂ»t moyen par breakthrough -- **Diversification** : Spread technologique sur domaines -- **CompĂ©titivitĂ©** : Position vs autres companies (si intel disponible) - -### 3. Expansion & Influence - -#### ContrĂŽle GĂ©ographique -- **Territoire contrĂŽlĂ©** : Surface, ressources accessibles, population -- **Infrastructure** : Density routes, bases, installations industrielles -- **Influence diplomatique** : Relations par pays/rĂ©gion, contrats actifs -- **SĂ©curitĂ© zones** : Threat levels, incidents sĂ©curitaires - - -## Visualisations - -### Graphiques Temporels - -#### Production Dashboard -``` -Production Steel (tonnes/jour) - â–Č -1000│ ╭─╼ - 800│ ╭─╯ ╰─╼ - 600│ ╭─╯ ╰─╼ - 400│╭╯ ╰─╼ - 200│╯ ╰─── - 0└─────────────────────▶ - Mois 1 2 3 4 5 6 -``` - -#### Financial Trends -``` -Cash Flow (M€) - â–Č - 5.0│ ██████████████████▒▒▒▒ Revenue - 4.0│ ████████████▒▒▒▒▒▒▒▒▒▒ Expenses - 3.0│ ████████▒▒▒▒▒▒▒▒▒▒▒▒▒▒ Profit - 2.0│ ████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ - 1.0│ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ - 0└─────────────────────▶ - Q1 Q2 Q3 Q4 -``` - -#### Breakthrough Timeline -``` -DĂ©couvertes Technologiques -│ -├─ Mois 2: Radar AvancĂ© (Scrap Analysis) -├─ Mois 4: MatĂ©riaux Composites (Natural) -├─ Mois 7: IA Tactique (Purchase Intel) -├─ Mois 9: Blindage RĂ©actif (Capture) -└─ Mois 12: Moteurs Fusion (Event) -``` - -### Radar Charts - -#### Technology Mastery -``` - IA (8/10) - /\ - / \ -Electronics MatĂ©riaux - (6/10) ────────── (9/10) - \ / - \ / - Moteurs (4/10) -``` - -### Heatmaps - -#### Market Opportunities -``` -Resource vs Country Demand - │UKR│POL│GER│FRA│ -Steel │ ██│ ▓▓│ ░░│ ▓▓│ -Electronics│▓▓│ ██│ ██│ ▓▓│ -Vehicles │ ██│ ▓▓│ ░░│ ░░│ -``` - -## SystĂšme de Stockage - -### Architecture DonnĂ©es - -#### Structure TimeSeries SimplifiĂ©e -```cpp -struct MetricTimeseries { - int32_t value; // 4 bytes signed int - // Timestamp et rĂ©solution stockĂ©s en mĂ©tadonnĂ©es -}; - -struct TimeseriesMetadata { - uint32_t start_timestamp; - uint32_t interval_seconds; // Ex: 30s pour joueur, 600s pour IA - uint32_t data_count; -}; - -struct EntityMetrics { - EntityID entity_id; - - // Production (par ressource) - listes simples de int32 - map> production_history; - map production_metadata; - - // Financial - listes simples - vector revenue_history; - vector expenses_history; - vector cash_flow_history; - TimeseriesMetadata financial_metadata; - - // Technology - vector breakthrough_timeline; -}; -``` - -#### Breakthrough Events SimplifiĂ© -```cpp -struct BreakthroughEvent { - uint32_t timestamp; - TechID technology_id; - BreakthroughSource source; // SCRAP, NATURAL, PURCHASE, EVENT - string details; // "Scrap: T-72 Tank" -}; -``` - -### AgrĂ©gation & Compression - -#### RĂ©solution Adaptative -- **DerniĂšre semaine** : Points toutes les 30sec (joueur) / 10min (IA) -- **Dernier mois** : AgrĂ©gation horaire -- **Derniers 6 mois** : AgrĂ©gation quotidienne -- **Plus ancien** : AgrĂ©gation hebdomadaire - -#### Compression Intelligente -- **Delta encoding** : Stocker diffĂ©rences vs valeurs absolues -- **Run-length encoding** : Pour pĂ©riodes stables (production constante) -- **Lossy compression** : DonnĂ©es anciennes → prĂ©cision rĂ©duite acceptable - -## Interface MĂ©triques - -### Dashboard Principal - -#### Vue d'Ensemble -``` -┌─────────────────┬─────────────────┬─────────────────┐ -│ PRODUCTION │ FINANCES │ RECHERCHE │ -│ Steel: ↗ +15% │ Profit: ↗ +8% │ 3 breakthroughs│ -│ Elec: ↘ -3% │ Cash: 2.4M€ │ this month │ -├─────────────────┌─────────────────┌────────────────── -│ TERRITOIRE │ DIPLOMATIC │ STATUS │ -│ 12 installations│ 3 trade deals │ ✅ Operational │ -│ 3 countries │ 85% relations │ 🔄 Expanding │ -└─────────────────┮─────────────────┮─────────────────┘ -``` - -#### Navigation & Drill-Down -- **Overview** → **Domain** → **Specific Metric** → **Detailed Timeline** -- **Comparisons** : Self vs time, targets vs actual, competitors (si data available) -- **Filters** : Date ranges, metric types, zoom levels, entity types - -### MĂ©triques SpĂ©cialisĂ©es - -#### Competitive Intelligence (si disponible) -``` -Market Share Analysis -Company │Production│Revenue│Breakthroughs│ -Thales │ 25% │ 30% │ 18 │ -Lockheed │ 18% │ 22% │ 15 │ -Player │ 12% │ 15% │ 12 │ -Dassault │ 15% │ 18% │ 10 │ -Others │ 30% │ 15% │ 45 │ -``` - - - -## Privacy & Intelligence - -### Data Visibility - -#### Player Data (Full Access) -- **Toutes mĂ©triques personnelles** : Production, finances, recherche, combat -- **Historique complet** : Depuis dĂ©but de partie -- **Analytics avancĂ©es** : Trends, predictions, optimization suggestions - -#### Competitor Data (Limited) -- **Via espionnage** : Intel partiel sur production/capabilities -- **Market signals** : DĂ©ductions via prix, volumes, nouvelles exportations -- **Combat assessment** : Performance observĂ©e lors d'engagements -- **Public information** : Certaines mĂ©triques "corporate" accessibles - -#### State Data (Contextual) -- **Economic indicators** : PIB, imports/exports publics -- **Military capabilities** : Intel selon relations diplomatiques -- **Technology level** : Observations Ă©quipements, brevets publics - - ---- - -*Les mĂ©triques constituent l'outil principal d'analyse et d'optimisation continue pour maĂźtriser la complexitĂ© industrielle et militaire de Warfactory* \ No newline at end of file diff --git a/docs/04-reference/questions-ouvertes.md b/docs/04-reference/questions-ouvertes.md deleted file mode 100644 index 383683f..0000000 --- a/docs/04-reference/questions-ouvertes.md +++ /dev/null @@ -1,319 +0,0 @@ -# Questions Ouvertes - Warfactory - -*Questions importantes Ă  rĂ©soudre lors du dĂ©veloppement* - -## Questions Architecturales - -### 1. **Operation Engine - ComprĂ©hension Situation** -**Question** : Comment implĂ©menter l'analyse de rapports War Engine pour "comprendre" situations complexes ? - -**Options envisagĂ©es** : -- Pattern matching simple (if-then rules) -- Algorithmes plus sophistiquĂ©s -- Machine learning avancĂ© - -**Status** : En suspens, sujet difficile Ă  rĂ©soudre pour l'instant - -### 2. **Designer Engine Role** ✅ RÉSOLU -**Question** : Qui design les vĂ©hicules pour les IA companies/Ă©tats ? - -**Solution** : Designer Engine unifiĂ© sert joueur ET IA -- IA : Random generation + evaluate + blueprints doctrinaux -- Joueur : Design manuel + assistance IA optionnelle -- Company features influencent choix procĂ©duraux IA - -### 3. **Factory Benchmarking Implementation** ✅ RÉSOLU -**Question** : Le systĂšme factory benchmarking est-il implĂ©mentĂ© ou spĂ©culatif ? - -**Solution** : ReportĂ© en long-term update -- Optimisation prĂ©maturĂ©e, focus sur gameplay core d'abord -- Concept conservĂ© pour dĂ©veloppement futur -- Status uniforme dans tous les documents - -## Questions Gameplay - -### 4. **Tension Militaire/Politique** -**Question** : MĂ©caniques concrĂštes pour rĂ©sistance militaire aux ordres politiques stupides ? - -**Exemples** : -- Militaire peut "traĂźner les pieds" sur ordres suicide -- DĂ©lais supplĂ©mentaires pour ordres non-optimaux -- SystĂšme de moral/confiance commandement - -**Status** : EnvisagĂ© pour long-term updates - -### 5. **Convergence Tactique IA** -**Question** : Comment Ă©viter homogĂ©nĂ©isation si toutes IA apprennent mĂȘmes tactiques efficaces ? - -**Solutions identifiĂ©es** : -- DiversitĂ© options/tech/ennemis -- Armes semi-random crĂ©ent diffĂ©rentiations -- Biais doctrinaux persistants - -**À surveiller** : Équilibrage convergence rĂ©aliste vs diversitĂ© gameplay - -## Questions Techniques - -### 6. **Chunk Size Standardization** ✅ RÉSOLU -**Question** : Quelle taille officielle pour les chunks ? - -**Solution** : Architecture multi-Ă©chelle clarifiĂ©e -- SystĂšme patches ressources (forme libre) vs chunks terrain/bĂątiments/effets -- Chaque type de donnĂ©e utilise rĂ©solution optimale selon besoins -- 64x64 = chunk principal gameplay, autres tailles pour donnĂ©es spĂ©cialisĂ©es - -### 7. **Client Capabilities** ✅ RÉSOLU -**Question** : Les clients sont-ils "dumb terminals" ou gĂšrent-ils streaming intelligent ? - -**Solution clarifiĂ©e** : Smart Client / Authoritative Server -- **Client Smart** : Interface complexe, rendu optimisĂ©, streaming carte, cache local -- **Client Dumb** : Aucune simulation gameplay, pas de logique mĂ©tier -- **ResponsabilitĂ©s client** : UI industrielle/militaire/diplomatique, LOD, culling, cache zones -- **Server Authoritative** : Toute simulation et Ă©tat de jeu - -**CohĂ©rence restaurĂ©e** : Terminologie "dumb terminal" remplacĂ©e par architecture plus prĂ©cise. - -## Questions Scope - -### 8. **SystĂšme Administration - Integration** ✅ RÉSOLU -**Question** : Comment intĂ©grer le systĂšme de points d'administration avec l'architecture engines ? - -**Solution** : MacroEntity Engine gĂšre entiĂšrement le systĂšme -- **Architecture** : MacroEntity Engine responsable companies/Ă©tats + administration -- **Isolation** : Autres engines ignorent systĂšme admin, consultent via API si besoin -- **Actions refusĂ©es** : Admin exhaustĂ© = refus immĂ©diat (pas de queue) -- **Performance** : Calculs lĂ©gers, batch processing, rythme adaptĂ© gameplay macro -- **Joueur exempt** : Pas de contraintes admin pour le joueur -- **Recherche** : CoĂ»ts admin faibles pour ne pas freiner le jeu - -### 9. **Client Rendering Stack** -**Question** : Quelle technologie pour le rendu 2D pixel art ? - -**Options techniques** : -- **Canvas 2D** : Simple, direct, compatible partout -- **WebGL** : Performance supĂ©rieure, scaling, effects -- **Hybrid** : Canvas UI + WebGL game world - -**ConsidĂ©rations** : -- Performance avec milliers d'unitĂ©s simultanĂ©es -- CompatibilitĂ© navigateurs et plateformes -- ComplexitĂ© dĂ©veloppement vs performance gains -- Support zoom discret pixel perfect - -**À dĂ©cider** : Choix tech stack rendu client - -### 10. **DĂ©veloppement Narratif** -**Question** : Comment dĂ©velopper le contenu narratif pour supporter la richesse du systĂšme ? - -**État actuel** : Travail narratif incomplet -- **Ukraine baseline** : Contexte initial dĂ©fini mais peu dĂ©veloppĂ© -- **Autres rĂ©gions** : Congo, Sahara, etc. - aucun contenu narratif -- **Storylines** : Manque de quĂȘtes, Ă©vĂ©nements, personnages -- **Immersion** : Gap entre mĂ©caniques sophistiquĂ©es et narrative basique - -**Besoins identifiĂ©s** : -- **Ukraine dense** : DĂ©velopper storylines Ă©piques, personnages, Ă©vĂ©nements historiques -- **RĂ©gions alternatives** : Warlords Congo, conflicts sahĂ©liens, tensions gĂ©opolitiques -- **ÉvĂ©nements dynamiques** : Crises, alliances, retournements de situation -- **Personnages** : Leaders, gĂ©nĂ©raux, figures historiques et fictives -- **Lore systĂ©mique** : Background Ă©conomique, technologique, culturel par rĂ©gion - -**À dĂ©velopper** : Contenu narratif riche pour toutes les rĂ©gions supportĂ©es - -### 11. **Optimisations Transport Factorio (Factory System Performance)** -**Question** : Quelle stratĂ©gie d'optimisation pour atteindre 50x-100x gains performance sur les belts/convoyeurs ? - -**Optimisations identifiĂ©es** : -- **Segment merging** : Fusion segments identiques pour rĂ©duire calculs -- **Compression caching** : Cache Ă©tats compressĂ©s pour Ă©viter recalculs -- **Belt batching** : Traiter items par lots plutĂŽt qu'individuellement -- **Spatial indexing** : Structures spatiales optimisĂ©es pour queries rapides - -**Trade-offs Ă  considĂ©rer** : -- **MĂ©moire vs CPU** : Caching augmente RAM mais rĂ©duit calculs -- **Latence vs Throughput** : Batching amĂ©liore dĂ©bit mais augmente latence -- **ComplexitĂ© vs Performance** : Optimisations avancĂ©es compliquent maintenance - -**À investiguer** : -- Profiling dĂ©taillĂ© systĂšme actuel pour identifier bottlenecks -- Benchmarking diffĂ©rentes approches (segment merging vs autres) -- Équilibrage optimal entre diffĂ©rentes optimisations -- Impact sur architecture modulaire (ProductionModule monolithique) - -### 12. **SOA Data Layout (Structure of Arrays)** -**Question** : Comment implĂ©menter efficacement le pattern SOA pour optimiser cache locality et prĂ©parer SIMD ? - -**Contexte technique** : -- **AOS traditionnel** : `struct Entity { x, y, z, health; } entities[1000];` -- **SOA optimisĂ©** : Arrays sĂ©parĂ©s `positions_x[1000]`, `positions_y[1000]`, etc. - -**Avantages SOA** : -- **Cache efficiency** : Traitement d'une propriĂ©tĂ© sur toutes entitĂ©s sans charger donnĂ©es inutiles -- **SIMD readiness** : DonnĂ©es alignĂ©es pour vectorisation automatique -- **Memory bandwidth** : RĂ©duction transferts mĂ©moire jusqu'Ă  4x - -**Application Warfactory** : -- **Belts** : Positions, vitesses, items sĂ©parĂ©s pour traitement batch -- **Factories** : États production, inventaires, types en arrays distincts -- **Units** : CoordonnĂ©es, santĂ©, munitions en structures sĂ©parĂ©es - -**DĂ©fis d'implĂ©mentation** : -- **ComplexitĂ© code** : AccĂšs moins intuitif qu'AOS -- **Maintenance** : Synchronisation entre arrays parallĂšles -- **Trade-off** : SOA pas optimal pour accĂšs random single entity - -**À dĂ©cider** : -- Quels systĂšmes bĂ©nĂ©ficient le plus de SOA ? -- Comment gĂ©rer la transition progressive AOS → SOA ? -- Quel niveau d'abstraction pour masquer complexitĂ© ? - -### 13. **Trade-off SIMD vs Claude (Optimisation vs MaintenabilitĂ©)** -**Question** : Faut-il privilĂ©gier auto-vectorisation compilateur ou SIMD manuel pour performance ? - -**Context dĂ©cisionnel** : -- **SIMD manuel** : Intrinsics SSE/AVX/NEON pour contrĂŽle total performance -- **Auto-vectorisation** : Compilateur optimise automatiquement avec flags appropriĂ©s - -**Arguments pour auto-vectorisation** : -- **SimplicitĂ© code** : Pas d'intrinsics complexes, code lisible -- **PortabilitĂ©** : Fonctionne sur toutes architectures sans modification -- **Claude-friendly** : IA peut comprendre et modifier facilement -- **Maintenance** : RĂ©duction drastique complexitĂ© long-terme - -**Arguments contre SIMD manuel** : -- **ComplexitĂ© extrĂȘme** : Code intrinsics illisible, bug-prone -- **Architecture-specific** : Versions diffĂ©rentes ARM/x86/x64 -- **ROI questionnable** : 10-20% gain pour 10x complexitĂ© -- **Claude incompatible** : IA difficile Ă  utiliser sur code SIMD - -**StratĂ©gie recommandĂ©e** : -- **Phase 1** : SOA + auto-vectorisation partout -- **Phase 2** : Profiling pour identifier hot spots rĂ©els -- **Phase 3** : SIMD manuel UNIQUEMENT si bottleneck critique prouvĂ© -- **Documentation** : Si SIMD manuel, isoler dans fonctions avec fallback C++ - -**Flags compilateur optimaux** : -- `-O3 -march=native` : Maximum auto-vectorisation -- `-ftree-vectorize` : Force vectorisation loops -- `-ffast-math` : Optimisations math agressives (attention prĂ©cision) - -### 14. **Infrastructure Binaire (AccĂšs Transport)** -**Question** : L'accĂšs aux infrastructures (port/rail/aĂ©roport) doit-il ĂȘtre binaire ou graduĂ© ? - -**Option Binaire (proposĂ©e)** : -- AccĂšs = true/false uniquement -- SimplicitĂ© maximale pour IA et gameplay -- Pas de niveaux ou gradients - -**Option GraduĂ©e (alternative)** : -- Niveaux infrastructure (petit port → grand port → mĂ©ga-port) -- CapacitĂ© throughput variable -- CoĂ»ts d'upgrade progressifs - -**Trade-offs** : -- **Binaire** : Simple mais moins de nuance stratĂ©gique -- **GraduĂ©** : Plus rĂ©aliste mais complexitĂ© accrue -- **Hybride** : Binaire pour accĂšs, capacitĂ© max comme propriĂ©tĂ© sĂ©parĂ©e - -**À dĂ©cider** : Quelle granularitĂ© pour l'infrastructure transport ? - -### 15. **Phases Économiques (Cycle 24h)** -**Question** : Comment structurer le cycle Ă©conomique quotidien de 24h ? - -**Proposition actuelle** : -- Offer: 6h - Companies postent offres -- Demand: 6h - Companies postent demandes -- Clearing: 1h - Algorithme matching -- Transport: 1h - Organisation logistique -- Execution: 10h - Livraison effective - -**Questions ouvertes** : -- **Synchronisation globale** : Tous sur mĂȘme cycle ou dĂ©calĂ©s par timezone ? -- **FlexibilitĂ©** : Permettre transactions hors-cycle pour urgences ? -- **GranularitĂ©** : 24h trop long/court pour gameplay ? -- **Interruptions** : Que se passe-t-il si guerre/embargo pendant cycle ? - -**Alternatives** : -- Cycles plus courts (6h) pour dynamisme -- Cycles asynchrones par marchĂ© rĂ©gional -- SystĂšme continu avec batch processing pĂ©riodique - -### 16. **Pricing Dynamique (Formule Prix)** -**Question** : Quelle formule prĂ©cise pour calculer les prix dynamiques ? - -**Composants identifiĂ©s** : -- Base price (coĂ»t production) -- Transport cost (distance × mode) -- Scarcity factor (offre/demande) -- Regional modifiers (taxes, risques) - -**Formule proposĂ©e** : -`Prix = Base × (1 + Scarcity) × (1 + Regional) + Transport` - -**Questions dĂ©tails** : -- **Scarcity calculation** : LinĂ©aire, exponentielle, ou par paliers ? -- **Regional factors** : Guerre (+50%), embargo (+100%), taxes (±20%) ? -- **Price caps** : Limiter prix max pour Ă©viter spirales ? -- **Historical smoothing** : Moyenne mobile pour stabilitĂ© ? - -**Impacts Ă  considĂ©rer** : -- VolatilitĂ© excessive peut frustrer joueurs -- Prix trop stables = pas d'opportunitĂ©s trading -- Balance rĂ©alisme vs fun gameplay - -### 17. **Vision Simulation ComplĂšte Victoria 3-Level (Point 35)** -**Question** : Comment implĂ©menter une simulation Ă©conomique Victoria 3-level dans le contexte factory game de Warfactory ? - -**Modules identifiĂ©s** : -- **PopulationModule** : Demographics avec classes (Workers/Engineers/Managers) -- **MarketModule** : Supply/demand dynamics avec price discovery real-time -- **MoneyModule** : Currency, inflation, banking systems -- **TradeModule** : International commerce, tariffs, trade agreements -- **PolicyModule** : Government intervention, taxation, regulation - -**DĂ©fis d'intĂ©gration** : -- **Performance scaling** : 0.01-0.1Hz simulation Ă©conomique vs real-time factory -- **Complexity balance** : Victoria 3-level sans overwhelming factory gameplay -- **Player agency** : Comment player influence Ă©conomie macro via actions micro -- **Data interdependencies** : Synchronisation entre modules Ă©conomiques - -**Questions spĂ©cifiques** : -- **Population dynamics** : Birth/death rates, migration patterns rĂ©alistes ? -- **Economic timescales** : Daily economic cycles vs hourly factory production ? -- **Government simulation** : Policies automatiques ou player-controlled ? -- **Market volatility** : Niveau rĂ©alisme vs stabilitĂ© gameplay ? - -**Architecture concerns** : -- Quel niveau dĂ©tail pour chaque module ? -- Comment Ă©viter simulation Ă©conomique devenant mini-jeu sĂ©parĂ© ? -- Interface player pour comprendre/influencer Ă©conomie macro ? -- Performance impact sur real-time factory operations ? - -**Scope questions** : -- Victoria 3-level = objectif final ou starting point ? -- Quels aspects Victoria 3 essentiels vs nice-to-have ? -- Timeline implĂ©mentation (post-MVP ou core feature) ? - -**À dĂ©terminer** : Scope prĂ©cis, architecture dĂ©taillĂ©e, prioritĂ©s implĂ©mentation - -## Process de RĂ©solution - -### PrioritĂ© 1 - Bloquants Architecture -- Factory benchmarking status -- Chunk size standardization -- Client capabilities dĂ©finition - -### PrioritĂ© 2 - Core Gameplay -- Designer Engine role -- Operation Engine comprehension method - -### PrioritĂ© 3 - Polish Features -- Tension militaire/politique -- Convergence tactique prevention - -### Long-term -- Narrative/technical alignment - ---- - -*Ces questions seront rĂ©solues progressivement lors du dĂ©veloppement. Certaines nĂ©cessitent prototypage pour validation.* \ No newline at end of file diff --git a/docs/04-reference/updates-long-terme.md b/docs/04-reference/updates-long-terme.md deleted file mode 100644 index 1a4072a..0000000 --- a/docs/04-reference/updates-long-terme.md +++ /dev/null @@ -1,174 +0,0 @@ -# Updates Long Terme - -## FonctionnalitĂ©s futures Ă  dĂ©velopper - -### Espionnage Industriel -- **Vol de breakthroughs** : MĂ©caniques permettant aux companies de voler les technologies d'autres actors -- **Protection IP** : SystĂšmes de sĂ©curisation des technologies sensibles -- **Contre-espionnage** : DĂ©fenses contre tentatives d'infiltration technologique -- **RĂ©seaux d'espions** : Agents infiltrĂ©s dans companies concurrentes - -### Factory Benchmarking System -**Concept** : Conversion des usines stables en lookup tables pour performance optimale - -**Inspiration** : ModĂšle Mindustry pour optimisation usines Ă  grande Ă©chelle -- DĂ©tection automatique patterns d'input/output stables -- Conversion vers calculs O(1) pour scaling optimal -- Maintien prĂ©cision comportement vs simulation complĂšte - -**Process envisagĂ©** : -1. Factory neuve → full simulation dĂ©taillĂ©e -2. AprĂšs X cycles stables → benchmark input/output ratios -3. Conversion en lookup table → unload detailed simulation -4. Recalibrage si modifications (upgrades, dĂ©gĂąts) - -**Justification report** : Optimisation prĂ©maturĂ©e, focus sur gameplay core d'abord - -### Économie avancĂ©e -- **Balance commerciale** : États surveillent imports/exports -- **Inflation** : SystĂšme d'impression monĂ©taire et dĂ©valuation en temps de guerre -- **Économie noire** : MarchĂ©s parallĂšles dans zones de conflit - -### Business Models Émergents (Point 24) -**Trois modĂšles Ă©conomiques Ă©mergents** crĂ©ent des niches Ă©conomiques distinctes : - -#### 1. Arbitrage Pur -- **MĂ©canisme** : Exploite diffĂ©rentiels prix gĂ©ographiques -- **Strategy** : Acheter cĂŽtier (ship 0.10€/kg) → Stocker stratĂ©gique → Revendre isolĂ© (truck 5.00€/kg) -- **Profit** = DiffĂ©rentiel prix - coĂ»ts stockage (0.02€/kg/jour) - transport - -#### 2. Transport Optimization -- **MĂ©canisme** : AgrĂ©gation commandes pour seuils 1000t shipping maritime -- **Strategy** : Consolidation volumes → Optimisation multi-modale (Ship→Rail→Truck) → Économies d'Ă©chelle -- **Profit** = RĂ©duction coĂ»ts transport via optimisation logistique - -#### 3. Market Making -- **MĂ©canisme** : Stabilisation marchĂ©s via stocks tampons et liquiditĂ© permanente -- **Strategy** : Buffer stock → Stabiliser prix → Profit sur bid/ask spreads -- **Profit** = Spreads + rĂ©duction volatilitĂ© + commissions transaction - -**Impact** : Companies AI dĂ©couvrent naturellement ces patterns, crĂ©ant Ă©conomie Ă©mergente complexe selon avantages gĂ©ographiques/logistiques. - -### SpĂ©cialisation Companies (Point 25) -**Quatre types de spĂ©cialisation Ă©mergent naturellement** dans l'Ă©cosystĂšme Ă©conomique : - -#### 1. Geographic Specialists -- **Regional expertise** : Connaissance approfondie zones spĂ©cifiques -- **Infrastructure deals** : Accords exclusifs ports/rail/aĂ©roports -- **Local intelligence** : RĂ©glementations, culture, contacts terrain -- **Transport optimization** : Solutions logistiques rĂ©gionales sur-mesure - -#### 2. Commodity Specialists -- **Vertical expertise** : Connaissance technique commodity unique -- **Quality assessment** : Certification, grading, standards qualitĂ© -- **Technical logistics** : Stockage/manipulation spĂ©cialisĂ©s -- **Market prediction** : Patterns supply/demand prĂ©cis par produit - -#### 3. Logistics Specialists -- **Multi-modal optimization** : Planification Ship→Rail→Truck -- **Volume consolidation** : AgrĂ©gation ordres pour seuils 1000t+ -- **Infrastructure leverage** : Maximisation efficacitĂ© transport -- **Economic timing** : Coordination phases Ă©conomiques 24h - -#### 4. Financial Specialists -- **Risk management** : Hedging, assurance, instruments dĂ©rivĂ©s -- **Futures markets** : Gestion contrats long-terme -- **Credit facilities** : Financement opĂ©rations commerciales -- **Currency hedging** : Protection change international - -**Émergence** : AI companies dĂ©veloppent automatiquement ces spĂ©cialisations selon avantages gĂ©ographiques/Ă©conomiques, crĂ©ant Ă©cosystĂšme diversifiĂ© sans scripting. - -### Anti-Cheat Psychologique (Point 34) -**Guerre psychologique contre cheaters** au lieu de bans traditionnels : - -#### Bugs SimulĂ©s Progressifs -```cpp -class PsychologicalAntiCheat { - void onCheatDetected(CheatType type, Player player) { - switch(type) { - case SPEED_HACK: - simulateRandomLag(player, 50, 500); // 50-500ms lag - break; - case RESOURCE_HACK: - introduceVisualGlitches(player, 0.05f); // 5% tanks affected - break; - case DAMAGE_HACK: - simulateMovementDesync(player, 0.02f); // 2% dĂ©viation - break; - } - } -}; -``` - -#### StratĂ©gies Comportementales -**Escalation progressive vs bans immĂ©diats :** -- **Phase 1 - Doute subtil** : Performance dĂ©gradation lĂ©gĂšre, faux positifs contrĂŽlĂ©s -- **Phase 2 - Chaos apparent** : DĂ©synchronisation sĂ©lective, inconsistant results -- **Player frustration** : Abandon volontaire cheating via psychological pressure - -#### Benefits vs Traditional Bans -- **Retention lĂ©gitimes** : Joueurs normaux 100% non affectĂ©s -- **Cheater abandonment** : Auto-exclusion via frustration plutĂŽt que dĂ©tection -- **No cat-and-mouse** : Pas course aux nouveaux cheats -- **Silent operation** : Cheaters ignorent qu'ils sont dĂ©tectĂ©s jusqu'Ă  abandonment - -### Interface et Vues -- **Vues multiples simultanĂ©es** : Plusieurs vues locales ouvertes en mĂȘme temps -- **Split-screen** : Surveiller plusieurs zones/usines simultanĂ©ment -- **Picture-in-picture** : Mini-vues dans vue principale - -### SystĂšme de Communication -- **SystĂšme de messages** : Communication asynchrone entre joueurs -- **Diplomatie formalisĂ©e** : Propositions, traitĂ©s, accords commerciaux -- **Intel sharing** : Partage de reconnaissance entre alliĂ©s - -### Limites Techniques Map -- **Chunks actifs max** : Limite nombre chunks simultanĂ©s pour performance -- **Distance rendu max** : LOD et culling selon distance -- **Joueurs par zone** : Limite joueurs dans mĂȘme zone locale -- **Optimisations mĂ©moire** : Compression chunks inactifs -- **Streaming adaptatif** : Ajustement qualitĂ© selon bande passante - -### GĂ©nĂ©ration ProcĂ©durale AvancĂ©e -- **Cultures urbaines** : Styles architecturaux par rĂ©gion/pays -- **ContinuitĂ© amĂ©liorĂ©e** : Algorithmes liaison inter-chunks -- **Biomes complexes** : Transitions naturelles entre terrains - -### Load Balancing et Distribution AvancĂ©e -**Future Ă©volution du CoordinationModule** pour optimisation performance automatique : - -#### Distribution Intelligente des Modules -- **CPU Load Monitoring** : Surveillance utilisation processeur par module -- **Network Latency Aware** : Placement modules selon latence rĂ©seau -- **Memory Usage Optimization** : RĂ©partition selon consommation mĂ©moire -- **Auto-scaling** : Lancement instances multiples modules haute charge - -#### Migration Dynamique -```cpp -class LoadBalancer { - void redistributeModules() { - // Analyse performance metrics - if (economyModule.getCPUUsage() > 80%) { - migrateToLowerLoadServer(economyModule); - } - - // Optimisation latence - if (networkLatency(tankModule, productionModule) > 50ms) { - colocateModules(tankModule, productionModule); - } - } -}; -``` - -#### StratĂ©gies de Placement -- **Colocation Intelligente** : Modules communicants sur mĂȘme serveur -- **Geographic Distribution** : Placement modules selon localisation joueurs -- **Resource Affinity** : Modules CPU-intensifs vs I/O-intensifs -- **Hot-Standby** : RĂ©plication modules critiques pour haute disponibilitĂ© - -### Autres fonctionnalitĂ©s Ă  explorer -*À complĂ©ter selon l'Ă©volution du projet* - ---- - -*Ce document liste les fonctionnalitĂ©s prĂ©vues pour les mises Ă  jour futures du jeu* \ No newline at end of file diff --git a/docs/README.md b/docs/README.md index c6fb6ec..3b72e1d 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,71 +1,175 @@ -# Documentation Warfactory +# AISSIA Documentation -## 📁 Structure Documentation +**AISSIA** (AI Smart Schedule & Interactive Assistant) - Assistant personnel intelligent pour la gestion du temps et de l'hyperfocus. -### 📋 00-overview/ -Vision gĂ©nĂ©rale, contexte, et introduction au projet -- `README.md` - Guide principal dĂ©veloppeur -- `vue-ensemble.md` - Vision et philosophie projet -- `contexte-narratif.md` - Background et univers -- `dlc-prevus.md` - Extensions planifiĂ©es +## Vue d'Ensemble -### đŸ—ïž 01-architecture/ -Architecture technique et patterns de dĂ©veloppement -- `architecture-technique.md` - Architecture modulaire complĂšte -- `claude-code-integration.md` - DĂ©veloppement optimisĂ© IA -- `behavior-composition-patterns.md` - Patterns comportement modulaire -- `player-integration.md` - IntĂ©gration client/serveur +AISSIA est un assistant personnel proactif qui aide Ă  gĂ©rer le temps, les prioritĂ©s et l'hyperfocus en utilisant l'architecture modulaire WarFactory pour un dĂ©veloppement rapide avec hot-reload. -### ⚙ 02-systems/ -SystĂšmes de jeu et mĂ©caniques core -- `gameplay-industriel.md` - SystĂšme factory/production -- `systeme-militaire.md` - Design vĂ©hicules et combat -- `economie-logistique.md` - Économie et transport -- `map-system.md` - GĂ©nĂ©ration procĂ©durale et terrain -- `factory-architecture-post-player.md` - Architecture production avancĂ©e +### ProblĂšme RĂ©solu -### 🔧 03-implementation/ -ImplĂ©mentation, configuration et dĂ©ploiement -- `testing-strategy.md` - StratĂ©gie tests et validation -- `systemes-techniques.md` - SpĂ©cifications techniques bas niveau -- `configuration/` - SystĂšme configuration modulaire +- **Hyperfocus** : IncapacitĂ© Ă  stopper une tĂąche une fois dĂ©marrĂ©e +- **Absence de limites** : Continuer jusqu'Ă  Ă©puisement physique +- **Transitions difficiles** : DifficultĂ© Ă  passer d'une activitĂ© Ă  une autre +- **RĂ©gulation dĂ©faillante** : Besoin d'un systĂšme externe pour gĂ©rer l'attention -### 📚 04-reference/ -RĂ©fĂ©rence technique et documentation de suivi -- `arbre-technologique.md` - Arbre tech 3000+ technologies -- `mecaniques-jeu.md` - MĂ©caniques et systĂšmes dĂ©taillĂ©s -- `metriques-joueur.md` - Analytics et mĂ©triques (3.1GB/game) -- `coherence-problem.md` - ProblĂšmes rĂ©solus et analyses -- `questions-ouvertes.md` - Questions techniques en cours -- `updates-long-terme.md` - Évolutions futures -- `effets-attendus.md` - Effets Ă©mergents prĂ©dits -- `content-integrated.md` - Suivi intĂ©gration contenu +### Solution ProposĂ©e +Assistant intelligent qui : +- Intervient de maniĂšre proactive selon planning +- Planifie intelligemment avec l'IA +- Force les transitions quand nĂ©cessaire +- S'adapte aux besoins utilisateur +- Accompagne l'apprentissage de langues Ă©trangĂšres -## 🎯 Points d'EntrĂ©e RecommandĂ©s +## Architecture -**Pour comprendre le projet :** -1. `00-overview/vue-ensemble.md` - Vision gĂ©nĂ©rale -2. `01-architecture/architecture-technique.md` - Architecture modulaire -3. `02-systems/gameplay-industriel.md` - Gameplay core +AISSIA rĂ©utilise l'**architecture modulaire WarFactory** : -**Pour dĂ©velopper :** -1. `01-architecture/claude-code-integration.md` - Workflow dĂ©veloppement IA -2. `03-implementation/testing-strategy.md` - Strategy tests -3. `04-reference/coherence-problem.md` - Analyses techniques rĂ©solues +- **Hot-reload 0.4ms** : Modifications instantanĂ©es sans restart +- **Modules 200-300 lignes** : DĂ©veloppement optimisĂ© pour Claude Code +- **Build autonome** : `cmake .` depuis chaque module +- **DĂ©veloppement parallĂšle** : Multiple instances Claude Code simultanĂ©es -**Pour la rĂ©fĂ©rence technique :** -1. `04-reference/arbre-technologique.md` - Tech tree complet -2. `04-reference/coherence-problem.md` - Analyses techniques -3. `04-reference/effets-attendus.md` - Effets Ă©mergents prĂ©dits +### Avantages ClĂ©s -## 📊 Statistiques +✅ **DĂ©veloppement ultra-rapide** : Hot-reload validĂ© Ă  0.4ms +✅ **Types stricts C++** : Pas de "wildcode" +✅ **Architecture Ă©prouvĂ©e** : WarFactory validĂ© en production +✅ **Privacy-first** : Mode local, donnĂ©es jamais uploadĂ©es +✅ **Évolution progressive** : MVP → Production → Cloud sans rĂ©Ă©criture -- **Architecture modulaire** rĂ©volutionnaire optimisĂ©e IA -- **85% d'intĂ©gration** architecture modulaire complĂšte -- **Documentation ultra-dense** : 1 spĂ©cification toutes les 3.8 lignes -- **PrĂȘt pour dĂ©veloppement** : Architecture production-ready +## Structure Documentation ---- +``` +docs/ +├── README.md # Ce fichier +├── architecture/ # Architecture technique +│ ├── architecture-modulaire.md # Interfaces WarFactory (IEngine, IModule, IIO) +│ ├── architecture-technique.md # Architecture systĂšme complĂšte +│ └── claude-code-integration.md # IntĂ©gration Claude Code +└── implementation/ # Guides d'implĂ©mentation + ├── CLAUDE-HOT-RELOAD-GUIDE.md # Guide hot-reload (0.4ms) + ├── AUTOMATION_GUIDE.md # Automatisation du build + ├── ADVANCED_TESTING.md # StratĂ©gies de test + └── configuration/ # Configuration systĂšme + ├── module-configuration.md + ├── deployment-strategies.md + ├── error-handling.md + ├── module-versioning.md + └── security-measures.md +``` -*Documentation nettoyĂ©e et rĂ©organisĂ©e - Structure hiĂ©rarchique optimisĂ©e pour navigation et dĂ©veloppement* \ No newline at end of file +## DĂ©marrage Rapide + +### 1. Lire l'Architecture + +**Ordre recommandĂ© :** + +1. **[architecture-modulaire.md](architecture/architecture-modulaire.md)** + → Comprendre les 5 interfaces fondamentales (IEngine, IModule, IModuleSystem, IIO, ICoordinationModule) + +2. **[architecture-technique.md](architecture/architecture-technique.md)** + → Voir comment AISSIA utilise WarFactory pour ses modules + +3. **[CLAUDE-HOT-RELOAD-GUIDE.md](implementation/CLAUDE-HOT-RELOAD-GUIDE.md)** + → Workflow de dĂ©veloppement avec hot-reload 0.4ms + +### 2. Modules AISSIA PrĂ©vus + +**MVP Phase 1 (Local uniquement) :** +- `SchedulerModule` : Planning intelligent des tĂąches +- `AIAssistantModule` : Interventions contextuelles via LLM +- `NotificationModule` : Alertes et TTS +- `DataModule` : Persistance SQLite +- `LanguageLearningModule` : Apprentissage et pratique de langues Ă©trangĂšres + +**Phase 2+ (Optionnel Cloud) :** +- Distribution modules IA sur serveur +- Synchronisation multi-appareils +- Mode PWA installable + +### 3. Workflow DĂ©veloppement + +```bash +# DĂ©veloppement d'un module (exemple : SchedulerModule) +cd modules/scheduler/ +code CLAUDE.md # Lire les instructions spĂ©cifiques +cmake . && make # Build autonome +./scheduler-test # Tests standalone + +# Edit SchedulerModule.cpp → Save +# → Auto-rebuild + hot-reload < 0.4ms ! +``` + +## Philosophie de DĂ©veloppement + +### MVP-First + +- **Phase 1 obligatoire** : Mode local Windows uniquement +- **Phases 2-4 optionnelles** : Seulement si besoin validĂ© +- **Configuration-driven** : 90% des besoins via JSON +- **SimplicitĂ© d'abord** : ComplexitĂ© Ă©merge de l'interaction + +### DĂ©veloppement ParallĂšle + +```bash +# Instance Claude Code A +cd modules/scheduler/ +# Context: 280 lignes (CLAUDE.md + Module.cpp + IModule.h) + +# Instance Claude Code B +cd modules/ai-assistant/ +# Context: 250 lignes + +# Instance Claude Code C +cd modules/language-learning/ +# Context: 230 lignes +``` + +### Évolution Progressive + +```cpp +// Phase 1 : MVP (obligatoire) +DebugEngine + SequentialModuleSystem + IntraIO +→ DĂ©veloppement ultra-rapide, hot-reload 0.4ms + +// Phase 2 : Optimization (optionnel) +DebugEngine + ThreadedModuleSystem + IntraIO +→ Performance sans rĂ©Ă©criture + +// Phase 3 : Production (optionnel) +HighPerfEngine + MultithreadedModuleSystem + LocalIO +→ Scale transparent + +// Phase 4 : Cloud (optionnel) +DataOrientedEngine + ClusterModuleSystem + NetworkIO +→ Distribution massive +``` + +## Cahiers des Charges + +**Documents principaux Ă  la racine :** + +- **[CDCDraft.md](../CDCDraft.md)** : Cahier des charges complet AISSIA +- **[AlternativesAnalysis.md](../AlternativesAnalysis.md)** : Analyse comparative des options techniques + +## Liens Externes + +- **WarFactory Engine** : Architecture source utilisĂ©e par AISSIA +- **Claude Code** : https://docs.claude.com/en/docs/claude-code + +## Contribution + +Ce projet utilise une approche de dĂ©veloppement modulaire optimisĂ©e pour Claude Code. Chaque module est autonome et peut ĂȘtre dĂ©veloppĂ© indĂ©pendamment. + +**Contraintes strictes :** +- ✅ Modules 200-300 lignes maximum +- ✅ Build autonome : `cmake .` depuis le module +- ✅ JSON-only communication +- ✅ Zero dependencies up +- ❌ Jamais `cmake ..` ou `#include "../"` + +## Licence + +À dĂ©finir diff --git a/docs/Sources Documentaires/SMP.md b/docs/Sources Documentaires/SMP.md deleted file mode 100644 index 328ce7b..0000000 --- a/docs/Sources Documentaires/SMP.md +++ /dev/null @@ -1,173 +0,0 @@ -SociĂ©tĂ©s Militaires PrivĂ©es : Analyse StratĂ©gique et Étude de Cas d'Executive Outcomes - -SynthĂšse ExĂ©cutive - -Ce document de synthĂšse analyse le phĂ©nomĂšne croissant des SociĂ©tĂ©s Militaires PrivĂ©es (SMP), des entitĂ©s qui opĂšrent dans des secteurs traditionnellement rĂ©servĂ©s aux forces armĂ©es Ă©tatiques. PoussĂ© par des logiques Ă©conomiques post-Guerre Froide, des impĂ©ratifs de discrĂ©tion politique et la volontĂ© de contourner les contraintes lĂ©gales, le recours aux SMP s'est intensifiĂ© depuis les annĂ©es 1980. - -Le secteur se caractĂ©rise par une grande diversitĂ© de modĂšles. Le modĂšle amĂ©ricain privilĂ©gie le soutien logistique aux armĂ©es rĂ©guliĂšres, tandis que le modĂšle chinois, en pleine expansion, est dĂ©diĂ© Ă  la protection des intĂ©rĂȘts Ă©conomiques de l'État. Le modĂšle russe, incarnĂ© par le groupe Wagner, est une forme hybride, agissant Ă  la fois en soutien de l'armĂ©e et de maniĂšre autonome pour des objectifs gĂ©opolitiques et Ă©conomiques. - -L'archĂ©type du modĂšle sud-africain est Executive Outcomes (EO), une SMP qui a dĂ©montrĂ© une efficacitĂ© redoutable dans les annĂ©es 1990. Son Ă©tude de cas rĂ©vĂšle un modĂšle d'affaires sophistiquĂ©, intĂ©grant verticalement les opĂ©rations militaires, l'exploitation de ressources naturelles (pĂ©trole, diamants) et une structure corporative complexe conçue pour maximiser les profits tout en naviguant dans les zones grises du droit international. FondĂ©e par d'anciens membres des forces spĂ©ciales sud-africaines de l'Ăšre de l'apartheid, EO a menĂ© des campagnes militaires autonomes en Angola et en Sierra Leone, liant directement ses succĂšs militaires Ă  l'obtention de concessions miniĂšres et pĂ©troliĂšres. - -Cependant, l'emploi des SMP soulĂšve de graves questions Ă©thiques et stratĂ©giques : violations des droits humains (massacre de la place Nissour, torture Ă  Abou Ghraib), guerres par procuration entre puissances, perte de compĂ©tences pour les armĂ©es nationales et manque de transparence. L'avenir du secteur est appelĂ© Ă  se dĂ©velopper, notamment avec l'Ă©mergence d'un vaste contingent de combattants expĂ©rimentĂ©s issus de la guerre en Ukraine, promettant une nouvelle Ăšre de complexitĂ© dans les conflits mondiaux. - - --------------------------------------------------------------------------------- - - -1. Le PhĂ©nomĂšne des SociĂ©tĂ©s Militaires PrivĂ©es (SMP) - -1.1. DĂ©finition et Spectre d'ActivitĂ©s - -Une SociĂ©tĂ© Militaire PrivĂ©e (SMP) est une entreprise privĂ©e qui fournit des services et des compĂ©tences de nature militaire ou opĂ©rant dans un contexte militarisĂ©. Leurs activitĂ©s couvrent un large spectre : - -* Soutien logistique aux armĂ©es rĂ©guliĂšres. -* Conseil et formation de forces armĂ©es Ă©trangĂšres. -* Protection de personnes (VIP), de biens et de convois. -* Gardiennage d'infrastructures critiques (champs pĂ©troliers, mines). -* Participation directe aux combats et opĂ©rations offensives. - -1.2. Distinction avec le Mercenariat Traditionnel - -Le statut juridique des SMP est ambigu, leur permettant souvent d'Ă©chapper Ă  la dĂ©finition stricte du mercenariat. - -* Article 47 du protocole additionnel de 1977 aux Conventions de GenĂšve : DĂ©finit un mercenaire comme un combattant recrutĂ© spĂ©cifiquement pour un conflit, qui n'est pas ressortissant d'une des parties au conflit, et dont la rĂ©munĂ©ration est nettement supĂ©rieure Ă  celle d'un militaire de rang similaire. -* Conventions Internationales : La Convention de l'Organisation de l'UnitĂ© Africaine de 1977 et la Convention de l'ONU de 2001 tentent d'encadrer le mercenariat, mais cette derniĂšre n'a Ă©tĂ© ratifiĂ©e que par huit États et a peu d'impact. - -En pratique, les grandes SMP structurent leurs activitĂ©s pour ne pas ĂȘtre considĂ©rĂ©es lĂ©galement comme du mercenariat, bien que la distinction sur le terrain soit souvent tĂ©nue. - -1.3. Aperçu Historique - -L'emploi d'acteurs militaires privĂ©s par des États n'est pas nouveau et remonte Ă  plusieurs dĂ©cennies avant l'Ăšre contemporaine. - -* Seconde Guerre mondiale (1940) : L'entreprise amĂ©ricaine Central Aircraft Manufacturing Company (CAMC) monte l'escadrille des "Flying Tigers" pour soutenir la Chine contre le Japon. -* Guerre du Vietnam : L'entreprise Civil Air Transport ("Air America"), hĂ©ritiĂšre de la CAMC, collabore avec la CIA pour des opĂ©rations au Vietnam. -* AnnĂ©es 1960-70 : - * Watchgard International Limited (1966) : CrĂ©Ă©e par David Sterling, fondateur des SAS britanniques, elle propose des formations et participe Ă  des combats en AmĂ©rique du Sud, en Afrique et au Moyen-Orient. - * Kini Mini Services (1975) : Cette SMP britannique forme les moudjahidines afghans pour combattre l'URSS. - -2. ModĂšles OpĂ©rationnels des SMP Ă  l'Échelle Mondiale - -2.1. Le ModĂšle Sud-Africain - -ReprĂ©sentĂ© par Executive Outcomes, ce modĂšle est le plus proche du mercenariat traditionnel. - -* CaractĂ©ristiques : MĂšne des campagnes militaires autonomes, souvent pour le compte d'États en difficultĂ©. -* Financement : Se finance via les contrats Ă©tatiques ou directement par l'exploitation des ressources naturelles (ex: mines de diamants en Sierra Leone) qu'elle est chargĂ©e de protĂ©ger. -* Motivation : Principalement lucrative, mais des variantes idĂ©ologiques existent, comme Malhama Tactical, une SMP djihadiste offrant ses services Ă  des groupes islamistes en Syrie. - -2.2. Le ModĂšle AmĂ©ricain - -Ce modĂšle se concentre sur le soutien aux forces armĂ©es rĂ©guliĂšres, principalement celles des États-Unis. - -* RĂŽle : Fournir des services annexes (logistique, gardiennage, protection de VIP, transport) pour permettre Ă  l'armĂ©e de se concentrer sur le combat. -* Exemple emblĂ©matique : La sociĂ©tĂ© Blackwater (devenue Academi), massivement employĂ©e en Irak et en Afghanistan. Elle a Ă©galement Ă©tĂ© utilisĂ©e pour des actions offensives en collaboration avec la CIA et les forces spĂ©ciales. - -2.3. Le ModĂšle Russe - -IncarnĂ© par le groupe Wagner, il s'agit d'un modĂšle hybride combinant les approches amĂ©ricaine et sud-africaine. - -* DualitĂ© : Peut intervenir en soutien de l'armĂ©e rĂ©guliĂšre russe (comme en Ukraine) ou mener des opĂ©rations autonomes pour promouvoir les intĂ©rĂȘts gĂ©opolitiques de la Russie, notamment en Afrique. -* ActivitĂ©s diversifiĂ©es : Combat de haute intensitĂ©, protection de ressources, propagande, renseignement, et lutte anti-guĂ©rilla. -* Structure Corporative : Wagner fait partie d'un Ă©cosystĂšme d'entreprises avec des intĂ©rĂȘts dans le secteur minier. D'autres entitĂ©s russes, comme le gĂ©ant gazier Gazprom, possĂšdent Ă©galement leur propre SMP. -* Statut LĂ©gal : Bien que les SMP soient officiellement interdites par la loi russe, elles sont tolĂ©rĂ©es et utilisĂ©es par le pouvoir. - -2.4. Le ModĂšle Chinois - -Ce modĂšle, en pleine expansion, est entiĂšrement au service des intĂ©rĂȘts Ă©conomiques et stratĂ©giques de l'État chinois. - -* Cadre LĂ©gal : Les SMP sont lĂ©galisĂ©es depuis 2011 mais doivent obtenir une licence du gouvernement. -* Mission Principale : ProtĂ©ger les infrastructures et le personnel chinois le long des "Nouvelles Routes de la Soie", ainsi que les navires contre la piraterie. -* Exemples d'entreprises : - * Huaing Chong An Security Service : Fournit la sĂ©curitĂ© pour la premiĂšre compagnie maritime chinoise, China Ocean Shipping Company. - * Beijing Dayway Security Services Company : Intervient en Afrique (ex: Kenya) pour sĂ©curiser des projets financĂ©s par la Chine, et protĂšge des clients comme la China National Petroleum et le rĂ©seau d'ambassades. -* Forces et Faiblesses : - * Avantage : CoĂ»t trĂšs compĂ©titif (un contracteur chinois coĂ»te jusqu'Ă  12 fois moins cher qu'un occidental). - * Faiblesses : Manque d'expĂ©rience de terrain et mauvaise maĂźtrise des langues Ă©trangĂšres. - -3. Motivations et Avantages du Recours aux SMP - -3.1. Facteurs Économiques - -La fin de la Guerre Froide a entraĂźnĂ© une rĂ©duction des budgets militaires (jusqu'Ă  30 % en France et aux États-Unis), rendant chaque soldat "plus rare et plus cher". Une idĂ©ologie libĂ©rale de dĂ©sengagement de l'État a favorisĂ© l'externalisation des fonctions de sĂ©curitĂ©. Cette tendance est illustrĂ©e par l'Ă©volution du ratio contracteurs/militaires dans les dĂ©ploiements amĂ©ricains : - -* Guerre du Golfe (1991) : 1 contracteur pour 100 militaires. -* DĂ©but de la guerre d'Irak (2003) : 1 contracteur pour 10 militaires. -* Irak (2008) : 1 contracteur pour 1 militaire. - -3.2. ImpĂ©ratifs Politiques et StratĂ©giques - -* Plausible DĂ©niabilitĂ© : Les SMP permettent de mener des opĂ©rations sensibles ("sale besogne") comme la dĂ©stabilisation d'États ou des assassinats. En cas d'Ă©chec ou de scandale, l'État mandataire peut nier toute implication. Exemple : les Émirats Arabes Unis ont employĂ© la SMP amĂ©ricaine Spear Operations Group pour des assassinats au YĂ©men. -* Gestion de l'Opinion Publique : La mort d'un contracteur a un impact mĂ©diatique et public bien moindre que celle d'un soldat de l'armĂ©e rĂ©guliĂšre. Cela permet de minimiser le coĂ»t politique des interventions militaires. Exemple : en 2016 en Syrie, la Russie a dĂ©plorĂ© officiellement une trentaine de morts militaires contre 500 Ă  600 personnels de Wagner tuĂ©s. -* Contournement des Limites : Les SMP permettent de dĂ©passer les limites capacitaires ou lĂ©gales imposĂ©es Ă  une armĂ©e. Exemple : durant la guerre de Bosnie, le CongrĂšs amĂ©ricain ayant limitĂ© le dĂ©ploiement Ă  20 000 soldats, cette limite a Ă©tĂ© contournĂ©e par l'envoi de contracteurs. - -4. Controverses, DĂ©rives et Enjeux - -4.1. Violations des Droits Humains et Crimes de Guerre - -* Incident de la Place Nissour (16 septembre 2007) : Des contracteurs de Blackwater ont ouvert le feu sur des civils Ă  Bagdad, tuant 17 personnes et en blessant 20 autres. -* Prison d'Abou Ghraib : Les SMP CACI Group et Titan Corporation sont impliquĂ©es dans des actes de torture sur des prisonniers irakiens. - -4.2. Maltraitance des Contractuels - -Les contracteurs eux-mĂȘmes peuvent ĂȘtre victimes d'abus. La SMP Ă©miratie Blackshield a recrutĂ© 611 Soudanais sous prĂ©texte d'un emploi dans la sĂ©curitĂ© privĂ©e aux Émirats, avant de les envoyer de force combattre en Libye pour le MarĂ©chal Haftar. L'opĂ©ration a Ă©tĂ© annulĂ©e suite Ă  un scandale dĂ©clenchĂ© lorsque les recrues ont pu contacter leurs familles. - -4.3. Guerres par Procuration et ProlifĂ©ration - -Les SMP peuvent ĂȘtre les instruments de conflits par procuration. En Libye, la SMP turque SADAT a envoyĂ© des combattants (parfois d'anciens djihadistes) pour lutter contre le MarĂ©chal Haftar, tandis que les Émirats Arabes Unis envoyaient des combattants via Blackshield pour le soutenir. - -4.4. Usage Domestique et RĂ©pression Interne - -Les SMP peuvent ĂȘtre utilisĂ©es par un gouvernement contre sa propre population. La sociĂ©tĂ© turque SADAT a Ă©tĂ© impliquĂ©e dans la rĂ©pression qui a suivi la tentative de coup d'État de 2016 contre le prĂ©sident Erdoğan. - -4.5. Perte de CompĂ©tences pour les ArmĂ©es RĂ©guliĂšres - -Les SMP recrutent massivement d'anciens militaires, mais aussi des militaires d'active, en particulier des unitĂ©s d'Ă©lite, attirĂ©s par des salaires bien plus Ă©levĂ©s. Ce "drain des cerveaux" affaiblit les armĂ©es rĂ©guliĂšres. Pour contrer ce phĂ©nomĂšne, le Royaume-Uni a expĂ©rimentĂ© un programme permettant Ă  ses militaires de travailler pour une SMP pendant 1 ou 2 ans avant de rĂ©intĂ©grer l'armĂ©e. - -5. Étude de Cas Approfondie : Executive Outcomes (EO) - -5.1. GenĂšse et Contexte - -Executive Outcomes, fondĂ©e en 1989 par Eeben Barlow, est nĂ©e des cendres du systĂšme de sĂ©curitĂ© de l'Afrique du Sud de l'apartheid. - -* Origines du Personnel : Barlow et ses recrues Ă©taient issus d'unitĂ©s d'Ă©lite et secrĂštes comme le Bataillon 32 (une unitĂ© de contre-insurrection composĂ©e d'Angolais et d'officiers blancs sud-africains) et le Civil Cooperation Bureau (CCB), une cellule clandestine chargĂ©e d'assassiner des opposants au rĂ©gime. -* Premier Contrat Majeur (1993) : EngagĂ©e en Angola pour reprendre des installations pĂ©troliĂšres Ă  l'UNITA. Ironiquement, les mĂȘmes hommes qui, au sein du Bataillon 32, soutenaient l'UNITA contre le MPLA (soutenu par les communistes), se sont retrouvĂ©s Ă  combattre l'UNITA pour le compte du gouvernement MPLA, dĂ©montrant que les intĂ©rĂȘts financiers priment sur l'idĂ©ologie. - -5.2. Le ModĂšle d'Affaires : IntĂ©gration Militaro-Industrielle - -Le succĂšs d'EO reposait sur une synergie parfaite entre la force militaire et l'exploitation Ă©conomique. - -* Angola (1994) : EO repousse une offensive de l'UNITA sur la capitale Luanda. En paiement, la sociĂ©tĂ© reçoit 40 millions de dollars par an ainsi que des concessions pĂ©troliĂšres et diamantaires. -* Sierra Leone (1996) : Le gouvernement engage EO pour repousser les rebelles du RUF. En Ă©change, des sociĂ©tĂ©s liĂ©es Ă  EO obtiennent d'importantes concessions sur les mines de diamants que les mercenaires sĂ©curisent. - -5.3. Une Galaxie d'Entreprises : Structure et Acteurs ClĂ©s - -EO n'Ă©tait que la partie visible d'un vaste conglomĂ©rat de plus de 30 sociĂ©tĂ©s. - -EntitĂ© RĂŽle et Description Personnages ClĂ©s -Executive Outcomes (EO) Branche militaire opĂ©rationnelle. Fournissait les hommes, le matĂ©riel et l'expertise. Eeben Barlow, Lafras Luitingh -Strategic Resources Corp. (SRC) Holding sud-africaine crĂ©Ă©e en 1995 pour chapeauter les activitĂ©s africaines. Eeben Barlow -Sandline International SMP britannique utilisĂ©e comme "vitrine" pour signer des contrats et gĂ©rer les relations publiques. Sous-traitait les opĂ©rations Ă  EO. Tim Spicer, Simon Mann -Heritage Oil and Gas Compagnie pĂ©troliĂšre dirigĂ©e par le contact britannique qui a fourni Ă  EO son premier contrat. Anthony Buckingham -Branch Energy Branche miniĂšre du groupe, dĂ©tenant des concessions en Angola, Sierra Leone, etc. Anthony Buckingham -Diamond Works Limited NĂ©e en 1996 de la fusion des actifs de Branch Energy et d'une sociĂ©tĂ© canadienne, pour exploiter les concessions de diamants. Anthony Buckingham, Eeben Barlow, Tim Spicer - -5.4. Le DĂ©clin et la Reconversion - -La fin des annĂ©es 1990 marque le dĂ©clin officiel d'EO. - -* Affaire de Papouasie-Nouvelle-GuinĂ©e (1997) : Un contrat signĂ© par Sandline (sous-traitant EO) est rĂ©vĂ©lĂ© par la presse, provoquant un scandale politique majeur, une mutinerie et la dĂ©mission du Premier ministre. -* LĂ©gislation Sud-Africaine (1997) : Une nouvelle loi bannissant le mercenariat contraint EO Ă  cesser officiellement ses activitĂ©s en 1998. - -Cependant, les fondateurs ont poursuivi leurs carriĂšres dans le secteur : - -* Eeben Barlow : AprĂšs une pĂ©riode de consulting, il fonde STTEP en 2006, qui combat Boko Haram au NigĂ©ria (2015) et des djihadistes au Mozambique (2020). En 2020, il annonce la relance d'Executive Outcomes, la positionnant comme une solution "africaine pour les Africains". -* Tim Spicer : Fonde Aegis Defence Services en 2002. -* Simon Mann : Est arrĂȘtĂ© au Zimbabwe en 2004 pour une tentative prĂ©sumĂ©e de coup d'État en GuinĂ©e Équatoriale. Il est libĂ©rĂ© en 2009 et meurt en mai 2025. -* Lafras Luitingh : CrĂ©e d'autres SMP comme Sarasen et Sterling Corporate, actives dans le secteur minier et la lutte anti-piraterie. - -6. Perspectives et Avenir du Secteur - -Le secteur des SMP est en constante Ă©volution et devrait connaĂźtre une nouvelle phase d'expansion. - -* Impact de la Guerre en Ukraine : Le conflit a crĂ©Ă© un immense vivier de combattants (estimĂ© entre 250 000 et 300 000 Ukrainiens) dotĂ©s d'une expĂ©rience de combat de haute intensitĂ©, maĂźtrisant Ă  la fois les technologies modernes (drones) et les Ă©quipements plus anciens. -* Demande Croissante : Les Ukrainiens figurent dĂ©jĂ  dans le top 5 des nationalitĂ©s les plus employĂ©es par les SMP. Ces vĂ©tĂ©rans trĂšs expĂ©rimentĂ©s pourront "se vendre cher" sur le marchĂ© mondial de la sĂ©curitĂ© privĂ©e, complexifiant davantage les dynamiques des futurs conflits. diff --git a/docs/ai-framework.md b/docs/ai-framework.md deleted file mode 100644 index 3525726..0000000 --- a/docs/ai-framework.md +++ /dev/null @@ -1,1414 +0,0 @@ -# AI Framework - Unified Decision System - -## Philosophie - -Le systĂšme d'IA de Warfactory repose sur un **framework unifiĂ© de prise de dĂ©cision par scoring**. Tous les types d'IA (tactique, opĂ©rationnelle, Ă©conomique, diplomatique) utilisent le mĂȘme pattern fondamental : - -1. **GĂ©nĂ©rer options** disponibles dans le contexte actuel -2. **Scorer chaque option** selon poids configurables et situation -3. **Choisir la meilleure option** (highest score) -4. **ExĂ©cuter l'action** correspondante - -Ce pattern unifiĂ© permet : -- **CohĂ©rence** : MĂȘme logique Ă  travers tous les systĂšmes IA -- **ConfigurabilitĂ©** : Comportements ajustables via JSON -- **Apprentissage** : Reinforcement Learning ajuste les poids -- **ModularitĂ©** : Nouveaux types de dĂ©cisions ajoutables facilement -- **TestabilitĂ©** : Chaque dĂ©cision isolĂ©e et vĂ©rifiable - -## Architecture Globale - -### HiĂ©rarchie des Modules IA - -``` -AI Framework -├── Core Decision System -│ ├── IDecision (interface de base) -│ ├── Decision Factory (crĂ©ation objets) -│ └── Scoring Engine (Ă©valuation uniforme) -│ -├── Helper Modules (services, pas de dĂ©cisions) -│ ├── PathfinderModule (calcul chemins) -│ ├── AcquisitionModule (sĂ©lection cibles) -│ └── MovementModule (exĂ©cution mouvement) -│ -├── Decision Modules (utilisent helpers) -│ ├── TacticalModule (combat temps-rĂ©el) -│ ├── OperationalModule (stratĂ©gie bataille) -│ ├── CompanyAIModule (business) -│ └── StateAIModule (politique) -│ -└── Data Modules (consultĂ©s par tous) - ├── DiplomacyModule (relations, traitĂ©s) - └── EconomyModule (marchĂ©, prix) -``` - -### Flux de DĂ©cision Type - -``` -OperationalModule - ↓ (donne posture: "rush blindĂ©") -TacticalModule - ↓ (demande chemins pour flanking) -PathfinderModule → retourne 3 chemins possibles - ↓ (demande cibles prioritaires) -AcquisitionModule → retourne 5 cibles scorĂ©es - ↓ (choisit meilleure tactique) -TacticalModule → dĂ©cision: flanking par chemin 2, cible 1 - ↓ (exĂ©cute mouvement) -MovementModule → unitĂ©s se dĂ©placent -``` - -## Interface IDecision - Core Pattern - -### DĂ©finition - -Toutes les dĂ©cisions IA implĂ©mentent cette interface : - -```cpp -class IDecision { -public: - virtual ~IDecision() = default; - - // 1. GĂ©nĂ©rer toutes les options disponibles - virtual std::vector