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

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/multiplayer-overview.md

• For physical architecture design, see the Physical Architecture References table below.
• For system-specific design, see the System-Specific References table below.
• For multiplayer system design, see the Multiplayer References table below.

Note : Only read the multiplayer references when multiplayer is needed.

Physical Architecture References

When	Read
Project structure & file organization	references/project-structure.md
Data formats, processing, custom formats, bundles, metadata	references/data-files.md
Asset conventions & pipeline	references/asset-conventions.md

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
Mod & DLC System (Plugin Architecture, Config Database, Scripting, Hooks, Extensibility)	references/system-mod.md
Algorithm & Data Structures (Pathfinding, Search, Physics, Generic Solver)	references/algorithm.md

Multiplayer References

Focus	Reference	Use When
Multiplayer overview	references/multiplayer-overview.md	Decide client/server responsibility, authority split, and gameplay sync style
Multiplayer protocol and connection	references/multiplayer-protocol.md	Design messages, serialization, Req/Resp/Notify, heartbeat, reconnect
Multiplayer server architecture	references/multiplayer-server-architecture.md	Design ownership boundaries, process roles, deployment, persistence, recovery
Common server components and services	references/multiplayer-implementation-common.md	Build shared infrastructure such as auth, gateway, connector, db, cache, discovery, queue, observability
Room server build playbook	references/multiplayer-implementation-room.md	Build a concrete small-to-medium room-based realtime server with join flow, room ownership, settlement, reconnect
Encounter server build playbook	references/multiplayer-implementation-encounter.md	Build a concrete turn-based or combat-workflow server with checkpointing, idempotent actions, settlement
Persistent world server build playbook	references/multiplayer-implementation-world.md	Build a concrete AOI world server with region ownership, transfer, location registry, reconnect
Deterministic sync, lockstep, and rollback	references/multiplayer-deterministic-sync.md	Design deterministic input-sync architectures, frame pipelines, rollback, replay, and desync handling

---

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.	references/domain-driven-design.md
Data-Driven Design	Data Layer First	High Content Complexity. <br> Flow Orchestration. <br> Simple Data Management.	Content: Quests, Level Design.<br>Flow: Tutorial Flow, Skill Execution, Narrative.<br>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

---