添加 claude code game studios 到项目
This commit is contained in:
panw
@@ -0,0 +1,87 @@
|
||||
# Agent Test Spec: unity-addressables-specialist
|
||||
|
||||
## Agent Summary
|
||||
Domain: Addressable Asset System — groups, async loading/unloading, handle lifecycle management, memory budgeting, content catalogs, and remote content delivery.
|
||||
Does NOT own: rendering systems (engine-programmer), game logic that uses the loaded assets (gameplay-programmer).
|
||||
Model tier: Sonnet (default).
|
||||
No gate IDs assigned.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references Addressables / asset loading / content catalogs / remote delivery)
|
||||
- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
|
||||
- [ ] Model tier is Sonnet (default for specialists)
|
||||
- [ ] Agent definition does not claim authority over rendering systems or gameplay using the loaded assets
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: In-domain request — appropriate output
|
||||
**Input:** "Load a character texture asynchronously and release it when the character is destroyed."
|
||||
**Expected behavior:**
|
||||
- Produces the `Addressables.LoadAssetAsync<Texture2D>()` call pattern
|
||||
- Stores the returned `AsyncOperationHandle<Texture2D>` in the requesting object
|
||||
- On character destruction (`OnDestroy()`), calls `Addressables.Release(handle)` with the stored handle
|
||||
- Does NOT use `Resources.Load()` as the loading mechanism
|
||||
- Notes that releasing with a null or uninitialized handle causes errors — includes a validity check
|
||||
- Notes the difference between releasing the handle vs. releasing the asset (handle release is correct)
|
||||
|
||||
### Case 2: Out-of-domain redirect
|
||||
**Input:** "Implement the rendering system that applies the loaded texture to the character mesh."
|
||||
**Expected behavior:**
|
||||
- Does NOT produce rendering or mesh material assignment code
|
||||
- Explicitly states that rendering system implementation belongs to `engine-programmer`
|
||||
- Redirects the request to `engine-programmer`
|
||||
- May describe the asset type and API surface it will provide (e.g., `Texture2D` reference once the handle completes) as a handoff spec
|
||||
|
||||
### Case 3: Memory leak — un-released handle
|
||||
**Input:** "Memory usage keeps climbing after each level load. We use Addressables to load level assets."
|
||||
**Expected behavior:**
|
||||
- Diagnoses the likely cause: `AsyncOperationHandle` objects not being released after use
|
||||
- Identifies the handle leak pattern: loading assets into a local variable, losing reference, never calling `Addressables.Release()`
|
||||
- Produces an auditing approach: search for all `LoadAssetAsync` / `LoadSceneAsync` calls and verify matching `Release()` calls
|
||||
- Provides a corrected pattern using a tracked handle list (`List<AsyncOperationHandle>`) with a `ReleaseAll()` cleanup method
|
||||
- Does NOT assume the leak is elsewhere without evidence
|
||||
|
||||
### Case 4: Remote content delivery — catalog versioning
|
||||
**Input:** "We need to support downloadable content updates without requiring a full app re-install."
|
||||
**Expected behavior:**
|
||||
- Produces the remote catalog update pattern:
|
||||
- `Addressables.CheckForCatalogUpdates()` on startup
|
||||
- `Addressables.UpdateCatalogs()` for detected updates
|
||||
- `Addressables.DownloadDependenciesAsync()` to pre-warm the updated content
|
||||
- Notes catalog hash checking for change detection
|
||||
- Addresses the edge case: what happens if a player starts a session, the catalog updates mid-session — defines behavior (complete current session on old catalog, reload on next launch)
|
||||
- Does NOT design the server-side CDN infrastructure (defers to devops-engineer)
|
||||
|
||||
### Case 5: Context pass — platform memory constraints
|
||||
**Input:** Platform context: Nintendo Switch target, 4GB RAM, practical asset memory ceiling 512MB. Request: "Design the Addressables loading strategy for a large open-world level."
|
||||
**Expected behavior:**
|
||||
- References the 512MB memory ceiling from the provided context
|
||||
- Designs a streaming strategy:
|
||||
- Divide the world into addressable zones loaded/unloaded based on player proximity
|
||||
- Defines a memory budget per active zone (e.g., 128MB, max 4 zones active)
|
||||
- Specifies async pre-load trigger distance and unload distance (hysteresis)
|
||||
- Notes Switch-specific constraints: slower load times from SD card, recommend pre-warming adjacent zones
|
||||
- Does NOT produce a loading strategy that would exceed the stated 512MB ceiling without flagging it
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Stays within declared domain (Addressables loading, handle lifecycle, memory, catalogs, remote delivery)
|
||||
- [ ] Redirects rendering and gameplay asset-use code to engine-programmer and gameplay-programmer
|
||||
- [ ] Returns structured output (loading patterns, handle lifecycle code, streaming zone designs)
|
||||
- [ ] Always pairs `LoadAssetAsync` with a corresponding `Release()` — flags handle leaks as a memory bug
|
||||
- [ ] Designs loading strategies against provided memory ceilings
|
||||
- [ ] Does not design CDN/server infrastructure — defers to devops-engineer for server side
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- Handle lifecycle (Case 1) must include a test verifying memory is reclaimed after release
|
||||
- Handle leak diagnosis (Case 3) should produce a findings report suitable for a bug ticket
|
||||
- Platform memory case (Case 5) verifies the agent applies hard constraints from context, not default assumptions
|
||||
@@ -0,0 +1,87 @@
|
||||
# Agent Test Spec: unity-dots-specialist
|
||||
|
||||
## Agent Summary
|
||||
Domain: ECS architecture (IComponentData, ISystem, SystemAPI), Jobs system (IJob, IJobEntity, Burst), Burst compiler constraints, DOTS gameplay systems, and hybrid renderer.
|
||||
Does NOT own: MonoBehaviour gameplay code (gameplay-programmer), UI implementation (unity-ui-specialist).
|
||||
Model tier: Sonnet (default).
|
||||
No gate IDs assigned.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references ECS / Jobs / Burst / IComponentData)
|
||||
- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
|
||||
- [ ] Model tier is Sonnet (default for specialists)
|
||||
- [ ] Agent definition does not claim authority over MonoBehaviour gameplay or UI systems
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: In-domain request — appropriate output
|
||||
**Input:** "Convert the player movement system to ECS."
|
||||
**Expected behavior:**
|
||||
- Produces:
|
||||
- `PlayerMovementData : IComponentData` struct with velocity, speed, and input vector fields
|
||||
- `PlayerMovementSystem : ISystem` with `OnUpdate()` using `SystemAPI.Query<>` or `IJobEntity`
|
||||
- Bakes the player's initial state from an authoring MonoBehaviour via `IBaker`
|
||||
- Uses `RefRW<LocalTransform>` for position updates (not deprecated `Translation`)
|
||||
- Marks the job `[BurstCompile]` and notes what must be unmanaged for Burst compatibility
|
||||
- Does NOT modify the input polling system — reads from an existing `PlayerInputData` component
|
||||
|
||||
### Case 2: MonoBehaviour push-back
|
||||
**Input:** "Just use MonoBehaviour for the player movement — it's simpler."
|
||||
**Expected behavior:**
|
||||
- Acknowledges the simplicity argument
|
||||
- Explains the DOTS trade-off: more setup upfront, but the ECS/Burst approach provides the performance characteristics documented in the project's ADR or requirements
|
||||
- Does NOT implement a MonoBehaviour version if the project has committed to DOTS
|
||||
- If no commitment exists, flags the architecture decision to `lead-programmer` / `technical-director` for resolution
|
||||
- Does not make the MonoBehaviour vs. DOTS decision unilaterally
|
||||
|
||||
### Case 3: Burst-incompatible managed memory
|
||||
**Input:** "This Burst job accesses a `List<EnemyData>` to find the nearest enemy."
|
||||
**Expected behavior:**
|
||||
- Flags `List<T>` as a managed type that is incompatible with Burst compilation
|
||||
- Does NOT approve the Burst job with managed memory access
|
||||
- Provides the correct replacement: `NativeArray<EnemyData>`, `NativeList<EnemyData>`, or `NativeHashMap<>` depending on the use case
|
||||
- Notes that `NativeArray` must be disposed explicitly or via `[DeallocateOnJobCompletion]`
|
||||
- Produces the corrected job using unmanaged native containers
|
||||
|
||||
### Case 4: Hybrid access — DOTS system needs MonoBehaviour data
|
||||
**Input:** "The DOTS movement system needs to read the camera transform managed by a MonoBehaviour CameraController."
|
||||
**Expected behavior:**
|
||||
- Identifies this as a hybrid access scenario
|
||||
- Provides the correct hybrid pattern: store the camera transform in a singleton `IComponentData` (updated from the MonoBehaviour side each frame via `EntityManager.SetComponentData`)
|
||||
- Alternatively suggests the `CompanionComponent` / managed component approach
|
||||
- Does NOT access the MonoBehaviour from inside a Burst job — flags that as unsafe
|
||||
- Provides the bridge code on both the MonoBehaviour side (writing to ECS) and the DOTS system side (reading from ECS)
|
||||
|
||||
### Case 5: Context pass — performance targets
|
||||
**Input:** Technical preferences from context: 60fps target, max 2ms CPU script budget per frame. Request: "Design the ECS chunk layout for 10,000 enemy entities."
|
||||
**Expected behavior:**
|
||||
- References the 2ms CPU budget explicitly in the design rationale
|
||||
- Designs the `IComponentData` chunk layout for cache efficiency:
|
||||
- Groups frequently-queried together components in the same archetype
|
||||
- Separates rarely-used data into separate components to keep hot data compact
|
||||
- Estimates entity iteration time against the 2ms budget
|
||||
- Provides memory layout analysis (bytes per entity, entities per chunk at 16KB chunk size)
|
||||
- Does NOT design a layout that will obviously exceed the stated 2ms budget without flagging it
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Stays within declared domain (ECS, Jobs, Burst, DOTS gameplay systems)
|
||||
- [ ] Redirects MonoBehaviour-only gameplay to gameplay-programmer
|
||||
- [ ] Returns structured output (IComponentData structs, ISystem implementations, IBaker authoring classes)
|
||||
- [ ] Flags managed memory access in Burst jobs as a compile error and provides unmanaged alternatives
|
||||
- [ ] Provides hybrid access patterns when DOTS systems need to interact with MonoBehaviour systems
|
||||
- [ ] Designs chunk layouts against provided performance budgets
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- ECS conversion (Case 1) must include a unit test using the ECS test framework (`World`, `EntityManager`)
|
||||
- Burst incompatibility (Case 3) is safety-critical — the agent must catch this before the code is written
|
||||
- Chunk layout (Case 5) verifies the agent applies quantitative performance reasoning to architecture decisions
|
||||
@@ -0,0 +1,83 @@
|
||||
# Agent Test Spec: unity-shader-specialist
|
||||
|
||||
## Agent Summary
|
||||
Domain: Unity Shader Graph, custom HLSL, VFX Graph, URP/HDRP pipeline customization, and post-processing effects.
|
||||
Does NOT own: gameplay code, art style direction.
|
||||
Model tier: Sonnet (default).
|
||||
No gate IDs assigned.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references Shader Graph / HLSL / VFX Graph / URP / HDRP)
|
||||
- [ ] `allowed-tools:` list includes Read, Write, Edit, Glob, Grep
|
||||
- [ ] Model tier is Sonnet (default for specialists)
|
||||
- [ ] Agent definition does not claim authority over gameplay code or art direction
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: In-domain request — appropriate output
|
||||
**Input:** "Create an outline effect for characters using Shader Graph in URP."
|
||||
**Expected behavior:**
|
||||
- Produces a Shader Graph node setup description:
|
||||
- Inverted hull method: Scale Normal → Vertex offset in vertex stage, Cull Front
|
||||
- OR screen-space post-process outline using depth/normal edge detection
|
||||
- Recommends the appropriate method based on URP capabilities (inverted hull for URP compatibility, post-process for HDRP)
|
||||
- Notes URP limitations: no geometry shader support (rules out geometry-shader outline approach)
|
||||
- Does NOT produce HDRP-specific nodes without confirming the render pipeline
|
||||
|
||||
### Case 2: Out-of-domain redirect
|
||||
**Input:** "Implement the character health bar UI in code."
|
||||
**Expected behavior:**
|
||||
- Does NOT produce UI implementation code
|
||||
- Explicitly states that UI implementation belongs to `ui-programmer` (or `unity-ui-specialist`)
|
||||
- Redirects the request appropriately
|
||||
- May note that a shader-based fill effect for a health bar (e.g., a dissolve/fill gradient) is within its domain if the visual effect itself is shader-driven
|
||||
|
||||
### Case 3: HDRP custom pass for outline
|
||||
**Input:** "We're on HDRP and want the outline as a post-process effect."
|
||||
**Expected behavior:**
|
||||
- Produces the HDRP `CustomPassVolume` pattern:
|
||||
- C# class inheriting `CustomPass`
|
||||
- `Execute()` method using `CoreUtils.SetRenderTarget()` and a full-screen shader blit
|
||||
- Depth/normal buffer sampling for edge detection
|
||||
- Notes that CustomPass requires HDRP package and does not work in URP
|
||||
- Confirms the project is on HDRP before providing HDRP-specific code
|
||||
|
||||
### Case 4: VFX Graph performance — GPU event batching
|
||||
**Input:** "The explosion VFX Graph has 10,000 particles per event and spawning 20 simultaneous explosions is causing GPU frame spikes."
|
||||
**Expected behavior:**
|
||||
- Identifies GPU particle spawn as the cost driver (200,000 simultaneous particles)
|
||||
- Proposes GPU event batching: spawn events deferred over multiple frames, stagger initialization
|
||||
- Recommends a particle budget cap per active explosion (e.g., 3,000 per explosion, queue excess)
|
||||
- Notes the VFX Graph Event Batcher pattern and Output Event API for cross-frame distribution
|
||||
- Does NOT change the gameplay event system — proposes a VFX-side budgeting solution
|
||||
|
||||
### Case 5: Context pass — render pipeline (URP or HDRP)
|
||||
**Input:** Project context: URP render pipeline, Unity 2022.3. Request: "Add depth of field post-processing."
|
||||
**Expected behavior:**
|
||||
- Uses URP Volume framework: `DepthOfField` Volume Override component
|
||||
- Does NOT use HDRP Volume components (e.g., HDRP's `DepthOfField` with different parameter names)
|
||||
- Notes URP-specific DOF limitations vs HDRP (e.g., Bokeh quality differences)
|
||||
- Produces C# Volume profile setup code compatible with Unity 2022.3 URP package version
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Stays within declared domain (Shader Graph, HLSL, VFX Graph, URP/HDRP customization)
|
||||
- [ ] Redirects gameplay and UI code to appropriate agents
|
||||
- [ ] Returns structured output (node graph descriptions, HLSL code, CustomPass patterns)
|
||||
- [ ] Distinguishes between URP and HDRP approaches — never cross-contaminates pipeline-specific APIs
|
||||
- [ ] Flags geometry shader approaches as URP-incompatible when relevant
|
||||
- [ ] Produces VFX optimizations that do not change gameplay behavior
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- Outline effect (Case 1) should be paired with a visual screenshot test in `production/qa/evidence/`
|
||||
- HDRP CustomPass (Case 3) confirms the agent produces the correct Unity pattern, not a generic post-process approach
|
||||
- Pipeline separation (Case 5) verifies the agent never assumes the render pipeline without context
|
||||
@@ -0,0 +1,83 @@
|
||||
# Agent Test Spec: unity-specialist
|
||||
|
||||
## Agent Summary
|
||||
Domain: Unity-specific architecture patterns, MonoBehaviour vs DOTS decisions, and subsystem selection (Addressables, New Input System, UI Toolkit, Cinemachine, etc.).
|
||||
Does NOT own: language-specific deep dives (delegates to unity-dots-specialist, unity-ui-specialist, etc.).
|
||||
Model tier: Sonnet (default).
|
||||
No gate IDs assigned.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references Unity patterns / MonoBehaviour / subsystem decisions)
|
||||
- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
|
||||
- [ ] Model tier is Sonnet (default for specialists)
|
||||
- [ ] Agent definition acknowledges the sub-specialist routing table (DOTS, UI, Shader, Addressables)
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: In-domain request — appropriate output
|
||||
**Input:** "Should I use MonoBehaviour or ScriptableObject for storing enemy configuration data?"
|
||||
**Expected behavior:**
|
||||
- Produces a pattern decision tree covering:
|
||||
- MonoBehaviour: for runtime behavior, needs to be attached to a GameObject, has Update() lifecycle
|
||||
- ScriptableObject: for pure data/configuration, exists as an asset, shared across instances, no scene dependency
|
||||
- Recommends ScriptableObject for enemy configuration data (stateless, reusable, designer-friendly)
|
||||
- Notes that MonoBehaviour can reference the ScriptableObject for runtime use
|
||||
- Provides a concrete example of what the ScriptableObject class definition looks like (does not produce full code — refers to engine-programmer or gameplay-programmer for implementation)
|
||||
|
||||
### Case 2: Wrong-engine redirect
|
||||
**Input:** "Set up a Node scene tree with signals for this enemy system."
|
||||
**Expected behavior:**
|
||||
- Does NOT produce Godot Node/signal code
|
||||
- Identifies this as a Godot pattern
|
||||
- States that in Unity the equivalent is GameObject hierarchy + UnityEvent or C# events
|
||||
- Maps the concepts: Godot Node → Unity MonoBehaviour, Godot Signal → C# event / UnityEvent
|
||||
- Confirms the project is Unity-based before proceeding
|
||||
|
||||
### Case 3: Unity version API flag
|
||||
**Input:** "Use the new Unity 6 GPU resident drawer for batch rendering."
|
||||
**Expected behavior:**
|
||||
- Identifies the Unity 6 feature (GPU Resident Drawer)
|
||||
- Flags that this API may not be available in earlier Unity versions
|
||||
- Asks for or checks the project's Unity version before providing implementation guidance
|
||||
- Directs to verify against official Unity 6 documentation
|
||||
- Does NOT assume the project is on Unity 6 without confirmation
|
||||
|
||||
### Case 4: DOTS vs. MonoBehaviour conflict
|
||||
**Input:** "The combat system uses MonoBehaviour for state management, but we want to add a DOTS-based projectile system. Can they coexist?"
|
||||
**Expected behavior:**
|
||||
- Recognizes this as a hybrid architecture scenario
|
||||
- Explains the hybrid approach: MonoBehaviour can interface with DOTS via SystemAPI, IComponentData, and managed components
|
||||
- Notes the performance and complexity trade-offs of mixing the two patterns
|
||||
- Recommends escalating the architecture decision to `lead-programmer` or `technical-director`
|
||||
- Defers to `unity-dots-specialist` for the DOTS-side implementation details
|
||||
|
||||
### Case 5: Context pass — Unity version
|
||||
**Input:** Project context provided: Unity 2023.3 LTS. Request: "Configure the new Input System for this project."
|
||||
**Expected behavior:**
|
||||
- Applies Unity 2023.3 LTS context: uses the New Input System (com.unity.inputsystem) package
|
||||
- Does NOT produce legacy Input Manager code (`Input.GetKeyDown()`, `Input.GetAxis()`)
|
||||
- Notes any 2023.3-specific Input System behaviors or package version constraints
|
||||
- References the project version to confirm Burst/Jobs compatibility if the Input System interacts with DOTS
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Stays within declared domain (Unity architecture decisions, pattern selection, subsystem routing)
|
||||
- [ ] Redirects Godot patterns to appropriate Godot specialists or flags them as wrong-engine
|
||||
- [ ] Redirects DOTS implementation to unity-dots-specialist
|
||||
- [ ] Redirects UI implementation to unity-ui-specialist
|
||||
- [ ] Flags Unity version-gated APIs and requires version confirmation before suggesting them
|
||||
- [ ] Returns structured pattern decision guides, not freeform opinions
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- MonoBehaviour vs. ScriptableObject (Case 1) should be documented as an ADR if it results in a project-level decision
|
||||
- Version flag (Case 3) confirms the agent does not assume the latest Unity version without context
|
||||
- DOTS hybrid (Case 4) verifies the agent escalates architecture conflicts rather than resolving them unilaterally
|
||||
@@ -0,0 +1,81 @@
|
||||
# Agent Test Spec: unity-ui-specialist
|
||||
|
||||
## Agent Summary
|
||||
Domain: Unity UI Toolkit (UXML/USS), UGUI (Canvas), data binding, runtime UI performance, and UI input event handling.
|
||||
Does NOT own: UX flow design (ux-designer), visual art style (art-director).
|
||||
Model tier: Sonnet (default).
|
||||
No gate IDs assigned.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references UI Toolkit / UGUI / Canvas / data binding)
|
||||
- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
|
||||
- [ ] Model tier is Sonnet (default for specialists)
|
||||
- [ ] Agent definition does not claim authority over UX flow design or visual art direction
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: In-domain request — appropriate output
|
||||
**Input:** "Implement an inventory UI screen using Unity UI Toolkit."
|
||||
**Expected behavior:**
|
||||
- Produces a UXML document defining the inventory panel structure (ListView, item templates, detail panel)
|
||||
- Produces USS styles for the inventory layout and item states (default, hover, selected)
|
||||
- Provides C# code binding the inventory data model to the UI via `INotifyValueChanged` or `IBindable`
|
||||
- Uses `ListView` with `makeItem` / `bindItem` callbacks for the scrollable item list
|
||||
- Does NOT produce the UX flow design — implements from a provided spec
|
||||
|
||||
### Case 2: Out-of-domain redirect
|
||||
**Input:** "Design the UX flow for the inventory — what happens when the player equips vs. drops an item."
|
||||
**Expected behavior:**
|
||||
- Does NOT produce UX flow design
|
||||
- Explicitly states that interaction flow design belongs to `ux-designer`
|
||||
- Redirects the request to `ux-designer`
|
||||
- Notes it will implement whatever flow the ux-designer specifies
|
||||
|
||||
### Case 3: UI Toolkit data binding for dynamic list
|
||||
**Input:** "The inventory list needs to update in real time as items are added or removed from the player's bag."
|
||||
**Expected behavior:**
|
||||
- Produces the `ListView` pattern with a bound `ObservableList<T>` or event-driven refresh approach
|
||||
- Uses `ListView.Rebuild()` or `ListView.RefreshItems()` on the backing collection change event
|
||||
- Notes the performance considerations for large lists (virtualization via `makeItem`/`bindItem` pattern)
|
||||
- Does NOT use `QuerySelector` loops to update individual elements as a list refresh strategy — flags that as a performance antipattern
|
||||
|
||||
### Case 4: Canvas performance — overdraw
|
||||
**Input:** "The main menu canvas is causing GPU overdraw warnings; there are many overlapping panels."
|
||||
**Expected behavior:**
|
||||
- Identifies overdraw causes: multiple stacked canvases, full-screen overlay panels not culled when inactive
|
||||
- Recommends:
|
||||
- Separate canvases for world-space, screen-space-overlay, and screen-space-camera layers
|
||||
- Disable/deactivate panels instead of setting alpha to 0 (invisible alpha-0 panels still draw)
|
||||
- Canvas Group + alpha for fade effects, not individual Image alpha
|
||||
- Notes UI Toolkit alternative if the project is in a migration position
|
||||
|
||||
### Case 5: Context pass — Unity version
|
||||
**Input:** Project context: Unity 2022.3 LTS. Request: "Implement the settings panel with data binding."
|
||||
**Expected behavior:**
|
||||
- Uses UI Toolkit with the 2022.3 LTS version of the runtime binding system
|
||||
- Notes that Unity 2022.3 introduced runtime data binding (as opposed to editor-only binding in earlier versions)
|
||||
- Does NOT use the Unity 6 enhanced binding API features if they are not available in 2022.3
|
||||
- Produces code compatible with the stated Unity version, with version-specific API notes
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Stays within declared domain (UI Toolkit, UGUI, data binding, UI performance)
|
||||
- [ ] Redirects UX flow design to ux-designer
|
||||
- [ ] Returns structured output (UXML, USS, C# binding code)
|
||||
- [ ] Uses the correct Unity UI framework version for the project's Unity version
|
||||
- [ ] Flags Canvas overdraw as a performance antipattern and provides specific remediation
|
||||
- [ ] Does not use alpha-0 as a hide/show pattern — uses SetActive() or VisualElement.style.display
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- Inventory UI (Case 1) should have a manual walkthrough doc in `production/qa/evidence/`
|
||||
- Dynamic list binding (Case 3) should have an integration test or automated interaction test
|
||||
- Canvas overdraw (Case 4) verifies the agent knows the correct Unity UI performance patterns
|
||||
Reference in New Issue
Block a user