mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 10:17:06 +00:00
Release 1.1.2 — the default path works end to end
Fix release for 1.1.1: the minimal path end to end, engine commands that run on Godot, Unity and Unreal, hook warnings you can see, and verdicts that say when they could not check. Details in CHANGELOG.md; upgrade steps in UPGRADING.md (v1.1.1 → v1.1.2). Fixes #67 Fixes #131 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WuJn2FdynEybfL5KC697nJ
This commit is contained in:
Donchitos
co-authored by
Claude Opus 5.5
Claude Opus 5.5
parent
7ed2c3e9c4
commit
b21fa0f7f2
@@ -2,17 +2,16 @@
|
||||
|
||||
## Agent Summary
|
||||
- **Domain**: Blueprint architecture, the Blueprint/C++ boundary, Blueprint graph quality, Blueprint performance optimization, Blueprint Function Library design
|
||||
- **Does NOT own**: C++ implementation (engine-programmer or gameplay-programmer), art assets or shaders, UI/UX flow design (ux-designer)
|
||||
- **Model tier**: Sonnet
|
||||
- **Gate IDs**: None; defers to unreal-specialist or lead-programmer for cross-domain rulings
|
||||
- **Does NOT own**: C++ implementation (gameplay-programmer exposes the C++ hooks Blueprint calls), art assets or shaders, UI/UX flow design (ux-designer)
|
||||
- **Gate IDs**: None; defers C++/Blueprint boundary architecture rulings to unreal-specialist
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references Blueprint architecture and optimization)
|
||||
- [ ] `allowed-tools:` list matches the agent's role (Read for Blueprint project files; no server or deployment tools)
|
||||
- [ ] Model tier is Sonnet (default for specialists)
|
||||
- [ ] `tools:` list matches the agent's role (Read/Write/Edit for Blueprint-facing files; no server or deployment tools, and Bash withheld via `disallowedTools:`)
|
||||
- [ ] Model tier is `sonnet` — frontmatter `model:` reads exactly `sonnet` (tiers: `.claude/docs/model-tiers.md`)
|
||||
- [ ] Agent definition does not claim authority over C++ implementation decisions
|
||||
|
||||
---
|
||||
@@ -23,26 +22,25 @@
|
||||
**Input**: "Review our AI behavior Blueprint. It has tick-based logic running every frame that checks line-of-sight for 30 NPCs simultaneously."
|
||||
**Expected behavior**:
|
||||
- Identifies tick-heavy logic as a performance problem
|
||||
- Recommends switching from EventTick to event-driven patterns (perception system events, timers, or polling on a reduced interval)
|
||||
- Flags the per-NPC cost of simultaneous line-of-sight checks
|
||||
- Suggests alternatives: AIPerception component events, staggered tick groups, or moving the system to C++ if Blueprint overhead is measured to be significant
|
||||
- Output is structured: problem identified, impact estimated, alternatives listed
|
||||
- Recommends switching from EventTick to event-driven patterns (perception system events, timers, or polling on a reduced interval) — never polling every frame when an event would suffice
|
||||
- Flags the per-NPC cost of simultaneous line-of-sight checks, including any loop over the NPC array inside Tick
|
||||
- Recommends profiling first (`stat game`, Blueprint profiler), and treats moving the system to C++ as warranted when the measured Blueprint overhead is significant — 30 NPCs is below its automatic C++ threshold (tick logic with more than 100 instances)
|
||||
- Output names, for each finding, the Performance Rule or Review Checklist item it breaks and the replacement pattern
|
||||
|
||||
### Case 2: Out-of-domain request — C++ implementation
|
||||
**Input**: "Write the C++ implementation for this ability cooldown system."
|
||||
**Expected behavior**:
|
||||
- Does not produce C++ implementation code
|
||||
- Provides the Blueprint equivalent of the cooldown logic (e.g., using a Timeline or GameplayEffect if GAS is in use)
|
||||
- States clearly: "C++ implementation is handled by engine-programmer or gameplay-programmer; I can show the Blueprint approach or describe the boundary where Blueprint calls into C++"
|
||||
- Optionally notes when the cooldown complexity warrants a C++ backend
|
||||
- Classifies the cooldown system with its boundary rules: ability-system logic is on its "Must Be C++" list, so it does not offer a Blueprint reimplementation of the system
|
||||
- Describes the boundary instead: C++ defines the framework and exposes hooks (`BlueprintCallable`, `BlueprintNativeEvent`, `BlueprintImplementableEvent`); Blueprint supplies tuning values (`EditAnywhere` / `BlueprintReadWrite`) and simple event responses such as cooldown feedback
|
||||
- Routes the C++ implementation to gameplay-programmer (its named partner for exposing C++ hooks to Blueprint) and the boundary decision to unreal-specialist, rather than writing the C++ system itself
|
||||
|
||||
### Case 3: Domain boundary — unsafe raw pointer access in Blueprint
|
||||
**Input**: "Our Blueprint calls GetOwner() and then immediately accesses a component on the result without checking if it's valid."
|
||||
**Expected behavior**:
|
||||
- Flags this as a runtime crash risk: GetOwner() can return null in some lifecycle states
|
||||
- Provides the correct Blueprint pattern: IsValid() node before any property/component access
|
||||
- Flags this as a runtime crash risk under its Review Checklist item "Error/failure paths are handled (not just the happy path)": GetOwner() can return null in some lifecycle states
|
||||
- Provides the correct Blueprint pattern: IsValid() node before any property/component access, with the invalid branch handled
|
||||
- Notes that Blueprint's null checks are not optional on Actor-derived references
|
||||
- Does NOT silently fix the code without explaining why the original was unsafe
|
||||
- Does NOT silently fix the code — explains why the original was unsafe and asks before editing the Blueprint
|
||||
|
||||
### Case 4: Blueprint graph complexity — readiness for Function Library refactor
|
||||
**Input**: "Our main GameMode Blueprint has 600+ nodes in a single graph with duplicated damage calculation logic in 8 places."
|
||||
@@ -57,24 +55,25 @@
|
||||
**Input context**: Project conventions specify a maximum of 100 nodes per Blueprint event graph before a mandatory Function Library extraction.
|
||||
**Input**: "Here is our inventory Blueprint graph [150 nodes shown]. Is it ready to ship?"
|
||||
**Expected behavior**:
|
||||
- References the stated 150-node count against the 100-node budget from project conventions
|
||||
- References the stated 150-node count against the 100-node event-graph budget from project conventions
|
||||
- Flags the graph as exceeding the complexity threshold
|
||||
- Does NOT approve it as-is
|
||||
- Produces a list of candidate subgraphs for Function Library extraction to bring the main graph within budget
|
||||
- Applies its own standard (maximum 20 nodes per function graph) to the extracted functions, keeping it distinct from the project's event-graph budget rather than substituting one number for the other
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Stays within declared domain (Blueprint architecture, performance, graph quality)
|
||||
- [ ] Redirects C++ implementation requests to engine-programmer or gameplay-programmer
|
||||
- [ ] Returns structured findings (problem/impact/alternatives format) rather than freeform opinions
|
||||
- [ ] Routes C++ implementation requests to gameplay-programmer and boundary rulings to unreal-specialist
|
||||
- [ ] Grounds findings in its own Performance Rules and Blueprint Review Checklist, naming the rule each finding breaks, rather than freeform opinions
|
||||
- [ ] Enforces Blueprint safety patterns (null checks, IsValid) proactively
|
||||
- [ ] References project conventions when evaluating graph complexity
|
||||
- [ ] References project conventions when evaluating graph complexity, alongside its own per-function node limit
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- Case 3 (null pointer safety) is a safety-critical test — this is a common source of shipping crashes
|
||||
- Case 5 requires that project conventions include a stated node budget; if none is configured, the agent should note the absence and recommend setting one
|
||||
- Case 5 requires that project conventions include a stated node budget; if none is configured, the agent falls back to its own standard (maximum 20 nodes per function graph) and says so
|
||||
- No automated runner; review manually or via `/skill-test`
|
||||
|
||||
@@ -2,8 +2,7 @@
|
||||
|
||||
## Agent Summary
|
||||
- **Domain**: Gameplay Ability System (GAS) — abilities (UGameplayAbility), gameplay effects (UGameplayEffect), attribute sets (UAttributeSet), gameplay tags, ability tasks (UAbilityTask), ability specs (FGameplayAbilitySpec), GAS prediction and latency compensation
|
||||
- **Does NOT own**: UI display of ability state (ue-umg-specialist), net replication of GAS data beyond built-in GAS prediction (ue-replication-specialist), art or VFX for ability feedback (vfx-artist)
|
||||
- **Model tier**: Sonnet
|
||||
- **Does NOT own**: UI display of ability state (ue-umg-specialist), net replication of GAS data beyond built-in GAS prediction (ue-replication-specialist), art or VFX for ability feedback (technical-artist)
|
||||
- **Gate IDs**: None; defers cross-domain calls to the appropriate specialist
|
||||
|
||||
---
|
||||
@@ -11,8 +10,8 @@
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references GAS, abilities, GameplayEffects, AttributeSets)
|
||||
- [ ] `allowed-tools:` list matches the agent's role (Read/Write for GAS source files; no deployment or server tools)
|
||||
- [ ] Model tier is Sonnet (default for specialists)
|
||||
- [ ] `tools:` reads Read, Glob, Grep, Write, Edit, Bash — no `Agent` tool
|
||||
- [ ] Model tier is `sonnet` — frontmatter `model:` reads exactly `sonnet` (tiers: `.claude/docs/model-tiers.md`)
|
||||
- [ ] Agent definition does not claim authority over UI implementation or low-level net serialization
|
||||
|
||||
---
|
||||
@@ -22,18 +21,18 @@
|
||||
### Case 1: In-domain request — dash ability with cooldown
|
||||
**Input**: "Implement a dash ability that moves the player forward 500 units and has a 1.5 second cooldown."
|
||||
**Expected behavior**:
|
||||
- Produces a GAS AbilitySpec structure or outline: UGameplayAbility subclass with ActivateAbility logic, an AbilityTask for movement (e.g., AbilityTask_ApplyRootMotionMoveToForce or custom root motion), and a UGameplayEffect for the cooldown
|
||||
- Produces a GAS AbilitySpec structure or outline: an ability deriving from the project's base ability class (not raw UGameplayAbility) with ActivateAbility logic, an AbilityTask for movement (e.g., AbilityTask_ApplyRootMotionMoveToForce or custom root motion), and a UGameplayEffect for the cooldown
|
||||
- Cooldown GameplayEffect uses Duration policy with the 1.5s duration and a GameplayTag to block re-activation
|
||||
- Tags clearly named following a hierarchy convention (e.g., Ability.Dash, Cooldown.Ability.Dash)
|
||||
- Output includes both the ability class outline and the GameplayEffect definition
|
||||
|
||||
### Case 2: Out-of-domain request — GAS state replication
|
||||
### Case 2: Mixed-domain request — cooldown replication feeding the UI
|
||||
**Input**: "How do I replicate the player's ability cooldown state to all clients so the UI updates correctly?"
|
||||
**Expected behavior**:
|
||||
- Clarifies that GAS has built-in replication for AbilitySpecs and GameplayEffects via the AbilitySystemComponent's replication mode
|
||||
- Explains the three ASC replication modes (Full, Mixed, Minimal) and when to use each
|
||||
- For custom replication needs beyond GAS built-ins, explicitly states: "For custom net serialization of GAS data, coordinate with ue-replication-specialist"
|
||||
- Does NOT attempt to write custom replication code outside GAS's own systems without flagging the domain boundary
|
||||
- Answers the replication half from GAS built-ins: the cooldown is a Duration Gameplay Effect granting a cooldown tag, replicated through the AbilitySystemComponent
|
||||
- Explains the three ASC replication modes (Full, Mixed, Minimal) and which clients each one delivers cooldown state to
|
||||
- Does NOT write custom replication (RepNotify properties or RPCs) for state GAS already replicates — effect-driven attribute changes replicate automatically and must not be double-replicated
|
||||
- Hands the cooldown-indicator UI to ue-umg-specialist, and names ue-replication-specialist for multiplayer prediction concerns beyond the ASC's built-in handling
|
||||
|
||||
### Case 3: Domain boundary — incorrect GameplayTag hierarchy
|
||||
**Input**: "We have an ability that applies a tag called 'Stunned' and another that checks for 'Status.Stunned'. They're not matching."
|
||||
@@ -47,19 +46,20 @@
|
||||
### Case 4: Conflict — attribute set conflict between two abilities
|
||||
**Input**: "Our Shield ability and our Armor ability both modify a 'DefenseValue' attribute. They're stacking in ways that aren't intended — after both are active, defense goes well above maximum."
|
||||
**Expected behavior**:
|
||||
- Identifies this as a GameplayEffect stacking and magnitude calculation problem
|
||||
- Proposes a resolution using Execution Calculations (UGameplayEffectExecutionCalculation) or Modifier Aggregators to cap the combined result
|
||||
- Alternatively recommends using Gameplay Effect Stacking policies (Aggregate, None) to prevent unintended additive stacking
|
||||
- Produces a concrete resolution: either an Execution Calculation class outline or a change to the Modifier Op (Override instead of Additive for the cap)
|
||||
- Identifies the cause: two different Gameplay Effects both modify DefenseValue, and nothing bounds their combined result
|
||||
- Resolves it with its own Attribute Set rules: DefenseValue gets a defined min/max, and `PreAttributeChange()` clamps the current value to that range — with `PreAttributeBaseChange()` or `PostGameplayEffectExecute()` for base-value changes from instant effects, as the pinned GAS reference's "Clamping Attributes" says — so no combination of effects can push it past the maximum
|
||||
- Anything else it proposes (an Execution Calculation, changing how the two effects combine) comes on top of the clamp, not instead of it; it does not offer a stacking policy as the fix — stacking policies govern re-applications of the same effect, not two different effects — and it does not present an Override modifier as a cap
|
||||
- Does NOT propose removing one of the abilities as the solution
|
||||
|
||||
### Case 5: Context pass — designing against an existing attribute set
|
||||
**Input context**: Project has an existing AttributeSet with attributes: Health, MaxHealth, Stamina, MaxStamina, Defense, AttackPower.
|
||||
**Input**: "Design a Berserker ability that increases AttackPower by 50% when Health drops below 30%."
|
||||
**Expected behavior**:
|
||||
- Uses the existing Health, MaxHealth, and AttackPower attributes — does NOT invent new attributes
|
||||
- Designs a Passive GameplayAbility (or triggered Effect) that fires on Health change, checks Health/MaxHealth ratio via a GameplayEffectExecutionCalculation or Attribute-Based magnitude
|
||||
- Uses a Gameplay Cue or Gameplay Tag to track the Berserker active state
|
||||
- Uses the existing Health, MaxHealth, and AttackPower attributes — does NOT add an attribute without flagging it as a change to the existing AttributeSet and asking first
|
||||
- Applies the +50% as an Infinite Gameplay Effect with a Modifier on AttackPower — never by writing AttackPower directly
|
||||
- Reacts to Health changes (e.g. in `PostGameplayEffectExecute()` or an Ability Task waiting on an event) to apply the effect below 30% of MaxHealth and remove it above
|
||||
- Documents the effect as its standards require: what it modifies, stacking behavior, duration, and removal condition
|
||||
- Tracks the active state with a hierarchical Gameplay Tag (e.g. `Effect.Buff.Berserk`), not a boolean
|
||||
- References the actual attribute names from the provided AttributeSet (AttackPower, not "Damage" or "Strength")
|
||||
|
||||
---
|
||||
@@ -67,15 +67,16 @@
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Stays within declared domain (GAS: abilities, effects, attributes, tags, ability tasks)
|
||||
- [ ] Redirects custom replication requests to ue-replication-specialist with clear explanation of boundary
|
||||
- [ ] Keeps GAS state replication inside the ASC (no double-replication); routes ability UI to ue-umg-specialist and multiplayer prediction concerns to ue-replication-specialist
|
||||
- [ ] Returns structured findings (ability outline + GameplayEffect definition) rather than vague descriptions
|
||||
- [ ] Enforces tag hierarchy naming conventions proactively
|
||||
- [ ] Uses only attributes and tags present in the provided context; does not invent new ones without noting it
|
||||
- [ ] Uses only attributes and tags present in the provided context; flags any new one as a change to the existing set before adding it
|
||||
- [ ] Asks "May I write this to [filepath]?" naming the file before writing
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- Case 3 (tag hierarchy) is a frequent source of subtle bugs; test whenever tag naming conventions change
|
||||
- Case 4 requires knowledge of GAS stacking policies — verify this case if the GAS integration depth changes
|
||||
- Case 4 tests the agent's own clamping rule (`PreAttributeChange()` against a defined min/max, and the base-value hooks for instant effects); stacking policies and Override modifiers do not cap two different effects, so they are accepted only as additions
|
||||
- Case 5 is the most important context-awareness test; failing it means the agent ignores project state
|
||||
- No automated runner; review manually or via `/skill-test`
|
||||
|
||||
@@ -2,17 +2,16 @@
|
||||
|
||||
## Agent Summary
|
||||
- **Domain**: Property replication (UPROPERTY Replicated/ReplicatedUsing), RPCs (Server/Client/NetMulticast), client prediction and reconciliation, net relevancy and always-relevant settings, net serialization (FArchive/NetSerialize), bandwidth optimization and replication frequency tuning
|
||||
- **Does NOT own**: Gameplay logic being replicated (gameplay-programmer), server infrastructure and hosting (devops-engineer), GAS-specific prediction (ue-gas-specialist handles GAS net prediction)
|
||||
- **Model tier**: Sonnet
|
||||
- **Gate IDs**: None; escalates security-relevant replication concerns to lead-programmer
|
||||
- **Does NOT own**: Gameplay logic being replicated (gameplay-programmer), transport-layer networking and matchmaking (network-programmer, who coordinates server hosting with devops-engineer), GAS-specific prediction (ue-gas-specialist handles GAS net prediction)
|
||||
- **Gate IDs**: None; takes security-relevant replication concerns to security-engineer
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references replication, RPCs, client prediction, bandwidth)
|
||||
- [ ] `allowed-tools:` list matches the agent's role (Read/Write for C++ and Blueprint source files; no infrastructure or deployment tools)
|
||||
- [ ] Model tier is Sonnet (default for specialists)
|
||||
- [ ] `tools:` reads Read, Glob, Grep, Write, Edit, Bash — no `Agent` tool
|
||||
- [ ] Model tier is `sonnet` — frontmatter `model:` reads exactly `sonnet` (tiers: `.claude/docs/model-tiers.md`)
|
||||
- [ ] Agent definition does not claim authority over server infrastructure, game server architecture, or gameplay logic correctness
|
||||
|
||||
---
|
||||
@@ -32,7 +31,7 @@
|
||||
**Input**: "Design our game server infrastructure — how many dedicated servers we need, regional deployment, and matchmaking architecture."
|
||||
**Expected behavior**:
|
||||
- Does not produce server infrastructure architecture, hosting recommendations, or matchmaking design
|
||||
- States clearly: "Server infrastructure and deployment architecture is owned by devops-engineer; I handle the Unreal replication layer within a running game session"
|
||||
- States that its scope is the Unreal replication layer within a running game session, and names network-programmer (its coordination partner for networking below that layer) as the route for matchmaking and server architecture
|
||||
- Does not conflate in-game replication with server hosting concerns
|
||||
|
||||
### Case 3: Domain boundary — RPC without server authority validation
|
||||
@@ -40,8 +39,8 @@
|
||||
**Expected behavior**:
|
||||
- Flags this as a critical security vulnerability: unvalidated server RPCs are exploitable by cheaters sending arbitrary RPC calls
|
||||
- Provides the required fix: server-side validation before the deduct — check that the player actually has the currency, verify the transaction is valid, reject and log if not
|
||||
- Uses the pattern: `if (!HasAuthority()) return;` guard plus explicit state validation before mutation
|
||||
- Notes this should be reviewed by lead-programmer given the economy implications
|
||||
- Validation covers the three checks every client RPC needs: can this player perform the action now, are the parameters within valid ranges, and is the request rate within limits (rate-limiting the RPC)
|
||||
- Notes this should be reviewed by security-engineer, its named partner for network security validation, given the economy implications
|
||||
- Does NOT produce the "fixed" code without explaining why the original was dangerous
|
||||
|
||||
### Case 4: Bandwidth optimization — high-frequency movement replication
|
||||
@@ -49,18 +48,19 @@
|
||||
**Expected behavior**:
|
||||
- Identifies tick-rate replication of full-precision Vector3 as bandwidth-expensive
|
||||
- Proposes quantized replication: use FVector_NetQuantize or FVector_NetQuantize100 instead of raw FVector to reduce bytes per update
|
||||
- Recommends reducing replication frequency via SetNetUpdateFrequency() for non-owning clients
|
||||
- Recommends lowering how often the movement actor replicates — a per-actor net update frequency (`NetUpdateFrequency` in its standards), not a per-client setting — naming the API it uses and marking it unverified unless `docs/engine-reference/unreal/` documents it
|
||||
- Notes that Unreal's built-in Character Movement Component already has optimized movement replication — recommends using or extending it rather than rolling a custom system
|
||||
- Produces a concrete bandwidth estimate comparison if possible, or explains the tradeoff
|
||||
- Measures the result against its per-client target (under 10 KB/s for action games) and names the tools to confirm the saving (`stat net`, Network Profiler)
|
||||
|
||||
### Case 5: Context pass — designing within a network budget
|
||||
**Input context**: Project network budget is 64 KB/s per player, with 32 players = 2 MB/s total server outbound. Current movement replication already uses 40 KB/s per player.
|
||||
**Input**: "We want to add real-time inventory replication so all clients can see other players' equipment changes immediately."
|
||||
**Expected behavior**:
|
||||
- Acknowledges the existing 40 KB/s movement cost leaves only 24 KB/s for everything else per player
|
||||
- Notes that these project figures sit well above its own default target (under 10 KB/s per client for action games) and works to the project's stated budget while flagging the gap
|
||||
- Does NOT design a naive full-inventory replication approach (would exceed budget)
|
||||
- Recommends a delta-only or event-driven approach: replicate only changed slots rather than the full inventory array
|
||||
- Uses FGameplayItemSlot or equivalent with ReplicatedUsing to trigger targeted updates
|
||||
- Separates what other players see (equipped items, replicated to all) from the full inventory (`COND_OwnerOnly`)
|
||||
- Recommends a delta-only or event-driven approach: replicate only changed slots rather than the full inventory array, with `ReplicatedUsing` to trigger targeted updates
|
||||
- Explicitly states the proposed approach's bandwidth estimate relative to the remaining 24 KB/s budget
|
||||
|
||||
---
|
||||
@@ -68,10 +68,11 @@
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Stays within declared domain (property replication, RPCs, client prediction, bandwidth)
|
||||
- [ ] Redirects server infrastructure requests to devops-engineer without producing infrastructure design
|
||||
- [ ] Flags unvalidated server RPCs as security issues and recommends lead-programmer review
|
||||
- [ ] Routes server infrastructure and matchmaking requests to network-programmer without producing infrastructure design
|
||||
- [ ] Flags unvalidated server RPCs as security issues and recommends security-engineer review
|
||||
- [ ] Returns structured findings (property declarations, bandwidth estimates, optimization options) not freeform advice
|
||||
- [ ] Uses project-provided bandwidth budget numbers when evaluating replication design choices
|
||||
- [ ] Asks "May I write this to [filepath]?" naming the file before writing
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,9 +1,8 @@
|
||||
# Agent Test Spec: ue-umg-specialist
|
||||
|
||||
## Agent Summary
|
||||
- **Domain**: UMG widget hierarchy design, data binding patterns, CommonUI input routing and action tags, widget styling (WidgetStyle assets), UI optimization (widget pooling, ListView, invalidation)
|
||||
- **Domain**: UMG widget hierarchy design, data binding patterns, CommonUI input routing and input action data, widget styling (WidgetStyle assets), UI optimization (widget pooling, ListView, invalidation)
|
||||
- **Does NOT own**: UX flow and screen navigation design (ux-designer), gameplay logic (gameplay-programmer), backend data sources (game code), server communication
|
||||
- **Model tier**: Sonnet
|
||||
- **Gate IDs**: None; defers UX flow decisions to ux-designer
|
||||
|
||||
---
|
||||
@@ -11,8 +10,8 @@
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references UMG, widget hierarchy, CommonUI)
|
||||
- [ ] `allowed-tools:` list matches the agent's role (Read/Write for UI assets and Blueprint files; no server or gameplay source tools)
|
||||
- [ ] Model tier is Sonnet (default for specialists)
|
||||
- [ ] `tools:` reads Read, Glob, Grep, Write, Edit, Bash — no `Agent` tool
|
||||
- [ ] Model tier is `sonnet` — frontmatter `model:` reads exactly `sonnet` (tiers: `.claude/docs/model-tiers.md`)
|
||||
- [ ] Agent definition does not claim authority over UX flow, navigation architecture, or gameplay data logic
|
||||
|
||||
---
|
||||
@@ -23,7 +22,7 @@
|
||||
**Input**: "Create an inventory widget that shows a grid of item slots. Each slot should display item icon, quantity, and rarity color. It needs to update when the inventory changes."
|
||||
**Expected behavior**:
|
||||
- Produces a UMG widget structure: a parent WBP_Inventory containing a UniformGridPanel or TileView, with a child WBP_InventorySlot widget per item
|
||||
- Describes data binding approach: either Event Dispatchers on an Inventory Component triggering a refresh, or a ListView with a UObject item data class implementing IUserObjectListEntry
|
||||
- Describes data binding approach: either Event Dispatchers on an Inventory Component triggering a refresh, or a TileView fed UObject-based item data (not raw structs); it names the entry widget's list-entry interface (`IUserObjectListEntry`) and marks it unverified against `docs/engine-reference/unreal/`, which does not document it
|
||||
- Specifies how rarity color is driven: a WidgetStyle asset or a data table lookup, not hardcoded color values
|
||||
- Output includes the widget hierarchy, binding pattern, and the refresh trigger mechanism
|
||||
|
||||
@@ -31,15 +30,15 @@
|
||||
**Input**: "Design the full navigation flow for our inventory system — how the player opens it, transitions to character stats, and exits to the pause menu."
|
||||
**Expected behavior**:
|
||||
- Does not produce a navigation flow or screen transition architecture
|
||||
- States clearly: "Navigation flow and screen transition design is owned by ux-designer; I can implement the UMG widget structure once the flow is defined"
|
||||
- Does not make UX decisions (back button behavior, transition animations, modal vs. fullscreen) without a UX spec
|
||||
- Names ux-designer, its coordination partner for interaction design, as the owner of the flow, and offers to build the screens on its layered architecture (Menu Layer, `UCommonActivatableWidgetStack`) once the flow is defined
|
||||
- Does not make UX decisions (back button behavior, transition animations, modal vs. fullscreen) without a UX spec — it asks for the spec or lists these as open questions instead
|
||||
|
||||
### Case 3: Domain boundary — CommonUI input action mismatch
|
||||
**Input**: "Our inventory widget isn't responding to the controller Back button. We're using CommonUI."
|
||||
**Expected behavior**:
|
||||
- Identifies the likely cause: the widget's Back input action tag does not match the project's registered CommonUI InputAction data asset
|
||||
- Explains the CommonUI input routing model: widgets declare input actions via `CommonUI_InputAction` tags; the CommonActivatableWidget handles routing
|
||||
- Provides the fix: verify that the widget's Back action tag matches the registered tag in the project's CommonUI input action data table
|
||||
- Identifies the likely causes: the widget's Back binding does not point at the Back row of the project's `CommonInputActionDataBase` data table, or the widget is not the activated, focused screen on its stack
|
||||
- Explains the CommonUI input routing model: screens derive from `UCommonActivatableWidget` and bind UI actions to data-table rows; only the focused, activated widget consumes input and unfocused widgets ignore it
|
||||
- Provides the fix: verify the Back binding's data-table row and that the widget is pushed onto (and active on) its activatable-widget stack
|
||||
- Distinguishes this from a hardware input binding issue (which would be Enhanced Input territory)
|
||||
|
||||
### Case 4: Widget performance issue — many widget instances per frame
|
||||
@@ -47,28 +46,29 @@
|
||||
**Expected behavior**:
|
||||
- Identifies the root cause: 500 widget instantiations in a single frame causes a construction hitch
|
||||
- Recommends switching to ListView or TileView with virtualization — only visible rows are constructed
|
||||
- Explains the IUserObjectListEntry interface requirement for ListView data objects
|
||||
- Explains the ListView data requirement: each row's data is a UObject-based entry item, not a raw struct; it names the row widget's list-entry interface (`IUserObjectListEntry`) and marks it unverified against `docs/engine-reference/unreal/`
|
||||
- If ListView is not appropriate, recommends pooling: pre-instantiate a fixed number of rows and recycle them with new data
|
||||
- Output is a concrete recommendation with the specific UMG component to use, not a vague "optimize it"
|
||||
|
||||
### Case 5: Context pass — CommonUI setup already configured
|
||||
**Input context**: Project uses CommonUI with the following registered InputAction tags: UI.Action.Confirm, UI.Action.Back, UI.Action.Pause, UI.Action.Secondary.
|
||||
**Input context**: Project uses CommonUI; its `CommonInputActionDataBase` data table defines these input action rows: Confirm, Back, Pause, Secondary.
|
||||
**Input**: "Add a 'Sort Inventory' button to the inventory widget that works with CommonUI."
|
||||
**Expected behavior**:
|
||||
- Uses UI.Action.Secondary (or recommends registering a new tag like UI.Action.Sort if Secondary is already allocated)
|
||||
- Does NOT invent a new InputAction tag without noting that it must be registered in the CommonUI data table
|
||||
- Does NOT use a non-CommonUI input binding approach (e.g., raw key press in Event Graph) when CommonUI is the established pattern
|
||||
- References the provided tag list explicitly in the recommendation
|
||||
- Uses the existing Secondary row (or recommends adding a new Sort row if Secondary is already allocated on this screen)
|
||||
- Does NOT invent a new input action without noting that it must be added as a row to the project's CommonUI input action data table
|
||||
- Uses a `UCommonButtonBase` for the button and CommonUI's input routing — not a non-CommonUI binding (e.g., raw key press in Event Graph or `APlayerController::InputComponent`)
|
||||
- References the provided action rows explicitly in the recommendation
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Stays within declared domain (UMG structure, data binding, CommonUI, widget performance)
|
||||
- [ ] Redirects UX flow and navigation design requests to ux-designer
|
||||
- [ ] Redirects UX flow and navigation design requests to ux-designer, making no binding UX decisions itself
|
||||
- [ ] Returns structured findings (widget hierarchy + binding pattern) rather than freeform opinions
|
||||
- [ ] Uses existing CommonUI InputAction tags from context; does not invent new ones without flagging registration requirement
|
||||
- [ ] Uses existing CommonUI input action rows from context; does not invent new ones without flagging that they must be added to the data table
|
||||
- [ ] Recommends virtualized lists (ListView/TileView) before widget pooling for large collections
|
||||
- [ ] Asks "May I write this to [filepath]?" naming the file before writing
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -3,7 +3,6 @@
|
||||
## Agent Summary
|
||||
- **Domain**: Unreal Engine patterns and architecture — Blueprint vs C++ decisions, UE subsystems (GAS, Enhanced Input, Niagara), UE project structure, plugin integration, and engine-level configuration
|
||||
- **Does NOT own**: Art style and visual direction (art-director), server infrastructure and deployment (devops-engineer), UI/UX flow design (ux-designer)
|
||||
- **Model tier**: Sonnet
|
||||
- **Gate IDs**: None; defers gate verdicts to technical-director
|
||||
|
||||
---
|
||||
@@ -11,8 +10,8 @@
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references Unreal Engine)
|
||||
- [ ] `allowed-tools:` list matches the agent's role (Read, Write for UE project files; no deployment tools)
|
||||
- [ ] Model tier is Sonnet (default for specialists)
|
||||
- [ ] `tools:` reads Read, Glob, Grep, Write, Edit, Bash and `Agent(ue-gas-specialist, ue-blueprint-specialist, ue-replication-specialist, ue-umg-specialist)` — it may spawn only its four sub-specialists
|
||||
- [ ] Model tier is `inherit` — frontmatter `model:` reads exactly `inherit` (tiers: `.claude/docs/model-tiers.md`)
|
||||
- [ ] Agent definition does not claim authority outside its declared domain (no art, no server infra)
|
||||
|
||||
---
|
||||
@@ -22,26 +21,27 @@
|
||||
### Case 1: In-domain request — Blueprint vs C++ decision criteria
|
||||
**Input**: "Should I implement our combo attack system in Blueprint or C++?"
|
||||
**Expected behavior**:
|
||||
- Provides structured decision criteria: complexity, reuse frequency, team skill, and performance requirements
|
||||
- Recommends C++ for systems called every frame or shared across 5+ ability types
|
||||
- Recommends Blueprint for designer-tunable values and one-off logic
|
||||
- Applies its stated default: C++ for the combo system's framework, Blueprint for content and prototyping
|
||||
- Routes the combat logic through GAS (combo attacks as Gameplay Abilities, combo state as Gameplay Tags, montage flow via Ability Tasks) and names ue-gas-specialist for the GAS design rather than implementing it itself
|
||||
- Recommends Blueprint for designer-tunable values (exposed with `EditAnywhere` / `BlueprintReadWrite`, data-only Blueprints for combo variations, `BlueprintNativeEvent` where designers override behavior)
|
||||
- Cites its ~20-nodes-per-function threshold as the point where Blueprint combo logic belongs in C++
|
||||
- Does NOT render a final verdict without knowing project context — asks clarifying questions if context is absent
|
||||
- Output is structured (criteria table or bullet list), not a freeform opinion
|
||||
- Presents the split as a proposed class structure with its trade-offs, not a freeform opinion
|
||||
|
||||
### Case 2: Out-of-domain request — Unity C# code
|
||||
**Input**: "Write me a C# MonoBehaviour that handles player health and fires a Unity event on death."
|
||||
**Expected behavior**:
|
||||
- Does not produce Unity C# code
|
||||
- States clearly: "This project uses Unreal Engine; the Unity equivalent would be an Actor Component in UE C++ or a Blueprint Actor Component"
|
||||
- Optionally offers to provide the UE equivalent if requested
|
||||
- Does not redirect to a Unity specialist (none exists in the framework)
|
||||
- Confirms the project's engine from `engine.name` in `project.yaml` before answering: with Unreal configured, states that the project is built in Unreal Engine 5; with it unset, asks which engine the project uses rather than assuming
|
||||
- With Unreal configured, maps the request to the Unreal equivalent its own standards prescribe: health as an Attribute Set attribute changed only through Gameplay Effects when GAS is in use, otherwise a C++ `UActorComponent` exposing a death event to Blueprint
|
||||
- Does not redirect to unity-specialist — that agent serves Unity projects only, and this agent's `Agent` grant covers only its four Unreal sub-specialists
|
||||
|
||||
### Case 3: Domain boundary — UE5.4 API requirement
|
||||
**Input**: "I need to use the new Motion Matching API introduced in UE5.4."
|
||||
**Expected behavior**:
|
||||
- Flags that UE5.4 is a specific version with potentially limited LLM training coverage
|
||||
- Recommends cross-referencing official Unreal docs or the project's engine-reference directory before trusting any API suggestions
|
||||
- Provides best-effort API guidance with explicit uncertainty markers (e.g., "Verify this against UE5.4 release notes")
|
||||
- Flags that UE5.4 is past the model's training coverage (`docs/engine-reference/unreal/VERSION.md` lists 5.4 as a post-cutoff, HIGH-risk version)
|
||||
- Checks `docs/engine-reference/unreal/` before trusting any API suggestion
|
||||
- States that no file under `docs/engine-reference/unreal/` documents Motion Matching, and labels any class or node names it offers as unverified against the pinned version
|
||||
- Does NOT silently produce stale or incorrect API signatures without a caveat
|
||||
|
||||
### Case 4: Conflict — Blueprint spaghetti in a core system
|
||||
@@ -67,14 +67,16 @@
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Stays within declared domain (Unreal patterns, Blueprint/C++, UE subsystems)
|
||||
- [ ] Redirects Unity or other-engine requests without producing wrong-engine code
|
||||
- [ ] Returns structured findings (criteria tables, decision trees, migration plans) rather than freeform opinions
|
||||
- [ ] Flags version uncertainty explicitly before producing API suggestions
|
||||
- [ ] Answers Unity or other-engine requests with the Unreal equivalent, never wrong-engine code
|
||||
- [ ] Proposes class structure, data flow and trade-offs before implementing (Implementation Workflow step 3) rather than freeform opinions
|
||||
- [ ] Flags version uncertainty explicitly before producing API suggestions, citing `docs/engine-reference/unreal/`
|
||||
- [ ] Coordinates with lead-programmer for architecture-scale refactors rather than deciding unilaterally
|
||||
- [ ] Asks "May I write this to [filepath]?" naming the file before writing
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- No automated runner exists for agent behavior tests — these are reviewed manually or via `/skill-test`
|
||||
- Version-awareness (Case 3, Case 5) is the highest-risk failure mode for this agent; test regularly when engine version changes
|
||||
- Cases 3 and 5 pass only if the agent is directed to `docs/engine-reference/unreal/`; `CLAUDE.md` imports the Unreal `VERSION.md` only after `/setup-engine` selects Unreal, so the agent's own file must carry that direction
|
||||
- Case 4 integration with lead-programmer is a coordination test, not a technical correctness test
|
||||
|
||||
Reference in New Issue
Block a user