Trigger Scenarios

设计游戏系统架构查询游戏架构领域知识进行需求分析或系统设计规划

Install

npx skills add Yuki001/game-dev-skills --skill game-architect -g -y

More Options

Use without installing

npx skills use Yuki001/game-dev-skills@game-architect

指定 Agent (Claude Code)

npx skills add Yuki001/game-dev-skills --skill game-architect -a claude-code -g -y

安装 repo 全部 skill

npx skills add Yuki001/game-dev-skills --all -g -y

预览 repo 内 skill

npx skills add Yuki001/game-dev-skills --list

SKILL.md

Frontmatter

{
    "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`
Effect & Feedback System (Screen Shake, VFX, Hit-Stop, Haptics, SFX, Floating Text, UI Feedback, Orchestration)	`references/system-effect-feedback.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:

Macro Consistency: All modules follow the same Module Management Framework.
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).
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).
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.
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.
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