Add comprehensive engine-focused documentation structure

📚 Complete documentation reorganization:

🗂️ Structure:
- docs/global/ → Complete project documentation (all original files)
- docs/engines/ → 10 engine-specific docs with focused responsibilities
- docs/serveur/ → Server coordinator and inter-engine communication
- docs/client/ → Smart Client interface and user experience

🔧 Engine Documentation:
- Designer: Vehicle design with AI assistance (1-2 designs/tick)
- Economy: Market simulation and dynamic pricing
- Event: Breakthrough system and global events
- Factory: Factorio-like production with belts/assemblers
- Intelligence: Metrics collection (3.1GB adaptive) + reconnaissance
- Logistic: Supply chains and convoy management
- MacroEntity: Companies, diplomacy, administration (1000 pts/day)
- Map: Procedural generation (218+ elements) + chunk streaming
- Operation: Military strategy and adaptive AI generals
- War: Multi-chunk combat and persistent frontlines

📋 Each engine doc includes:
- Core responsibilities and system overview
- Key mechanics from relevant design documents
- Communication patterns with other engines
- Implementation notes and architecture details

🎯 Navigation optimized for:
- Engine developers (focused system details)
- System architects (coordination patterns)
- Game designers (mechanics integration)

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

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
StillHammer 2025-09-19 14:41:03 +08:00
parent 4e1f46f4d8
commit bb92e9dc93
29 changed files with 7041 additions and 15 deletions

View File

