Game Architect Skill

Game architecture domain knowledge reference. Provides paradigm selection, system design references for game project architecture.

[!NOTE]
This skill contains domain knowledge only, not a workflow. Pair it with a workflow skill (e.g., OpenSpec, SpecKit) or an agent's plan mode for structured design flow.

Usage Modes

With Workflow Skill (Recommended)

When used with a workflow skill (e.g., OpenSpec, SpecKit) or in the plan mode of an agent, this skill serves as a domain knowledge plugin:

• - During requirements/spec phases: Consult the Paradigm Selection Guide and System-Specific References to inform architectural decisions
• During design/planning phases: Use the Reference Lookup Guide below to read relevant references/ documents

Standalone

A lightweight workflow-standalone.md is also available as a self-contained design pipeline if needed.

Knowledge Mode (Query)

When user requests to query knowledge for game architecture, this skill provides a reference lookup guide to relevant references/ documents based on the task.

---

Reference Lookup Guide

When designing game architecture, read the relevant references/ documents based on the task:

Architecture References

When	Read
Always (high-level structure)	INLINECODE4
Always (core principles)

references/principles.md | | Requirement analysis | references/requirements.md | | Choosing DDD paradigm | references/domain-driven-design.md | | Choosing Data-Driven paradigm | references/data-driven-design.md | | Choosing Prototype paradigm | references/prototype-design.md | | Evolution & extensibility review | references/evolution.md | | Performance optimization needed | references/performance-optimization.md | | Multiplayer support needed | references/system-multiplayer.md |

For system-specific design, see the System-Specific References table below.

System-Specific References

System Category	Reference
Foundation & Core (Logs, Timers, Modules, Events, Resources, Audio, Input)	INLINECODE13
Time & Logic Flow (Update Loops, Async, FSM, Command Queues, Controllers)

references/system-time.md | | Combat & Scene (Scene Graphs, Spatial Partitioning, ECS/EC, Loading) | references/system-scene.md | | UI & Modules (Modules Management, MVC/MVP/MVVM, UI Management, Data Binding, Reactive) | references/system-ui.md | | Skill System (Attribute, Skill, Buff) | references/system-skill.md | | Action Combat System (HitBox, Damage, Melee, Projectiles) | references/system-action-combat.md | | Narrative System (Dialogue, Cutscenes, Story Flow) | references/system-narrative.md | | Game AI System (Movement, Pathfinding, Decision Making, Tactical) | references/system-game-ai.md | | Multiplayer System (Client-Server, Sync Models, Distributed Server, AOI, Communication) | references/system-multiplayer.md | | Algorithm & Data Structures (Pathfinding, Search, Physics, Generic Solver) | references/algorithm.md |

---

Paradigm Selection Guide

Paradigm	KeyPoint	Applicability Scope	Examples	Reference
Domain-Driven Design (DDD)	OOP & Entity First	High Rule Complexity. <br> Rich Domain Concepts. <br> Many Distinct Entities.	Core Combat Logic, Physics Interactions, Damage/Buff Rules, Complex AI Decision.	INLINECODE23
Data-Driven Design

Data Layer First | High Content Complexity.
Flow Orchestration.
Simple Data Management. | Content: Quests, Level Design.
Flow: Tutorial Flow, Skill Execution, Narrative.
Mgmt: Inventory, Shop, Mail, Leaderboard. | references/data-driven-design.md | | Use-Case Driven Prototype | Use-Case Implementation First | Rapid Validation | Game Jam, Core Mechanic Testing. | references/prototype-design.md |

Mixing Paradigms

Most projects mix paradigms:

1. 1. Macro Consistency: All modules follow the same Module Management Framework.
2. Domain for Core Entities & Rules: Use DDD for systems with high rule complexity, rich domain concepts, and many distinct entities (e.g., Combat Actors, Damage Formulas, AI Decision).
3. Data for Content, Flow & State: Use Data-Driven for expandable content (Quests, Level Design), flow orchestration (Tutorial, Skill Execution, Narrative), and simple data management (Inventory, Shop).
4. Hybrid Paradigms:

- 4.1 Entities as Data: Domain Entities naturally hold both data (fields) and behavior (methods). Design entities to be serialization-friendly (use IDs, keep state as plain fields) so they serve both roles without a separate data layer.
- 4.2 Flow + Domain: Use data-driven flow to orchestrate the sequence/pipeline, domain logic to handle rules at each step. E.g., Skill System: flow drives cast→channel→apply, domain handles damage calc and buff interactions.
- 4.3 Separate Data/Domain Layers: Only when edit-time and runtime representations truly diverge. Use a Bake/Compile step to bridge them. E.g., visual node-graph editors, compiled assets.

1. 5. Paradigm Interchangeability: Many systems can be validly implemented with either paradigm. E.g., Actor inheritance hierarchy (Domain) ↔ ECS components + systems (Data-Driven); Buff objects with encapsulated rules (Domain) ↔ Tag + Effect data entries resolved by a generic pipeline (Data-Driven). See Selection Criteria table above for trade-off signals.
2. Integration: Application Layer bridges different paradigms.

Selection Criteria

When both DDD and Data-Driven fit, use these signals:

Signal	Favor DDD	Favor Data-Driven
Entity interactions	Complex multi-entity rules (attacker × defender × buffs × environment)	Mostly CRUD + display, few cross-entity rules
Behavior source

Varies by entity type, hard to express as pure data | Driven by config tables, designer-authored content |
| Change frequency | Rules change with game balance iterations | Content/flow changes far more often than logic |
| Performance profile | Acceptable overhead for rich object graphs | Needs batch processing, cache-friendly layouts |
| Networking | Stateful objects acceptable | Flat state snapshots preferred (sync, rollback) |
| Team workflow | Programmers own the logic | Designers need to iterate without code changes |

---