Yuki001 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-analysis.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 |
| Changing requirements in an existing implementation | references/requirement-change-strategy.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 |
| Gameplay content editor applications and authoring pipelines | references/content-editor.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 |
| Puzzle Game System (Match-3, Jigsaw, Water Sort, Blocks, Physics Puzzles, Board Games, Content & Presentation Boundaries) | references/system-puzzle.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 |
Here, Data-Driven Design means a data-structure-first programming paradigm, not specifically configuration-driven gameplay. See references/data-driven-design.md for the full terminology boundary.
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 |