Integrate technical points 11-23 from INTEGRATION-MASTER-LIST

- Add ProductionModule exception (500-800 lines) for performance
- Add Belt System 4-phase evolution (Mono→Multi→Dual→Full Factorio)
- Add War subsystems decomposition with async frequencies
- Add network tolerance specifications (50-100ms acceptable)
- Add inventory strategies (Desperate/Normal/Cautious/Oversupplied)
- Add transport cost hierarchy (Ship 0.10€→Truck 5.00€/kg)
- Add 6 new questions to questions-ouvertes.md (optimizations, infrastructure, pricing)

🤖 Generated with Claude Code

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
StillHammer 2025-09-22 11:22:35 +08:00
parent 6c7934d530
commit 551beffa68
4 changed files with 255 additions and 2 deletions

View File

@ -44,11 +44,40 @@ class IModule {
```
**Contraintes strictes** :
- **200-300 lignes maximum** par module
- **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)

View File

@ -4,6 +4,39 @@
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
## Acteurs Économiques
### Companies privées
@ -252,6 +285,34 @@ L'économie de Warfactory est un système dynamique multi-acteurs où companies
- **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** :

View File

@ -143,7 +143,29 @@ L'idée est que puisque la conception se fait sur une grille, il faut placer les
### Logistique
- **Style** : Factorio-like
- **Considération** : Peut-être pas de belt 2-line
- **É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

View File

@ -120,6 +120,147 @@
**À 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
## Process de Résolution
### Priorité 1 - Bloquants Architecture