Feedback should strengthen the player's understanding of gameplay outcomes that have already occurred, and must not replace server rules, hit determination, or economic facts. Before starting, read the gameplay events, visual and audio registry, andStudio plugin routing。
For any feedback that includes character or object animation, first follow theanimation intent and integration contractto specify the producer, Rig/Animator, AnimationId permissions, event semantics, and respawn/interruption cleanup; Studio plugins have no automatic animation production, recording, or export tools, and animation completion cannot be inferred from mesh generation or technical wiring.
Responsibilities and Inputs
- Gameplay owns authoritative state, event semantics, action triggers, and values; juice is responsible for the presentation mapping and lifecycle of confirmed events.
- Read the real Animation, Sound, ParticleEmitter, UI, and object pool structures; confirm whether the presentation should run on the client or the server.
- When events include new rules, knockback, hitstop, or input control, hand them back to gameplay/balance for evaluation, and do not expand effect logic into gameplay implementation.
- When there are substantive trade-offs in special visual direction or primary feedback semantics, hand them to the production designer; complete routine intensity and duration according to approved goals.
- If the feedback involves new gameplay permissions, stimulus budgets, or target selection and the evidence cannot eliminate ambiguity, hand it tointerrogation skill, and do not decide the rules for the user through effect production.
Execution Steps
- For the event, record the source, the information the player should understand, parameters, trigger timing, consumer side, presentation channels, and priority.
- Clarify the intensity, duration, repetition strategy, and stop conditions for animation, sound, particles, Tween, camera, and UI respectively.
- When similar events repeat rapidly, choose replay, reset, merge, rate-limit, or ignore, and verify that important gameplay information is not obscured.
- When multiple types of events stack, specify priority and concurrency limits; avoid multiple effects simultaneously competing to write the same property.
- Define cleanup for AnimationTrack, Tween, connections, delayed tasks, and temporary properties on character respawn, player exit, object pool reuse, and UI close.
- The client only plays feedback and does not grant rewards or confirm hits based on it; a clear waiting state may be shown before the server fact arrives.
- Check behavior after pause, respawn, leaving, and missing resources; restore temporarily modified properties after feedback is complete.
Delivery and Verification
- Deliver the event mapping table, resource identities, trigger side, intensity/duration, repetition and stacking rules, priority, and cleanup strategy.
- Use Studio instances and script checks to confirm connections and resource paths; after the user authorizes running, record the actual repetition, stacking, and interruption traces.
- QA accepts item by item according to normal triggering, rapid repetition, peak stacking, interruption, respawn, pause, and exit.
- Numerical settlement is handled by gameplay development ; for audio and resource sources, refer respectively to audio and visual resources。
- When visual acceptance is needed, provide screenshots and inspection points, and wait for the user to manually judge the display effect; do not automatically judge images.
Do not let the camera/animation/UI rewrite server-authoritative state. Do not leave behind stale feedback state on looping tasks, event connections, or object pool instances.
Presentation conflict handling
- Hit confirmation, damage values, reward results, and turn state are driven by server events; predictive animations must be able to wrap up when the result is rejected.
- High-priority feedback may interrupt lower-priority presentation, but after it ends, restore the overridden transparency, color, speed, and volume.
- Specify only one primary writing presentation for the same character attribute; other feedback uses independent layers or a compositing strategy.
- Touch and small-screen scenarios reduce long-term occlusion; critical events must not be distinguishable only by color, screen shake, or sound effects.
- Persistent visual effects should be recycled based on player distance, visibility, or gameplay state, limiting the number on screen at once.
- When animation loading fails, fall back to a clear base pose or event prompt; do not let gameplay state wait on presentation resources.
- When a match ends, a menu opens, or the player dies, cancel feedback sequences that no longer make sense.
- World feedback shared by multiple players must indicate replication responsibility; only local camera or HUD effects remain on the client.
- QA must separately check single effects, rapid consecutive triggers, and multi-event stacking, and must not infer actual presentation from resource previews.