Files
gd-playground/Docs/Architecture/PROJECT_STRUCTURE.md
54shitaimzf e465f1cbb0 feat: 基础卡牌场景与卡牌逻辑可扩展框架,以及todo文档
- Added BattleState class to manage battle flow, including turn management and event handling.
- Introduced BuffInstance class to represent buffs applied to combatants.
- Created CardInstance class to handle card definitions and cost calculations.
- Developed CombatantState class to manage combatant attributes and actions.
- Implemented EffectRegistry to apply effects based on event specifications.
- Added various handlers (BlockHandler, DamageHandler, DrawHandler, etc.) to process specific events.
- Created IntentPlanner and IntentState classes to manage enemy actions and intents.
- Established a queue system for handling battle events with BattleEventQueue and BattleEventTask.
- Introduced triggers for applying effects based on game events (e.g., OnCardDrawnGainBlockTrigger).
- Added necessary UID files for new scripts to ensure proper resource management.
2026-04-22 21:58:15 +08:00

1.3 KiB

Project Structure

.
├── Game
│   ├── Application          # Use cases / commands
│   ├── Content              # Resource definitions and static data
│   │   ├── Cards
│   │   └── Test
│   ├── Infrastructure       # Event bus, registry, persistence adapters
│   ├── Presentation         # Scenes, UI, view binders
│   │   └── Cards
│   ├── Runtime              # Battle runtime state/models
│   └── Tests                # Test harness and fixtures
├── Docs
│   └── Architecture
├── addons
├── project.godot
└── Godot Playground.csproj

Notes

  • Game/Content only stores static definitions (Resource) and test resources.
  • Game/Presentation only handles visuals and input/view bindings.
  • Game/Application, Game/Runtime, Game/Infrastructure implement battle rules with GDScript.

Refactor Focus (2026-04)

  • Battle runtime is being refactored to a unified event queue model.
  • Card effects and buff effects share one execution path: enqueue event task -> handler applies state -> publish result event.
  • BattleRuleProvider will be the single strategy switch point for autoplay and draw policies.
  • Documentation-first workflow: update architecture docs before each refactor phase.