Before calling any skill in this module: if you are about to call a skill with parameters guessed from its name or description, STOP — read this file (or fetch its schema via
GET /skills/recommend?includeSchema=true) first. If you already have the parameter definitions from recommend/schema, you may proceed straight to dryRun.
Triggers
- Deciding which pattern fits a problem
- Structuring decoupled systems
- Choosing event/state-machine/pool approaches
- 判断哪种模式适合某问题、构建解耦系统、在事件/状态机/对象池方案间抉择
Unity Pattern Selector
Use this skill to decide whether a pattern is justified. Do not recommend every pattern at once.
Guardrails
Mode: Documentation only — no REST skills to gate; load freely under any operating mode (Approval / Auto / Bypass).
- Recommend at most 1-3 patterns, and explain why simpler options are not enough.
Pattern Guide
-
ScriptableObject- Use for authored config, shared static data, event channels, and reusable data assets.
- Avoid as the default home for per-run mutable gameplay state.
-
C# events / delegates- Use for one-to-many notifications with clear ownership and unsubscribe points.
- Avoid for imperative flows that need ordering, return values, or complex debugging.
-
Global event bus / observer hub- Use sparingly and only when many systems truly need broad decoupled notifications.
- Avoid as the default answer to coupling. It often hides ownership and makes debugging harder.
-
Interfaces- Use when multiple implementations or clearer dependency boundaries are needed.
- Avoid adding interfaces around every class without a real seam.
-
State machine- Use for actors with mutually exclusive states and explicit transitions.
- Avoid when a few booleans or a small command flow is enough.
-
Object pool- Use for frequent spawn/despawn of bullets, VFX, enemies, UI items.
- Avoid for rare objects or when lifetime is simple.
-
Service layer- Use for a small number of cross-scene systems with explicit bootstrap and interfaces.
- Avoid turning everything into hidden singletons or service locators.
-
Generics / custom attributes- Use when they remove repeated boilerplate with clear type safety or editor metadata value.
- Avoid when they make gameplay code harder to read than duplicated simple code.
Decision Lab: Same Goal, Multiple Implementations
The Pattern Guide above answers "which pattern?". For most non-trivial design decisions, the better exercise is: pick the 2-3 plausible implementations, put them side by side, and compare on switch cost, query cost, code complexity, and failure modes. Below is a worked example; use it as the shape for other decisions rather than as the answer.
Worked example: "Pause AI on 100 enemies for a cutscene"
| Implementation | Switch cost (enter/exit cutscene) | Per-frame cost while paused | Code complexity | Failure modes |
|---|---|---|---|---|
Field flag: each EnemyAI.Update starts with if (_paused) return;; manager sets the flag | O(N) writes, no allocations | N branch tests + dispatch overhead per frame | Lowest — one bool, one guard clause | Silent bugs when a dev adds a new Update and forgets the guard |
enabled = false: manager disables the MonoBehaviour on every enemy | O(N) writes, no allocations | Zero — Unity skips disabled Behaviours in its message list | Low, but state spread across components | OnDisable / OnEnable side effects (coroutines stop, listeners unsubscribe) may fire unexpectedly |
Subset list: manager keeps _active / _frozen lists; no per-enemy Update — manager ticks only _active | O(N) list move on switch | Proportional to _active count only — perfect early-cull | Highest — one source of truth for ownership, requires managed ticking | Adding a new Update on enemies reintroduces per-frame cost; the list is easy to desync if other code respawns enemies directly |
How to use
- Pick the smallest scale where the trade-off matters. At N=5 all three are indistinguishable; at N=5000 only the subset list stays flat.
- State what gets worse under each option, not only what improves. A table with only upsides is a sign you haven't thought about it yet.
- The ECS lesson is that the same three shapes (value change, structural change, enableable) show up everywhere — the labels transfer even when the framework does not. Source:
Dots101/Entities101/Assets/HelloCube/13. StateChange/SetStateSystem.cs:42-80— one system dispatches to three implementations behindconfig.Mode, each with measurably different cost in the profiler.
When to skip this exercise
If one option is obviously bounded (N ≤ 10, state changes once per session, or the code runs once at startup), a single paragraph "we picked X because it's simplest" is enough. Decision Lab is for choices that will outlive the current task.
Output Format
- Recommended pattern(s)
- Why they fit this case
- Why not the simpler alternative
- Minimal implementation boundary
- Known tradeoffs
