Turn player actions and rule changes within the current task into timely, understandable feedback that fits the theme. First ensure the information and causality are clear, then choose deformation, particles, audio, camera, or time expression; quiet feedback can stand on its own, and quantity or intensity is not the quality standard.
Visible feedback complies withIn-game copy: Rewards, costs, and states are preferentially expressed with icons, numbers, symbols, or local changes; when text is needed, reuse the currently visible short labels and display conditions, and do not turn the reasons, settlement rules, or design intent from the event spec directly into floating text, toasts, or explanation panels.
Control plane and responsibilities
This domain may propose, review, and modify feedback design, configuration, or implementation within the Work Item, Implementation Package, and path ownership scope of the current user task; conclusions return to threejs-game-workflow-control audit and state transitions. It does not own global state, approval ledgers, or a second lifecycle, and does not add juice phases, mandatory artifacts, or approval gates.
- Gameplay owns rules, state, collision, and settlement; when hitstop, knockback, magnetism, input buffering, etc. would change gameplay, they are determined by gameplay and the applicable numeric domains and cannot be disguised as pure presentation changes.
- UI owns layout, focus presentation, and the layout coordinate contract; gameplay retains interaction code, and architecture maintains cross-module coordinate conventions. Feedback is enhanced through explicit visual offsets or presentation nodes, and does not contend for base layout properties and input handling.
- Art, 2D frame animation, 3D model animation, and audio continue to own the corresponding asset production, registration, timelines, and lifecycles. Frame animation can be used for HUD, billboards, or texture sequences, while 3D character skeletal animation is driven by model clips and
AnimationMixer; the two routes cannot impersonate each other. Prefer reusing existing modules, and do not create a new runtime manager for invoking this Skill. - QA automatically verifies rules, events, parameters, assets, cleanup, and performance; the display effect and actual feel of screenshots and recordings are manually accepted by the user. Do not automatically analyze images without explicit authorization, and do not infer visual pass from machine pass.
- Reuse the already authorized scope, service reuse, current branch, and testing rules; do not automatically start a real device or perform protected operations such as external writes, payments, or publishing.
Read on demand
| Current problem | Read content |
|---|---|
| Define direction, choose effects, or review feedback gaps | Complete design guideconcepts, feedback library, emotion and type chapters |
| Multi-channel conflicts, long play sessions, pause and resume | guide's combination, engineering boundaries, platform, and long-term experience chapters |
| Develop project event specs and acceptance | guide's feedback semantics, event templates, coverage checklist, and examples chapters |
| Integrate with existing GDD, scene phases, and domain handoff | Workflow integration |
The guide is a complete reference, but local tasks only read and adopt the relevant chapters; do not load the full type checklist by default or create effects for inapplicable items.
Execution loop
- Read the current scope, GDD/brief, actual ThreeJS version, existing events, and presentation components to determine the event being addressed, the problem, and the observable outcome. Reuse existing feedback contracts; do not recreate the same facts.
- Select capabilities according to the type applicability matrix, and clearly specify the applicable parts of preparation, occurrence, result, duration, and wrap-up, as well as the semantics of success, rejection, cancellation, interruption, and pending confirmation.
- Add the event table to the existing specification; when it is an independent feedback task and the original document is inconvenient to carry it, you may use
docs/game-feel.mdas needed. Record responsibilities, parameter units, repetition strategy, time and coordinate spaces, resources, and cleanup methods; these are domain facts, not a new machine schema. - Determine the minimal combination first, then add effects according to importance. Ordinary high-frequency events should be local, brief, and mergeable; danger and the current operation should remain clear. Fixed values are only a starting point for tuning; actual thresholds are defined by the project.
- Implement or hand off according to the current phase: in V1, clarify intent during scenario design; in V2, incorporate it into the existing breakdown/layout and production scope; in V3, deliver resources; formal scenario functionality, combination checks, and runtime acceptance are implemented within the existing V4 scope. Juice optimization must not be used to bypass any valid prerequisite.
- Recommend and automatically execute applicable checks according to the test level rules, and re-verify affected items after fixes; provide applicable dynamic evidence for repetition, stacking, interruption, and wrap-up, as well as key points for manual inspection. Clearly mark parts that were not run or not watched as unverified.
Delivery
Deliver only the event specifications or revisions, configuration/code/resource diffs, program and performance evidence, manual acceptance status, and remaining issues actually required by the current task. Record design completion, implementation completion, engineering verification, and manual experience acceptance separately; do not substitute "has juice" or "very satisfying" for evidence. Follow existing artifacts and valid confirmations, and do not reopen completed work or add a new confirmation chain for this Skill.