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)	references/macro-design.md
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)	references/system-foundation.md
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. Rich Domain Concepts. Many Distinct Entities.	Core Combat Logic, Physics Interactions, Damage/Buff Rules, Complex AI Decision.	references/domain-driven-design.md
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. 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.
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.
6. 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

---