Convert player actions and rule changes within the current task into timely, understandable, theme-appropriate feedback. First ensure the information and causality are clear, then choose deformation, particles, sound, camera, or timing presentation; quiet feedback can be valid, and quantity or intensity is not used as a quality standard.
Visible feedback complianceIn-game copy: Rewards, costs, and states should preferably be 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 event specifications directly into floating text, toasts, or explanation panels.
Control surface 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 phaser4-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, snapping, input buffering, etc. would change gameplay, they are determined by gameplay and the applicable numerical domains, and cannot be disguised as pure presentation changes.
- UI is responsible for layout, focus presentation, and layout coordinate contracts; 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, frame animation, and audio continue to own the corresponding asset production, registration, timeline, and lifecycle. Prefer reusing existing modules, and do not create a new runtime manager for invoking this Skill.
- QA automatically verifies rules, events, parameters, resources, cleanup, and performance; the display effect of screenshots and recordings and the actual feel are manually accepted by the user. Do not automatically analyze visuals without explicit authorization, and do not infer visual pass from machine pass.
- Follow the already authorized scope, service reuse, current branch, and testing rules; do not automatically start real devices or perform protected operations such as external writes, payments, or publishing.
Read on demand
| Current issue | Read content |
|---|---|
| Define direction, choose effects, or review feedback gaps | Complete design guide's concepts, feedback library, emotion, and type chapters |
| Multi-channel conflicts, long play sessions, pause and resume | The guide's combination, engineering boundaries, platform, and long-term experience chapters |
| Create project event specifications and acceptance | The guide's feedback semantics, event templates, coverage checklists, 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 list by default or create effects for inapplicable items.
Execution loop
- Read the current scope, GDD/brief, actual Phaser version, existing events, and presentation components to determine the events being addressed, the problems, and the observable results. Reuse an existing feedback contract; do not recreate the same facts.
- Select capabilities according to the type applicability matrix, and clearly write the applicable parts of preparation, occurrence, result, duration, and wrap-up, as well as the semantics of success, rejection, cancellation, interruption, and pending confirmation.
- Supplement the event table in the existing specification; for an independent feedback task when 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 space, resources, and cleanup method; these are domain facts, not a new machine schema. - First determine the minimal combination, 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 stage: in V1, clarify intent in scene design; in V2, incorporate it into the existing breakdown/layout and production scope; in V3, deliver resources; formal scene functionality, combination checks, and runtime acceptance are implemented within the existing V4 scope. Do not use juice optimization to bypass any valid prerequisite.
- Recommend and automatically execute applicable checks according to testing level rules, and re-verify affected items after fixes; provide applicable dynamic evidence and manual inspection points for repetition, stacking, interruption, and wrap-up. Clearly mark parts that were not run or not watched as unverified.
Deliver
Deliver only the event specifications or revisions actually required by the current task, configuration/code/resource differences, program and performance evidence, manual acceptance status, and remaining issues. Record design completion, implementation completion, engineering verification, and manual experience acceptance separately; do not replace evidence with “juicy” or “very satisfying.” Follow existing artifacts and valid confirmations; do not restart completed work or add a new confirmation chain for this Skill.