game-architect

name	game-architect
description	READ this skill when designing or planning any game system architecture — including combat, skills, AI, UI, multiplayer, narrative, or scene systems. Contains paradigm selection guides (DDD / Data-Driven / Prototype), system-specific design references, and mixing strategies. Works as a domain knowledge plugin alongside workflow skills (OpenSpec, SpecKit) or plan mode of an agent.

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
Distribution, packaging, hot update, CDN, deployment	references/distribution.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
Camera, Character & Controller 3C (PlayerController, Physics, Camera, Actor States)	references/system-3c.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
Procedural Content Generation (PCG) (World/Level Generation, Roguelike, Noise, Simulation)	references/system-pcg.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. 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

---