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

game-architect

Installation