PDT Cyberpunk Roguelike - Unity Architecture Documentation
Overview
This document outlines the system architecture for the PDT Cyberpunk Roguelike Unity project, designed to support a turn-based tactical grid combat game with roguelike progression mechanics.
Architecture Principles
1. Service-Oriented Architecture
- Uses Service Locator pattern for dependency management
- Promotes loose coupling between systems
- Enables easy testing and system swapping
2. Event-Driven Communication
- Event Bus system for decoupled inter-system communication
- Type-safe event handling
- Reduces direct dependencies between game systems
3. Modular Design
- Clear separation of concerns across layers
- Each system has well-defined responsibilities
- Easy to extend and maintain
System Layers
Core Infrastructure Layer
Purpose: Provides fundamental services that all other systems depend on.
Bootstrapper (Bootstrapper.cs)
- Responsibility: System initialization and startup sequence
- Key Features:
- Discovers and initializes all
IInitializablecomponents - Manages application startup flow
- Loads initial scenes
- Discovers and initializes all
- Integration: Entry point for the entire application
Service Locator (ServiceLocator.cs)
- Responsibility: Dependency injection and service discovery
- Key Features:
- Type-safe service registration/retrieval
- Prevents duplicate service registration
- Debug logging for service lifecycle
- Pattern: Singleton service registry
Event Bus (EventBus.cs)
- Responsibility: Decoupled communication between systems
- Key Features:
- Type-safe event publishing/subscribing
- Generic event handling
- Automatic cleanup of event listeners
- Usage: Post structs / data from one system out to anything that wants to listen without direct dependancy
Object Pooling System
- Responsibility: Performance optimization through object reuse
- Key Features:
- Configurable pool sizes
- Automatic object lifecycle management
- Memory optimization for frequently instantiated objects
Asset Management System
- Responsibility: Centralized asset loading and management
- Key Features:
- Asset catalogue for organized resource management
- Scene asset management
- Async asset loading support
Logging System (LoggingSystem.cs)
- Responsibility: Debug information and error tracking
- Key Features:
- Centralized logging interface
- Debug build optimizations
- Error tracking and reporting
Game Systems Layer
Purpose: Implements core game mechanics and logic.
Battle System
- Responsibility: Grid-based tactical combat
- Key Components:
- Grid management and cell states
- Turn-based combat flow
- Unit positioning and movement
- Ability execution and effects
- Integration: Uses Event Bus for combat events, Service Locator for dependencies
Unit Management System
- Responsibility: Character stats, abilities, and AI
- Key Components:
- Character stat management
- Ability system implementation
- AI behavior trees
- Animation control integration
- Data Flow: Receives input from Battle System, outputs to Presentation Layer
Progression System
- Responsibility: Run management and character advancement
- Key Components:
- Run lifecycle management
- Character upgrade systems
- Permanent unlock progression
- Pact of Punishment difficulty scaling
- Persistence: Integrates with Save System for progress tracking
World Generation System
- Responsibility: Procedural level and suburb generation
- Key Components:
- Suburb map generation
- Procedural level creation
- Grid layout algorithms
- Environmental object placement
- Integration: Feeds into Battle System for combat environments
Input System (InputManager.cs)
- Responsibility: Player input handling and mapping
- Key Components:
- Action-based input system
- Device-agnostic input handling
- UI navigation support
- Customizable control schemes
- Integration: Invokes Actions to relevant systems that are listening / subscribed
Save System (JsonManager.cs)
- Responsibility: Game state persistence
- Key Components:
- JSON-based data serialization
- Run progress tracking
- Settings and preferences storage
- Cross-session data management
- Integration: Used by Progression System and other persistent systems
Presentation Layer
Purpose: Handles all user-facing elements and feedback.
UI System
- Responsibility: User interface and menu management
- Key Components:
- Menu navigation systems
- Battle interface elements
- HUD and status displays
- Inventory and character screens
- Integration: Listens to game events, updates visual elements
Audio System
- Responsibility: Music and sound effect management
- Key Components:
- Dynamic music system
- Spatial audio for combat
- Audio mixing and balancing
- Performance-optimized audio streaming
- Integration: Responds to game events for audio cues
Visual Effects System
- Responsibility: Particle effects and visual feedback
- Key Components:
- Combat effect particles
- UI transitions and animations
- Environmental effects
- Performance-optimized effect pooling
- Integration: Triggered by battle and progression events
Rendering Pipeline
- Responsibility: Graphics rendering and optimization
- Key Components:
- URP (Universal Render Pipeline) integration
- 2D/3D hybrid rendering
- Post-processing effects
- Performance optimization techniques
- Integration: Works with all visual systems
External Systems Layer
Purpose: Integration with platform services and external libraries.
Platform Services
- Responsibility: Platform-specific integrations
- Key Components:
- Steam/platform integration
- Achievement system
- Cloud save synchronization
- Analytics and telemetry
- Integration: Uses Service Locator for registration
External Libraries
- Key Dependencies:
- UniTask: For async/await operations
- Unity Services: Platform integration
- Input System: New Unity Input System
- Purpose: Leverages proven solutions for common problems
Data Flow Patterns
1. Initialization Flow
Bootstrapper → Service Registration → System Initialization → Scene Loading
2. Game Loop Flow
Input → Event Bus → Game Systems → State Changes → UI Updates
3. Battle Flow
Input System → Battle System → Unit Management → Visual Effects → UI Updates
4. Progression Flow
Battle Results → Progression System → Save System → UI Updates
Key Design Decisions
Service Locator vs Dependency Injection
- Decision: Service Locator pattern
- Rationale: Simpler implementation, Unity-friendly, easier debugging
- Trade-off: Less explicit dependencies but more flexible for Unity workflow
Event-Driven Architecture
- Decision: Centralized Event Bus
- Rationale: Decoupled communication, easier to extend systems
- Trade-off: Slight performance overhead for maximum flexibility
Async Operations with UniTask
- Decision: UniTask over Unity Coroutines
- Rationale: Better async/await support, more performant, easier error handling
- Benefit: Modern async programming patterns
JSON for Save Data
- Decision: JSON over binary serialization
- Rationale: Human-readable, easier debugging, version-friendly
- Benefit: Better development experience and easier save system debugging
Performance Considerations
1. Object Pooling
- All frequently instantiated objects use pooling
- Reduces garbage collection pressure
- Configurable pool sizes for different object types
2. Event System Optimization
- Events are type-safe and use generics for performance
- Automatic cleanup prevents memory leaks
- Minimal boxing/unboxing overhead
3. Asset Loading
- Async asset loading prevents frame drops
- Asset catalogue enables efficient resource management
- Scene-based asset organization
4. Rendering Optimization
- URP provides better performance than built-in pipeline
- Post-processing effects are performance-tuned
- LOD and culling systems for complex scenes
Testing Strategy
Unit Testing
- Service Locator functionality
- Event Bus message passing
- Game logic systems (battle calculations, progression)
Integration Testing
- Cross-system communication via events
- Save/load functionality
- Scene transition workflows
Performance Testing
- Object pooling efficiency
- Memory allocation patterns
- Frame rate consistency during gameplay
Future Extensibility
Adding New Systems
- Implement required interfaces (
IService,IInitializable) - Register with Service Locator
- Subscribe to relevant events
- Follow established patterns
Modding Support
- Event system enables external mod integration
- Service Locator allows system replacement
- JSON save format supports custom data
Platform Extensions
- Service-oriented design supports new platform integrations
- Event system enables platform-specific features
- Modular architecture supports different build targets
Development Guidelines
Code Organization
- Follow existing namespace conventions
- Group related systems in folders
- Maintain clear separation of concerns
Performance Guidelines
- Use object pooling for frequently created objects
- Prefer events over direct method calls between systems
- Cache frequently accessed services from Service Locator
Testing Guidelines
- Write unit tests for core game logic
- Test cross-system integration via events
- Maintain test coverage for critical systems
This architecture provides a solid foundation for the cyberpunk roguelike game while maintaining flexibility for future expansion and modification.