StillHammer ba42b6d9c7 Update CDC with hybrid architecture (WarFactory + multi-target)

- Add hybrid deployment modes: local_dev (MVP) and production_pwa (optional)
- Integrate WarFactory engine reuse with hot-reload 0.4ms
- Define multi-target compilation strategy (DLL/SO/WASM)
- Detail both deployment modes with cost analysis
- Add progressive roadmap: Phase 1 (local), Phase 2 (POC WASM), Phase 3 (cloud)
- Budget clarified: $10-20/mois (local) vs $13-25/mois (cloud)
- Document open questions for technical validation

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

2025-10-27 11:49:09 +08:00

28 KiB

Raw Blame History

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