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.