@ -1,17 +1,94 @@
# Warfactory - Documentation
# Warfactory Documentation Index
## Structure de la documentation
## Documentation Structure
- [Vue d'ensemble](./vue-ensemble.md) - Vision et objectifs du projet
- [Architecture technique](./architecture-technique.md) - Multi-serveurs, performance, développement IA
- [Systèmes techniques](./systemes-techniques.md) - Tile system, mémoire, chunks
- [Gameplay industriel](./gameplay-industriel.md) - Ressources, production, gameloop
- [Système militaire](./systeme-militaire.md) - Véhicules, combat, IA
- [Map system](./map-system.md) - Cartes, navigation, FOW, reconnaissance
- [Économie et logistique](./economie-logistique.md) - Marchés, prix, supply chains
- [Mécaniques de jeu](./mecaniques-jeu.md) - Recherche, progression, simulation
- [Arbre technologique](./arbre-technologique.md) - 3000+ techs avec passerelles inter-domaines
- [Métriques joueur](./metriques-joueur.md) - Analytics complètes, graphiques, intelligence compétitive
- [Contexte narratif](./contexte-narratif.md) - Lore, géopolitique, scénarios
- [DLC prévus](./dlc-prevus.md) - Extensions inspirées RimWorld
- [Updates long terme](./updates-long-terme.md) - Fonctionnalités futures
This documentation is organized by component type to provide focused information for each part of the Warfactory system.
### 📁 Global Documentation (`/global/`)
Complete project documentation with all design documents:
- `vue-ensemble.md` - Project vision and philosophy
- `architecture-technique.md` - Complete technical architecture
- `map-system.md` - Multi-scale map system (218+ elements)
- `systeme-militaire.md` - Combat and vehicle design systems
- `economie-logistique.md` - Economic simulation and supply chains
- `gameplay-industriel.md` - Factory management (Factorio-like)
- `mecaniques-jeu.md` - Research, breakthrough, and progression
- `arbre-technologique.md` - 3000+ technology tree
- `metriques-joueur.md` - Analytics system (3.1GB adaptive)
- `coherence-problem.md` - Resolved design challenges
- `questions-ouvertes.md` - Open questions and future considerations
### 🔧 Engine Documentation (`/engines/`)
Focused documentation for each of the 10 autonomous engines:
#### Core Engines
- **[Designer](./engines/designer/)** - Vehicle design with AI assistance (1-2 designs/tick)
- **[Economy](./engines/economy/)** - Market simulation and dynamic pricing
- **[Factory](./engines/factory/)** - Factorio-like production with belts and assemblers
- **[War](./engines/war/)** - Multi-chunk combat and persistent frontlines
#### Specialized Engines
- **[Intelligence](./engines/intelligence/)** - Metrics collection (3.1GB adaptive) and reconnaissance
- **[Logistic](./engines/logistic/)** - Supply chains and convoy management
- **[Map](./engines/map/)** - Procedural generation (218+ elements) and chunk streaming
- **[Operation](./engines/operation/)** - Military strategy and adaptive AI generals
#### Support Engines
- **[Event](./engines/event/)** - Breakthrough system and global events
- **[MacroEntity](./engines/macroentity/)** - Companies, diplomacy, administration (1000 pts/day)
### 🖥️ Server Documentation (`/serveur/`)
Server coordinator system:
- Engine communication and coordination
- Smart Client request/response handling
- Performance monitoring and load balancing
- Inter-engine message routing
### 💻 Client Documentation (`/client/`)
Smart Client interface system:
- Multi-scale user interface (World → Regional → Local → Detail)
- Factory management interface (Factorio-like)
- Vehicle design interface (grid-based component placement)
- Strategic command and diplomatic interfaces
## Quick Navigation
### For Engine Developers
Each engine folder contains:
- **Core responsibilities** and system overview
- **Key mechanics** from relevant design documents
- **Communication patterns** with other engines
- **Implementation notes** and architecture details
### For System Architects
- **[Global Documentation](./global/)** - Complete system overview
- **[Server Documentation](./serveur/)** - Coordination architecture
- **Performance specs**: 60fps, 1000+ AI companies, adaptive scaling
### For Game Designers
- **[Global Documentation](./global/)** - All gameplay mechanics
- **Engine-specific docs** - Focused system details
- **[Client Documentation](./client/)** - User interface requirements
## Implementation Status
**Complete**: Documentation structure with engine-specific focus
**Complete**: 10 engine implementations with CMake build system
**Complete**: Fast/full build presets for development efficiency
🔄 **In Progress**: Engine logic expansion and inter-engine communication
📋 **Next**: Gameplay feature implementation and testing
## Build Commands Quick Reference
```bash
# Fast development build (minimal sanitizers)
cmake -DFAST_BUILD=ON .. && make claude-workflow-fast
# Full validation build (all sanitizers)
cmake -DCMAKE_BUILD_TYPE=Debug .. && make
# Single engine development
make economy-engine && ./bin/economy-engine
```
For complete build system documentation, see `CLAUDE.md` in the project root.

130
docs/client/README.md Normal file
View File

@ -0,0 +1,130 @@
# Client Documentation
## Overview
The **Smart Client** provides the user interface and interacts with the server coordinator using a request/response pattern.
**Key Responsibilities:**
- User interface for all game systems
- Request/response communication with server
- Local state caching and optimization
- Fog of War rendering and management
## Architecture
### Smart Client Pattern
From `architecture-technique.md`:
- **No Streaming**: Pure request/response communication
- **Stateless Requests**: Each request is independent
- **Local Caching**: Client-side optimization for responsiveness
- **FOW Integration**: Chunk-level fog of war rendering
### User Interface Systems
#### Multi-Scale Interface
From `map-system.md`:
- **World View**: Diplomatic and strategic overview
- **Regional View**: Logistics and major operations coordination
- **Local View**: Factory management and base operations
- **Detail View**: Combat oversight and precise control
#### Factory Management Interface
From `gameplay-industriel.md`:
- **Production Line Design**: Factorio-like belt and assembler placement
- **Resource Flow Visualization**: Real-time production monitoring
- **Optimization Tools**: Bottleneck identification and efficiency metrics
- **Automation Controls**: Production scheduling and priority management
#### Vehicle Design Interface
From `systeme-militaire.md`:
- **Grid-Based Placement**: Component positioning on vehicle chassis
- **Interface Controls**: Pick/place with A/E rotation, R for snap toggle
- **Template System**: Save/load vehicle blueprints
- **Validation Feedback**: Real-time design constraint checking
#### Military Command Interface
- **Frontline Visualization**: Persistent battle line display
- **Auto-Battler Controls**: Strategic oversight without micro-management
- **Intelligence Dashboard**: Reconnaissance and enemy analysis
- **Strategic Planning**: Operation coordination and resource allocation
## Core Client Systems
### Communication Manager
```cpp
class ClientCommunication {
// Server communication
ServerResponse sendRequest(const ClientRequest& request);
void cacheResponse(const ServerResponse& response);
bool hasValidCache(const RequestKey& key) const;
// FOW management
void updateFOW(const FOWData& data);
bool isVisible(int chunkX, int chunkY) const;
void requestChunkData(int chunkX, int chunkY);
// State synchronization
void synchronizeState();
void handleGlobalEvent(const GlobalEvent& event);
};
```
### Interface Controllers
#### Factory Interface
- **Belt Placement**: Drag-and-drop belt network design
- **Assembler Configuration**: Production recipe and priority settings
- **Resource Monitoring**: Real-time throughput and efficiency display
- **Expansion Planning**: Factory layout optimization tools
#### Design Interface
- **Component Library**: Available vehicle components and specifications
- **Chassis Editor**: Irregular shape design and component placement
- **Performance Calculator**: Real-time design statistics and validation
- **Blueprint Manager**: Template save/load and sharing system
#### Strategic Interface
- **Company Dashboard**: Economic, military, and industrial overviews
- **Diplomatic Panel**: Inter-company relations and negotiations
- **Research Tree**: Technology progression and breakthrough system
- **Analytics Dashboard**: Comprehensive metrics and trend analysis
### Performance Optimization
#### Local Caching
- **Response Caching**: Store frequently accessed data locally
- **Predictive Loading**: Pre-fetch likely needed data
- **Cache Invalidation**: Smart cache updates on state changes
- **Compression**: Minimize bandwidth usage
#### Rendering Optimization
- **LOD System**: Level-of-detail based on zoom and relevance
- **Culling**: Only render visible and relevant elements
- **Chunk Streaming**: Dynamic loading of map data
- **UI Responsiveness**: Maintain 60fps interface performance
## Client Request Patterns
### Common Request Types
1. **State Queries**: Get current system state (factory status, battles, etc.)
2. **Action Commands**: Execute player actions (place building, issue orders)
3. **Data Updates**: Refresh cached information (market prices, research progress)
4. **Event Subscriptions**: Register for relevant global events
### FOW-Aware Requests
- **Visibility Checks**: Ensure requested data is visible to player
- **Partial Information**: Handle incomplete data due to FOW
- **Intelligence Requests**: Request reconnaissance on hidden areas
- **Update Notifications**: Receive visibility changes and new intel
## Key Design Documents
- `architecture-technique.md` - Smart Client specification
- `gameplay-industriel.md` - Factory interface requirements
- `systeme-militaire.md` - Vehicle design and combat interfaces
- `map-system.md` - Multi-scale interface coordination
- `mecaniques-jeu.md` - UI integration with game mechanics
## Implementation Notes
- Request/response pattern eliminates complex state synchronization
- Local caching provides responsive user experience
- FOW integration requires careful visibility checking
- Multi-scale interface demands efficient view switching

View File

@ -0,0 +1,69 @@
# Designer-Engine Documentation
## Engine Overview
**Designer-Engine** handles autonomous vehicle conception for AI companies and provides design assistance for players.
**Key Responsibilities:**
- Vehicle design generation (1-2 designs globally per tick)
- Component grid placement and validation
- Blueprint management and evolution
- AI-driven design optimization
## Core Systems
### Vehicle Design System
From `systeme-militaire.md`:
- **Grid-based Component Placement**: Irregular chassis shapes with precise component positioning
- **Interface Mechanics**: Pick/place with A/E rotation, R for snap toggle
- **Template Support**: Save/load vehicle blueprints
- **Validation**: Ensure design constraints (weight, power, armor coverage)
### Design Evolution
From `arbre-technologique.md`:
- **Progressive Evolution**: T-72 → T-80 → T-90 design lineage
- **Technology Integration**: New components unlock through research
- **Doctrine Adaptation**: Designs adapt to military doctrine preferences
### Performance Requirements
From `architecture-technique.md`:
- **Design Rate**: 1-2 vehicle designs globally per tick maximum
- **Autonomous Operation**: AI companies generate designs independently
- **Player Assistance**: Provide design suggestions and optimization
## Engine Architecture
### Core Classes
```cpp
class DesignerEngine {
// Design management (1-2 designs globally per tick)
std::unique_ptr<VehicleDesign> createDesign(const std::string& type);
void validateDesign(const VehicleDesign& design);
void saveBlueprint(const VehicleDesign& design, const std::string& name);
// Blueprint evolution
void evolveBlueprintsFromExisting(); // T-72 → T-80 → T-90
// Performance monitoring
double getDesignRate() const;
size_t getPendingDesigns() const;
};
```
### Communication with Other Engines
- **War-Engine**: Receives combat effectiveness feedback for design optimization
- **Economy-Engine**: Gets cost constraints and production capabilities
- **Intelligence-Engine**: Receives reconnaissance data on enemy designs
- **MacroEntity-Engine**: Gets company design preferences and doctrine
- **Event-Engine**: Processes breakthrough events for new technologies
## Key Design Documents
- `systeme-militaire.md` - Vehicle design system details
- `arbre-technologique.md` - Technology progression and design evolution
- `architecture-technique.md` - Performance specifications
- `mecaniques-jeu.md` - Research integration
## Implementation Notes
- Focus on autonomous AI design generation
- Player assistance tools for design optimization
- Blueprint persistence and sharing system
- Technology integration from research breakthroughs

View File

@ -0,0 +1,70 @@
# Economy-Engine Documentation
## Engine Overview
**Economy-Engine** handles market simulation, pricing dynamics, and economic interactions between companies.
**Key Responsibilities:**
- Real-time market pricing simulation
- Supply and demand calculations
- Company economic interactions
- Resource flow optimization
## Core Systems
### Market Simulation
From `economie-logistique.md`:
- **Dynamic Pricing**: Supply/demand based price fluctuations
- **Market Depth**: Multiple buyers/sellers with varying priorities
- **Price Discovery**: Realistic market mechanisms
- **Resource Categories**: Raw materials, components, finished products
### Economic Mechanics
- **Company Budgets**: Financial constraints and cash flow
- **Trade Networks**: Inter-company commerce
- **Market Manipulation**: Large players affecting prices
- **Economic Warfare**: Sanctions, embargos, trade restrictions
### Performance Requirements
From `architecture-technique.md`:
- **Real-time Processing**: Market updates at 60fps
- **Scalability**: Support 1000+ AI companies
- **Autonomous Operation**: Self-regulating market dynamics
## Engine Architecture
### Core Classes
```cpp
class EconomyEngine {
// Market management
void updateMarketPrices();
double getPrice(const std::string& resource) const;
void processTradeOrder(const TradeOrder& order);
// Company economics
void updateCompanyBudgets();
bool validateTransaction(int buyerCompany, int sellerCompany, const TradeOrder& order);
// Market analysis
MarketData getMarketData(const std::string& resource) const;
std::vector<PriceHistory> getPriceHistory(const std::string& resource) const;
};
```
### Communication with Other Engines
- **Factory-Engine**: Production costs and output volumes
- **Logistic-Engine**: Transportation costs and supply chain efficiency
- **MacroEntity-Engine**: Company budgets, diplomatic trade relations
- **War-Engine**: Wartime economic impacts, resource scarcity
- **Intelligence-Engine**: Market intelligence and economic espionage
## Key Design Documents
- `economie-logistique.md` - Complete economic system design
- `architecture-technique.md` - Performance specifications
- `coherence-problem.md` - Economic balance considerations
- `mecaniques-jeu.md` - Economic progression mechanics
## Implementation Notes
- Negative prices are allowed for certain scenarios (waste disposal, etc.)
- Market depth simulation for realistic price discovery
- Company-specific pricing preferences and strategies
- Economic warfare and sanction mechanics

View File

@ -0,0 +1,70 @@
# Event-Engine Documentation
## Engine Overview
**Event-Engine** handles the breakthrough system, global events, and event-driven mechanics throughout the game.
**Key Responsibilities:**
- Breakthrough system processing (scrap analysis → technology)
- Global event generation (geopolitical, natural disasters)
- Event scheduling and timing
- Research progression triggers
## Core Systems
### Breakthrough System
From `mecaniques-jeu.md`:
- **Scrap Analysis**: Combat wreckage provides technology insights
- **Technology Discovery**: Reverse engineering captured equipment
- **Progressive Unlocks**: Gradual technology revelation
- **Failure/Success Mechanics**: Not all analysis succeeds
### Global Events
From `arbre-technologique.md`:
- **Geopolitical Events**: International conflicts, alliances
- **Natural Disasters**: Impact on production and logistics
- **Market Events**: Economic shocks, resource discoveries
- **Technology Events**: Scientific breakthroughs, espionage
### Event Scheduling
- **Delayed Events**: Timed consequences of player actions
- **Cascading Events**: Events triggering other events
- **Random Events**: Procedural event generation
- **Player-Triggered Events**: Research completions, diplomatic actions
## Engine Architecture
### Core Classes
```cpp
class EventEngine {
// Event management
void scheduleEvent(std::unique_ptr<GameEvent> event, double delaySeconds);
void triggerImmediateEvent(std::unique_ptr<GameEvent> event);
// Breakthrough system (event-driven with scrap analysis)
void analyzeScrapForBreakthrough(const std::string& scrapData);
void triggerBreakthrough(const std::string& technologyDomain);
// Global events
void generateRandomEvent();
void processScheduledEvents();
};
```
### Communication with Other Engines
- **War-Engine**: Receives battle data for scrap analysis
- **Intelligence-Engine**: Coordinates breakthrough discoveries
- **MacroEntity-Engine**: Triggers diplomatic events
- **Economy-Engine**: Generates market disruption events
- **All Engines**: Broadcasts global events affecting all systems
## Key Design Documents
- `mecaniques-jeu.md` - Breakthrough system and research mechanics
- `arbre-technologique.md` - Technology progression events
- `architecture-technique.md` - Event processing performance
- `coherence-problem.md` - Event balance and timing
## Implementation Notes
- Event-driven architecture for breakthrough system
- Scrap analysis probability mechanics
- Global event impact on all game systems
- Cascading event chains for complex scenarios

View File

@ -0,0 +1,70 @@
# Factory-Engine Documentation
## Engine Overview
**Factory-Engine** handles Factorio-like production simulation with assembly lines, belts, and automated manufacturing.
**Key Responsibilities:**
- Production line simulation
- Resource flow management
- Factory optimization
- Industrial automation
## Core Systems
### Production System
From `gameplay-industriel.md`:
- **Assembly Lines**: Multi-stage production processes
- **Belt Networks**: Resource transportation within factories
- **Assemblers**: Automated production units
- **Quality Control**: Production efficiency and defect rates
### Resource Flow
- **Input/Output Management**: Raw materials → finished products
- **Throughput Optimization**: Bottleneck identification and resolution
- **Inventory Management**: Buffer stocks and storage
- **Production Scheduling**: Order prioritization and batching
### Factory Design
- **Layout Optimization**: Efficient factory floor planning
- **Upgrade Paths**: Production line improvements
- **Automation Levels**: Manual → semi-auto → fully automated
- **Modular Design**: Expandable production modules
## Engine Architecture
### Core Classes
```cpp
class FactoryEngine {
// Factory management
void addProductionLine(std::unique_ptr<ProductionLine> line);
void removeProductionLine(int lineId);
// Production control
void startProduction();
void stopProduction();
void pauseProduction();
// Performance monitoring
double getTickRate() const;
size_t getActiveLines() const;
};
```
### Communication with Other Engines
- **Economy-Engine**: Production costs, resource pricing, order fulfillment
- **Logistic-Engine**: Raw material delivery, finished goods shipping
- **Designer-Engine**: Vehicle production requirements and specifications
- **Intelligence-Engine**: Production metrics and efficiency reporting
- **MacroEntity-Engine**: Company production goals and priorities
## Key Design Documents
- `gameplay-industriel.md` - Complete factory system design
- `economie-logistique.md` - Production economics and supply chains
- `architecture-technique.md` - Performance requirements
- `mecaniques-jeu.md` - Research and upgrade mechanics
## Implementation Notes
- Factorio-inspired belt and assembler mechanics
- Real-time production simulation at 60fps
- Modular production line design
- Automatic optimization suggestions for players

View File

@ -0,0 +1,70 @@
# Intelligence-Engine Documentation
## Engine Overview
**Intelligence-Engine** handles comprehensive metrics collection (3.1GB adaptive scaling), reconnaissance systems, and fog of war management.
**Key Responsibilities:**
- Metrics collection with adaptive scaling (2 pts/min → 0.4 pts/min multiplayer)
- Satellite reconnaissance and intelligence gathering
- Fog of War (FOW) management at chunk granularity
- Analytics and intelligence reporting
## Core Systems
### Metrics Collection
From `metriques-joueur.md`:
- **Adaptive Scaling**: 3.1GB per game with intelligent compression
- **Data Points**: 2 points/minute solo → 0.4 points/minute in multiplayer
- **Categories**: Economic, military, industrial, diplomatic metrics
- **Real-time Analytics**: Live dashboard and trend analysis
### Reconnaissance System
From `architecture-technique.md`:
- **Satellite Intel**: Graduated levels (buildings → factories → company-specific)
- **Intelligence Gathering**: Economic espionage, military reconnaissance
- **Counter-Intelligence**: Protecting own information, detecting spying
- **Information Warfare**: Disinformation and intelligence manipulation
### Fog of War Management
- **Chunk Granularity**: 64x64 tile visibility units
- **Company-Specific FOW**: Each company has independent visibility
- **Information Sharing**: Allied intelligence cooperation
- **Visibility Mechanics**: Line of sight, reconnaissance units
## Engine Architecture
### Core Classes
```cpp
class IntelligenceEngine {
// Metrics (adaptive scaling: 2 pts/min → 0.4 pts/min multiplayer)
void collectMetrics(int companyId, const std::string& data);
void pushMetricsToDatabase();
void adjustScalingForMultiplayer(int numCompanies);
// Reconnaissance (satellite: buildings → factories → company specific)
void updateSatelliteIntel(int x, int y, const std::string& intelLevel);
std::string getIntelligence(int companyId, int x, int y) const;
// FOW management (chunk granularity)
void setChunkVisibility(int companyId, int chunkX, int chunkY, bool visible);
};
```
### Communication with Other Engines
- **All Engines**: Collects metrics from every system
- **Map-Engine**: Coordinates FOW and chunk visibility
- **MacroEntity-Engine**: Company intelligence operations
- **War-Engine**: Military reconnaissance and battle intelligence
- **Economy-Engine**: Economic intelligence and market analysis
## Key Design Documents
- `metriques-joueur.md` - Complete metrics system specification
- `architecture-technique.md` - FOW and reconnaissance mechanics
- `map-system.md` - Chunk-based visibility system
- `coherence-problem.md` - Performance optimization strategies
## Implementation Notes
- 3.1GB data scaling requires sophisticated compression
- Real-time metrics processing with minimal performance impact
- Chunk-level FOW for optimal performance
- Intelligence sharing mechanics between allied companies

View File

@ -0,0 +1,70 @@
# Logistic-Engine Documentation
## Engine Overview
**Logistic-Engine** handles transport networks, supply chains, and convoy management across all map scales.
**Key Responsibilities:**
- Supply chain coordination between production sites
- Convoy routing and management
- Infrastructure vulnerability and security
- Transport optimization across multiple map scales
## Core Systems
### Supply Chain Management
From `economie-logistique.md`:
- **Multi-Site Coordination**: Raw materials → production → distribution
- **Route Optimization**: Cost-effective transportation paths
- **Capacity Planning**: Transport vehicle allocation
- **Supply Reliability**: Backup routes and contingency planning
### Transport Networks
From `map-system.md`:
- **Multi-Scale Routes**: World → Regional → Local scale coordination
- **Infrastructure**: Roads, railways, shipping lanes, air corridors
- **Convoy Management**: Vehicle groups with escorts and timing
- **Vulnerability**: Routes are visible on map and attackable
### Route Security
- **Infrastructure Protection**: Defending supply lines
- **Convoy Escorts**: Military protection for valuable shipments
- **Route Intelligence**: Monitoring for threats and optimal paths
- **Alternative Routing**: Adapting to blocked or dangerous routes
## Engine Architecture
### Core Classes
```cpp
class LogisticEngine {
// Supply chain management
void createSupplyChain(const std::string& chainId, const std::vector<int>& sites);
void updateRoute(const std::string& routeId, const std::vector<std::pair<int,int>>& waypoints);
// Convoy management
void dispatchConvoy(const std::string& convoyId, const std::string& routeId);
void trackConvoyProgress(const std::string& convoyId);
// Infrastructure (routes visible on map, attackable)
void markInfrastructureVulnerable(const std::string& routeId, bool vulnerable);
bool isRouteSecure(const std::string& routeId) const;
};
```
### Communication with Other Engines
- **Economy-Engine**: Transportation costs, supply/demand coordination
- **Factory-Engine**: Production schedules and inventory requirements
- **War-Engine**: Route security, convoy protection, infrastructure attacks
- **Map-Engine**: Route planning across multiple map scales
- **Intelligence-Engine**: Route intelligence and threat assessment
## Key Design Documents
- `economie-logistique.md` - Complete supply chain system
- `map-system.md` - Multi-scale transport coordination
- `systeme-militaire.md` - Infrastructure vulnerability and protection
- `architecture-technique.md` - Performance requirements
## Implementation Notes
- Routes are visible on map and can be targeted by enemies
- Multi-scale coordination requires efficient route planning
- Real-time convoy tracking and threat response
- Supply chain resilience through redundant routing

View File

@ -0,0 +1,72 @@
# MacroEntity-Engine Documentation
## Engine Overview
**MacroEntity-Engine** handles companies, diplomacy, and administration points with macro-level strategic rhythm.
**Key Responsibilities:**
- Company management (2-4 features per company)
- Diplomatic relations and sanctions
- Administration points system (1000 points/day, 1 day = 10 min real)
- Macro-level strategic decisions (~1 action every 3-5 days per company)
## Core Systems
### Company Management
From `mecaniques-jeu.md`:
- **Company Features**: 2-4 distinct capabilities per company
- **Strategic Focus**: Specialization in military, economic, or industrial domains
- **Company Evolution**: Gradual expansion and capability development
- **AI Behavior**: Distinct personalities and strategic preferences
### Administration System
- **Point Allocation**: 1000 administration points per day (10 minutes real-time)
- **Action Costs**: Major decisions consume administration points
- **Daily Reset**: Fresh allocation each game day
- **Strategic Pacing**: Prevents rapid micro-management, encourages planning
### Diplomacy System
From `coherence-problem.md`:
- **Relations Management**: Company-to-company diplomatic status
- **Economic Sanctions**: Trade restrictions and embargos
- **Military Alliances**: Coordinated defense and intelligence sharing
- **Diplomatic Actions**: Treaties, trade agreements, conflict declarations
## Engine Architecture
### Core Classes
```cpp
class MacroEntityEngine {
// Company management (2-4 features per company)
void createCompany(int companyId, const std::string& name);
void updateCompanyFeatures(int companyId);
// Administration (1000 points/day, 1 day = 10 min real)
bool consumeAdminPoints(int companyId, int points);
void resetDailyAdminPoints(int companyId);
// Diplomacy (sanctions, embargos, relations)
void setDiplomaticRelation(int company1, int company2, const std::string& relation);
void applySanctions(int targetCompany, const std::vector<std::string>& sanctions);
// Performance: ~1 action every 3-5 days per company (macro rhythm)
double getActionFrequency() const { return actionFrequency_; }
};
```
### Communication with Other Engines
- **Economy-Engine**: Diplomatic trade relations, sanctions impact
- **War-Engine**: Military alliances, conflict coordination
- **Intelligence-Engine**: Diplomatic intelligence, espionage operations
- **All Engines**: Company-level decision coordination and policy implementation
## Key Design Documents
- `mecaniques-jeu.md` - Administration and company systems
- `coherence-problem.md` - Diplomatic balance and sanctions
- `architecture-technique.md` - Macro-level performance requirements
- `economie-logistique.md` - Company economic interactions
## Implementation Notes
- Macro rhythm: 1 action every 3-5 days prevents micro-management
- Administration points create meaningful strategic choices
- Company features provide distinct strategic identities
- Diplomatic actions have long-term consequences across all systems

View File

@ -0,0 +1,70 @@
# Map-Engine Documentation
## Engine Overview
**Map-Engine** handles procedural generation, chunk streaming, and multi-scale map coordination with 218+ terrain elements.
**Key Responsibilities:**
- Procedural terrain generation with budget system (-10 to +10)
- Chunk management (64x64 tiles, streaming on demand)
- Multi-scale map coordination (World → Regional → Local → Detail)
- Fog of War coordination with Intelligence-Engine
## Core Systems
### Procedural Generation
From `map-system.md`:
- **218 Terrain Elements**: Comprehensive terrain feature set
- **Budget System**: -10 to +10 scoring for balanced generation
- **Millions of Combinations**: Procedural variety through element mixing
- **Scale-Appropriate Detail**: Different detail levels for each map scale
### Chunk System
From `systemes-techniques.md`:
- **64x64 Tiles**: Standard chunk size (1m×1m tiles)
- **Streaming**: On-demand loading/unloading for memory optimization
- **Persistent Storage**: Chunk data persistence across sessions
- **Memory Management**: Automatic cleanup of unused chunks
### Multi-Scale Architecture
- **World Scale**: Diplomatic and strategic overview
- **Regional Scale**: Logistics and major operations
- **Local Scale**: Factory and base management
- **Detail Scale**: Combat and precise operations
## Engine Architecture
### Core Classes
```cpp
class MapEngine {
// Chunk management (64x64 tiles, 1m×1m)
std::shared_ptr<Chunk> getChunk(int x, int y);
void generateChunk(int x, int y);
void unloadChunk(int x, int y);
// FOW (granularity: chunk level)
void updateFOW(int companyId, const std::vector<std::pair<int,int>>& visibleChunks);
bool isChunkVisible(int companyId, int x, int y) const;
// 218 procedural elements, budget -10 to +10
void generateTerrain(int chunkX, int chunkY);
};
```
### Communication with Other Engines
- **Intelligence-Engine**: FOW coordination and chunk visibility
- **War-Engine**: Combat terrain effects, battle locations
- **Logistic-Engine**: Route planning across multiple scales
- **Factory-Engine**: Terrain suitability for industrial development
- **All Engines**: Coordinate actions across appropriate map scales
## Key Design Documents
- `map-system.md` - Complete multi-scale map system
- `systemes-techniques.md` - Chunk system and memory management
- `architecture-technique.md` - Performance requirements and streaming
- `coherence-problem.md` - Multi-scale coordination challenges
## Implementation Notes
- 218 terrain elements provide rich procedural variety
- Budget system ensures balanced and interesting terrain
- Chunk streaming maintains performance with large worlds
- Multi-scale coordination requires careful data synchronization

View File

@ -0,0 +1,67 @@
# Operation-Engine Documentation
## Engine Overview
**Operation-Engine** handles military strategy, adaptive AI generals with machine learning, and strategic decision-making.
**Key Responsibilities:**
- Strategic planning and AI generals with ML adaptation
- Military doctrine evolution through learning
- Battle analysis and strategy optimization
- Operational coordination across multiple engagements
## Core Systems
### AI General System
From `architecture-technique.md`:
- **Machine Learning Adaptation**: AI generals learn from battle results
- **Behavioral Evolution**: Strategies adapt based on success/failure patterns
- **Personality Systems**: Distinct AI general characteristics and preferences
- **Performance Tracking**: Success metrics and learning algorithms
### Strategic Planning
From `systeme-militaire.md`:
- **Operation Coordination**: Multi-battle strategic campaigns
- **Resource Allocation**: Strategic asset distribution
- **Timing Coordination**: Synchronized multi-front operations
- **Contingency Planning**: Alternative strategies and fallback plans
### Doctrine Evolution
- **Learning from Results**: Battle outcomes inform strategic adjustments
- **Company Doctrines**: Faction-specific strategic preferences
- **Adaptive Strategies**: Dynamic response to enemy tactics
- **Knowledge Transfer**: Successful strategies spread between AI generals
## Engine Architecture
### Core Classes
```cpp
class OperationEngine {
// Strategic planning and AI generals with ML
void createOperation(const std::string& operationId, const std::string& type);
void assignGeneral(const std::string& operationId, std::unique_ptr<AIGeneral> general);
void adaptBehaviorFromResults(const std::string& generalId, bool success);
// Doctrine evolution (learning from successes/failures)
void updateDoctrine(const std::string& companyId, const std::string& lessons);
void analyzeBattleReports(const std::vector<std::string>& reports);
};
```
### Communication with Other Engines
- **War-Engine**: Receives battle results for learning and strategy adaptation
- **Intelligence-Engine**: Strategic intelligence and reconnaissance coordination
- **MacroEntity-Engine**: Company-level strategic goals and doctrine preferences
- **Designer-Engine**: Vehicle design requirements based on strategic needs
- **Logistic-Engine**: Strategic supply chain and operational logistics
## Key Design Documents
- `systeme-militaire.md` - Military strategic systems
- `architecture-technique.md` - AI general ML specifications
- `mecaniques-jeu.md` - Doctrine evolution mechanics
- `coherence-problem.md` - Strategic AI balance considerations
## Implementation Notes
- AI generals use machine learning to adapt strategies
- Battle reports provide data for strategic learning
- Doctrine evolution creates dynamic strategic environments
- Multi-operation coordination requires sophisticated planning algorithms

View File

@ -0,0 +1,71 @@
# War-Engine Documentation
## Engine Overview
**War-Engine** handles combat simulation, multi-chunk battles, persistent frontlines, and auto-battler mechanics with player oversight.
**Key Responsibilities:**
- Combat simulation across multiple chunks
- Persistent frontline management
- Auto-battler mechanics with strategic player control
- Battle result analysis and reporting
## Core Systems
### Combat System
From `systeme-militaire.md`:
- **Multi-Chunk Battles**: Combat spanning multiple 64x64 tile chunks
- **Auto-Battler Mechanics**: Automated tactical combat with strategic oversight
- **Unit Coordination**: Multi-vehicle formations and tactical maneuvers
- **Terrain Effects**: Map-based combat modifiers and tactical considerations
### Frontline Management
- **Persistent Frontlines**: Battle lines that persist across sessions
- **Dynamic Front Movement**: Frontlines shift based on combat results
- **Strategic Control Points**: Key locations affecting frontline stability
- **Frontline Intelligence**: Reconnaissance and frontline monitoring
### Battle Resolution
- **Real-time Combat**: Fast-paced tactical resolution
- **Player Oversight**: Strategic control without micro-management
- **Battle Reporting**: Detailed analysis for Operation-Engine learning
- **Casualty Tracking**: Unit losses and damage assessment
## Engine Architecture
### Core Classes
```cpp
class WarEngine {
// Combat management
void initiateBattle(const BattleSetup& setup);
void updateActiveBattles();
BattleResult resolveBattle(int battleId);
// Frontline system
void updateFrontlines();
std::vector<FrontlineSegment> getFrontlines(int companyId) const;
void setFrontlinePosition(int segmentId, const Position& newPosition);
// Auto-battler with player oversight
void setPlayerOversight(int battleId, const StrategicOrders& orders);
AutoBattlerResult processAutoBattle(int battleId);
};
```
### Communication with Other Engines
- **Operation-Engine**: Provides battle results for strategic learning
- **Designer-Engine**: Vehicle combat effectiveness feedback
- **Intelligence-Engine**: Battle intelligence and reconnaissance data
- **Map-Engine**: Multi-chunk combat terrain coordination
- **Event-Engine**: Provides scrap data for breakthrough system
## Key Design Documents
- `systeme-militaire.md` - Complete combat system specification
- `architecture-technique.md` - Multi-chunk battle performance
- `map-system.md` - Combat terrain integration
- `mecaniques-jeu.md` - Auto-battler mechanics and player control
## Implementation Notes
- Multi-chunk battles require efficient spatial coordination
- Auto-battler provides engaging combat without micro-management
- Persistent frontlines create strategic territorial control
- Battle analysis feeds into strategic AI learning systems

17
docs/global/README.md Normal file
View File

@ -0,0 +1,17 @@
# Warfactory - Documentation
## Structure de la documentation
- [Vue d'ensemble](./vue-ensemble.md) - Vision et objectifs du projet
- [Architecture technique](./architecture-technique.md) - Multi-serveurs, performance, développement IA
- [Systèmes techniques](./systemes-techniques.md) - Tile system, mémoire, chunks
- [Gameplay industriel](./gameplay-industriel.md) - Ressources, production, gameloop
- [Système militaire](./systeme-militaire.md) - Véhicules, combat, IA
- [Map system](./map-system.md) - Cartes, navigation, FOW, reconnaissance
- [Économie et logistique](./economie-logistique.md) - Marchés, prix, supply chains
- [Mécaniques de jeu](./mecaniques-jeu.md) - Recherche, progression, simulation
- [Arbre technologique](./arbre-technologique.md) - 3000+ techs avec passerelles inter-domaines
- [Métriques joueur](./metriques-joueur.md) - Analytics complètes, graphiques, intelligence compétitive
- [Contexte narratif](./contexte-narratif.md) - Lore, géopolitique, scénarios
- [DLC prévus](./dlc-prevus.md) - Extensions inspirées RimWorld
- [Updates long terme](./updates-long-terme.md) - Fonctionnalités futures

View File

@ -0,0 +1,973 @@
# Arbre Technologique
## Vue d'ensemble
**Volume technologique** : 2000-3000 technologies organisées en **domaines interconnectés**
**Principe des passerelles** : Expertise dans un domaine débloque des "prototypes" dans d'autres domaines, permettant de court-circuiter les progressions linéaires et d'ouvrir de nouvelles branches.
## Philosophie Discovery & Rejouabilité
### Design Core
**Le player n'est PAS censé rechercher toutes les 3000 technologies** ! Le système est conçu pour la **découverte organique** et la **rejouabilité** :
#### Discovery Progressive
- **Breakthrough system** : Technologies débloquées par gameplay naturel (construction, production, combat)
- **Prerequisites gating** : Seules ~10-50 techs eligible simultanément, jamais 3000
- **Random element** : Chaque run = découvertes différentes selon actions player
- **Organic emergence** : "Je construis → je découvre" vs "je regarde un arbre"
#### Rejouabilité Infinie
- **3000 techs = content pool** pour expériences variées
- **Run spécialisé** : Focus métallurgie vs électronique = paths complètement différents
- **Combinaisons nouvelles** : Passerelles créent synergies inattendues entre runs
- **Surprises constantes** : "Wow ! Cette tech existe ?" même après 100h
#### Performance & Scaling
- **Prerequisites check** : Validation ponctuelle quand conditions remplies, pas polling
- **Ticker optimisé** : Vérification breakthrough toutes les minutes, pas 60fps
- **Interface proven** : Similar à Factorio qui gère 100+ techs sans problème
- **Design for scale** : Standard industrie pour gros content pools
## Mécaniques des Passerelles
### Principe Fondamental
- Chaque arbre a sa **progression linéaire classique**
- Des techs d'autres arbres débloquent des **[PROTOTYPE]** qui court-circuitent la progression
- Ces prototypes ouvrent de **nouvelles branches** dans l'arbre de destination
- **Évite le grind linéaire** : Player spécialisé peut accéder à d'autres domaines sans tout refaire
### Types de Déblocages
1. **Court-circuit** : Saute 1-3 techs de la progression linéaire
2. **Nouvelle branche** : Ouvre une ligne technologique alternative
3. **Hybridation** : Combine deux domaines pour créer des technologies uniques
4. **Spécialisation** : Versions spécialisées de technologies existantes
### Exemple Concret : Châssis
**Progression classique** :
```
Châssis Léger → Châssis Moyen → Châssis Lourd → Châssis Blindé
```
**Passerelles depuis autres arbres** :
```
Métallurgie Avancée → [PROTOTYPE] Châssis Composite (saute Châssis Moyen)
→ Ouvre branche : Châssis Composite → Châssis Modulaire → Châssis Ultra-Léger
Électronique → [PROTOTYPE] Châssis Smart (saute Châssis Lourd)
→ Ouvre branche : Châssis Smart → Châssis Adaptatif → Châssis Morphing
Moteur → [PROTOTYPE] Châssis Performance
→ Ouvre branche : Châssis Performance → Châssis Racing → Châssis Hypervéloce
```
## Domaines Technologiques Principaux
### 0. Technologies Civiles - ARBRE MASTER (~800 techs)
**Rôle central** : L'arbre civil est le **backbone technologique** qui nourrit TOUS les autres domaines. Il représente la base industrielle, scientifique et sociale qui permet le développement militaire.
#### Structure de l'Arbre Civil
**A. Infrastructure & Industrie de Base (~150 techs)**
```
Outils Manuels → Machines Simples → Automation Basique → Industrie Lourde → Complexes Industriels → Méga-Usines
```
Sous-branches :
- **Extraction** : Mines → Foreuses → Extraction Automatisée → Mining Complexes
- **Sidérurgie** : Forges → Hauts Fourneaux → Aciéries → Complexes Métallurgiques
- **Chimie** : Laboratoires → Usines Chimiques → Pétrochimie → Nanotechnologie
**Passerelles offertes** :
- → **Métallurgie** : [PROTOTYPE] Alliages Industriels (court-circuite Aciers Spéciaux)
- → **Production** : [PROTOTYPE] Assembly Lines (court-circuite Automation)
- → **Énergie** : [PROTOTYPE] Générateurs Industriels
**B. Sciences Fondamentales (~120 techs)**
```
Mathématiques → Physique → Chimie → Biologie → Sciences Avancées → Recherche Fondamentale → Théories Unifiées
```
Sous-branches détaillées :
- **Mathématiques** : Arithmétique → Algèbre → Calcul → Statistiques → Topologie → Théorie des Groupes
- **Physique** : Mécanique → Thermodynamique → Électromagnétisme → Quantique → Relativité → Physique Exotique
- **Chimie** : Chimie de Base → Organique → Polymères → Catalyse → Supramoléculaire
- **Biologie** : Cellulaire → Génétique → Biotechnologie → Ingénierie Génétique
**Passerelles offertes** :
- → **Électronique** : [PROTOTYPE] Semi-Conducteurs Avancés
- → **Matériaux** : [PROTOTYPE] Matériaux Quantiques
- → **Médecine** : [PROTOTYPE] Biotechnologies Militaires
- → **Énergie** : [PROTOTYPE] Réacteurs Avancés
**C. Technologies de l'Information (~100 techs)**
```
Écriture → Imprimerie → Télégraphe → Téléphone → Ordinateurs → Internet → IA Civile → Singularité Info
```
Sous-branches :
- **Calcul** : Abaque → Calculatrices → Ordinateurs → Superordinateurs → Quantique
- **Réseaux** : Télégraphe → Téléphone → Internet → Réseaux Avancés → Neural Networks
- **Stockage** : Papier → Magnétique → Optique → Quantique → Moléculaire
**Passerelles offertes** :
- → **Électronique** : [PROTOTYPE] Processeurs Civils → branch militaire
- → **Communication** : [PROTOTYPE] Réseaux Sécurisés
- → **Capteurs** : [PROTOTYPE] Surveillance Civile
**D. Transport & Logistique Civile (~80 techs)**
```
Marche → Roue → Animaux → Vapeur → Moteur → Aviation → Spatial → Téléportation
```
Sous-branches :
- **Terrestre** : Pieds → Vélo → Automobile → Trains → Transport de Masse
- **Maritime** : Radeaux → Voiliers → Vapeur → Cargo → Porte-Conteneurs
- **Aérien** : Ballons → Avions → Jets → Supersonique → Spatial
- **Logistique** : Entrepôts → Supply Chains → Automation → Distribution
**Passerelles offertes** :
- → **Moteurs** : [PROTOTYPE] Moteurs Haute Performance
- → **Châssis** : [PROTOTYPE] Véhicules Civils Adaptés
- → **Logistic Engine** : [PROTOTYPE] Systèmes de Distribution
**E. Énergie & Ressources (~90 techs)**
```
Muscle → Eau → Vapeur → Électricité → Fossiles → Nucléaire → Renouvelables → Fusion → Exotique
```
Sous-branches massives :
- **Renouvelables** : Éolien → Solaire → Hydroélectrique → Géothermique → Biomasse
- **Fossiles** : Charbon → Pétrole → Gaz → Raffinerie → Pétrochimie
- **Nucléaire** : Fission → Réacteurs → Sécurité → Fusion → Réacteurs Avancés
- **Stockage** : Batteries → Supercondensateurs → Stockage Massif
**Passerelles offertes** :
- → **Moteurs** : [PROTOTYPE] Propulsion Alternative
- → **Électronique** : [PROTOTYPE] Alimentation Avancée
- → **Armes** : [PROTOTYPE] Armes Énergétiques
**F. Agriculture & Biotechnologie (~70 techs)**
```
Cueillette → Agriculture → Élevage → Sélection → Mécanisation → OGM → Agriculture Verticale → Bio-usines
```
Sous-branches :
- **Crops** : Céréales → Légumes → Fruits → Plantes Industrielles → OGM
- **Élevage** : Domestication → Sélection → Élevage Intensif → Clonage
- **Bio-industrie** : Fermentation → Biocarburants → Pharmaceutiques → Biomatériaux
**Passerelles offertes** :
- → **Médecine** : [PROTOTYPE] Pharmacologie Militaire
- → **Matériaux** : [PROTOTYPE] Biomatériaux
- → **Énergie** : [PROTOTYPE] Biocarburants Avancés
**G. Médecine & Sciences de la Vie (~60 techs)**
```
Herboristerie → Anatomie → Chirurgie → Antibiotiques → Médecine Moderne → Génétique → Augmentation
```
Sous-branches :
- **Diagnostics** : Observation → Rayons X → Scanners → Diagnostics Moléculaires
- **Traitements** : Chirurgie → Médicaments → Thérapie Génique → Nanotechnologie Médicale
- **Augmentation** : Prothèses → Implants → Cybernétique → Enhancement Génétique
**Passerelles offertes** :
- → **Électronique** : [PROTOTYPE] Biocapteurs
- → **Matériaux** : [PROTOTYPE] Matériaux Biocompatibles
- → **IA** : [PROTOTYPE] IA Médicale → IA Militaire
**H. Sciences Sociales & Organisation (~80 techs)**
```
Tribus → Villages → Cités → États → Organisations → Corporations → Gouvernance Mondiale
```
Sous-branches :
- **Gouvernance** : Monarchie → Démocratie → Bureaucratie → E-gouvernement
- **Économie** : Troc → Monnaie → Banques → Marchés → Économie Numérique
- **Education** : Oral → Écrit → Universités → Recherche → Education de Masse
- **Média** : Oral → Écrit → Imprimé → Radio/TV → Internet → Réalité Virtuelle
**Passerelles offertes** :
- → **Communication** : [PROTOTYPE] Propagande Moderne
- → **IA** : [PROTOTYPE] IA Sociale
- → **Capteurs** : [PROTOTYPE] Surveillance Sociale
#### Mécaniques Spéciales de l'Arbre Civil
**1. Déblocage en Cascade**
Une tech civile peut débloquer des passerelles dans **MULTIPLES domaines** :
```
"Internet" → [PROTOTYPE] Réseaux Militaires (Communication)
→ [PROTOTYPE] Guerre Électronique (EW)
→ [PROTOTYPE] IA Distribuée (Électronique)
→ [PROTOTYPE] Logistique Intelligente (Transport)
```
**2. Prérequis Civils Obligatoires**
Certaines techs militaires **EXIGENT** des bases civiles :
- Armes Guidées → Nécessite "Électronique Civile"
- Véhicules Autonomes → Nécessite "IA Civile"
- Matériaux Avancés → Nécessite "Sciences des Matériaux"
**3. Synergie Économie-Recherche**
- Techs civiles influencent la **capacité économique** de production
- Plus de tech civile = plus de **research points** générés
- Certaines techs civiles débloquent des **bâtiments de recherche** spécialisés
**4. Évènements de Tech-Transfer**
- Events aléatoires : "Découverte civile" → breakthrough militaire inattendu
- "Dual-use technology" : Tech civile automatiquement adaptée au militaire
- "Brain-drain" : Scientifiques civils → boost recherche militaire
#### Exemples Concrets de Passerelles Civile → Militaire
**Chimie Agricole → Explosifs** :
```
Agriculture : Engrais Azotés → [PROTOTYPE] Explosifs Artisanaux
→ [PROTOTYPE] Nitrate d'Ammonium → Explosifs Industriels
→ [PROTOTYPE] Pesticides → Armes Chimiques
→ [PROTOTYPE] Fertilisants → Propergols Roquettes
Pétrochimie : Plastiques → [PROTOTYPE] Explosifs Plastiques
→ [PROTOTYPE] Polymères → Propergols Solides
→ [PROTOTYPE] Solvants → Carburants Militaires
```
**Médecine → Applications Militaires** :
```
Pharmacologie : Anesthésiques → [PROTOTYPE] Gaz Incapacitants
→ [PROTOTYPE] Stimulants → Drogues de Combat
→ [PROTOTYPE] Antibiotiques → Protection NBC
Chirurgie : Traumatologie → [PROTOTYPE] Médecine de Guerre
→ [PROTOTYPE] Prothèses → Augmentations Militaires
→ [PROTOTYPE] Analgésiques → Stims de Combat
```
**Électronique Civile → Militaire** :
```
Télécommunications : GPS Civil → [PROTOTYPE] Navigation Militaire
→ [PROTOTYPE] Satellites → Reconnaissance Spatiale
→ [PROTOTYPE] Internet → Cyberguerre
Gaming : Processeurs Graphiques → [PROTOTYPE] Simulation Balistique
→ [PROTOTYPE] Réalité Virtuelle → Entraînement Militaire
→ [PROTOTYPE] IA de Jeu → IA Tactique
```
**Transport Civil → Applications Militaires** :
```
Aviation Civile : Moteurs Civils → [PROTOTYPE] Moteurs Militaires
→ [PROTOTYPE] Navigation Aérienne → Systèmes Guidage
→ [PROTOTYPE] Drones Livraison → Drones Militaires
Automobile : Moteurs Performance → [PROTOTYPE] Véhicules Blindés
→ [PROTOTYPE] Systèmes Hybrides → Véhicules Furtifs
→ [PROTOTYPE] Autonomous Cars → Véhicules Autonomes Militaires
```
**Sciences des Matériaux → Applications Militaires** :
```
Industrie : Alliages Légers → [PROTOTYPE] Blindages Composites
→ [PROTOTYPE] Céramiques → Plaques Balistiques
→ [PROTOTYPE] Fibres Carbone → Casques Avancés
→ [PROTOTYPE] Nanomatériaux → Furtivité Avancée
Construction : Béton Haute Résistance → [PROTOTYPE] Bunkers Avancés
→ [PROTOTYPE] Aciers Spéciaux → Blindages Réactifs
```
**Énergie Civile → Applications Militaires** :
```
Nucléaire Civil : Réacteurs → [PROTOTYPE] Propulsion Nucléaire
→ [PROTOTYPE] Isotopes → Armes Radiologiques
→ [PROTOTYPE] Fusion Contrôlée → Armes Thermonucléaires
Renouvelables : Panneaux Solaires → [PROTOTYPE] Alimentation Terrain
→ [PROTOTYPE] Batteries → Systèmes Autonomes
→ [PROTOTYPE] Supercondensateurs → Armes Énergétiques
```
**Agriculture → Applications Militaires** :
```
Biotechnologie : Génétique Végétale → [PROTOTYPE] Bioarmes
→ [PROTOTYPE] Fermentation → Production Explosifs
→ [PROTOTYPE] Enzymes → Décontamination NBC
Mécanisation : Tracteurs → [PROTOTYPE] Véhicules Logistiques
→ [PROTOTYPE] GPS Agricole → Navigation Militaire
→ [PROTOTYPE] Drones Agricoles → Surveillance/Attack Drones
```
**Total Passerelles Civile → Militaire** : ~40-50 prototypes
- Chaque domaine civil offre 5-8 passerelles militaires
- Certaines techs civiles débloquent dans PLUSIEURS domaines militaires
- Progression naturelle : applications civiles → adaptations militaires
### 1. Métallurgie & Matériaux (~300 techs)
#### Progression Principale Étendue
```
Métaux de Base → Alliages Simples → Aciers Spéciaux → Métaux Légers → Composites → Superalliages → Matériaux Quantiques → Matériaux Exotiques
```
#### Sous-branches Détaillées
**A. Matériaux Traditionnels & Naturels (70 techs)**
- **Métaux de Base** : Fer → Cuivre → Bronze → Acier → Acier Carbone → Fonte → Acier Doux (10 techs)
- **Alliages Simples** : Laiton → Acier Inox → Chrome → Nickel → Cobalt → Zinc → Étain (10 techs)
- **Aciers Spéciaux** : Haute Résistance → Rapide → Inoxydable → Outillage → Ressorts → Maraging (10 techs)
- **Traitements Métalliques** : Trempe → Recuit → Cémentation → Nitruration → Chromage → Galvanisation (10 techs)
- **Bois & Dérivés** : Bois Massif → Contreplaqué → Aggloméré → Bois Pressé → Bois Lamellé → MDF → OSB → Bois Traité → Bois Densifié → Bois Composite (15 techs)
- **Bétons & Ciments** : Mortier → Béton Simple → Béton Armé → Béton Précontraint → Béton Romain (Auto-Réparant) → Béton Fibré → Béton Ultra-Haute Performance → Béton Translucide → Béton Auto-Plaçant → Géopolymères → Béton Léger → Béton Lourd (15 techs)
**B. Métaux Légers & Avancés (40 techs)**
- **Aluminium** : Pur → Alliages 2xxx → 6xxx → 7xxx → Aéronautique → Ultra-Léger (12 techs)
- **Titane** : Grade 1 → Grade 2 → Ti-6Al-4V → Aérospatial → Bio-compatible → Beta-Titane (12 techs)
- **Magnésium** : Pur → AZ Series → AM Series → Structural → Ignifuge → Ultra-Léger (10 techs)
- **Lithium & Rares** : Lithium → Béryllium → Terres Rares → Scandium → Métaux Exotiques (6 techs)
**C. Matériaux Composites (55 techs)**
- **Fibres de Base** : Verre E → Verre S → Carbone T300 → T700 → T800 → Aramide → Basalte → Lin (15 techs)
- **Matrices** : Époxy → Polyester → Vinylester → Thermoplastiques → PEEK → Bio-résines (12 techs)
- **Composites Avancés** : Sandwich → Tissage 3D → Nanotubes → Graphène → Fibres Hybrides → RTM (18 techs)
- **Composites Métalliques** : Métal-Matrice → Céramique-Métal → Hybrides → MMC Aluminium (10 techs)
**D. Matériaux Intelligents & Programmables (45 techs)**
- **Smart Materials** : Mémoire de Forme → Piézoélectriques → Magnétorhéologiques → Électrorhéologiques → Thermochromiques (15 techs)
- **Nanomatériaux** : Nanoparticules → Nanotubes → Graphène → Fullerènes → Quantum Dots → Nanocomposites (15 techs)
- **Matériaux Programmables** : Auto-Assemblage → Reconfigurables → Adaptatifs → Morphing → 4D Printing (10 techs)
- **Bio-matériaux** : Bio-inspirés → Vivants → Auto-Réparants → Évolutifs → Biocompatibles (5 techs)
**E. Blindages & Protection (35 techs)**
- **Blindages Passifs** : Homogène → Composite → Espacé → Modulaire → Laminé → Multi-Couches (12 techs)
- **Blindages Réactifs** : ERA → NERA → Smart Armor → Adaptatif → Électrique → Magnétique (12 techs)
- **Protection Avancée** : Furtivité → Multi-Spectral → Caméléon → Phase-Change → Plasma (11 techs)
**F. Matériaux Exotiques & Quantiques (25 techs)**
- **Supraconducteurs** : Haute Température → Ambiants → Quantiques → Organiques → Cuprates (8 techs)
- **Métamatériaux** : Optiques → RF → Acoustiques → Mécaniques → Plasmoniques → Photoniques (10 techs)
- **Matériaux Quantiques** : Cristaux Temporels → Topologiques → Plasma → Antimatière → Matière Noire → Dimensions Supérieures → Singularités Contrôlées (7 techs)
#### Passerelles Offertes Étendues
- → **Châssis** : [PROTOTYPE] Châssis Composite (court-circuite Châssis Moyen)
- → **Châssis** : [PROTOTYPE] Châssis Ultra-Léger (court-circuite Châssis Lourd)
- → **Armement** : [PROTOTYPE] Canon Léger (court-circuite Artillerie de Base)
- → **Armement** : [PROTOTYPE] Blindage Réactif (court-circuite Protection Passive)
- → **Électronique** : [PROTOTYPE] Dissipateurs Avancés
- → **Électronique** : [PROTOTYPE] Supraconducteurs (court-circuite Refroidissement)
- → **Transport** : [PROTOTYPE] Véhicules Ultra-Légers
- → **Énergie** : [PROTOTYPE] Stockage Supraconducteur
- → **Capteurs** : [PROTOTYPE] Optiques Avancées
### 2. Châssis & Structures (~100 techs)
#### Progression Principale
```
Châssis Léger → Châssis Moyen → Châssis Lourd → Châssis Blindé → Châssis Modulaire
```
#### Branches Classiques Focus
- **Légers** : Châssis Scout → Châssis Reconnaissance → Châssis Infiltration (20 techs)
- **Moyens** : Châssis Transport → Châssis Polyvalent → Châssis Support (20 techs)
- **Lourds** : Châssis Bataille → Châssis Assault → Châssis Forteresse (20 techs)
#### Branches Débloquées par Passerelles (40 techs)
- **Métallurgie** → [PROTOTYPE] Châssis Composite → Châssis Ultra-Léger → Châssis Furtif
- **Électronique** → [PROTOTYPE] Châssis Smart → Châssis Adaptatif → Châssis IA
- **Moteurs** → [PROTOTYPE] Châssis Performance → Châssis Racing → Châssis Hypervéloce
#### Passerelles Offertes
- → **Armement** : [PROTOTYPE] Tourelles Stabilisées
- → **Capteurs** : [PROTOTYPE] Plateformes Sensorielles
### 3. Électronique & Informatique (~400 techs)
#### Progression Principale Étendue
```
Circuits de Base → Processeurs → IA Basique → IA Avancée → IA Militaire → IA Autonome → IA Symbiotique → Conscience Artificielle
```
#### Sous-branches Massives
- **Processeurs** : CPU → GPU → Quantique → Neuromorphique → Bio-processeurs (80 techs)
- **Capteurs Électroniques** : Optiques → Thermiques → Radars → Multi-spectraux → Quantiques (60 techs)
- **IA & Machine Learning** : Expert Systems → ML → Neural Networks → Deep Learning → AGI (100 techs)
- **Microélectronique** : Circuits Intégrés → Nanopuces → Quantique → Moléculaire (80 techs)
- **Systèmes Embarqués** : Contrôleurs → Temps Réel → Distribués → Autonomes (80 techs)
#### Passerelles Offertes
- → **Armement** : [PROTOTYPE] Viseurs Intelligents
- → **Châssis** : [PROTOTYPE] Châssis Smart
- → **Communication** : [PROTOTYPE] Guerre Électronique
- → **Capteurs** : [PROTOTYPE] Radars Adaptatifs
- → **Transport** : [PROTOTYPE] Véhicules Autonomes
### 4. Moteurs & Propulsion (~150 techs)
#### Progression Principale Resserrée
```
Moteurs Diesel → Moteurs Turbo → Moteurs Hybrides → Moteurs Électriques → Propulsion Alternative
```
#### Sous-branches Focus
- **Thermiques** : Diesel → Essence → Turbine → Fusion (40 techs)
- **Électriques** : Batteries → Supercondensateurs → Pile à Combustible (35 techs)
- **Hybrides** : Série → Parallèle → Plug-in → Intelligent (25 techs)
- **Exotiques** : Ionique → Plasma → Antigravité → Propulsion Spatiale (50 techs)
#### Passerelles Offertes
- → **Châssis** : [PROTOTYPE] Châssis Performance
- → **Transport** : [PROTOTYPE] Transport Rapide
- → **Aviation** : [PROTOTYPE] Moteurs Aéro
- → **Naval** : [PROTOTYPE] Propulsion Marine
### 5. Armement & Munitions (~400 techs)
#### Progression Principale Massive
```
Armes Légères → Artillerie → Missiles → Armes Guidées → Armes Intelligentes → Armes Énergétiques → Armes Exotiques
```
#### Sous-branches Ultra-Détaillées
- **Armes Légères** : Fusils → Mitrailleuses → Armes Spécialisées → Smart Weapons (80 techs)
- **Artillerie** : Canons → Mortiers → Artillery Guided → Railguns → Plasma Cannons (100 techs)
- **Missiles** : Roquettes → Missiles Guidés → Missiles Intelligents → Essaims → Hypersoniques (120 techs)
- **Armes Énergétiques** : Lasers → Plasma → Particle Beams → Weapons Exotiques (100 techs)
#### Branches Débloquées par Passerelles
- **Métallurgie** → [PROTOTYPE] Canon Léger → Artillerie Composite → Canons Electromagnétiques
- **Électronique** → [PROTOTYPE] Viseurs Intelligents → Armes Autonomes → Essaims de Combat
- **Moteurs** → [PROTOTYPE] Missiles Hypersoniques → Projectiles Cinétiques
### 6. Capteurs & Reconnaissance (~200 techs)
#### Progression Principale
```
Optiques de Base → Radars → Capteurs Multispectraux → Reconnaissance Satellite → Intel Fusion → Omniscience
```
#### Exemple Détaillé : Évolution Radar
- **Proto radar** : Composant 6x6, 2kw, fiabilité 50%
- **Recherche radar 1** : Composant 5x5, 2kw, fiabilité 60% + sous-composant électronique 4x4, 500w, fiabilité 20%
- **Recherche radar 2** : Composant 8x3, 1.5kw, fiabilité 80%
- **Radar Avancé** : Composant 6x2, 1kw, fiabilité 95% + mode stealth
- **Radar Quantique** : Composant 4x2, 500w, fiabilité 99% + pénétration furtivité
### 7. Communication & Guerre Électronique (~100 techs)
#### Progression Principale Focus
```
Radio → Communications Sécurisées → Réseaux Tactiques → Guerre Électronique → Cyber Warfare
```
#### Sous-branches Concentrées
- **Communications** : Radio → Crypté → Satellites → Réseaux Mesh (30 techs)
- **Guerre Électronique** : Jamming → SIGINT → ELINT → Cyber Ops (40 techs)
- **Réseaux** : P2P → Tactiques → Stratégiques → Quantiques (30 techs)
### 8. Transport & Logistique (~60 techs)
#### Progression Principale Streamline
```
Véhicules de Base → Transport Lourd → Rail → Transport Maritime → Hyperloop
```
#### Sous-branches Essentielles
- **Terrestre** : Camions → Convois → Trains → Hyperloop (20 techs)
- **Maritime** : Cargos → Porte-Conteneurs → Transport Rapide (15 techs)
- **Aérien** : Cargo → Transport Stratégique → Orbital (15 techs)
- **Logistique** : Supply Chains → Distribution → Automation (10 techs)
### 9. Production & Assembly (~100 techs)
#### Progression Principale Efficace
```
Assembly Manuel → Automation → Robotique → Nano-Assembly → Fabrication Moléculaire
```
#### Sous-branches Focus
- **Automation** : Chaînes → Robots → IA Production (30 techs)
- **Qualité** : Contrôle → Précision → Perfectionnement (25 techs)
- **Vitesse** : Optimisation → Parallélisation → Instantané (25 techs)
- **Flexibilité** : Modulaire → Adaptatif → Reconfigurable (20 techs)
### 10. Énergie & Alimentation (~100 techs)
#### Progression Principale Condensée
```
Générateurs de Base → Énergie Renouvelable → Batteries Avancées → Fusion → Anti-matière
```
#### Sous-branches Concentrées
- **Génération** : Fossiles → Nucléaire → Fusion → Exotique (35 techs)
- **Renouvelables** : Solaire → Éolien → Géothermique → Bio (25 techs)
- **Stockage** : Batteries → Supercaps → Stockage Massif (25 techs)
- **Distribution** : Réseaux → Smart Grids → Sans-fil (15 techs)
## Mécaniques Avancées des Passerelles
### Passerelles Multi-Domaines
Certains prototypes nécessitent expertise dans **plusieurs domaines** :
```
Métallurgie Avancée + Électronique → [PROTOTYPE] Armure Réactive
→ Nouvelle branche : Défenses Adaptatives
Moteurs + Communication → [PROTOTYPE] Véhicules Coordinés
→ Branche : Essaims Terrestres
IA + Capteurs + Armement → [PROTOTYPE] Tourelles Autonomes
→ Branche : Défenses Intelligentes
Matériaux + Moteurs + IA → [PROTOTYPE] Véhicules Morphing
→ Branche : Technologie Adaptive
```
### Profondeur et Distribution Finale
- **Technologies Civiles** : 800 techs (backbone)
- **Métallurgie & Matériaux** : 300 techs
- **Châssis & Structures** : 100 techs
- **Électronique & Informatique** : 400 techs
- **Moteurs & Propulsion** : 150 techs
- **Armement & Munitions** : 400 techs
- **Capteurs & Reconnaissance** : 200 techs
- **Communication & Guerre Électronique** : 100 techs
- **Transport & Logistique** : 60 techs
- **Production & Assembly** : 100 techs
- **Énergie & Alimentation** : 100 techs
**Total estimé** : 2710 technologies + ~300 passerelles inter-domaines = **~3000 technologies** avec progression non-linéaire ultra-riche
## Interface Utilisateur - Vues Modulaires
### Principe des Vues Focalisées
Pour éviter l'overwhelm des 3000 technologies, l'interface propose des **vues modulaires** permettant de se concentrer sur des progressions spécifiques.
### Vue "Arbre Linéaire"
**Fonctionnement** :
1. Player **sélectionne une tech racine** (ex: "Métaux de Base", "Circuits de Base", "Moteurs Diesel")
2. L'interface affiche **uniquement l'arbre de progression linéaire** à partir de cette racine
3. **Pas de passerelles** affichées → focus sur la progression naturelle du domaine
4. **Système Discovery** : Les techs sans breakthrough ne sont **JAMAIS** visibles (principe Ymir)
### Exemples Concrets
**Exemple 1 : Tech Racine "Métaux de Base"**
```
Métaux de Base
├── Fer [RECHERCHÉ] ✅
├── Cuivre [RECHERCHÉ] ✅
├── Bronze [DISPONIBLE] 🔓
├── Acier [DISPONIBLE] 🔓
├── Acier Carbone [VERROUILLÉ] 🔒
└── Fonte [INCONNU] ❓ (si toggle OFF)
```
**Exemple 2 : Discovery Progressive "Radar"**
**Run 1 - Player débutant** :
```
Proto Radar
├── [RECHERCHÉ] Proto radar (6x6, 2kw, 50% fiabilité) ✅
└── [DISPONIBLE] Recherche radar 1 (5x5, 2kw, 60% fiabilité) 🔓
?? Plus de techs radar disponibles ??
```
**Run 2 - Player a fait breakthrough "Scrap Radar Militaire"** :
```
Proto Radar
├── [RECHERCHÉ] Proto radar ✅
├── [RECHERCHÉ] Recherche radar 1 ✅
├── [DISPONIBLE] Recherche radar 2 (8x3, 1.5kw, 80% fiabilité) 🔓
└── [BREAKTHROUGH] Radar Militaire (4x4, 1kw, 70% fiabilité, mode furtif) 🔥
💡 "Wow ! Je ne savais pas que ça existait !"
```
**Run 5 - Player expérimenté** :
```
Proto Radar
├── [RECHERCHÉ] Proto radar ✅
├── [RECHERCHÉ] Recherche radar 1 ✅
├── [RECHERCHÉ] Recherche radar 2 ✅
├── [BREAKTHROUGH] Radar Militaire ✅
├── [BREAKTHROUGH] Radar Adaptatif (découvert via scrap drone) 🔥
├── [AVAILABLE] Radar Quantique (débloqué par Radar Adaptatif) 🔓
└── [BREAKTHROUGH] Radar Multispectral (découvert via capture satellite) 🔥
```
### États des Technologies
**Couleurs/Icônes** :
- ✅ **RECHERCHÉ** : Vert, disponible pour utilisation
- 🔓 **DISPONIBLE** : Jaune, peut être recherché maintenant
- 🔒 **VERROUILLÉ** : Rouge, prérequis manquants
- 🔥 **BREAKTHROUGH** : Orange, découvert via scrap/capture/événement
- 🔗 **PASSERELLE** : Bleu, accessible via autre domaine (vue séparée)
### Contrôles Interface
**Sélecteur Tech Racine** :
```
Domaine: [Métallurgie ▼]
Tech Racine: [Métaux de Base ▼] [Alliages Simples ▼] [Aciers Spéciaux ▼]
```
**Options d'Affichage** :
```
☑️ Montrer prérequis détaillés
☑️ Montrer coûts de recherche
☐ Mode compact
```
## Breakthrough Tech System (À la Ymir)
### Principe Fondamental
**TOUTE** technologie nécessite un **breakthrough** avant d'être recherchable. Pas de tech tree visible - système de découverte organique basé sur l'expérience de jeu.
### Mécaniques Core
#### 1. Conditions de Breakthrough
Chaque tech a des **conditions de découverte** variées :
#### State-Based vs Historic Validation
**State-Based Conditions (Préférées)** :
- **Avoir** 5 radars actifs → breakthrough "Radar Avancé"
- **Avoir** 10 usines simultanément → breakthrough "Automation Industrielle"
- **Avoir** 20 tourelles déployées → breakthrough "Défenses Intégrées"
- **Avoir** 1M€ en banque → breakthrough "Capital Industriel"
**Historic + Counters (Minimales)** :
- **Total produit** : 1000t acier (compteur cumulatif simple)
- **Designs créés** : 50 véhicules (compteur simple)
- **Ventes cumulées** : 100k€ sur marché (compteur simple)
**Triggers Événementiels (Pas de stockage)** :
- **Concevoir véhicule** avec 5+ composants électroniques → check immédiat
- **Exporter vers nouveau pays** → check immédiat
- **Rechercher tech** → check dépendances immédiat
### Optimisation Mémoire - System Design
#### Données State Actuelles (Toujours en RAM)
```cpp
struct PlayerState {
// Installations actives
int active_radars = 0;
int active_factories = 0;
int deployed_turrets = 0;
// Finances actuelles
long current_money = 0;
// Technologies recherchées (BitSet)
bitset<3000> researched_techs;
// Pays d'export actifs (Set)
set<CountryID> export_countries;
}
```
#### Compteurs Cumulatifs (Minimal Historic)
```cpp
struct LifetimeCounters {
// Production totale (compteurs simples)
long total_steel_produced = 0;
long total_vehicles_designed = 0;
long total_revenue = 0;
// Événements majeurs (flags)
bool designed_composite_vehicle = false;
bool designed_autonomous_system = false;
bool exported_to_5_countries = false;
}
```
#### Validation en Temps Réel
```cpp
// Trigger immédiat lors d'événements
void OnVehicleDesigned(Design vehicle) {
if (vehicle.hasComponentType(ELECTRONIC) >= 5) {
TriggerBreakthroughCheck("Electronic_Embedded");
}
if (vehicle.hasComposite()) {
counters.designed_composite_vehicle = true;
TriggerBreakthroughCheck("Advanced_Protection");
}
}
void OnRadarBuilt() {
state.active_radars++;
if (state.active_radars >= 5) {
TriggerBreakthroughCheck("Advanced_Radar");
}
}
```
#### Exemples Optimisés
**Breakthrough "Radar Avancé"** :
```
Conditions:
✅ State: active_radars >= 5 (check continu)
✅ State: researched_techs[RADAR_BASIC] == true
❌ Pas: "avoir détecté 100 unités" (trop coûteux à tracker)
```
**Breakthrough "Automation Industrielle"** :
```
Conditions:
✅ State: active_factories >= 10
✅ Counter: total_vehicles_designed >= 100
✅ Event: designed_autonomous_system == true
```
**Breakthrough "Commerce International"** :
```
Conditions:
✅ State: export_countries.size() >= 5
✅ Counter: total_revenue >= 1000000
❌ Pas: "historique des ventes détaillé" (trop coûteux)
```
#### 2. Random Ticker System
- Condition remplie → **random chance** chaque tick de découvrir le breakthrough
- Probabilité augmente avec le temps (évite frustration)
- **Pas instantané** → crée suspense et anticipation
#### 3. Méthodes de Force
**Scrap Analysis** :
- Étudier équipement ennemi → breakthrough garanti (mais coûteux)
- "Tu étudies ce radar captured → découvres Radar Militaire"
**Reverse Engineering** :
- Acheter produit sur marché → décomposer → breakthrough
- Conséquences diplomatiques mais accès garanti
**Design Study** :
- Analyser designs capturés → breakthrough composants spécifiques
#### 4. Trading de Breakthroughs
**Marché des connaissances** :
- **Breakthrough ≠ tech researched** → breakthrough = accès à la recherche
- Companies peuvent vendre/acheter l'accès aux recherches
- Prix selon rareté et demande
- Créé économie de l'innovation
### Exemples Concrets
#### Progression "Radar"
```
Base: Proto Radar (toujours disponible)
Breakthrough "Radar 1":
├── Condition A: Avoir 3 radars opérationnels pendant 10 jours
├── Condition B: Détecter 100 unités ennemies
└── Force: Scrap "Radar militaire ukrainien"
Breakthrough "Radar Adaptatif":
├── Condition A: Avoir recherché Radar 1 + IA Basique
├── Condition B: Concevoir véhicule avec radar + 3 capteurs
└── Force: Reverse engineer "Radar AESA commercial"
Breakthrough "Radar Quantique":
├── Condition A: Recherché Radar Adaptatif + Physique Quantique
├── Condition B: Avoir 50M€ investis en R&D
└── Event: "Découverte scientifique" (rare, 1-2 niveaux max)
```
#### Progression "Métallurgie"
```
Base: Métaux de Base (toujours disponible)
Breakthrough "Aciers Spéciaux":
├── Condition A: Produire 1000t d'acier standard
├── Condition B: Construire 5 hauts fourneaux
└── Force: Scrap "Blindage de tank"
Breakthrough "Alliages Légers":
├── Condition A: Avoir Aciers Spéciaux + exporter 500t métal
├── Condition B: Designer véhicule nécessitant poids réduit
└── Force: Purchase "Alliage aéronautique"
Breakthrough "Matériaux Composites":
├── Condition A: 3 techs métallurgie + 2 techs chimie
├── Condition B: Commande client "véhicule ultra-léger"
└── Multiple forces: Scrap composite, reverse engineer, etc.
```
### Impacts Gameplay
#### Discovery Organique
- **Pas de tech tree** → player découvre par expérience
- **Gameplay naturel** → "Je produis → je découvre"
- **Surprise constante** → "Oh ! Nouvelle tech disponible !"
- **Emergent progression** → chaque partie unique
#### Companies IA
- **Même système** → IA découvre par leurs actions
- **Spécialisations naturelles** → Company "Metal" découvre métal faster
- **Compétition réaliste** → Qui découvre en premier ?
- **Tech transfer** → IA peut vendre breakthroughs au player
#### Event System
- **Breakthrough events** → découvertes aléatoires limitées (1-2 niveaux max)
- **Scientific conferences** → échange breakthroughs
- **Industrial espionage** → voler breakthroughs competitors
- **Government funding** → accélère découvertes civiles
### Interface Adaptée
#### Vue "Recherches Disponibles"
```
🔬 RECHERCHES DISPONIBLES
├── Acier Spécial (Métallurgie) - 100 unités fer + 50 charbon - 3 jours
├── Radar 1 (Capteurs) - 200 composants électroniques - 5 jours
└── Moteur Hybride (Propulsion) - 50 batteries + 2 moteurs - 7 jours
🎯 BREAKTHROUGHS PROCHES (conditions presque remplies)
├── Matériaux Composites - Recherche 1 tech chimie de plus (2/3)
├── IA Tactique - Construis 3 véhicules autonomes de plus (2/5)
└── Défenses Avancées - Produis 200 tourelles de plus (150/350)
💡 BREAKTHROUGH FORCÉ
├── Analyse Scrap: Tank T-72 → "Blindage Réactif" (coût: 5000€)
├── Reverse Engineer: GPS Civil → "Navigation Précise" (coût: 2000€)
└── Achat Intel: Thales → "Radar AESA" (coût: 50000€)
```
#### Découverte en Jeu
```
🎉 BREAKTHROUGH DÉCOUVERT !
"Matériaux Composites"
Débloqué grâce à: Production de 1000t d'acier + 3 techs chimie
Nouvelles recherches disponibles:
• Blindage Composite (15 jours, matériaux avancés)
• Châssis Ultra-Léger (10 jours, fibres carbone)
• Structures Adaptatives (20 jours, smart materials)
```
### Avantages Système
**Découverte naturelle** : Tech emerge du gameplay
**Pas d'overwhelm** : Seules techs pertinentes visibles
**Rejouabilité infinie** : Chaque run = découvertes différentes
**Économie innovation** : Marché des breakthroughs
**Emergent strategy** : Spécialisations naturelles
**Surprise constante** : Toujours de nouvelles possibilités
**Realistic progression** : Comme vraie R&D industrielle
**C'est EXACTEMENT le système qu'il faut pour 3000 techs !** 🔥
### Vue "Passerelles" (Séparée)
**But** : Montrer les **court-circuits possibles** depuis autres domaines
```
Tech Cible: "Châssis Composite"
Passerelles disponibles:
← Métallurgie : "Composites Avancés" → [PROTOTYPE] Châssis Composite
← Civil : "Matériaux Industriels" → [PROTOTYPE] Châssis Composite
← Énergie : "Matériaux Légers" → [PROTOTYPE] Châssis Composite
Status: 2/3 passerelles débloquées ✅
```
### Navigation Inter-Domaines
**Links intelligents** :
- Tech montre ses **dépendances externes** : "Nécessite: Électronique de Base"
- **Click** → switch automatique vers vue Électronique > Circuits de Base
- **Breadcrumb** : Métallurgie > Métaux de Base ← **Électronique > Circuits de Base**
### Vue "Action Immédiate" (Style Factorio)
**Focus** : "**QU'EST-CE QUE JE PEUX FAIRE MAINTENANT ?**"
**Structure verticale** :
```
🚀 RECHERCHES DISPONIBLES (Clique pour lancer)
├── Acier (Métallurgie) - 50 points tech - 2min
├── Radar 1 (Capteurs) - 75 points tech - 3min
├── Moteur Hybride (Propulsion) - 100 points tech - 5min
└── Béton Armé (Civil) - 25 points tech - 1min
🔬 BREAKTHROUGHS POSSIBLES (Via scrap/capture)
├── Explosifs Plastiques ← Scrap: RPG-7 (x3 disponible)
├── Blindage Composite ← Capture: Bradley M2
└── IA Tactique ← Scrap: Drone FPV (x12 disponible)
📚 DÉJÀ RECHERCHÉ (Masquer/Montrer)
├── ✅ Métaux de Base, Fer, Cuivre, Bronze...
├── ✅ Circuits de Base, Transistors, Processeurs...
├── ✅ Moteurs Diesel, Essence, Turbo...
└── [147 technologies researched] [Voir toutes ▼]
🔒 PAS ENCORE ACCESSIBLE
├── Radar 2 → Nécessite: Radar 1
├── Missiles Guidés → Nécessite: Électronique Avancée
└── Châssis Composite → Nécessite: Matériaux Composites
(ou PASSERELLE via Métallurgie Avancée)
```
**Priorité visuelle** :
- **ÉNORME** : Recherches disponibles (ce qu'il peut faire NOW)
- **Moyen** : Breakthroughs (opportunités spéciales)
- **Petit/Collapsé** : Déjà recherché (juste pour référence)
- **Gris** : Pas accessible (avec hints sur comment débloquer)
### Vue "Dashboard Personnel"
**Résumé progression** :
```
Domaines actifs:
🔬 Métallurgie [●●●○○] 12/20 techs recherchées
⚡ Électronique [●●○○○] 8/25 techs recherchées
🏗️ Châssis [●○○○○] 3/15 techs recherchées
Prochaines recommandations:
🎯 Acier (complète ta ligne Métaux)
🎯 Radar 1 (améliore tes drones)
🎯 Moteur Hybride (unlock Châssis Performance)
```
### Interface Principale : 2 Onglets
**🎯 Onglet "ACTION"** (Vue Action Immédiate)
- **Utilisation** : 80% du temps → "Qu'est-ce que je peux faire ?"
- **Layout** : Vertical, priorité visuelle sur le disponible
- **Click & Go** : Lancer recherche directement
**🌳 Onglet "EXPLORATION"** (Vue Arbre Linéaire)
- **Utilisation** : 20% du temps → "Où est-ce que je vais ?"
- **Layout** : Horizontal, focus sur progression
- **Planning** : Voir les chemins futurs
### Workflow Player Typique
1. **Ouvre l'onglet ACTION** → voit 4-6 recherches disponibles
2. **Lance une recherche** → continue à jouer
3. **Research terminée** → notification + retour onglet ACTION
4. **Nouvelles options** apparaissent → cycle continue
Occasionnellement :
- **Switch vers EXPLORATION** → "Hmm, comment j'arrive aux missiles ?"
- **Sélectionne racine "Armement"** → voit le chemin
- **Retour ACTION** → focus sur les étapes immédiates
### Avantages Système
**No overwhelm** : Player voit 5-15 techs max par vue
**Focus** : Progression claire dans un domaine
**Discovery** : Nouvelles techs révélées progressivement
**Flexibilité** : Peut explorer différentes racines
**Passerelles** : Vue séparée pour les court-circuits
**Context** : Toujours savoir où on en est
**Action immédiate** : 1 click = lancer recherche
**Style Factorio** : Interface familière et efficace
**C'est exactement l'UX qu'il faut pour 3000 techs !** 🎯
---
*Ce document sera complété avec les détails de chaque domaine technologique*

View File

@ -0,0 +1,874 @@
# Architecture Technique
## Vision Globale
**Concept** : RTS/4X hybride hommageant l'Ukraine avec système industriel complexe (Factorio-like), simulation militaire réaliste et gestion géopolitique.
**Innovation clé** : Architecture multi-serveurs modulaire permettant scaling horizontal et développement parallèle par IA.
## Architecture Système
### Structure Modulaire Multi-Serveurs
```
┌─────────────────────┐
│ Central Coordinator │ ← Meta orchestrator (bootstrap, health, lifecycle)
└─────────────────────┘
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ │ │ │ │ │ │ │ │ │ │
┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐
│Fact │ │Logic│ │Econ │ │Desig│ │Macro│ │ Map │ │Comb │ │Oper │ │Intel│ │Event│
│ory │ │istic│ │omy │ │ner │ │Enti │ │ │ at │ │ation│ │ li │ │
└─────┘ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘
│ │ │ │ │ │ │ │ │ │
└───────┼───────┼───────┼───────┼───────┼───────┼───────┼───────┼───────┘
│ │ │ │ │ │ │ │
┌─────────────────────────────────────────────────────────────┐
│ Clients │ ← Smart UI/Rendering, Authoritative Server
└─────────────────────────────────────────────────────────────┘
```
## Engines Autonomes
### Définition Autonomie
L'architecture repose sur 10 engines autonomes communicant via APIs standardisées, chacun responsable d'un domaine spécifique du gameplay.
**Autonome signifie** :
- ✅ **Logique métier** : Calculs, décisions, algorithmes dans son domaine
- ✅ **State persistence** : Gère ses données en mémoire/disque
- ✅ **Graceful degradation** : Continue de fonctionner si autres engines down
- ✅ **Independent scaling** : Peut être optimisé/étendu séparément
**Autonome ne signifie PAS** :
- ❌ **Infrastructure isolée** : Utilise services communs (metrics, health, config)
- ❌ **Communication zero** : Échange données via Redis/HTTP selon besoins
- ❌ **No dependencies** : Utilise données d'autres engines (prix, terrain, etc.)
**Timing interactions** :
- **Critique temps réel** : Direct HTTP GET (ex: War Engine → Map Engine terrain)
- **Background sync** : Redis Pub/Sub async (ex: Economy → tous engines prix)
- **Infrastructure services** : HTTP à demande (ex: Intelligence Engine métriques)
### Vue d'ensemble Engines
### Factory Engine
- **Responsabilité** : Systèmes Factorio du joueur uniquement
- **Scope** : Mining, production, assemblage, infrastructures joueur
- **Autonomie** : Simulation complète des usines joueur
- **Communication** : Export données production vers Logistic Engine
### Logistic Engine
- **Responsabilité** : Flux physiques et virtuels de ressources
- **Scope** : Transport, supply chains, FOBs militaires, distribution
- **Autonomie** : Gestion complète des mouvements de biens
- **Communication** : Interface avec Factory, Economy et Combat Engines
### Economy Engine
- **Responsabilité** : Usines IA, marchés, prix dynamiques
- **Scope** : Productions IA, company behaviors, marchés segmentés
- **Autonomie** : Simulation économique globale indépendante
- **Communication** : Prix/demandes vers tous engines consommateurs
### Designer System Engine
- **Responsabilité** : Design véhicules procédural pour IA + assistance joueur
- **Scope** :
- Design procédural IA : random generation + evaluate + pass/drop
- Assistance design joueur : même système utilisable manuellement
- Blueprints doctrinaux : grilles efficaces, designs dev, captures enemy
- Modification designs existants vs création from scratch
- **Autonomie** :
- Engine autonome répondant aux commandes joueur + IA
- Random ticking génération avec évaluation viabilité basique
- Company features influencent choix procéduraux
- **Évaluation Designs** :
- Check stats sur CDC théorique ("design viable ?")
- Détection automatique designs défaillants (tank 1km/h = reject)
- Long-term : Retex spécifiques d'Operation Engine (anti-Javelin urbain)
- Future : Combat simulations via War Engine
- **Communication** :
- Reçoit demandes Operation Engine + joueur
- Nouveaux designs vers Economy et War Engines
- Blueprints évolutifs inter-companies (captures)
- **Spécialité** : Inclut système de recherche dual et breakthroughs
### MacroEntity Engine (Company & State)
- **Responsabilité** : Entités (companies, états), diplomatie, points administration
- **Scope** :
- Features companies, relations, politiques commerciales
- Système points administration pour companies et états
- Actions coûtant admin : recherche, commerce, diplomatie, production, militaire
- **Autonomie** : Comportements entités, évolution features, gestion pools admin quotidiens
- **Communication** : Commandes vers Economy, restrictions vers tous engines
- **Points Administration** :
- Pool quotidien companies (1000 base) et états (variable selon taille)
- Actions bloquées si admin exhausté (pas de queue, refus immédiat)
- Modificateurs via company features et contexte (guerre, récession)
- Calculs légers, batch processing, rythme bas adapté gameplay macro
### Map Engine
- **Responsabilité** : Gestion carte, streaming, génération
- **Scope** : Chunks, FOW, navigation, terrain procedural
- **Autonomie** : Génération à la demande, optimisation mémoire
- **Communication** : Données terrain vers Combat et Factory Engines
### Combat Engine (War Engine)
- **Responsabilité** : Auto-battler tactique avec stocks embarqués
- **Scope** :
- Batailles temps réel avec ~500 unités actives simultanées
- Last meter logistics (camions, dépôts locaux, 3km radius)
- Stocks munitions/carburant dans véhicules et dépôts tactiques
- Zones trigger pour défense automatique
- **Autonomie** :
- Self-contained avec propres stocks et round de commande
- Unités agissent avec derniers ordres reçus si communication coupée
- Gestion autonome logistique courte distance
- **Communication** :
- Reports situation brute vers Operation Engine (pull par waves)
- Intel bâtiments vers Intelligence Engine
- Demandes resupply vers Logistic Engine (longue distance)
- Updates Economy Engine post-bataille (délai acceptable ~1 minute)
### Operation Engine
- **Responsabilité** : IA militaire décisionnelle et coordination organisationnelle
- **Scope** :
- Analyse rapports War Engine pour "comprendre" situations (méthode TBD)
- Génération ordres tactiques et stratégiques
- Coordination avec politique via Economy Engine
- Doctrines militaires différenciées par nation/company
- **Autonomie** :
- Vraie IA militaire (analyse, compréhension, décision)
- Peut créer latence décisionnelle réaliste (France 1940)
- Gestion orders de bataille (test → attaque → exploitation)
- **Machine Learning Simple** :
- Apprentissage tactiques efficaces par contexte/terrain/véhicules
- Retex par général avec influence modèles nationaux (doctrines)
- Évolution doctrinale lente vs apprentissage général rapide
- Résistance convergence par diversité tech/armes semi-random
- **Coordination Politique** :
- Reçoit objectifs stratégiques du politique (Economy Engine)
- Politique peut override directions militaires
- Adaptation militaire aux contraintes politiques
- **Communication** :
- Reçoit reports du War Engine
- Envoie ordres au War Engine
- Reçoit objectifs stratégiques Economy Engine
- Demandes intel à Intelligence Engine
### Intelligence Engine
- **Responsabilité** : Reconnaissance, espionnage, fog of war, métriques économiques
- **Scope** : Satellites, intel gathering, information warfare, collecte métriques
- **Autonomie** : Collecte et analyse renseignements, agrégation data économique
- **Communication** : Intel vers Operation et Company Engines
- **Métriques multijoueur** : Scaling adaptatif selon nombre companies, data sharing intelligent
### Event Engine
- **Responsabilité** : Événements aléatoires, crises, disruptions
- **Scope** : Wars, breakthroughs, economic crashes, endgame crisis
- **Autonomie** : Déclenchement et gestion événements contextuels
- **Communication** : Trigger events vers engines concernés
## Architecture Communication Inter-Engines
### Stack Technique
- **Redis Pub/Sub** : Communication asynchrone événementielle (pull par waves)
- **HTTP REST** : Queries synchrones et commands
- **JSON** : Format d'échange uniforme
- **TCP** : Reliability pour données critiques
### Principe de Communication
- **War Engine** : Self-contained, pulls par waves (évite spam messages)
- **Latence assumée** : Délais logistiques intégrés au gameplay (réalisme)
- **Autonomie engines** : Continuent à fonctionner avec dernières données reçues
- **Reports non temps réel** : Economy updates acceptent délais 1+ minute
### Patterns Redis par Engine
#### Factory Engine
**PUBLISHES** :
```
factory:production_complete → Economy, Logistic
factory:shutdown → Logistic, Map
factory:resource_request → Economy, Logistic
factory:blueprint_test → Designer
```
**SUBSCRIBES** :
```
economy:price_update ← Economy
logistic:resource_available ← Logistic
designer:blueprint_ready ← Designer
```
#### Economy Engine
**PUBLISHES** :
```
economy:price_update → Factory, Combat, Logistic
economy:market_crash → ALL
economy:company_bankrupt → Company&State, Map
economy:resource_shortage → Factory, Logistic
```
**SUBSCRIBES** :
```
factory:production_complete ← Factory
combat:battle_result ← Combat
logistic:transport_complete ← Logistic
company:order_placed ← Company&State
```
#### Combat Engine
**PUBLISHES** :
```
combat:battle_start → Economy, Map, Intelligence
combat:battle_result → Economy, Map, Intelligence, Operation
combat:unit_destroyed → Economy, Logistic
combat:resource_consumed → Economy, Logistic
```
**SUBSCRIBES** :
```
economy:price_update ← Economy
logistic:supply_delivered ← Logistic
operation:battle_order ← Operation
intelligence:enemy_spotted ← Intelligence
```
#### Map Engine
**PUBLISHES** :
```
map:territory_change → ALL
map:resource_discovered → Economy, Factory
map:terrain_updated → Combat, Logistic
map:fog_revealed → Intelligence, Operation
```
**SUBSCRIBES** :
```
factory:shutdown ← Factory
combat:battle_result ← Combat
intelligence:recon_complete ← Intelligence
```
#### Logistic Engine
**PUBLISHES** :
```
logistic:transport_complete → Economy, Factory
logistic:supply_delivered → Combat
logistic:resource_available → Factory
logistic:convoy_attacked → Combat, Economy
```
**SUBSCRIBES** :
```
factory:production_complete ← Factory
combat:resource_consumed ← Combat
economy:resource_shortage ← Economy
map:terrain_updated ← Map
```
#### Designer Engine
**PUBLISHES** :
```
designer:blueprint_ready → Factory, Economy
designer:tech_breakthrough → ALL
designer:design_validated → Economy, Combat
```
**SUBSCRIBES** :
```
factory:blueprint_test ← Factory
combat:performance_data ← Combat
economy:market_demand ← Economy
```
#### MacroEntity Engine (Company & State)
**PUBLISHES** :
```
macroentity:order_placed → Economy
macroentity:feature_changed → Economy, Designer
macroentity:diplomatic_action → ALL
macroentity:policy_change → Economy, Map
macroentity:admin_exhausted → Economy (action refusée)
```
**SUBSCRIBES** :
```
economy:company_bankrupt ← Economy
combat:battle_result ← Combat
event:crisis_triggered ← Event
economy:action_request ← Economy (check admin disponible)
```
#### Operation Engine
**PUBLISHES** :
```
operation:battle_order → War Engine
operation:strategy_change → War Engine, Logistic
operation:target_selected → War Engine, Intelligence
operation:resupply_request → Logistic
```
**SUBSCRIBES** :
```
war:situation_report ← War Engine (pull par waves)
intelligence:intel_update ← Intelligence
economy:political_directive ← Economy (political coordination)
```
#### War Engine (Combat Engine)
**PUBLISHES** :
```
war:situation_report → Operation Engine (waves, non temps réel)
war:building_discovered → Intelligence
war:resupply_needed → Logistic
war:battle_complete → Economy (délai 1+ min acceptable)
```
**SUBSCRIBES** :
```
operation:battle_order ← Operation Engine
logistic:supply_delivered ← Logistic (long distance resupply)
map:terrain_updated ← Map
```
#### Intelligence Engine
**PUBLISHES** :
```
intelligence:enemy_spotted → Combat, Operation
intelligence:intel_update → Operation, Company&State
intelligence:recon_complete → Map, Operation
```
**SUBSCRIBES** :
```
combat:battle_start ← Combat
map:fog_revealed ← Map
```
#### Event Engine
**PUBLISHES** :
```
event:crisis_triggered → ALL
event:breakthrough_event → Designer, Economy
event:diplomatic_crisis → Company&State
```
**SUBSCRIBES** :
```
(Monitore all channels pour trigger contextuel)
```
### APIs HTTP Standardisées
#### Format URL Standard
```
http://{engine-name}:808{N}/{endpoint}
Ports :
factory:8080, economy:8081, combat:8082, map:8083
logistic:8084, designer:8085, macroentity:8086, operation:8087
intelligence:8088, event:8089
```
#### Endpoints Communs (tous engines)
```
GET /health → Health check
GET /status → État général engine
GET /metrics → Métriques performance
POST /shutdown → Arrêt propre engine
```
#### Endpoints Spécifiques par Engine
**Factory Engine** :
```
GET /factories → Liste usines actives
GET /factories/{id} → Détails usine
POST /factories/{id}/start → Démarrer production
POST /factories/{id}/stop → Arrêter production
GET /production/queue → Queue production
POST /blueprints/validate → Valider blueprint
```
**Economy Engine** :
```
GET /prices → Prix actuels toutes ressources
GET /prices/{resource} → Prix ressource spécifique
GET /market/demand → Demande par ressource
GET /companies → Liste companies actives
POST /orders → Placer commande
```
**Combat Engine** :
```
GET /battles/active → Batailles en cours
POST /battles/start → Démarrer bataille
GET /units/status → Status toutes unités
POST /units/{id}/order → Donner ordre unité
```
### Format JSON Uniforme
#### Structure Standard Message
```json
{
"timestamp": "2024-03-15T14:30:00Z",
"source_engine": "factory",
"target_engines": ["economy", "logistic"],
"event_type": "production_complete",
"sequence_id": 12345,
"data": {
"factory_id": "fact_001",
"produced_item": "steel_plate",
"quantity": 100,
"quality": 85
},
"metadata": {
"priority": "normal",
"retry_count": 0
}
}
```
#### Format HTTP Response Standard
```json
{
"success": true,
"timestamp": "2024-03-15T14:30:00Z",
"engine": "economy",
"data": {
"steel_price": 45.0,
"trend": "increasing"
},
"error": null,
"execution_time_ms": 23
}
```
#### Format Error Standard
```json
{
"success": false,
"timestamp": "2024-03-15T14:30:00Z",
"engine": "combat",
"data": null,
"error": {
"code": "UNIT_NOT_FOUND",
"message": "Unit with ID unit_123 not found",
"details": {
"unit_id": "unit_123",
"requested_action": "move"
}
},
"execution_time_ms": 5
}
```
### Flux de Données Critiques
```
Factory Engine → Economy/Logistic : Production outputs
Economy Engine → ALL : Prix et demandes
Designer Engine → Economy/Combat : Nouveaux designs
Intelligence Engine → Operation : Reconnaissance data
Event Engine → ALL : Crisis triggers
Map Engine → Combat/Factory : Terrain data
Operation Engine → Combat : Battle orders
Combat Engine → Economy/Map : Battle results
```
## Error Handling & Reliability
### Engine Crash/Restart Strategy
**Detection rapide de crash**
```
Health check HTTP: GET /health toutes les 30 secondes
Redis heartbeat: PUBLISH engine:heartbeat {"engine": "factory", "timestamp": "..."}
Timeout detection: Si pas de heartbeat depuis 60s = engine down
```
**Recovery automatique**
```
Engine redémarre → republish état current dans Redis
Example: Factory Engine restart → PUBLISH factory:status {"active_productions": [...]}
Autres engines reçoivent l'update et ajustent leur état local
```
**Graceful degradation**
```cpp
// Dans chaque engine
if (!canReachEngine("economy")) {
// Utiliser derniers prix connus en cache
price = fallbackPriceCache.get(resource);
logWarning("Using cached price, Economy engine unreachable");
}
```
### Redis Failover Strategy
**Redis persistence activée**
```
# Configuration Redis
save 900 1 # Save snapshot if 1+ keys changed in 15min
appendonly yes # Log toutes les commandes
```
**Multiple Redis instances** (plus tard)
```
Primary Redis: 6379 (read/write)
Replica Redis: 6380 (read-only backup)
Si primary down → engines switch automatiquement vers replica
```
**Message replay après Redis restart**
```
Chaque engine garde buffer local des derniers messages
Engine restart → replay buffer vers Redis pour resync
```
### Circuit Breaker Pattern
**Éviter cascade failures**
```cpp
class EngineCircuitBreaker {
int failureCount = 0;
bool isOpen = false;
bool callEngine(string endpoint) {
if (isOpen && failureCount > 5) {
return false; // Circuit ouvert, pas d'appel
}
if (httpCall(endpoint).success()) {
failureCount = 0; // Reset sur succès
return true;
} else {
failureCount++;
if (failureCount > 5) isOpen = true;
return false;
}
}
}
```
### Message Persistence & Replay
**Event sourcing basique**
```
Redis streams pour persistence:
XADD events:factory * engine factory event production_complete data {...}
XADD events:combat * engine combat event battle_end data {...}
Recovery: XREAD depuis last timestamp connu
```
**State snapshots**
```
Chaque engine sauvegarde état complet périodiquement:
HSET snapshots:factory:1234567890 state "{...complete_state...}"
Recovery = load last snapshot + replay events depuis timestamp
```
### Timeout & Retry Strategy
**HTTP calls avec timeouts**
```cpp
HttpConfig config {
.connectionTimeout = 5000ms, // 5s pour établir connection
.requestTimeout = 10000ms, // 10s pour réponse complète
.retryCount = 3,
.retryDelay = 1000ms
};
```
**Redis operations timeouts**
```cpp
RedisConfig config {
.commandTimeout = 2000ms, // 2s max par commande Redis
.reconnectRetryInterval = 5000ms
};
```
### Health Check System
**Endpoint standard pour tous engines**
```json
GET /health
Response:
{
"status": "healthy|degraded|unhealthy",
"dependencies": {
"redis": "connected",
"other_engines": ["factory:healthy", "economy:degraded"]
},
"metrics": {
"uptime": 3600,
"requests_per_second": 45,
"error_rate": 0.02
}
}
```
**Central monitoring simple**
```
Script qui poll /health de tous engines toutes les 30s
Log les status changes
Alert si engine down > 2 minutes
```
## Détails des Engines
### Factory Engine
- **Responsabilité** : Systèmes Factorio du joueur uniquement
- **Scope** : Mining, production, assemblage, infrastructures joueur
- **Autonomie** : Simulation complète des usines joueur
- **Communication** : Export données production vers Logistic Engine
- **Innovation** : Factory benchmarking → conversion stable factories en lookup tables
- **Performance** : Unload simulation détaillée après stabilisation
### Logistic Engine
- **Responsabilité** : Flux physiques et virtuels de ressources
- **Scope** : Transport, supply chains, FOBs militaires, distribution
- **Autonomie** : Gestion complète des mouvements de biens
- **Communication** : Interface avec Factory, Economy et Combat Engines
- **Features** : Transport multi-modal (camions, trains, avions, drones, navires)
- **Vulnérabilités** : Convois attaquables, infrastructure destructible
### Economy Engine
- **Responsabilité** : Usines IA, marchés, prix dynamiques
- **Scope** : Productions IA, company behaviors, marchés segmentés
- **Autonomie** : Simulation économique globale indépendante
- **Communication** : Prix/demandes vers tous engines consommateurs
- **Features** : Système économique réactif aux événements militaires
- **Marchés** : National, company-specific, blocs, mondial avec restrictions
### Designer System Engine
- **Responsabilité** : Conception IA de véhicules et équipements
- **Scope** : Algorithmes design, validation, recherche technologique
- **Autonomie** : Processus design distribué, cultural blueprints
- **Communication** : Nouveaux designs vers Economy et Combat Engines
- **Spécialité** : Inclut système de recherche dual et breakthroughs
- **Performance** : 1-2 designs créés globalement par tick (total mondial, pas par company), évolution vs création from scratch
### MacroEntity Engine (Company & State)
- **Responsabilité** : Entités (companies, états), diplomatie, points administration
- **Scope** : Features companies, relations, politiques commerciales, système admin
- **Autonomie** : Comportements entités, évolution features, gestion admin pools
- **Communication** : Commandes vers Economy, restrictions vers tous
- **Features** : Système 2-4 features par company, évolution dynamique
- **Diplomatie** : Relations internationales, sanctions, embargos
- **Administration** : Pool quotidien, actions bloquées si exhausté, modificateurs contextuels
### Map Engine
- **Responsabilité** : Gestion carte, streaming, génération
- **Scope** : Chunks, FOW, navigation, terrain procedural
- **Autonomie** : Génération à la demande, optimisation mémoire
- **Communication** : Données terrain vers Combat et Factory Engines
- **Système** : Zoom discret (global + local 1mx1m), chunks 64x64
- **Navigation** : Node-based pour terrestre, libre pour aérien
### Combat Engine
- **Responsabilité** : Batailles temps réel, IA militaire
- **Scope** : Unités, doctrines, combats locaux
- **Autonomie** : Simulations tactiques indépendantes
- **Communication** : Résultats vers Map et Logistic Engines
- **Performance** : Adaptive tick rate (60→15 TPS sous charge)
- **Features** : Actions normales (assaut, reco, soutien, etc.)
### Operation Engine
- **Responsabilité** : Opérations militaires, généraux IA
- **Scope** : Stratégie macro, AI decision making, planning
- **Autonomie** : Prise de décision stratégique autonome
- **Communication** : Ordres vers Combat Engine, demandes vers Logistic
- **Features** : Généraux avec ML, doctrines, expérience terrain
- **IA** : Adaptation comportements selon succès/échecs
### Intelligence Engine
- **Responsabilité** : Reconnaissance, espionnage, fog of war
- **Scope** : Satellites, intel gathering, information warfare
- **Autonomie** : Collecte et analyse renseignements
- **Communication** : Intel vers Operation et Company Engines
- **Système** : FOW par chunks, qualité reconnaissance progressive
- **Persistance** : Mémoire intel par actor, expiration possible
### Event Engine
- **Responsabilité** : Événements aléatoires, crises, disruptions
- **Scope** : Wars, breakthroughs, economic crashes, endgame crisis
- **Autonomie** : Déclenchement et gestion événements contextuels
- **Communication** : Trigger events vers engines concernés
- **Features** : 3 endgames (zombies, aliens, démons), events géopolitiques
- **Probabilités** : Events égales entre companies, adaptation contextuelle
### Central Coordinator
- **Fonction** : Meta orchestrator - bootstrap, health monitoring, lifecycle management
- **Scope ultra-limité** :
- Lancement engines + load map/gameset initial
- Health ping engines (pas leur contenu)
- Time sync basique si nécessaire
- Graceful shutdown + unload map (quit partie)
- **Aveugle au gameplay** : Ne connaît rien des mécaniques de jeu, pure infrastructure
- **Post-bootstrap** : Engines communiquent directement via Redis, coordinator passif
- **Crash-safe** : Coordinator down = invisible pour gameplay, engines continuent autonomes
## Décisions Techniques Clés
### 1. Performance Stack
- **Langages** : C++ / C / ASM pour performance critique
- **Justification** : Simulation temps réel complexe + milliers d'unités
- **Compromise** : Complexité dev acceptable vs performance requirements
### 2. Synchronisation Multijoueur
- **Problème** : Déterminisme impossible avec multi-serveurs
- **Solution** : Server-authoritative + error-resilient design
- **Approach** : Graceful degradation + periodic sync + rollback capability
### 3. Smart Client / Authoritative Server
- **Client Smart** : Interface complexe, rendu optimisé, streaming carte, cache local
- **Client Dumb** : Aucune simulation gameplay, pas de logique métier
- **Server Authoritative** : Toute simulation et état de jeu sur serveurs
- **Avantages** : Anti-cheat naturel, interface réactive, pas de sync client-side
- **Trade-off** : Latency interactions vs sécurité et cohérence
### 4. Async Gameplay Design
- **Principe** : Combat peut avoir latence, player gère autre chose
- **Implémentation** : Background processing pendant que player fait diplo/éco
- **Exemple** : Bataille 10k unités = 30 secondes → player continue production
## Optimisations Performance
### Load Management
- **Adaptive Tick Rate** : 60 TPS → 15 TPS si surcharge
- **Queue Systems** : Batch processing pour opérations coûteuses
- **Future Scaling** : Clustering dynamique per module
## Workflow Développement
### IA-Assisted Development
- **Claude Code #1** → Factory Engine + Logistic Engine
- **Claude Code #2** → Combat Engine + Operation Engine
- **Claude Code #3** → Economy Engine + Designer Engine
- **Claude Code #4** → MacroEntity Engine + Intelligence Engine
- **Claude Code #5** → Map Engine + Event Engine
- **Humain** → Central Coordinator + architecture globale + vision produit
### Principe Modulaire pour IA
- **Self-contained modules** → Claude peut "faire du spagos" dans sa boîte
- **Clean APIs** → interfaces claires entre modules
- **Isolation** → bugs dans un module n'affectent pas les autres
## Repository Structure
```
Ukraine-War-Game/ # Meta-repository
├── Factory-Engine/ # Git submodule
├── Logistic-Engine/ # Git submodule
├── Economy-Engine/ # Git submodule
├── Designer-Engine/ # Git submodule
├── MacroEntity-Engine/ # Git submodule
├── Map-Engine/ # Git submodule
├── Combat-Engine/ # Git submodule
├── Operation-Engine/ # Git submodule
├── Intelligence-Engine/ # Git submodule
├── Event-Engine/ # Git submodule
├── Client-Renderer/ # Git submodule
├── Central-Coordinator/ # Git submodule
├── shared/ # Protocols & configs communs
│ ├── engine-apis/ # Interface contracts entre engines
│ ├── message-schemas/ # Format des messages inter-engines
│ └── event-definitions/ # Types d'événements standardisés
├── docs/ # Documentation architecture
├── scripts/ # Dev tools (build-all, deploy)
└── docker/ # Dev environment setup
```
## Scalabilité Future
### Clustering Capability
- **Current** : 1 serveur par module
- **Future** : N serveurs per module avec load balancing
- **Implementation** : Kubernetes orchestration + auto-scaling
### Performance Monitoring
- **Health Checks** : Inter-server communication monitoring
- **Metrics** : Tick rates, queue sizes, response times
- **Alerting** : Auto-failover + human notifications
## Considérations Multijoueur
### Sync Strategy
- **Error-Resilient** : Accept temporary inconsistencies
- **Periodic Reconciliation** : Checkpoints + state correction
- **Conflict Resolution** : Server priority rules + rollback capability
### Network Architecture
- **Server-to-Server** : Reliable message queues (Redis/RabbitMQ)
- **Client-to-Server** : Standard TCP/WebSocket
- **Client Responsibilities** :
- Rendu 2D pixel art avec LOD et culling
- Interface utilisateur complexe (industrielle, militaire, diplomatique)
- Streaming carte intelligent (zoom, position, cache zones explorées)
- Cache local pour performance UI
- **Server Authority** : Simulation, logique métier, état de jeu
- **Bandwidth** : Clients reçoivent state updates, n'envoient que commands
## Art Direction & Rendering
### Style Visuel : Pixel Art
- **Justification** : Prototypage rapide, génération par IA (Claude), performance optimale
- **Aesthetic** : Factorio-like, RTS classique, lisibilité maximale
- **Avantages développement** :
- Claude capable de générer sprites cohérents par batch
- Itération rapide sur feedback visuel
- Pas de complexité 3D/animation
- Style intemporel et scalable
### Spécifications Assets
- **Véhicules** : 32x32 pixels (chars, IFV, drones)
- **Bâtiments** : 64x64 pixels (usines, défenses)
- **Terrain** : Tiles 32x32 (sol, routes, végétation)
- **UI Elements** : Pixel perfect, zoom discret (1x, 2x, 4x)
- **Color Palette** : Limitée pour cohérence (à définir selon contexte Ukraine)
## Roadmap Technique
### Phase 1 : Core Engines MVP
- [ ] Factory Engine (mining + production basique)
- [ ] Economy Engine (resources tracking)
- [ ] Map Engine (chunks + navigation basique)
- [ ] Client renderer pixel art (tech stack TBD)
### Phase 2 : Multi-Engine Integration
- [ ] Central Coordinator implementation
- [ ] Inter-engine communication protocols (message queues)
- [ ] Logistic Engine (transport basique)
- [ ] Combat Engine (unit battles simple)
### Phase 3 : Advanced Engines
- [ ] Designer Engine (IA vehicle conception)
- [ ] MacroEntity Engine (entities + diplomatie + administration)
- [ ] Operation Engine (généraux IA)
- [ ] Intelligence Engine (FOW + reconnaissance)
### Phase 4 : Complete System
- [ ] Event Engine (crises + événements)
- [ ] Factory benchmarking system
- [ ] Performance optimizations (adaptive tick rate)
- [ ] Endgame crisis implementations
## Notes de Conception
### Pragmatisme vs Perfection
- **Principle** : Ship working system > perfect architecture
- **Error Strategy** : Resilient design > error-free design
- **Performance** : Good enough > premature optimization
### Hommage Ukraine
- **Lore** : Guerre réelle comme base narrative
- **Valeurs** : Mettre en avant courage et liberté ukrainiens
- **Authenticity** : Systèmes militaires basés sur conflit réel
---
**"Ave Machina, guide my development !"** ⚙️🇺🇦

View File

@ -0,0 +1,486 @@
# 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
**Système réel déjà documenté** :
- **Prerequisites gating** : Seules 10-50 techs éligibles simultanément (pas 3000)
- **Player pas censé tout rechercher** : Focus spécialisations comme dans jeux réels
- **Interface proven** : Factorio gère 100+ techs successfully
- **Design adaptatif** : UI peut temporairement montrer plus lors breakthroughs majeurs
**Statut** : Doublon de problème déjà résolu en P18.
## Conclusions
### Analyse Complète Terminée
**30 problèmes identifiés** analysés et résolus :
- **8 problèmes réels résolus** (P7, P8, P10, P16, P17, P18, P21, P22, P23)
- **11 problèmes invalidés** par clarifications (P1, P2, P3, P4, P5, P6, P9, P11, P12, P13, P14, P15, P19, P20, P24, P26, P27, P28, P29, P30)
- **3 doublons éliminés** (P25=P20, P30=P18)
### État de Cohérence Actuel
**Documentation cohérente** : La majorité des "problèmes" provenaient de :
- **Mauvaises lectures** de spécifications techniques
- **Assumptions incorrectes** sur l'architecture
- **Incompréhensions** des systèmes de jeu
- **Manque de contextualisation** cross-système
### Améliorations Apportées
- **Clarifications architecturales** : Engines, autonomie, performance
- **Expansion génération procédurale** : 218 éléments, budget -10/+10
- **Précisions timing** : Administration, métriques, breakthrough
- **Interface design** : Spécifications UI complétées
- **Cross-références** : Liens entre systèmes établis
**Verdict final** : **Projet techniquement viable** avec documentation maintenant cohérente.
## Actions de Suivi
### Problèmes Restants à Traiter
**P7** : Responsabilités engines → Continuer analyse architecture (identifié comme réel)
### Prochaines Étapes Documentation
1. **Validation technique** : Review implémentation faisabilité
2. **Tests cohérence** : Vérification cross-système
3. **Mise à jour références** : Synchronisation entre docs
### Recommandations
- **Documentation technique** : Maintenant solide et cohérente
- **Implémentation** : Aucun blocage majeur identifié
- **Design** : Systèmes compatibles et réalisables

View File

@ -0,0 +1,100 @@
# Contexte narratif
## Inspiration Ukraine
### Motivation morale
L'Ukraine parce qu'ils sont des héros, parce qu'ils meurent pour leur liberté et pour la nôtre. Sachant ce que je sais aujourd'hui, j'ai l'obligation morale de mettre en avant leur combat et leur valeur.
Je l'oublie parfois mais la conclusion s'impose systématiquement.
### Justification artistique
Effectivement il serait plus simple de faire un monde généré procéduralement ou whatever mais à travers l'art (ce JV) l'imaginaire collectif doit se souvenir qu'il y a des gens qui meurent pour leur liberté.
De ce point de vue là, je pense qu'il devient injustifiable de drop l'Ukraine.
### Origine du concept
Sans parler que c'est de leur combat qu'a été le concept de ce jeu. Je leur dois ce jeu et ma liberté à "faible prix (relativement parlant)" peut-être autant qu'à mes ancêtres.
**SLAVA UKRAINI !**
## Lore géopolitique
### Contexte géopolitique
**Les russes les méchants c'est sûr !**
**Scénarios géopolitiques** :
- Une victoire russe en Ukraine provoque une agression chinoise sur Taiwan
- Une victoire russe en Ukraine prépare les prochains conflits en Europe
### Intégration du lore réel
Le lore IRL doit être intégré autant que possible sans être overwhelming.
### Problématique nucléaire
**Les nukes** :
Nations → nukes → utilisations ? → c'est chiant
## Terrain de combat PMC
### Zones d'opération
- Amérique du Sud dans les zones peu peuplées
- Madagascar
- Afrique
- Ouest de la Chine
- Russie
- Moyen-Orient
## Scénarios de crise (Endgame Crisis)
Au moins trois options avec leurs propres conséquences, mécaniques et variations.
### 1. Zombie Apocalypse (militaire)
**Défi principal** : Être surtout très rapide pour neutraliser les menaces quand elles apparaissent et de tenir les lignes si la manœuvre a échoué.
**Types d'invasion** :
- **Romero zombie** : lent mais solide
- **Fast zombie** : rapide mais fragile
- **Bunny zombie** : Il saute c'est très fort mais très fragile
- **Classique + spéciaux**
**Objectifs** :
- Garder le plus de gens en vie possible
- Trouver le(s) laboratoire(s) d'origine
- Y établir une base
- Rechercher le vaccin
### 2. Invasion ET (militaire)
**Caractéristiques de l'ennemi** :
- Technologie supérieure et très aérienne
- Résolument hostile
- Plusieurs stratégies possibles
**Axes stratégiques possibles** :
- Destruction des systèmes énergétiques
- Destruction des assets navals
- Invasion des points stratégiques
**Objectifs** :
- Surtout survivre
- La survie des états peut donner un sacré boost sur la défense planétaire
- Pour les vaincre il faut détruire le vaisseau mère ainsi que toutes les Ancres aliennes sur la planète
### 3. Demon Portal Invasion (militaire)
**Mécaniques** :
- Impossible de savoir où le portail suivant va s'ouvrir
- Il faut être prêt à agir vite et fort pour détruire les portails qui laisseront rentrer des démons tant qu'ils ne seront pas détruits
**Stratégie ennemie** :
- Les démons ayant pour objectif de tout détruire
- La plupart des ouvertures de portail se feront dans les villes pour occasionner un max de dégâts
**Mécaniques de pression** :
- C'est la course pour éviter les victimes
- Si trop de victimes → appelle des démons majeurs
- Et puis du démon mangeur de monde
## Inspiration choix géopolitiques
Peut-être s'inspirer d'Undertale pour la partie choix géopolitique.

15
docs/global/dlc-prevus.md Normal file
View File

@ -0,0 +1,15 @@
# DLC Prévus
## Inspiration RimWorld
Le projet prévoit des extensions inspirées des DLC de RimWorld :
### DLC Planifiés
- **Anomaly** - *À définir*
- **Biotech** - *À définir*
- **Ideology** - *À définir*
- **Odyssey** - *À définir*
---
*Détails et mécaniques à développer ultérieurement*

View File

@ -0,0 +1,347 @@
# Économie et Logistique
## Vue d'ensemble
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.
## Acteurs Économiques
### Companies privées
- **Joueur** : Company initiale avec avantage technologique (Factorio-like)
- **Multinationales** : Thales, Dassault, Lockheed Martin, etc.
- **Concurrents IA** : Companies générées avec productions automatisées
- **Coûts opérationnels** : Workers + salaires pour companies IA vs électricité seule joueur
### Système de Features Company
**Principe** : Chaque company IA a 2-4 features qui définissent ses capacités et spécialisations
#### Types de Features
**Domaines de production** :
- **Metal** : Métallurgie, alliages, structures métalliques
- **Electronic** : Circuits, capteurs, processeurs, systèmes avancés
- **Tank** : Véhicules blindés, systèmes de combat terrestre
- **Plane** : Aéronautique, avionique, systèmes volants
- **Wood** : Foresterie, produits bois, dérivés organiques
- **Food** : Agro-alimentaire, bio-ressources
- **Engine** : Moteurs, propulsion, systèmes mécaniques
- **Cannon** : Armement direct, artillerie, systèmes balistiques
- **Missile** : Armement guidé, roquettes, systèmes de navigation
**Modificateurs de qualité** :
- **Quality** : Production haut de gamme, précision, durabilité
- **Quantity** : Production de masse, efficacité volume
- **Speed** : Production rapide, délais courts
- **Cost** : Production économique, optimisation prix
- **Modularity** : Designs modulaires, adaptabilité, standardisation
- **Innovation** : R&D focus, breakthrough technologies, expérimentation
**Autres propositions** :
- **Stealth** : Furtivité, signature réduite, camouflage
- **Repair** : Maintenance, reconstruction, durabilité terrain
- **Transport** : Logistique, mobilité, capacité transport
- **Communication** : Réseaux, coordination, guerre électronique
#### Exemples de Companies
**"Metal, Plane, Quantity, Electronic"** :
- Produit : Avions métalliques en masse avec électronique embarquée
- Avantages : Volume, intégration complète, coûts optimisés
- Faiblesses : Peut-être moins de raffinement qu'un spécialiste qualité
**"Tank, Quality"** :
- Produit : Chars haut de gamme, précision d'assemblage
- Limites : Doit acheter électronique sur marchés externes
- Dépendances : Supply chain complexe pour composants non-maîtrisés
#### Dynamiques des Features
**Influence sur recherche** :
- **Features → Research paths** : Capacités influencent fortement directions R&D
- **Synergies via tech** : "Metal + Tank" unlock recherches blindage spécialisées
- **Pas d'exclusions strictes** : Features coexistent, synergies via recherche
**Évolution des Companies** :
- **Mortalité** : Companies peuvent disparaître (exemple : "Food + Tank" = dispersion fatale)
- **Naissance** : Nouvelles companies selon besoins contextuels
- **Changement features** : Possible aléatoirement en descente financière
- **Acquisition** : Events aléatoires permettent gain nouvelles features
- **Perte** : Events si >4 features (overflow)
#### Events Aléatoires
**Types d'events** :
- **Guerres** : Dégradation/amélioration relations, génération companies militaires
- **Crises locales** : Peuvent déclencher crises globales en cascade
- **Breakthroughs technologiques** : Nouvelles capacités, disruption marché
- **Probabilités égales** : Company "Quality" n'a pas plus de chances que "Cost"
**Impacts contextuels** :
- **Guerre → Tank companies** : Génération companies spécialisées combat
- **Blocus → Innovation locale** : Développement alternatives domestiques
- **Crisis → Consolidation** : Fusion/disparition companies faibles
**Contexte Géographique** :
- **Génération locale** : Features selon contexte (guerre → companies Tank)
- **Build-up progressif** : Nouvelles companies commencent basiques, s'améliorent
- **Adaptation étatique** : État sans électronique → dev company électronique médiocre
#### Capacité Économique des États
**Limitation companies** :
- **Capacité par état** : Nombre companies selon économie nationale
- **Ressources partagées** : Grosses companies consomment capacité économique
- **Avantage émergents** : États faibles = innovation possible (pas de monopoles internes)
**Mécaniques d'adaptation** :
- **Besoin critique** : Manque électronique → naissance company Electronic (qualité faible)
- **Substitution** : Mieux que rien > dépendance externe totale
- **Prix explosion** : Pénurie → développement alternatifs locaux
#### Dégradation Qualité et Adaptation
**Composants inférieurs** :
- **Design constraints** : Électronique locale = composants plus gros sur grille
- **Chaleur excessive** : Plus de surchauffe, radiateurs supplémentaires requis
- **Variations design** : Adaptation véhicules aux composants disponibles
- **Courbe apprentissage** : Amélioration progressive vers standards internationaux
- **Trade-offs** : Autonomie vs performance optimale
#### Position du Joueur
**Liberté totale** :
- **Pas de features** : Joueur non-contraint par système company
- **Choix gameplay naturels** : Spécialisation émerge des décisions
- **Factorio advantage** : Flexibilité vs modèles figés IA
- **Concurrence efficacité** : "Tank, Quantity, Cost" = défi mais surmontable
#### Récupération et Recyclage
**Déconstruction produits** :
- **Composants recovery** : Démontage pour pièces détachées
- **Économie circulaire** : Réutilisation en cas de pénurie
- **Stratégie backup** : Alternative aux supply chains rompues
## Système de Conception IA
### Défis d'Implémentation
**Problématique conception** :
- **IA utilise grille** : Même système conception que joueur
- **Complexité computationnelle** : Génération designs = coûteux
- **Performance temps réel** : Impossible si IA réfléchit comme humain
### Solutions d'Implémentation
**Distribution temporelle** :
- **1-2 designs par tick globalement** : Performance acceptable (total mondial, toutes companies confondues)
- **Milliers de ticks** : Designs émergent progressivement
- **Background invisible** : Processus conception non-visible joueur
**Évolution vs Création** :
- **Modification designs existants** : T-72 → T-80 → T-90 (style russe)
- **Plus rapide et réaliste** : Companies IRL évoluent designs
- **Historical accuracy** : Progression technologique authentique
**Système de Validation** :
- **Features comme filtres** : Tank sans arme = design invalide
- **Règles de base** : Guidelines pour IA (tank = châssis + moteur + arme)
- **Validation cohérence** : Features influencent acceptation designs
**Probabilités vs Rigidité** :
- **"Innovation" = plus tentatives** : Pas timing fixe, plus d'essais
- **Réactivité réaliste** : Companies IRL prennent 6+ mois réagir
- **Market dynamics** : Joueur ne peut répondre à toutes demandes simultanément
### Doctrines Culturelles Nationales
**Système de Doctrine** :
- **Influences multiples** : Companies, généraux, tactiques et choix économiques
- **Transmission** : Nouvelles entités héritent tendances nationales
- **Probabilités ajustées** : Bonus/malus selon affinité culturelle
#### Exemple : États-Unis
**Features dominantes** : "Quality", "Electronic", "Innovation"
- **Companies** : +60% chance Quality/Electronic, -40% chance Speed/Cost
- **Généraux** : Tactiques tech-intensive, support aérien, logistique lourde
- **Économie** : Préférence R&D, investissements long terme, high-tech
#### Exemple : France
**Features dominantes** : "Speed", "Modularity", "Innovation"
- **Companies** : +50% chance Speed/Modularity, -30% chance Quantity
- **Généraux** : Doctrines flexibles, combined arms, mobilité
- **Économie** : Cycles courts, adaptabilité, export diversifié
**Mécaniques d'Influence** :
- **Génération companies** : Probabilités pondérées par doctrine nationale
- **Formation généraux** : Schools nationales influencent styles command
- **Décisions étatiques** : Orientations économiques selon culture
- **Adaptation** : Companies étrangères s'adaptent progressivement à culture locale
### Blueprints Culturels
**Héritage par Company** :
- **Blueprints intégrés** : Chaque company hérite culture design + doctrine nationale
- **Examples** :
- Company russe "Tank, Quantity" : T-34 style (low profile, sloped armor)
- Company allemande "Tank, Quality" : Leopard style (modular, precision)
- Company américaine "Tank, Electronic" : Abrams style (high-tech, digital)
**Identités technologiques** :
- **Thales** : Blueprints électronique française (intégration, miniaturisation)
- **Dassault** : Blueprints aéro français (Rafale DNA = agile, multirole)
- **Lockheed** : Blueprints US (stealth, high-tech, expensive)
**Évolution culturelle** :
- **Regional influences** : Companies même région partagent styles + doctrine
- **Feature evolution** : "Quality" améliore précision blueprints existants
- **Acquisition heritage** : Racheter company = récupérer blueprints + culture
- **Doctrine inheritance** : Nouvelles companies adoptent doctrine nationale
**Émergence** :
- **Nouvelles companies** : Héritent blueprints régionaux/culturels + doctrine
- **Innovation contextuelle** : "Tank, Innovation" japonaise → blueprints hyper-modulaires
- **Adaptation locale** : "Engine, Cost" chinoise → moteurs économiques volumineux
- **Cultural drift** : Companies étrangères développent hybrides doctrine/origine
### États
- **Statut hybride** : États = companies spécialisées avec production propre
- **Capacités** : Production, commandes, restrictions commerciales
- **Politique** : Sanctions, embargos, accords commerciaux
- **Exemple** : État ukrainien produit + commande mais ne réquisitionne pas
## Marchés Segmentés
### Types de marchés
- **National** : Marché par pays (ex: marché ukrainien)
- **Company-specific** : Marchés privés entre companies
- **Blocs multinationaux** : UE, OTAN, etc.
- **Mondial** : Marché global ouvert
### Restrictions d'accès
- **Doubles verrous** : Blocages possibles par companies ET états
- **Exemples** :
- France bloque ventes Thales → joueur
- Thales bloque directement → joueur
- Ukraine bloque importations → concurrent
- **Scope** : Matériel industriel, biens production, consommation (électricité, acier)
## Système de Prix Dynamiques
### Facteurs d'influence
- **Offre/Demande** : Mécaniques classiques d'économie de marché
- **Événements militaires** : Conflits modifient prix selon proximité/impact
- **Pénuries** : Prix fonction durée estimée résolution ("2 mois" vs "5 ans")
- **Production adaptative** : Ajustement selon signaux marché
### Exemples concrets
- **Bataille massive** → pénurie composants blindage → prix x3
- **Victoire ukrainienne** → confiance économique → investissements
- **Embargo russe** → rareté métaux spécifiques → alternatives recherchées
## Système Logistique
### Transport Multi-Modal
**Moyens disponibles** :
- **Camions** : Flexibles, tous terrains, capacité limitée
- **Trains** : Grande capacité, nécessite infrastructure rails
- **Avions cargo** : Rapides, coûteux en pétrole, capacité moyenne
- **Drones** : Livraison précise, capacité faible, autonomes
- **Navires** : Très grande capacité, lents, limités aux côtes/rivières
**Caractéristiques** :
- **Poids max** : Limitation par véhicule
- **Volume** : Pour véhicules transportés (pas pour biens standards)
- **Coût indirect** : Consommation carburant (15 avions pour tables = inefficient)
### Supply Chain Militaire
**Architecture FOB** :
- **Forward Operating Bases** : Une ou plusieurs par armée
- **Stocks décentralisés** : Chaque FOB stocke équipements/munitions
- **Distribution autonome** : Armées gèrent propre logistique finale
**Ravitaillement Combat** :
- **Temps réel possible** : Livraison pendant batailles
- **Trade-off tactique** : Unité ravitaillée + ravitailleur immobilisées
- **Durée** : Définie par design ravitailleur ET ravitaillé
- **Vulnérabilité** : Moment critique exploitable par ennemi
### Infrastructure et Vulnérabilités
**Attaques possibles** :
- **Convois** : Cibles mobiles attaquables
- **Infrastructure** : Destruction ponts, rails, dépôts
- **Pas d'espionnage** : Sabotage physique uniquement
**Protection** :
- **Escortes** : Défense convois prioritaires
- **Redondance** : Routes alternatives préplanifiées
- **Réparation** : Reconstruction infrastructure critique
## Ressources et Extraction
### Système de Propriété
**Hiérarchie ownership** :
- **États** : Master ownership des ressources territoriales
- **Companies** : Droits d'exploitation accordés/achetés
- **Joueur** : Doit obtenir droits pour exploiter
- **Revente droits** : Possible si non-rentable
**Future** : Système réquisition état en temps de guerre
### Géopolitique des Ressources
**Ressources stratégiques** :
- **Titanium** : Aérospatial, blindages avancés
- **Lithium** : Batteries, électronique
- **Terres rares** : Processeurs, optiques avancées
- **Contrôle = Pouvoir** : Monopole ressource = leverage diplomatique
## Mécaniques de Marché
### Information et Trading
**Transparence** :
- **Information parfaite** : Prix publics connus de tous
- **Qualité négociateur** : Influence commerce inter-entités
- **Marché ouvert** : Système buy/sell orders (style hôtel des ventes)
### Manipulation Économique
**Pénuries artificielles** :
- **Possible théoriquement** : Achat massif pour créer rareté
- **Limites pratiques** : Nécessite moyens immenses
- **Multi-marchés** : Difficile créer pénurie mondiale
- **Contre-mesures** : Marchés alternatifs, substituts
### Dynamiques Prix
**Facteurs influençant** :
- **Proximité conflit** : Prix locaux augmentent près combats
- **Durée résolution** : "2 mois" vs "5 ans" = prix différents
- **Volume disponible** : Stocks mondiaux vs production
- **Routes commerciales** : Blocage routes = prix régionaux explosent
## Économie de Guerre
### Changement de Priorités Étatiques
**Principe** : États adaptent leurs commandes selon contexte
- **Temps de paix** : Nourriture, biens civils, infrastructure
- **Temps de guerre** : Réduction tables civiles, augmentation tanks/munitions
- **Companies compliance** : Tentative d'adaptation aux nouvelles commandes étatiques
- **Limites culturelles** : Company bois ne peut pas faire tanks instantanément
### Système de Rationnement
**Déclenchement** : En cas de pénuries critiques
- **Priorités étatiques** : Garantie besoins essentiels (nourriture)
- **Malus production** : Effets négatifs sur économie générale
- **Stratégie militaire** : Attaque infrastructure alimentaire = guerre totale
- **Ciblage intelligent** : Détruire supply chains ennemies pour forcer rationnement
### Finances et Crédit
**Système bancaire** :
- **Emprunts companies** : Financement expansion/reconversion
- **Taux variables** : Selon risque et contexte économique
- **Défauts possibles** : Faillites en cas de mauvaise gestion
### Supply Chain Vulnerabilities
**Effet cascade** :
- **Single point of failure** : Usine critique détruite → paralysie secteur
- **Interdépendances** : Composants → sous-assemblages → produits finis
- **Substituts** : Recherche alternatives en cas de rupture
- **Stockages stratégiques** : Buffer contre disruptions temporaires

View File

@ -0,0 +1,188 @@
# Gameplay industriel
## Progression des ressources
### Ordre d'acquisition théorique
**Ressources de base** :
- Bois → Coffre
- Pierre → Mur en pierre
- Scrap → Chaudière (alimentation vapeur dans un rayon de 1 case)
**Machines de base** :
- Assembleur à vapeur
- Four
**Chaîne de production** :
- Charbon de bois < bois
- Fer < minerais de fer / scrap + charbon de bois
- Engrenage < Fer
- Cuivre < minerais de cuivre + charbon de bois
- Bobine de cuivre < cuivre
- Sable < pierre
- Verre < sable
- Circuit électronique primitif < Bobine de cuivre + bois + verre
## Gameloop par phases
### Early
- Exploitation et production
- Scrap et bois
- Recherche
- Électricité et commerce
### Mid
- Charbon et fer/cuivre/silice
- Acide sulfurique/nitrique
- Explosifs basiques/munitions
- Électronique
- Roquettes
- Assemblage et diplomatie
- Licences civiles
- Combat
- Radar
### Mid late
- Pétrole et alu/titane/gold
- Plastique/explosifs avancés
- Circuits avancés
- Licences militaires
- Tourelles de défenses (AA, terrestre, gun)
- Missiles, C&C basique
### Late game
- Nucléaire et platine/composite
- Processeurs
## Philosophie Bac à Sable
### Liberté d'Échelle Joueur
Warfactory est conçu comme un **bac à sable économique** où le joueur définit sa propre échelle d'opération selon ses préférences :
**Spectrum complet possible** :
- **Artisan local** : Production tables, meubles, objets du quotidien
- **PME spécialisée** : Focus niche (électronique, composants spécifiques)
- **Industriel régional** : Usines moyennes, marchés nationaux
- **Géant multinational** : Concurrent direct Thales/Lockheed Martin, marchés globaux
**Principe fondamental** : **Aucune progression forcée**. Le joueur peut rester petit artisan toute la partie s'il le souhaite, ou scale selon ses ambitions.
### Principe Skip vs Optimize
**Philosophie design core** : **"Tous les systèmes du jeu doivent pouvoir être skippés"**
Le joueur choisit son niveau d'engagement selon ses préférences, compétences et temps disponible :
**Spectrum d'engagement** :
- **Skip/Commodité** : Solutions automatisées, efficacité réduite mais accessibles
- **Partial engagement** : Hybride manuel/auto selon systèmes
- **Full optimization** : Contrôle manuel complet, efficacité maximale
**Exemples d'application** :
- **Production** : Factory tout-en-un (médiocre) vs layouts Factorio optimisés
- **Design véhicules** : Templates basiques vs design manuel précis
- **Recherche** : Auto-tech vs chemins research focused
- **Commerce** : Auto-trade vs négociation manuelle
- **Militaire** : Templates doctrinaux vs tactiques custom
**Avantages** :
- **Accessibilité** : Nouveaux joueurs peuvent progresser sans frustration
- **Depth préservée** : Experts peuvent optimiser chaque aspect
- **Rejouabilité** : Même joueur peut changer d'approche selon contexte
- **Respect du temps** : Adaptation aux contraintes personnelles
### Flexibilité de Reconversion Industrielle
#### Mécaniques de Switch Production
La difficulté de reconversion dépend de la **similarité des processus industriels** :
**Reconversion Facile** (même ligne de production, ajustements mineurs) :
- **Tables fer → Blindages véhicules** : Même matériaux (acier), découpe/soudage similaire
- **Électronique civile → Électronique militaire** : Composants proches, normes différentes
- **Moteurs civils → Moteurs militaires** : Base commune, specifications renforcées
**Reconversion Complexe** (nouvelles machines, formation, supply chain) :
- **Tables fer → Canons d'artillerie** : Précision usininage, alliages spéciaux, timing critique
- **Textile → Électronique** : Processus complètement différents
- **Alimentaire → Composites avancés** : Matériaux et techniques sans rapport
**Reconversion Impossible** (reconstruction usine complète) :
- **Menuiserie → Production hydrogène** : Zéro overlap technologique
- **Pharmacie → Moteurs fusée** : Secteurs totalement disjoints
#### Impact Gameplay
- **Diversification intelligente** : Choisir productions complémentaires
- **Flexibilité stratégique** : Réagir aux événements (guerre → switch civil→militaire)
- **Spécialisation vs Généralisme** : Trade-off entre efficacité et adaptabilité
## Systèmes de production
### Factory
- **Extraction**
- **Minage**
- **Style** : Factorio-like
### Agriculture
- Concept à explorer
### Production
- **Style** : Factorio-like
- **Assemblage** : Voir l'aspect conception avant
#### Assemblage et qualité
L'idée est que puisque la conception se fait sur une grille, il faut placer les éléments sur une frame par des machines spéciales. Pour ce faire, il faut des bras spéciaux et placer dans un ordre correct. Si ce n'est pas respecté parfaitement, on observera une réduction dans la qualité du matériel.
**Exemple de placement** :
- Cases marron : éléments déjà placés plus tôt
- Élément vert à placer : bonne façon par la droite (flèche rouge)
- Placement par la gauche (flèche rose) : possible mais réduction qualité
- Composant bleu : 2 façons correctes (droite et arrière, flèches jaunes)
**Problème identifié** :
- "Chain des bras c'est pas ouf. Même si les machines changent de forme c'est clairement pas suffisant. Il faut plus. Visuellement c'est pauvre."
### Logistique
- **Style** : Factorio-like
- **Considération** : Peut-être pas de belt 2-line
### Électricité
- **Principe** : Très simple pour gagner en performance par rapport à Factorio
- **Pas de calcul dynamique** des consommations en entrée
- **Pas de balance** de consommation du réseau
## Systèmes de Production
### Dual Production System
**Système production brut** :
- Transforme ressources primaires en matériaux (minerai fer → plaques fer)
- Production de masse, standardisée
- Focus sur volume et efficacité
**Système d'assemblage** :
- Prend matériaux et les place dans lignes d'assemblage
- Création produits finis (plaques acier → armure tank)
- Focus sur qualité et précision
### Flexibilité production (style Factorio)
**Reconfiguration selon complexité** :
- **Simple** : Tables → blindages bois (reconfiguration manufacturateurs, même layout)
- **Complexe** : Tables fer → canons tank (refaire usines complètes - matériaux, timing, titane)
- **Radical** : Tables → hydrogène (reconstruction totale usines)
**Dépendance recettes** : Facilité changement selon similarité matériaux/process
### Avantage compétitif joueur
**Joueur** :
- **Factorio-like** : Design optimisé, consommation électricité seule
- **Efficacité maximale** : Pas de workers, pas de salaires
**IA Companies/États** :
- **Bâtiments simples** : Production sans design joueur
- **Coûts opérationnels** : Workers + salaires requis
- **Joueur peut accéder** : Mais moins efficace que ses propres designs
### Commandes et autonomie
- **Pas de suggestions IA** : Joueur gère sa production seul
- **Commandes externes** : États/Companies peuvent commander au joueur
- **État ukrainien** : Company parmi d'autres (produit, commande, pas réquisition)

1001
docs/global/map-system.md Normal file

File diff suppressed because it is too large Load Diff

View File

@ -0,0 +1,525 @@
# Mécaniques de jeu
## Recherche et progression
### Système de recherche
Recherche à la Factorio pour :
- Moyens d'extraction
- Production
- Assembly
- Communication
- Châssis civil
- Recherche
- Transport (rail, hyperloop)
- Diplomatie
- Électronique
- Prototype militaire
- Prototype IA
- Prototype composants
- Proto radar
**Exemple Proto radar** :
- Composant équipement taille 6x6, 2kw, fiabilité 50%
**Recherche radar 1** :
- Composant équipement taille 5x5, 2kw, fiabilité 60%
- Composant électronique taille 4x4, 500w, fiabilité 20%
**Recherche radar 2** :
- Composant équipement taille 8x3, 1.5kw, fiabilité 80%
## Système de Recherche Dual
### 1. Recherche Générique (Points de Tech)
- **Points de recherche standard** : Système classique d'accumulation points
- **Usage** : Recherches civiles, technologies de base, progressions linéaires
- **Source** : Production continue, investissement R&D, temps
### 2. Recherche Spécifique (Scrap Analysis)
- **Scrap Analysis** : Reverse engineering matériel ennemi
- **Découvertes aléatoires** : T-72 → ERA, blindage, canon (random)
- **Analyse ciblée** : Étude composants spécifiques pour breakthroughs
- **Efficacité variable** : Selon qualité et état du matériel récupéré
## Système de Breakthroughs
### Verrous technologiques
- **Recherches bloquées** : Certaines technologies inaccessibles sans breakthrough
- **Exemple** : "Armor Javelin-Proof" impossible sans analyse Javelin
- **Gating stratégique** : Force acquisition d'échantillons spécifiques
### Prerequisites Gating & Performance
**Scaling technique** : Le système breakthrough peut gérer 3000 technologies grâce au gating intelligent :
#### Prerequisites Chain
- **~10-50 techs eligible** simultanément pour un player donné (pas 3000)
- **Tech dependencies** : Nouvelle tech nécessite prérequis recherchés
- **Progressive unlock** : Chaque breakthrough débloque quelques nouvelles possibilités
- **Organic discovery** : Player découvre par gameplay naturel, pas par browsing
#### Validation Performance
- **On-demand checks** : Conditions vérifiées quand événement trigger (construction, production, etc.)
- **State-based** : Validation sur état actuel (avoir 5 radars), pas historique complexe
- **Ticker optimisé** : Vérifications breakthrough toutes les minutes, pas 60fps
- **Cache results** : Évite recalculs conditions identiques
### 3 Sources de Breakthroughs
**1. Scrap Analysis**
- **Méthode primaire** : Reverse engineering matériel ennemi
- **Simplicité** : Scrap = scrap (pas d'état, pas de fraîcheur)
- **Efficacité** : Méthode la plus directe et économique
**2. Points de Recherche Avancés**
- **Alternative coûteuse** : Breakthrough sans scrap
- **Caractéristiques** : Cher et lent
- **Usage** : Quand scrap spécifique inaccessible/rare
**3. Reverse Engineering Produits**
- **Systèmes capturés** : Équipement intact récupéré (1-3 breakthroughs)
- **Achat commercial** : Produits achetés sur marché (produit final seul)
- **Conséquences diplomatiques** : Relations gravement affectées avec company/état vendeur
- **Limites** : Produit accessible mais pas ses composants/ingrédients
### Efficacité par source
- **Scrap** : 0-1 breakthrough (aléatoire, économique)
- **Capture** : 1-3 breakthroughs (risqué, très efficace)
- **Achat** : 1 breakthrough produit (cher, conséquences diplomatiques)
- **Recherche avancée** : Garantie breakthrough (très cher et lent)
## Économie des Technologies
### Vente de technologies
- **Marché tech** : Breakthroughs déblocables vendables sur marché
- **Revenus additionnels** : Monétisation des découvertes R&D
- **Concurrence** : Autres actors peuvent acquérir vos innovations
### Contenu long terme (future)
- **Espionnage industriel** : Vol de breakthroughs entre companies
- **Protection IP** : Mécaniques de sécurisation des technologies
## Actions normales militaires
L'idée c'est qu'une action normale est un déroulement :
**Exemples de déroulements** :
- **Établir Position AA** = déplacement → déploiement → attente d'engagement
- **Assaut** = déplacement opérationnel → engagement tactique → attaque CQC → Prise de position de défense → attente d'engagement
### Mise en place
- Établissement de FOB, dépôt de munitions
- Établissement d'AP
- Établir Position radar
- Établir Position AA (point defense, area defense)
- Établir Position static Artillerie
- Établir Trench network
- Defense tempo (retrenchment)
### Ravitaillement
- Ravitaillement de convois
- Ravitaillement léger (drone)
- Ravitaillement classique (mono camion)
### Action de combat
- **Assaut** (prise de position ennemie)
- **Reconnaissance** (discrète)
- **Reconnaissance in force** (légère ou blindée)
- **Infiltration**
- **Raid** (logistique, anti-AA, anti-artillerie, JSP)
- **Attaque** (char → boum boum boum → retrait → recommencer) (détruire l'ennemi)
### Long range
On inclut ici l'artillerie, les missiles, le support aérien au sol :
- **Frappe destructive**
- **Contre frappe** (contre batterie)
- **Saturation artillerie**
- **Support des troupes**
- **Obscuration**
- **Suppression**
### Contrôle aérien
- **SEAD**
- **DEAD**
- **Interception**
- **Supériorité aérienne** → patrouille
- **Escorte**
- **Reconnaissance aérienne**
- **Identification**
- **Alerte** (warn non hostile)
## IA stratégique
### Défis de l'IA
Pas facile hein…
Déjà l'IA doit être capable d'implémenter toutes les "actions normales" ci-dessus.
Pour ce qui est de la décision de quelle action implémenter et où, c'est une vraie difficulté et c'est ce qui doit être réfléchi.
### Doctrines différenciées
Déjà il faut comprendre que toutes les IA ne feront pas la même chose (doctrine tactique et opérationnelle) et cela en fonction d'objectifs stratégiques, donc décidés par l'IA stratégique.
**Proposition** : Donner un set de préférences (par action) pour définir une doctrine, avec sûrement un concept de phases opérationnelles.
**Exemple doctrine US** :
Campagne aérienne → SEAD → DEAD → C&C target → CAS → Ground assault
### Concept de recette
Concept de recette avec un coût à trois composantes :
- **Raid****AA pos** → **125e compagnie d'inf moto**
- **Quoi ?** / **Qui/où ?** / **Comment/avec qui ?**
## Mécaniques de combat
### AOE (str)
Ça doit être possible mais bon à éviter.
### Tacops (tactique/4x)
Ce qu'est censé être le combat mid-late game. Une gestion des unités sur une carte de campagne et les unités qui se démerdent sur l'aspect combat IA. Il est important de pouvoir contempler les combats.
### Réparation/logistique
*À développer*
### RPG
*À développer*
## Simulation de monde
### Factions
Intégration de factions qui, souvent seront les états et avec lesquels l'interaction doit être possible (économie, diplomatie).
### Économique
Système économique avec lequel le joueur peut interagir, notamment par l'intermédiaire de la vente ou l'achat de ressources. Spéculation ?
Celle-ci doit être dynamique et intégrer un système d'économie d'échelle permettant une spécialisation économique des factions. Pour autant, les enjeux stratégiques (bouffe, armes etc.) doivent être pris en compte et intégrés à la production économique des factions.
### Stratégique
Compréhension des enjeux stratégiques liés aux ressources, aux positions géographiques.
### Politique
Intégration de l'ordre public et des courants politiques.
## Système d'Administration
### Principe Fondamental
Chaque **company** et **état** dispose de points d'**Administration** qui limitent leurs actions quotidiennes, représentant leur capacité organisationnelle et bureaucratique.
### Mécaniques Core
#### Points Administration Base
- **Companies** : 1000 points/jour de base (1 jour = 10 minutes réelles)
- **États** : Variable selon taille/développement (à définir)
- **Régénération** : Reset quotidien complet des points
- **Fréquence actions** : ~1 action tous les 3-5 jours par company (rythme macro stratégique)
#### Actions Coûtant Administration
**Recherche & Développement** :
- Lancer nouvelle recherche : 100-500 points (selon complexité)
- Breakthrough forcé (scrap analysis) : 200-800 points
- Achat technology sur marché : 150 points
**Commerce & Économie** :
- Négocier nouveau contrat : 50-200 points
- Changer prix produits : 25 points
- Ouvrir nouveau marché d'export : 300 points
- Merger/acquisition : 500+ points
**Diplomatie** :
- Proposer accord commercial : 200 points
- Sanctions économiques : 400 points
- Négociation traité : 600+ points
**Production & Infrastructure** :
- Construire nouvelle usine : 300 points
- Changer ligne de production : 100 points
- Optimisation processus : 150 points
- Expansion facilities : 250 points
**Opérations Militaires** (États principalement) :
- Lancer opération militaire : 500+ points
- Coordination multi-forces : 300 points
- Changement doctrine : 400 points
### Facteurs Modifiant Administration
#### Company Features Impact
**Features Réduisant Admin** :
- **Quality** : -10% coûts admin (organisation efficace)
- **Administration** : +50% points admin de base (spécialisation bureaucratique)
**Features Neutres** :
- **Innovation** : Pas de bonus admin (créativité ≠ organisation)
- **Cost** : Pas d'impact admin
- **Speed** : Pas d'impact admin
#### Investissements Infrastructure
**Bureaux & Management** :
- **Bureaux modernes** : +200 points admin/jour
- **Systèmes ERP** : +150 points admin/jour
- **Managers expérimentés** : +100 points admin/jour
- **Automation administrative** : +300 points admin/jour
#### Modificateurs Contextuels
**État de Guerre** :
- **Companies** : +200 points admin/jour (économie de guerre = urgence)
- **États** : +500 points admin/jour (mobilisation totale)
- **Justification** : Urgence permet décisions rapides, bypass bureaucratie
**État de Paix** :
- **Administration normale** : Valeurs de base
- **Bureaucratie standard** : Processus normaux
**Stress Économique** :
- **Récession** : -100 points admin/jour (ressources réduites)
- **Croissance** : +50 points admin/jour (expansion capabilities)
### Stratégies Administration
#### Optimisation Resource Management
- **Priorisation actions** : Quelles décisions sont critiques ?
- **Timing operations** : Grouper actions similaires
- **Investment planning** : ROI bureaux vs production
#### Spécialisations Companies
- **Company "Administration"** : Devient sous-traitant admin pour autres
- **Outsourcing** : Déléguer certaines tâches vs faire internal
- **Efficiency focus** : Quality companies = moins de waste admin
### Examples Concrets
#### Company Journée Type
```
Thales (Company "Electronic, Quality, Administration"):
├── Administration disponible: 1000 + 500 (Admin feature) + 200 (bureaux) = 1700/jour
├── Coûts journée:
│ ├── Recherche "Radar AESA": -400 points
│ ├── Négociation contrat Ukraine: -150 points
│ ├── Optimisation ligne production: -120 points (Quality = -10%)
│ └── Total utilisé: 670/1700
└── Surplus: 1030 points (peut faire plus d'actions)
```
#### Company Limitée
```
StartupCorp (Company "Innovation"):
├── Administration disponible: 1000/jour (base seulement)
├── Coûts journée:
│ ├── Recherche breakthrough: -500 points
│ ├── Négociation financement: -300 points
│ ├── Changement production: -250 points
│ └── Total: 1050 points
└── LIMITE ATTEINTE: Doit choisir priorités !
```
### Impact Gameplay
#### Pour l'IA
- **Performance naturellement limitée** : Pas d'actions infinies par tick
- **Comportements réalistes** : Companies choisissent priorités selon pools admin
- **Rythme macro** : ~1000 companies × 1 action/3-5 jours = ~0.33 actions/seconde système
- **Spécialisations émergentes** : Features influencent strategies
#### Pour le Joueur
- **Companies IA prévisibles** : Limitation actions = patterns plus lisibles
- **Opportunités timing** : Profiter quand competitors "admin-locked"
- **Market dynamics** : Administration shortage = prix changes moins fréquents
### Balance Considerations
#### Éviter Frustration
- **Actions critiques** : Survie company ne doit jamais être bloquée par admin
- **Emergency actions** : Certaines actions bypass admin en crisis
- **Learning curve** : Interface claire sur coûts admin
#### Maintain Dynamism
- **Baseline sufficient** : 1000 points permet gameplay de base
- **Scaling rewards** : Investment admin = exponential returns
- **Variety strategies** : Multiple paths pour optimiser admin
## Terrain de combat PMC
### Zones d'opération
- Amérique du Sud dans les zones peu peuplées
- Madagascar
- Afrique
- Ouest de la Chine
- Russie
- Moyen-Orient
## Meta Game Design
### Philosophie de difficulté
"Aucune satisfaction parce que le jeu est fait pour être gagné. Quel intérêt de gagner alors ?"
**Objectif** : Faire un jeu où le but de l'IA contre le joueur est bel et bien de gagner, pas de perdre.
## Système d'Expérience Véhicules
### Expérience Combat
- **Gain expérience** : Combat, missions réussies, survie prolongée
- **Effets** : Amélioration fiabilité, précision, temps de réaction IA
- **Vétérans** : Véhicules expérimentés plus efficaces, moins de pannes
### Système de Généraux et Armées
#### Structure de commandement
- **Composition automatique** : Joueur assigne types/nombres ("20 chars lourds"), gestion automatique
- **Types de véhicules** : Classification par rôles (char lourd, IFV, drone, etc.)
- **Logistique intégrée** : Assignement, maintenance, ravitaillement gérés automatiquement
- **Hiérarchie** : Général en chef donne objectifs à subalternes qui planifient opérations
- **Limite par expérience** : Capacité de commandement croît linéairement avec expérience
- **Malus surcharge** : Armée trop grosse → réserves, opérations limitées, qualité dégradée
#### Modes de planification
1. **Plans proposés** : Général propose plans que joueur valide/modifie
2. **Plans joueur** : Joueur conçoit plans détaillés, général exécute
3. **Objectifs généraux** : Joueur donne objectifs, général génère détails opérationnels
4. **Ordre simple** : Ordre "attaque", IA choisit méthodes et tactiques
#### Spécialisations et IA des généraux
- **Machine Learning** : Adaptation tactique selon résultats (échecs → évitement progressif)
- **Personnalité & Traits** : Influencent probabilité d'usage de certaines tactiques
- **Exemple adaptatif** : Général blindé échec urban → reste blindé mais tactiques adaptées
- **Apprentissage spécialisé** : Usage véhicules overloadés → amélioration overload dynamique
#### Cycle d'apprentissage overload dynamique
**Phase Planning** :
1. **Analyse menace** : Blindage insuffisant estimé pour mission
2. **Recherche solutions** : Liste options (Spaced armor, ERA, etc.)
3. **Check logistique** : Disponibilité équipements (ERA disponible)
4. **Commande automatique** : Order passé au réseau logistique
**Phase Pré-mission** :
- **Workshop preparation** : Équipement ERA sur véhicules compatibles
- **Validation configuration** : Vérification intégrité overload
**Phase Mid-mission** :
- **Observation détaillée** : Monitoring performance en temps réel
- **Data collection** : Impact sur vitesse, électronique, capteurs
**Phase Post-analyse** :
- **Efficacité ERA** : Réduction dégâts mesurée vs prédiction
- **Ajustement valeurs** : Calibrage algorithmes d'évaluation
- **Impact systémique** : Analyse systèmes ennemis, contre-mesures
- **Décision adaptative** : Mise à jour probabilités d'usage futur
**Caractéristiques générales** :
- **Templates flexibles** : Style HOI4 + contrôle fin possible
- **Influence principale** : Tactiques et opérations privilégiées
- **Influence secondaire** : Légers bonus stats selon expertise
#### Système logistique intégré
- **Orders automatiques** : Armées placent commandes logistiques automatiquement
- **Équipement dynamique** : Blocs ERA commandés via réseau logistique
- **Delivery system** : Logistique tente de livrer selon capacités/priorités
#### Contrôle joueur et politiques
**Séparation des rôles** :
- **Joueur** : Légo industriel + ordres stratégiques + planning optionnel
- **Généraux** : Exécution autonome selon designs et stocks disponibles
**Gestion des stocks** :
- **Stocks spéciaux** : Joueur contrôle mise à disposition (ERA, équipements rares)
- **Premier arrivé, premier servi** : Pas de système de priorités complexe
- **Contrôle indirect** : Arrêt production = fin disponibilité pour généraux
**Politiques par design** :
- **Design constraints** : Espace disponible pour overload ou interdiction
- **Pas de budgets généraux** : Pas d'autorisation ni limite financière
- **Contrôle passif** : IA utilise ce qui est disponible selon designs autorisés
#### Interface de planification
- **Plans séquentiels** : Phases avec objectifs et timeline
- **Visualisation carte** : Zone d'opération avec numéros, flèches, positions
- **Détails drill-down** : Accès effectifs prévus par phase/objectif
- **Validation joueur** : Approbation/modification des plans proposés
## Cycle Technologique des Armes
### Évolution forcée : Petit → Moyen → Gros
- **Recherche naturelle** : Nouvelles armes plus puissantes mais plus grosses
- **Dilemme châssis** : Armes avancées ne logent plus sur châssis existants
- **Solutions forcées** :
- Overload châssis existants (malus mais moins cher)
- Développer châssis super-lourds (coûteux, spécialisés, limités)
- **Équilibrage** : Châssis super-lourds pas OP (style HOI4) - lents, chers, vulnérables
## Architecture serveur
### Economy Server
#### Marché global dynamique
- **Fonction** : Ressources globales, commerce, spéculation, économie d'échelle
- **Trade dynamique** : Prix fluctuants selon offre/demande et événements
- **Réactivité militaire** : Économie réagit aux conflits et batailles
#### Acteurs économiques
- **Companies** : Entreprises privées (Thales, Dassault, joueur initial)
- **États** : Nations avec politiques et relations diplomatiques
- **Relations croisées** : Companies dépendent des états mais ont relations propres
- **Restrictions multi-niveaux** : Blocages possibles par companies ET états
- **Matières et services** : Restrictions sur industriel, production, consommation (électricité, acier)
#### Système de marchés
- **Marchés segmentés** : Par pays, par company, par bloc multinational, mondial
- **Exclusivités** : Joueur peut vendre exclusivement sur certains marchés
- **Designs concurrents** : Companies génèrent designs procéduraux, reverse engineering possible
- **Commandes nationales** : États passent commandes directes selon besoins
#### Early game - Économie de guerre Ukraine
- **Scrap russe** : Récupération tanks détruits comme ressource de base
- **Transformation** : Recyclage et revente sur marché ukrainien
- **Bootstrap économique** : Revenus initiaux via scrap → équipement → export
#### Dynamiques de pénurie et production
- **Pénuries temporaires** : Prix augmentent selon durée estimée de résolution
- **Différentiation temporelle** : "Réglé dans 2 mois" vs "réglé dans 5 ans"
- **Adaptation marché** : Production s'ajuste selon signaux prix et demande
#### Système de menaces (style AI War)
- **Basé sur capacité production** : Volume de production brute = menace principale
- **Impact indirect** : Tank company X détruit matos → menace pour company X
- **Escalade naturelle** : Succès militaire → attention ennemie → frappes ciblées
- **Exemple concret** : Anti-tank révolutionnaire détruit masses de véhicules → strikes russes
#### Mécanismes de protection
- **Défense personnelle** : Investissement défenses propres autorisé
- **Protection étatique** : État hôte (Ukraine) défend companies importantes
- **Dispersion géographique** : Étalement production pour réduire vulnérabilité
- **Négociation neutralité** : Accords diplomatiques possibles avec hostiles
- **Équilibrage mutuel** : État protège company → company contribue défense nationale
#### Expansion géographique
- **Délocalisation** : Possible si pays hôte accepte l'implantation
- **Changement nationalité** : Possible mais exclusif (pas de multi-nationalité)
- **Pas de filiales** : Structure company unifiée sous une seule nationalité
- **Approbation étatique** : Accord gouvernemental requis pour implantation
#### Système de renseignement
- **Fog of War** : Reconnaissance obligatoire pour informations précises
- **Identification progressive** : Bâtiments → Usines → Usines d'armement → Usine d'arme de X
- **Stats économiques publiques** : Menace calculée sur données ouvertes
- **Paradoxe info** : Menace omnisciente mais localisation floue
#### Rôle du joueur dans le monde
- **Échelle variable** : Du massif à l'insignifiant selon choix joueur
- **Joueur secondaire** : Le monde tourne indépendamment du joueur
- **Impact optionnel** : Joueur peut influencer mais n'est pas nécessaire à l'économie globale
### World Server
- **Fonction** : Factions, diplomatie, géopolitique, événements macro
- **Scope** : Relations internationales, politique interne, crises globales
- **Features** : 3 endgames (zombies, aliens, démons)
- **Intégration** : Ordre public et courants politiques
### Gameplay asynchrone
- **Principe** : Combat peut avoir latency, player gère autre chose
- **Implémentation** : Background processing pendant diplo/économie
- **Avantage** : Bataille 10k unités = 30 secondes → player continue production

View File

@ -0,0 +1,269 @@
# Métriques Joueur
## Vue d'ensemble
Le système de métriques de Warfactory fournit aux joueurs des **statistiques détaillées** avec graphiques complets de performance, permettant l'analyse fine de leur progression industrielle et militaire.
## Architecture Données
### Distinction Breakthrough vs Métriques
**Breakthrough System** : Données minimales (~KB par company)
- State actuel uniquement
- Compteurs cumulatifs simples
- Focus : Performance et déclenchement conditions
**Système Métriques** : Données historiques complètes (~MB par entité)
- Historique détaillé production
- Graphiques temporels complets
- Focus : Analyse et visualisation
### Volume de Données par Partie (300-400h)
#### Companies IA (1000)
- **Fréquence** : 1 point toutes les 10min
- **Ressources** : 10 produits trackés par company
- **Volume** : 1000 × 10 × (400h × 6 points/h) × 8 bytes = **192MB par partie**
#### États (50)
- **Fréquence** : 1 point toutes les 10min
- **Ressources** : 3000 ressources par état
- **Volume** : 50 × 3000 × (400h × 6 points/h) × 8 bytes = **2.9GB par partie**
#### Joueurs (Scaling Adaptatif Multijoueur)
- **Solo/Company partagée** : 1 point toutes les 30sec = 120 points/h
- **Multijoueur adaptatif** : Fréquence réduite selon nombre de companies
- **1 company** : 2 points/min (120 points/h)
- **5 companies** : 0.4 points/min (24 points/h)
- **10+ companies** : 0.25 points/min minimum (15 points/h)
- **Ressources** : 40 produits trackés
- **Volume variable** : 1 × 40 × (400h × points/h) × 8 bytes = **15MB à 3MB selon config**
**Total par partie** : ~3.1GB constant (data sharing + scaling adaptatif)
- **Joueurs même company** : Dataset partagé (pas de duplication)
- **Free-for-all** : Granularité réduite maintient volume total stable
## Types de Métriques
### 1. Production & Économie
#### Métriques de Production
- **Production par ressource** : Steel/h, Electronic components/h, Véhicules/jour
- **Efficacité usines** : % utilisation, downtime, bottlenecks identifiés
- **Évolution capacités** : Courbes de croissance industrielle
- **Ratios production** : Input/Output, waste, efficiency metrics
#### Métriques Économiques
- **Revenus/Dépenses** : Graphiques détaillés par source et destination
- **Flux financiers** : Cash flow, profit margins, ROI investissements
- **Commerce international** : Exports/imports par pays et ressource
- **Coûts opérationnels** : Breakdown par type (énergie, main d'œuvre, matières premières)
### 2. Recherche & Développement
#### Progression Technologique
- **Timeline breakthroughs** : Chronologie découvertes avec sources
- **Sources de découverte** : Ratio Scrap vs Natural vs Events vs Purchase
- **Domaines expertise** : Radar de spécialisations technologiques
- **Investissements R&D** : Allocations budget et ROI par domaine
#### Innovation Metrics
- **Taux découverte** : Breakthroughs/mois in-game
- **Efficacité R&D** : Coût moyen par breakthrough
- **Diversification** : Spread technologique sur domaines
- **Compétitivité** : Position vs autres companies (si intel disponible)
### 3. Expansion & Influence
#### Contrôle Géographique
- **Territoire contrôlé** : Surface, ressources accessibles, population
- **Infrastructure** : Density routes, bases, installations industrielles
- **Influence diplomatique** : Relations par pays/région, contrats actifs
- **Sécurité zones** : Threat levels, incidents sécuritaires
## Visualisations
### Graphiques Temporels
#### Production Dashboard
```
Production Steel (tonnes/jour)
1000│ ╭─╮
800│ ╭─╯ ╰─╮
600│ ╭─╯ ╰─╮
400│╭╯ ╰─╮
200│╯ ╰───
0└─────────────────────▶
Mois 1 2 3 4 5 6
```
#### Financial Trends
```
Cash Flow (M€)
5.0│ ██████████████████▒▒▒▒ Revenue
4.0│ ████████████▒▒▒▒▒▒▒▒▒▒ Expenses
3.0│ ████████▒▒▒▒▒▒▒▒▒▒▒▒▒▒ Profit
2.0│ ████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
1.0│ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
0└─────────────────────▶
Q1 Q2 Q3 Q4
```
#### Breakthrough Timeline
```
Découvertes Technologiques
├─ Mois 2: Radar Avancé (Scrap Analysis)
├─ Mois 4: Matériaux Composites (Natural)
├─ Mois 7: IA Tactique (Purchase Intel)
├─ Mois 9: Blindage Réactif (Capture)
└─ Mois 12: Moteurs Fusion (Event)
```
### Radar Charts
#### Technology Mastery
```
IA (8/10)
/\
/ \
Electronics Matériaux
(6/10) ────────── (9/10)
\ /
\ /
Moteurs (4/10)
```
### Heatmaps
#### Market Opportunities
```
Resource vs Country Demand
│UKR│POL│GER│FRA│
Steel │ ██│ ▓▓│ ░░│ ▓▓│
Electronics│▓▓│ ██│ ██│ ▓▓│
Vehicles │ ██│ ▓▓│ ░░│ ░░│
```
## Système de Stockage
### Architecture Données
#### Structure TimeSeries Simplifiée
```cpp
struct MetricTimeseries {
int32_t value; // 4 bytes signed int
// Timestamp et résolution stockés en métadonnées
};
struct TimeseriesMetadata {
uint32_t start_timestamp;
uint32_t interval_seconds; // Ex: 30s pour joueur, 600s pour IA
uint32_t data_count;
};
struct EntityMetrics {
EntityID entity_id;
// Production (par ressource) - listes simples de int32
map<ResourceType, vector<int32_t>> production_history;
map<ResourceType, TimeseriesMetadata> production_metadata;
// Financial - listes simples
vector<int32_t> revenue_history;
vector<int32_t> expenses_history;
vector<int32_t> cash_flow_history;
TimeseriesMetadata financial_metadata;
// Technology
vector<BreakthroughEvent> breakthrough_timeline;
};
```
#### Breakthrough Events Simplifié
```cpp
struct BreakthroughEvent {
uint32_t timestamp;
TechID technology_id;
BreakthroughSource source; // SCRAP, NATURAL, PURCHASE, EVENT
string details; // "Scrap: T-72 Tank"
};
```
### Agrégation & Compression
#### Résolution Adaptative
- **Dernière semaine** : Points toutes les 30sec (joueur) / 10min (IA)
- **Dernier mois** : Agrégation horaire
- **Derniers 6 mois** : Agrégation quotidienne
- **Plus ancien** : Agrégation hebdomadaire
#### Compression Intelligente
- **Delta encoding** : Stocker différences vs valeurs absolues
- **Run-length encoding** : Pour périodes stables (production constante)
- **Lossy compression** : Données anciennes → précision réduite acceptable
## Interface Métriques
### Dashboard Principal
#### Vue d'Ensemble
```
┌─────────────────┬─────────────────┬─────────────────┐
│ PRODUCTION │ FINANCES │ RECHERCHE │
│ Steel: ↗ +15% │ Profit: ↗ +8% │ 3 breakthroughs│
│ Elec: ↘ -3% │ Cash: 2.4M€ │ this month │
├─────────────────┼─────────────────┼─────────────────┤
│ TERRITOIRE │ DIPLOMATIC │ STATUS │
│ 12 installations│ 3 trade deals │ ✅ Operational │
│ 3 countries │ 85% relations │ 🔄 Expanding │
└─────────────────┴─────────────────┴─────────────────┘
```
#### Navigation & Drill-Down
- **Overview****Domain****Specific Metric** → **Detailed Timeline**
- **Comparisons** : Self vs time, targets vs actual, competitors (si data available)
- **Filters** : Date ranges, metric types, zoom levels, entity types
### Métriques Spécialisées
#### Competitive Intelligence (si disponible)
```
Market Share Analysis
Company │Production│Revenue│Breakthroughs│
Thales │ 25% │ 30% │ 18 │
Lockheed │ 18% │ 22% │ 15 │
Player │ 12% │ 15% │ 12 │
Dassault │ 15% │ 18% │ 10 │
Others │ 30% │ 15% │ 45 │
```
## Privacy & Intelligence
### Data Visibility
#### Player Data (Full Access)
- **Toutes métriques personnelles** : Production, finances, recherche, combat
- **Historique complet** : Depuis début de partie
- **Analytics avancées** : Trends, predictions, optimization suggestions
#### Competitor Data (Limited)
- **Via espionnage** : Intel partiel sur production/capabilities
- **Market signals** : Déductions via prix, volumes, nouvelles exportations
- **Combat assessment** : Performance observée lors d'engagements
- **Public information** : Certaines métriques "corporate" accessibles
#### State Data (Contextual)
- **Economic indicators** : PIB, imports/exports publics
- **Military capabilities** : Intel selon relations diplomatiques
- **Technology level** : Observations équipements, brevets publics
---
*Les métriques constituent l'outil principal d'analyse et d'optimisation continue pour maîtriser la complexité industrielle et militaire de Warfactory*

View File

@ -0,0 +1,143 @@
# 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
## 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.*

View File

@ -0,0 +1,884 @@
# Système militaire
## Conception de véhicules
### Système de Frames
Une frame est une base sur laquelle on vient ajouter des composants dans une grille. Les frames ont des formes variées, rarement rectangulaires, avec des zones mortes et des emplacements d'overload spécifiques.
#### Interface de Design
**Placement des Composants** :
- **Pick & Place** : Clic sur composant dans inventaire latéral, drag vers grille, clic pour placer
- **Snap automatique** : Alignement automatique sur grille avec feedback visuel
- **Rotations** : A/E pour tourner composants (standard PC gaming)
- **Snap toggle** : R pour désactiver/activer l'alignement grille
- **Zones interdites** : Feedback visuel rouge pour placements impossibles
- **Templates** : Designs pré-faits et patterns recommandés
- **Validation temps réel** : Contraintes (poids, énergie, etc.) vérifiées durant placement
#### Anatomie d'un Châssis
```
Exemple: Châssis "Griffon" (chenillé moyen)
[X][O][O][O][O][X] X = Zone morte (non utilisable)
[X][●][●][●][●][●][●][X] ● = Zone standard
[●][●][●][●][●][●][●][●] ○ = Zone overload possible
[●][●][●][●][●][●][●][●] ▲ = Zone centrale (critique)
[●][●][▲][▲][▲][▲][●][●] ■ = Zone flanc (vulnérable)
[■][■][▲][▲][▲][▲][■][■] ╬ = Zone déconnectée
[○][○][●][●][●][●][○][○]
[○][●][●][●][●][○]
Exemple: Châssis "Viper" modulaire (roues)
[●][●][●] [●][●][●] Zones déconnectées
[●][▲][●] [●][▲][●] → Composants 3x3+ impossibles
[○][○][○] [○][○][○] → Chaque bloc autonome
```
**Zones spéciales** :
- **Zone centrale** : Composants critiques (moteur, IA principale)
- **Zones flanc** : +50% dégâts si touchées, éviter composants vitaux
- **Zones mortes** : Cases bloquées par forme du châssis
- **Zones overload** : Seuls endroits où overload possible
- **Zones déconnectées** : Blocs isolés, limitent taille composants
### Générations et Styles de Châssis
#### Concept de Générations
- **Gen 1 (1960-1980)** : Robustes, simples, réparables sur le terrain
- **Gen 2 (1980-2000)** : Électronique basique, modularité émergente
- **Gen 3 (2000-2020)** : Numérisation, composites, furtivité
- **Gen 4 (2020+)** : IA intégrée, matériaux avancés, hybride/électrique
#### Styles Alternatifs & Originaux
**Châssis "Sloped" (inspiré soviétique)**
- **Grille en losange** : 7x10 mais forme inclinée
- **Bonus** : -20% chance d'être touché, +15% ricochet
- **Malus** : Espace intérieur réduit, ergonomie difficile
- **Exemple** : Châssis chenillé sloped Gen2
**Châssis "Boxy" (inspiré occidental)**
- **Grille rectangulaire standard** : 8x12 optimisé
- **Bonus** : +20% espace utilisable, maintenance facile
- **Malus** : Profile plus élevé, angles morts
- **Exemple** : Châssis roues boxy Gen3
**Châssis "Hexagonal" (expérimental)**
- **Grille hexagonale** : placement alternatif des composants
- **Bonus** : Synergies à 6 faces, répartition dégâts optimale
- **Malus** : Coût production +30%, complexité assemblage
- **Breakthrough requis** : "Advanced Geometry Manufacturing"
**Châssis "Modular Block" (futuriste)**
- **Grille segmentée** : 4 blocs de 3x3 non-connectés
- **Bonus** : Reconfiguration rapide sur le terrain
- **Malus** : Points faibles aux jonctions, composants >2x2 impossibles
- **Contrainte** : Chaque bloc isolé → composants doivent tenir dans un bloc
- **Spécial** : Peut changer configuration selon mission mais perd cohésion
**Châssis "Organic" (bio-inspiré)**
- **Grille courbe** : forme irrégulière naturelle
- **Bonus** : Auto-réparation partielle, adaptation terrain
- **Malus** : Incompatible composants standards
- **Breakthrough requis** : "Biomimetic Engineering"
#### Châssis Terrestres Nommés
**Roues**
- **"Fennec"** (ultra-léger Gen3) : Forme triangulaire 2x3, overload arrière uniquement
- **"Coyote"** (léger Gen2) : Forme hexagonale allongée, zones mortes avant
- **"Bison"** (moyen Gen3) : Rectangle avec coins coupés, flancs exposés
- **"Rhino"** (lourd Gen4) : Forme trapézoïdale, zone centrale renforcée
- **"Viper"** (Desert Runner) : Profil serpentin, 3 zones overload isolées
**Chenilles**
- **"Lynx"** (léger Gen3) : Forme diamant, excellente répartition
- **"Griffon"** (moyen Gen2) : Octogone irrégulier, zones mortes avant/arrière
- **"Mammoth"** (lourd Gen4) : Massif hexagonal, 8 zones overload périphériques
- **"Badger"** (Gen1 Vintage) : Rectangle simple, pas de zones mortes
- **"Crocodile"** (Low Profile) : Très allongé, zone centrale étroite
- **"Otter"** (Amphibie) : Forme hydrodynamique, zones mortes latérales
**Rails**
- **Châssis locomotive** : 4x20 grille (moteur obligatoire)
- **Châssis wagon léger** : 4x12 grille
- **Châssis wagon lourd** : 6x15 grille
- **Châssis wagon plateforme** : 5x18 grille
#### Châssis Aériens Nommés
**Volants légers**
- **"Sparrow"** (quadcopter Gen3) : Croix parfaite, 4 moteurs aux extrémités
- **"Wasp"** (hexacopter Gen4) : Forme étoile, zones overload entre rotors
- **"Kestrel"** (léger Gen2) : Forme T inversé, zone centrale large
- **"Osprey"** (Tilt-Rotor) : Forme H, zones mortes centrales
- **"Raven"** (Stealth Copter) : Triangle noir, overload pointe avant uniquement
**Volants moyens**
- **"Falcon"** (moyen Gen3) : Fusiforme classique, flancs vulnérables
- **"Eagle"** (Delta Wing) : Triangle parfait, pas de zones mortes
- **"Condor"** (Canard) : Forme X, 4 zones overload aux extrémités
- **"Phantom"** (Flying Wing) : Aile pure, zone centrale minimale
**Volants lourds**
- **"Albatross"** (lourd Gen3) : Forme cruciforme, soute centrale massive
- **"Pelican"** (transport Gen2) : Rectangle avec protubérance avant
- **"Vulture"** (très lourd Gen4) : Forme W, 6 zones overload réparties
- **"Leviathan"** (Ekranoplan) : Forme aplatie, zones mortes latérales massives
- **"Manta"** (Blended Body) : Ovale parfait, overload périphérique uniquement
#### Châssis Navals Nommés
**Surface**
- **"Barracuda"** (ultra-léger Gen3) : Forme effilée, overload proue uniquement
- **"Hammerhead"** (léger Gen2) : Forme T, zone centrale élargie avant
- **"Orca"** (moyen Gen3) : Fusiforme avec renflement central
- **"Neptune"** (Trimaran) : 3 coques parallèles, zones mortes entre coques
- **"Skimmer"** (Hydrofoil) : Forme V inversé, zone centrale surélevée
- **"Poseidon"** (SWATH) : Double coque immergée, pont étroit
- **"Kraken"** (lourd Gen4) : Forme tentaculaire, 8 zones overload
- **"Behemoth"** (très lourd Gen3) : Hexagone massif, flancs exposés
- **"Atlas"** (plateforme Gen2) : Rectangle avec découpes pour piste
**Submersibles**
- **"Piranha"** (ultra-léger Gen4) : Forme torpille pure
- **"Stingray"** (léger Gen3) : Forme diamant aplati
- **"Nautilus"** (Teardrop) : Goutte parfaite, pas de zones mortes
- **"Typhoon"** (Double Hull) : Rectangulaire avec double paroi
- **"Triton"** (moyen Gen2) : Cylindrique classique, zones mortes avant/arrière
- **"Abyss"** (lourd Gen3) : Forme bulbeuse, résistance pression
- **"Mariana"** (Deep Dive) : Sphère allongée, overload minimal
- **"Colossus"** (très lourd Gen4) : Multi-segments, zones overload entre sections
#### Châssis Breakthrough Uniques
**"Metamaterial Frame"** (tous domaines)
- **Grille adaptive** : Change de forme selon besoins
- **Breakthrough requis** : "Programmable Matter"
- **Bonus** : Reconfiguration temps réel
- **Malus** : Coût astronomique
**"Plasma Shield Chassis"** (terrestre/naval)
- **Grille standard** + champ plasma
- **Breakthrough requis** : "Plasma Containment"
- **Bonus** : Immunité projectiles cinétiques
- **Malus** : Consommation énergie massive
**"Quantum Tunneling Frame"** (submersible uniquement)
- **Grille quantique** : 4x4 mais espace infini
- **Breakthrough requis** : "Applied Quantum Mechanics"
- **Bonus** : Capacité interne illimitée
- **Malus** : Instabilité dimensionnelle
## Layers
Les frames sont les bases de chaque layer d'un matériel. Cela peut varier en fonction de la base d'un matériel : le châssis.
**Ce qu'on peut construire avec les châssis** :
Le même châssis peut servir à différents rôles selon ce qu'on y installe :
**Châssis terrestre léger à roues** :
- Avec IA autonome → drone terrestre UGV
- Avec cabine pilote → camion de transport
- Avec blindage + mitrailleuse → véhicule de reconnaissance
- Avec compartiment personnel → transport de troupe léger
**Châssis chenillé moyen** :
- Avec canon 30mm + compartiment → IFV
- Avec blindage renforcé + mitrailleuses → APC
- Avec canon 120mm → char léger
- Avec équipement génie → véhicule du génie
**Châssis volant léger** :
- Avec IA + caméra → drone de surveillance
- Avec cabine pilote → hélicoptère léger
- Avec armement guidé → drone kamikaze
- Avec compartiment médical → évacuation sanitaire
**Châssis volant lourd** :
- Avec soute à bombes → bombardier
- Avec compartiment cargo → transport
- Avec radar + missiles → intercepteur
- Avec équipement guerre électronique → AWACS
**Châssis naval moyen** :
- Avec hélipad → frégate ASW
- Avec VLS → destroyer
- Avec canons → croiseur léger
- Avec IA autonome → drone naval USV
**Châssis submersible** :
- Avec torpilles → sous-marin d'attaque
- Avec missiles balistiques → SSBN
- Avec compartiment cargo → transport furtif
- Avec IA + capteurs → UUV de reconnaissance
### 3 Layers principaux
1. **Châssis** (mobilité, armure, structure)
2. **Systèmes** (IA, transmetteurs, radiateurs, électronique)
3. **Armes & Capteurs** (optiques, canons, radars, ERA)
## Composants
Les composants sont les éléments qui sont placés dans les frames. Ils ont des formes variées, rarement carrées et jamais 1x1.
### Diversité Massive de Composants
**Principe** : Des centaines de composants uniques, chacun avec forme, taille et caractéristiques propres.
#### Exemples Layer Châssis
```
Moteur Diesel Compact Moteur V8 Racing Turbine Jet
[█][█] [█] [█] [█][█][█]
[█] [█][█][█] [█][█][█]
[█] [█]
Suspension Active Réservoir Principal Transmission CVT
[█] [█] [█][█][█][█] [█]
[█] [█][█][█][█] [█][█][█]
[█] [█] [█][█][█][█] [█]
Blindage NERA Cage Survie Flotteurs Amphibie
[█][█][█][█][█] [█] [█] [█][█] [█][█]
[█][█][█][█][█] [█][█] [█] [█]
```
#### Exemples Layer Systèmes
```
CPU Basique IA Tactique v3 Quantum Processor
[█][█] [█][█][█] [█]
[█][█][█] [█][█][█]
[█] [█]
Radio HF Système AEGIS ECM Suite
[█] [█] [█][█][█][█]
[█] [█][█][█] [█][█][█][█]
[█] [█][█][█]
Cooling Liquid Heat Pump Radiateur Graphène
[█][█][█] [█][█] [█] [█]
[█] [█] [█]
```
#### Exemples Layer Armes & Capteurs
```
Canon 30mm Missile VLS Railgun Exp.
[█] [█][█] [█]
[█] [█][█] [█]
[█] [█][█] [█]
[█][█] [█]
[█]
Optique x10 Radar AESA Sonar Passif
[█] [█][█][█][█] [█][█]
[█] [█][█]
ERA Block Trophy APS Laser CIWS
[█] [█] [█] [█][█]
[█][█] [█][█]
[█] [█] [█][█]
```
**Formes communes** :
- **Forme L** : Radiateurs, tuyaux cooling (2x2 en L)
- **Forme T** : Systèmes de distribution énergie (3x2 en T)
- **Forme I** : Canons, missiles (1x3, 1x4, 1x5)
- **Forme Z** : Composants électroniques complexes
- **Forme +** : Hubs de connexion, joints universels
- **Forme Rectangle** : Blindage, batteries (2x3, 2x4, jamais carré)
**Tailles minimales** :
- **Exceptions 1x1** : ERA blocks, capteurs basiques (seuls composants 1x1)
- **Plus petit standard** : 1x2 (optiques simples)
- **Standard petit** : 2x2 en forme L ou 1x3
- **Standard moyen** : 2x3, 3x2, formes irrégulières
- **Gros composants** : 3x4+, souvent formes complexes
### Explosion de Variantes par Technologie
**Principe** : Une seule tech débloque 5-15 variantes adaptées aux différents usages
#### Exemple : Tech "Autocannon Gen3" débloque :
```
25mm Chain Gun 30mm Bushmaster 35mm Oerlikon
[█] [█] [█][█]
[█] [█] [█][█]
[█] [█] [█][█]
[█]
40mm Bofors CT 20mm Gatling 30mm Coaxial
[█][█] [█][█][█] [█]
[█][█] [█] [█]
[█][█]
```
- **25mm** : Léger pour IFV rapides (forme I mince)
- **30mm** : Standard IFV/APC (forme I standard)
- **35mm** : Anti-aérien (forme rectangle)
- **40mm** : Support lourd (forme L)
- **20mm Gatling** : Haute cadence (forme T)
- **30mm Coaxial** : Compact pour tourelle (forme courte)
#### Exemple : Tech "Composite Armor v2" débloque :
```
NERA Light (IFV) Chobham Standard Dorchester Heavy
[█][█][█] [█][█][█][█] [█][█][█][█][█]
[█][█][█][█] [█][█][█][█][█]
[█][█][█][█][█]
Cage Armor Slat Kit Appliqué Module
[█] [█] [█] ═══════ [█][█]
[█] [█] [█] ═══════ [█][█]
═══════ [█]
```
#### Variations par Génération
**Gen 1 (1960s)** : Formes simples, robustes
- Canon 105mm L7 → 3 variantes (standard, court, long)
- Moteur diesel basique → 2 variantes (truck, tank)
**Gen 2 (1980s)** : Diversification
- Canon 120mm smoothbore → 6 variantes (L44, L55, compact, etc.)
- Moteur turbodiesel → 5 variantes (power/efficiency trade-offs)
**Gen 3 (2000s)** : Spécialisation
- Canon 120mm advanced → 10 variantes (urban, long-range, autoloader, etc.)
- Moteur hybride → 8 variantes (diesel-electric, turbine-electric, etc.)
**Gen 4 (2020s)** : Explosion des options
- Railgun experimental → 12 variantes (energy levels, sizes, cooling)
- Moteur full-electric → 15 variantes (battery types, power outputs)
#### Impact sur le Gameplay
**Pour le Joueur** :
- Une tech = choix stratégiques multiples
- Optimisation selon doctrine (speed vs armor vs firepower)
- Mix & match pour designs uniques
**Pour l'IA** :
- Companies développent préférences (Rheinmetall → gros canons)
- Évolution designs selon retours terrain
- Émergence de "schools of thought" régionales
**Total avec variations** :
- ~100 technologies principales
- × 5-15 variantes chacune
- = **1000-1500 composants réels dans le jeu**
**Règles d'exclusivité** :
- Composants généralement exclusifs par layer
- **Exception** : Certains composants de protection peuvent être partagés entre layers
### Système d'Amélioration Générique
**Principe** : Améliorations universelles applicables à toute catégorie d'équipement, stackables à l'infini avec rendements décroissants.
#### Améliorations Universelles par Catégorie
**Pour TOUTES les Armes** :
- **High ROF** : Cadence de tir +X%, chaleur +40% (non réduit)
- **High Velocity** : Vitesse projectile +X%, recul +30%
- **Match Grade** : Précision +X%, temps production +50%
- **Extended Barrel** : Portée +X%, poids +20%
- **Reliability** : MTBF +X%, coût maintenance -30%
**Pour TOUS les Moteurs** :
- **Turbo** : Puissance +X%, conso fuel +50%, chaleur +40%
- **Efficiency** : Conso fuel -X%, puissance -15%
- **High Torque** : Couple +X%, vitesse max -20%
- **Reliability** : Durabilité +X%, performance -10%
**Pour TOUS les Systèmes** :
- **Overclocking** : Performance +X%, élec +60%, chaleur +50%
- **Efficiency** : Conso élec -X%, performance -20%
- **Redundancy** : Fiabilité +X%, poids +30%
- **Miniaturization** : Poids -X%, coût +40%
#### Formule de Stacking
```
Bonus effectif = Bonus_base × (1/2)^(n-1)
où n = nombre de fois appliqué
Exemple High ROF:
1er: +20% ROF (120% total)
2e: +10% ROF (130% total)
3e: +5% ROF (135% total)
4e: +2.5% ROF (137.5% total)
Malus: TOUJOURS COMPLET
1er: +40% chaleur
2e: +40% chaleur (80% total!)
3e: +40% chaleur (120% total!!)
4e: +40% chaleur (160% total!!!)
Coût: Exponentiel modéré
Coût_final = Coût_base × 1.25^n
1 amélio: ×1.25
2 amélios: ×1.56
3 amélios: ×1.95
4 amélios: ×2.44
```
**Spécialisation** (bonus contextuel):
- **Arctic Package** : Fonctionne à -60°C, +15% coût
- **Desert Sealing** : Immunité sable, +20% coût
- **Urban Kit** : +30% rotation tourelle, -10% armure top
- **Naval Coating** : Anti-corrosion marine, +25% coût
#### Exemple Concret : Canon 30mm avec Multi-Stack
**Base** :
- 30mm Autocannon : 600 RPM, 100 damage, chaleur 50
**Application de 3× High ROF** :
```
Stack 1: +20% ROF → 720 RPM, chaleur +40% (70 total)
Stack 2: +10% ROF → 792 RPM, chaleur +40% (90 total)
Stack 3: +5% ROF → 831 RPM, chaleur +40% (110 total)
Coût: 100 × 1.25³ = 195 unités
Résultat: 831 RPM mais chaleur ×2.2!
```
**Application mixte (ROF + Velocity + Reliability)** :
```
High ROF: +20% cadence, +40% chaleur
High Velocity: +20% dégâts, +30% recul
Reliability ×2: +20% MTBF puis +10% MTBF
Coût: 100 × 1.25⁴ = 244 unités
Résultat: Arme polyvalente mais très chère
```
#### Exemples Extrêmes de Stacking
**"Chaingun of Doom" (6× High ROF)** :
```
Base: 600 RPM, 50 chaleur
Final: 945 RPM, 290 chaleur (!!)
Coût: ×3.81
→ Nécessite système cooling dédié énorme
```
**"Eco Motor" (4× Efficiency)** :
```
Base: 50L/100km, 300hp
Final: 31L/100km, 195hp (-35% perf totale!)
Coût: ×2.44
→ Autonomie excellente, performance médiocre
```
**"Glass Cannon Railgun" (ROF×3 + Velocity×3)** :
```
Base: 1000 damage, 10s reload, 500kW
Final: 1350 damage, 6.5s reload
Chaleur: +120%, Recul: +90%, Élec: 500kW
Coût: ×4.77
→ DPS massif mais ingérable sans support
```
#### Règles de Stacking
**Pas de limite** au nombre d'améliorations :
- Stack même amélioration = rendements décroissants
- Mix différentes amélios = synergie ou conflits
- **Forme reste IDENTIQUE** peu importe le stack
- Malus s'accumulent linéairement (danger!)
### Amélioration de Châssis
**Principe** : Les châssis peuvent aussi être améliorés mais avec coûts exponentiels et nouvelles ressources requises.
#### Améliorations Châssis Spécifiques
**Châssis "Griffon" Gen2 (base)** :
```
Base: 100 Steel
Forme: Octogone 8x14, zones mortes standard
+1 amélio: 125 Steel + 20 Composite
+2 amélios: 156 Steel + 40 Composite + 15 Titanium
+3 amélios: 195 Steel + 80 Composite + 35 Titanium
+4 amélios: 244 Steel + 160 Composite + 65 Titanium + 10 Ceramics
+5 amélios: 305 Steel + 320 Composite + 120 Titanium + 25 Ceramics
```
**Types d'améliorations châssis** :
- **Reinforced Structure** : +30% HP, +20% poids
- **Lightweight Frame** : -25% poids, -15% protection, +coût
- **Extended Grid** : +2 cases overload possibles
- **Improved Geometry** : -1 zone morte, +coût massif
- **Modular Mounting** : +1 zone centrale (critique → standard)
- **Composite Upgrade** : +20% résistance, +nouvelles ressources
#### Exemples Concrets
**"Griffon" Enhanced (3 amélios)** :
```
Base form: [X]●●●●[X]
●●●●●●●●
●▲▲▲▲●●
■■▲▲▲▲■■
Enhanced: [O]●●●●[O] (+Extended Grid)
●●●●●●●●
●▲▲▲▲▲●● (+Modular Mounting)
■●▲▲▲▲●■ (+Improved Geometry)
Coût: 195 Steel + 80 Composite + 35 Titanium
Bonus: +2 overload zones, +1 centrale, -2 zones mortes
```
**"Lynx" Ultra-Light (4 amélios)** :
```
4× Lightweight Frame stacked:
-25%, -12.5%, -6.25%, -3.125% = -43% poids total
-15%, -15%, -15%, -15% = -60% protection!!
Coût: 244 Steel + 160 Composite + 65 Titanium + 10 Ceramics
Résultat: Châssis papier mais ultra-rapide
```
#### Ressources Avancées Requises
**Composite Materials** :
- Requis pour améliorations châssis moyennes
- Production complexe (Carbon + Resin + Pressure)
**Titanium** :
- Châssis haute performance
- Ressource rare, extraction difficile
**Ceramics** :
- Améliorations extrêmes (5+ stacks)
- Tech très avancée requise
**Metamaterials** :
- Améliorations breakthrough uniquement
- Coûts astronomiques
#### Impact Économique
**Escalade des coûts** :
- Châssis Gen1 amélioré peut coûter plus qu'un Gen4 standard
- Nouvelles supply chains requises (Titanium, Ceramics)
- Choix stratégique : few super-châssis vs many standard
**Trade-offs** :
- Châssis perfect = 90% du budget véhicule
- Reste peu pour composants advanced
- Peut valoir le coup pour designs spécialisés
**Impact Stratégique** :
- Components peuvent devenir **ultra-spécialisés**
- Châssis custom = signature builds
- Stack moderé = optimal, stack extrême = niche
- Nécessite blueprints pour gérer complexité
- **Ressources tier-2** deviennent critiques
#### Conséquences Système
**Problèmes en cascade** :
- Canon overclocked → +80% chaleur → besoin 2x radiateurs
- Moteur racing → +100% fuel → réservoirs plus gros ou autonomie divisée
- IA overclocked → +60% élec → générateur supplémentaire requis
- Tout overclock → système cooling peut saturer → shutdown combat
**Choix tactiques** :
- Full performance = logistique cauchemar (fuel, maintenance)
- Efficacité max = performance médiocre mais autonomie
- Balance = compromis selon doctrine
#### Impact sur le Meta
**Designs uniques** :
- Même avec composants identiques, deux véhicules jamais pareils
- Companies IA ont préférences d'amélioration selon features
- Joueur peut créer designs signature
**Trade-offs stratégiques** :
- Performance maximale vs coût raisonnable
- Spécialisation vs polyvalence
- Production rapide vs qualité optimale
**Total possibilités** :
- 1500 composants de base
- × 5-10 améliorations possibles chacun
- × Combinaisons de 1-3 améliorations
- = **Millions de variantes possibles**
### Système de Blueprints Multi-Échelles
**Principe** : Sauvegarder et réutiliser des designs à toutes les échelles, du composant au véhicule complet.
#### Niveaux de Blueprints
**1. Micro-Blueprints (Arrangements de composants)**
```
"Power Module v3" (4x3 sauvegardé)
[Motor][Motor][Radiator]
[Motor][Motor][Battery ]
[Trans][Trans][Battery ]
[Trans][Trans][Generator]
→ Réutilisable dans tous mes designs futurs
```
**2. Layer Blueprints (Layer complet)**
```
"Châssis Standard IFV" (Layer 1 complet)
- Arrangement moteur/transmission testé
- Blindage optimisé zones critiques
- Suspension équilibrée
→ Compatible avec châssis "Lynx", "Griffon", etc.
```
**3. Système Blueprints (3 layers combinés)**
```
"Urban Fighter Mk2" (Système complet)
- Layer 1: Châssis mobilité urbaine
- Layer 2: Systèmes com/cooling optimisés
- Layer 3: Armes courte portée + APS
→ Adaptable à différents châssis de même classe
```
**4. Véhicule Blueprint (Design final)**
```
"Viper AT-4" (Véhicule complet)
- Châssis: "Desert Runner" Gen3
- Système: "Tank Hunter v5"
- Améliorations: Tous les overclocks
→ Production directe en usine
```
#### Gestion et Partage
**Organisation personnelle** :
```
Mes Blueprints/
├── Micro/
│ ├── Power/
│ │ ├── Compact_Power_2x3.bp
│ │ └── Racing_Power_4x3.bp
│ ├── Weapons/
│ │ └── AT_Combo_3x4.bp
│ └── Cooling/
│ └── Max_Cool_2x4.bp
├── Layers/
│ ├── Châssis_Speed.bp
│ └── Système_Overclocked.bp
├── Systèmes/
│ └── Glass_Cannon_Full.bp
└── Véhicules/
├── MBT_Fortress.bp
└── IFV_Swarm.bp
```
**Partage communautaire** :
- **Export/Import** : Fichiers .bp partageables
- **Workshop** : Blueprints notés par la communauté
- **Company Blueprints** : IA companies ont leurs propres bibliothèques
- **Évolution** : Blueprints peuvent être fork et modifiés
#### Adaptation et Compatibilité
**Micro → Universel** :
- Module 4x3 fonctionne dans tout châssis avec 4x3 libre
- Rotation/miroir automatique possible
- Alerte si incompatible (forme/taille)
**Layer → Semi-flexible** :
- Adapté aux châssis de même génération/style
- Ajustements mineurs automatiques possibles
- Warning si sub-optimal
**Système → Contraintes** :
- Besoin châssis compatible (taille/forme similaire)
- Peut nécessiter adaptations manuelles
- Preview montre conflits potentiels
#### Interface de Blueprint
```
[Conception Véhicule]
┌─────────────────────┬────────────────┐
│ Grille Active │ Blueprints │
│ │ ┌Favoris──────┐│
│ [Current Design] │ │☆ Power v3 ││
│ │ │☆ AT Combo ││
│ [Drag Blueprint→] │ │☆ Cool Max ││
│ │ └──────────────┘│
│ │ ┌Recent───────┐│
│ │ │ IFV Urban ││
│ [Drop Zone] │ │ Tank Rush ││
│ │ └──────────────┘│
└─────────────────────┴────────────────┘
[Save Current as Blueprint]
Type: [Micro|Layer|System|Vehicle]
Name: [_________________]
Tags: [Urban][Speed][Gen3]
```
#### Méta-Évolution
**Itération rapide** :
1. Design initial → test combat
2. Identifier module problématique
3. Remplacer juste ce module via micro-blueprint
4. Re-test → save nouvelle version
**Lignées de designs** :
```
MBT_Heavy_v1 (original)
├── MBT_Heavy_v2 (cooling fix)
├── MBT_Heavy_Urban (fork urbain)
│ └── MBT_Heavy_Urban_ERA (+ protection)
└── MBT_Heavy_Desert (fork désert)
└── MBT_Heavy_Desert_Eco (- conso)
```
**Impact stratégique** :
- Designs éprouvés deviennent "meta"
- Companies développent styles signature
- Joueur accumule bibliothèque personnelle
- Transfert de savoir entre parties
### Synergies
Il est important de mettre en place une synergie entre certains composants pour que leur contact dans la grille les rende plus efficaces.
**Types de synergies** :
1. **Synergie existentielle** : composants simplement présents dans la même frame
2. **Synergie couplée** : composants se touchent au moins une fois en un point
3. **Synergie de contact étendue** : composants se touchent le plus possible pour obtenir le plus gros bonus
- Calcul par nombre de faces adjacentes
- Visualisation : highlight des faces en contact avec micro-animation brillante
### Systèmes spéciaux
**Température** :
- **Sources de chaleur** : Puces IA dans layer systèmes, armes (railgun, canons)
- **Gestion** : Radiateurs dans layer systèmes pour refroidissement
- **Système dynamique** : Heat accumulation en temps réel selon utilisation
- **Overload system** : Possibilité de dépasser seuil thermique contre dégâts
- **Gestion IA** : IA combat gère automatiquement la température (pas le joueur)
- **Balance** : Avantage joueur contrebalancé par contraintes thermiques
**Qualité d'assemblage** :
- **Conception** : Design "parfait" dans l'interface de conception
- **Production** : Réduction qualité lors de l'assemblage automatique si placement non-optimal
- **Systèmes optimisables** : Chaque système peut être optimisé (pas de plan unique)
- **Designs OP** : Existence de designs/assemblages optimaux découvrables
- **Erreurs placement** : Réduisent qualité du système final
- **Upgrades bras** : Bras meilleure précision + bras de "lob" pour composants
- **Règle** : Penser à l'assemblage dès la conception pour éviter pénalités
**Châssis Overload** :
- **Principe** : Possibilité d'ajouter cases de conception au-delà des limites initiales
- **Limites** : Nombre max de cases d'overload défini par châssis + tech déblocables
- **Châssis différenciés** : Certains châssis plus "overload-friendly" que d'autres
- **Pénalités linéaires** par châssis : malus % sur fiabilité, vitesse, cooling, poids
- **Conséquences cascade** :
- Poids élevé → terrains impraticables, trains solides requis
- Cooling réduit → surchauffe plus rapide
- Fiabilité réduite → maintenance accrue
- **Timing** : Overload recommandé lors des refits (pas conception initiale)
- **IA tactique** : Sélection véhicules selon mission (haut risque = overloadés)
- **Coût réel** : Prix production des composants avancés (recherche)
- **Compensation** : Nouveaux composants tech compensent partiellement malus
- **Encouragement cycle armes** : Armes évoluent petit→moyen→gros, forçant overload ou châssis lourds
**Maintenance & Refit** :
- **Usure progressive** : Barrels d'armes deviennent inutilisables après usage intensif
- **Maintenance préventive** : Remplacement composants usés avant panne
- **Refit modifications** : Ajouter ERA, changer canon, upgrade composants
- **Usine obligatoire** : retour en usine pour modifications majeures
- **Usines de terrain** : maintenance basique et réparations d'urgence
- **Pièces de rechange** : Stock et logistique des composants critiques
## Valeurs des véhicules
### Valeurs par élément
- **Armure** (int)
- **HP** (int)
- **Profile** (int)
### Valeurs globales
- **HP** (int)
- **Multidmg aérien** (double) - armure du toit
- **Multidmg rear** (double) - armure arrière
- **Multiatk flank** (double)
- **Turret down is vehicule down** (bool)
- **Vmax** (int)
- **Accélération** (int)
- **Précision de tir** (double)
- **Précision de visée** (double)
- **Profile total** (int)
- **Reliability** (int %)
## Techniques de l'armée
### Catégories d'unités
*Tous les aspects doivent être applicables à toutes les factions*
**Infanterie** :
- Unité d'occupation de terrain
- Puissante par ses capacités polyvalentes et sa discrétion naturelle
**Véhicule de transport** :
- Transport de troupe, transport logistique, medevac
- Gamme : camion → M113
**IFV** :
- Doit être capable de transporter du personnel
- Exemple : Merkava comme IFV
**MBT** : Char de bataille principal
**Missiles** :
- Munition capable de se diriger
- Inclut artillerie guidée
- Missiles stratégiques : SCALP, Tomahawk
- Drones kamikaze stratégiques : Shahed
- Drones FPV ukrainiens
**Drone copter**
**Hélicoptère** : moteur "unique" mais lourd
**Jet léger** : un moteur
**Jet lourd** : deux moteurs
**Transport aérien**
**Bombardier lourd** : 3+ moteurs
## IA militaire
### Prévention des glitches
Il vaut mieux éviter qu'on puisse glitcher l'IA, et surtout de manière éternelle.
**Exemple de timeout sur pathfinding** :
1. IASystem give : "Soldat go to B (point A vers B)"
2. GameServer : "copy timeout is 30tick"
3. GameServer in 30ticks fails to move to the point
4. GameServer : "Soldat pathfinding failed from A to B"
5. IASystem : "Soldat go to C" (position de C totalement différente)
**Problème** : Si le soldat est bloqué de tous les côtés → proposer la destruction des obstacles ?
## Performance Combat Server
### Gestion de milliers d'unités
- **Adaptive tick rate** : 60→15 TPS sous charge
- **Simulation temps réel** complexe
- **Batailles massives** : 10k unités = 30 secondes de traitement
- **Background processing** : player continue autres tâches pendant combats
### Architecture performance
- **Langages** : C++/C/ASM pour calculs critiques
- **Scope étendu** : Infantry, véhicules, aviation, missiles, logistique militaire
- **Actions normales** intégrées : assaut, reconnaissance, soutien, etc.

View File

@ -0,0 +1,98 @@
# Systèmes techniques
## Tile System
### Superficies
- **Océan** : 362 000 000 000 m²
- **Total** : 510 000 000 000 m²
- **Terre** : 148 000 000 000 m² (118.4 Go)
- **Urbain** : 4 440 000 000 m² (3.552 Go)
### Référence Minecraft
- MC 256x256 = 3 540 ko
## Gestion mémoire
### Game Chunk max DD Absolue pire cas (256x256)
- **Land** : 131 ko
- **Ressources** : 393 ko
- **Build** : 459 ko
- **Roof** : 131 ko
- **Effect** : 131 ko
- **Total** : 1 245 ko
### Game Chunk RAM (256x256)
- **Land** : 131 ko
- **Ressources** : 655 ko
- **Build** : 720 ko
- **Roof** : 131 ko
- **Effect** : 131 ko
- **Total** : 1 768 ko
## Architecture Multi-Échelle des Chunks
### Principe de Design
Différents types de données utilisent différentes résolutions de chunks selon leur granularité naturelle et leurs besoins de performance.
### Hiérarchie des Échelles
#### Chunk 512x512 - Terrain de Base
**Usage** : Données homogènes sur grandes zones
- **landId** : 16b - Texture de la tile (potentiel modificateur) DD/Ram
- **roofId** : 16b - Identification toitures/couverture sol
- **Justification** : Terrain change peu, grandes zones homogènes
- **Mémoire** : Toujours en RAM (données de base)
#### Chunk 256x256 - Structures et Bâtiments
**Usage** : Bâtiments et constructions moyennes/grandes
- **buildingPtr** : 32b "DD"/Ram
```cpp
{
BuildingId : 32b DD/Ram
Collision : 4b Ram
PV : 20b DD(24b)/Ram
}
```
- **Justification** : Bâtiments ont taille intermédiaire, besoin résolution moyenne
- **Mémoire** : Chargement à la demande
#### Chunk 128x128 - Effets et Détails Fins
**Usage** : Effets visuels, particules, détails haute fréquence
- **effectId** : 16b
- **Justification** : Effets nécessitent granularité fine pour précision
- **Mémoire** : Streaming selon proximité joueur
#### Chunk 64x64 - Gameplay Principal
**Usage** : Simulation de base, FOW, navigation (documenté dans map-system.md)
- **Justification** : Échelle optimale pour mécanique Factorio-like
- **Mémoire** : Core gameplay, chargement prioritaire
### Système Ressources (Indépendant)
**ResourcePatches** : Formes libres non-alignées sur chunks (78x53 exemple)
- **Justification** : Gisements naturels ne respectent pas grilles artificielles
- **Documentation** : Détails complets dans map-system.md
- **Mémoire** : Chargement selon exploration et exploitation
### Avantages Architecture Multi-Échelle
- **Performance optimisée** : Chaque donnée à sa résolution naturelle
- **Mémoire efficace** : Granularité adaptée aux besoins d'accès
- **Scaling intelligent** : Pas de sur-échantillonnage ni sous-échantillonnage
- **Maintenance** : Systèmes indépendants, modifications isolées
## Stack technique
### Langages de performance
- **C++ / C / ASM** pour performance critique
- **Justification** : Simulation temps réel complexe + milliers d'unités
- **Compromise** : Complexité dev acceptable vs performance requirements
### Optimisations performance
#### Adaptive Tick Rate
- **Normal** : 60 TPS
- **Sous charge** : 15 TPS
- **Principe** : Dégradation gracieuse selon la charge
#### Queue Systems
- Batch processing pour opérations coûteuses
- Future scaling : clustering dynamique per module

View File

@ -0,0 +1,59 @@
# Updates Long Terme
## Fonctionnalités futures à développer
### Espionnage Industriel
- **Vol de breakthroughs** : Mécaniques permettant aux companies de voler les technologies d'autres actors
- **Protection IP** : Systèmes de sécurisation des technologies sensibles
- **Contre-espionnage** : Défenses contre tentatives d'infiltration technologique
- **Réseaux d'espions** : Agents infiltrés dans companies concurrentes
### Factory Benchmarking System
**Concept** : Conversion des usines stables en lookup tables pour performance optimale
**Inspiration** : Modèle Mindustry pour optimisation usines à grande échelle
- Détection automatique patterns d'input/output stables
- Conversion vers calculs O(1) pour scaling optimal
- Maintien précision comportement vs simulation complète
**Process envisagé** :
1. Factory neuve → full simulation détaillée
2. Après X cycles stables → benchmark input/output ratios
3. Conversion en lookup table → unload detailed simulation
4. Recalibrage si modifications (upgrades, dégâts)
**Justification report** : Optimisation prématurée, focus sur gameplay core d'abord
### Économie avancée
- **Balance commerciale** : États surveillent imports/exports
- **Inflation** : Système d'impression monétaire et dévaluation en temps de guerre
- **Économie noire** : Marchés parallèles dans zones de conflit
### Interface et Vues
- **Vues multiples simultanées** : Plusieurs vues locales ouvertes en même temps
- **Split-screen** : Surveiller plusieurs zones/usines simultanément
- **Picture-in-picture** : Mini-vues dans vue principale
### Système de Communication
- **Système de messages** : Communication asynchrone entre joueurs
- **Diplomatie formalisée** : Propositions, traités, accords commerciaux
- **Intel sharing** : Partage de reconnaissance entre alliés
### Limites Techniques Map
- **Chunks actifs max** : Limite nombre chunks simultanés pour performance
- **Distance rendu max** : LOD et culling selon distance
- **Joueurs par zone** : Limite joueurs dans même zone locale
- **Optimisations mémoire** : Compression chunks inactifs
- **Streaming adaptatif** : Ajustement qualité selon bande passante
### Génération Procédurale Avancée
- **Cultures urbaines** : Styles architecturaux par région/pays
- **Continuité améliorée** : Algorithmes liaison inter-chunks
- **Biomes complexes** : Transitions naturelles entre terrains
### Autres fonctionnalités à explorer
*À compléter selon l'évolution du projet*
---
*Ce document liste les fonctionnalités prévues pour les mises à jour futures du jeu*

View File

@ -0,0 +1,34 @@
# Vue d'ensemble du projet
## Vision et objectifs
- **Concept général** : Jeu d'usine avec une composante militaire forte
- **Inspiration** : Factorio-like avec dimension stratégique militaire
- **Principe clé** : L'importance du choix à tous les niveaux
- **Progression** : De PMC vers opérations conventionnelles, impact du joueur grandit avec le temps
## Philosophie de design
### Clarté et simplicité
- Interface claire avec pictogrammes simples pour éviter la fausse complexité
- Jeu déjà complexe nécessitant une présentation accessible
### Aspect usine
- La ligne d'assemblage soit le cœur
- La doctrine militaire que le joueur s'est trouvée indique les besoins industriels
- L'énergie c'est facile à gérer
- L'extraction c'est facile
### Aspect militaire
- Le joueur doit se trouver sa propre doctrine et créer son gameplay
- Mettre en avant le concept de doctrine d'emploi
- La contemplation du combat
- IA qui donne du feedback de sa compétence ou de sa médiocrité
- Bien que le contrôle direct soit important, il n'est pas le cœur
### Progression militaire
- Dans un premier temps on se cantonner à des opérations irrégulières
- L'impact du joueur grandit avec le temps
## Inspiration Undertale
- S'inspirer d'Undertale pour la partie choix géopolitique

107
docs/serveur/README.md Normal file
View File

@ -0,0 +1,107 @@
# Server Coordinator Documentation
## Overview
The **Server Coordinator** orchestrates communication between the 10 autonomous engines and manages the Smart Client architecture.
**Key Responsibilities:**
- Engine coordination and communication routing
- Smart Client request/response management
- Performance monitoring and load balancing
- System-wide state synchronization
## Architecture
### Smart Client Pattern
From `architecture-technique.md`:
- **Request/Response Only**: No streaming, stateless communication
- **Engine Autonomy**: Engines operate independently between requests
- **Performance Target**: 60fps with 1000+ AI companies
- **FOW Granularity**: Chunk-level fog of war coordination
### Engine Coordination
- **Inter-Engine Communication**: Message routing between engines
- **State Synchronization**: Coordinated updates across engine boundaries
- **Event Broadcasting**: Global events distributed to all engines
- **Performance Monitoring**: Engine load balancing and optimization
## Core Systems
### Communication Hub
```cpp
class ServerCoordinator {
// Engine management
void registerEngine(EngineType type, std::shared_ptr<Engine> engine);
void routeMessage(const Message& message);
void broadcastEvent(const GlobalEvent& event);
// Client management
void handleClientRequest(const ClientRequest& request);
ClientResponse processRequest(const ClientRequest& request);
void updateClientFOW(int clientId, const FOWUpdate& update);
// Performance monitoring
void monitorEnginePerformance();
void balanceEngineLoads();
PerformanceMetrics getSystemMetrics() const;
};
```
### Engine Communication Patterns
#### Economy ↔ Factory
- Production cost calculations
- Resource availability updates
- Manufacturing order processing
#### War ↔ Operation
- Battle result analysis
- Strategic learning data
- Tactical coordination
#### Intelligence ↔ All Engines
- Metrics collection from every system
- FOW updates and coordination
- Performance analytics
#### Event → All Engines
- Global event broadcasting
- Breakthrough notifications
- System-wide state changes
### Client Request Processing
From `architecture-technique.md`:
1. **Request Validation**: Ensure client permissions and data integrity
2. **Engine Routing**: Direct requests to appropriate engines
3. **State Coordination**: Manage cross-engine dependencies
4. **Response Assembly**: Compile responses from multiple engines
5. **FOW Filtering**: Apply visibility restrictions per client
### Performance Requirements
- **60fps Target**: Maintain real-time performance
- **1000+ Companies**: Scale to massive multiplayer scenarios
- **Engine Autonomy**: Minimize blocking between engines
- **Memory Efficiency**: Optimize inter-engine communication
## Key Integration Points
### Fog of War Coordination
- **Intelligence-Engine**: FOW state management
- **Map-Engine**: Chunk visibility coordination
- **Client Filtering**: Per-client visibility enforcement
### Event System Integration
- **Event-Engine**: Global event generation and scheduling
- **All Engines**: Event consumption and response
- **Client Notification**: Event broadcasting to relevant clients
### Metrics and Analytics
- **Intelligence-Engine**: System-wide metrics collection
- **Performance Monitoring**: Real-time system health
- **Load Balancing**: Dynamic resource allocation
## Implementation Notes
- Smart Client pattern eliminates streaming complexity
- Engine autonomy maximizes parallel processing
- FOW at chunk granularity optimizes performance
- Message routing minimizes engine coupling