aissia/docs/04-reference/questions-ouvertes.md

# 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.*