Agent-Skills.md

Agent Skills: Game Architect Skill

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.

UncategorizedID: Yuki001/game-dev-skills/game-architect

Repository

Yuki001/game-dev-skills
Yuki001
8

Install this agent skill to your local

pnpm dlx add-skill https://github.com/Yuki001/game-dev-skills/tree/HEAD/skills/game-architect

Skill Files

Browse the full folder contents for game-architect.

Download Skill

Loading file tree…

skills/game-architect/SKILL.md

Skill Metadata

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 |

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 | | 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 |