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:
parent
6c7934d530
commit
551beffa68
@ -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)
|
||||
|
||||
@ -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** :
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user