phaser4-gameplay-development

Phaser 4 gameplay development

Global phases, visual hard gates, and scene prerequisites are governed byControl Model、States, phases, and stop gatesand the corresponding Schema. This domain is only responsible for gameplay rules, states, interactions, and dynamic acceptance; scenes use the V1→V5 chain of the same Work Item, and V2 decomposition and layout confirmation are performed separately.

Global control access

Control plane boundary: may propose, may review, and may modify within the Work Item scope of the current user task, and must return to $phaser4-game-workflow-control audit and state transitions; only A4-A6 operation requests involving external writes, paid features, physical devices, destructive or external deletion, or release side effects require approval.

This domain may propose, review, and modify within the scope of the current user task, the frozen Implementation Package, the A level, and the path; any implementation must be preceded by running phaser4-game-workflow-control preflight, and after implementation, diff-audit and evidence-check must be run, then return to master control audit and state transitions; only A4-A6 operation requests involving external writes, paid features, physical devices, destructive or external deletion, or release side effects require approval.

Ownership

Gameplay exclusively owns gameplay rules, states, collision, interaction code, feature grayboxes, and low-fidelity cleanup. Art may own pure presentation-layer resource configuration, layout/presentation prefab data, and visual integration adjustments, but must not change gameplay rules, collision semantics, or state ownership; V5 runtime joint acceptance is completed collaboratively by gameplay and art. When changes in responsibilities, public contracts, state ownership, or dependency direction are found, stop the affected implementation and return to module audit and risk-triggered specialist review; grill only when protected trade-offs still exist.

When juice or dynamic feedback is involved, refer as needed toJuice Design Guide. Gameplay continues to own rule outcomes, collision, states, and feedback trigger conditions; behaviors such as knockback, hitstop, or input windows that change actual gameplay are still defined and accepted by gameplay, and pure presentation offsets do not override gameplay state.

Implementation

Player-visible content complies within-game copy: formal interfaces bind only to the visible expression, short labels/localization keys, and dynamic values of the current scene/state, and do not directly display rule paragraphs, feature descriptions, or acceptance fields from the GDD/brief. This rule covers no-mockup paths, HUD, buttons, pop-ups, Toasts, and reward floating text; necessary guidance and operation consequences are retained according to defined conditions.

1. Read the GDD, TDD, control plane, master control review funnel, and game implementation rules. Visual tasks also read the visual quality gate and gameplay visual contract; UI reads phaser4-game-ui-layout; reference reproduction reads the visual reproduction rules.
2. Advance gameplay delivery according to the phase gates of the current scene Work Item: V1 freezes feature specs and necessary grayboxes, V2 consumes confirmed decomposition and layout facts, V3 accepts formal resources, V4 saves and confirms sketches, V5 implements formal SCENE/DISPLAY_LAYER, and V5 completes joint feature and visual acceptance. foundation-only foundational capabilities and cross-scene INTEGRATION are scheduled by the control plane plan; this domain must not place gameplay implementation ahead of time into the foundation package or create a separate scene lifecycle.
3. For the current scene, clearly identify observable player behavior, state transitions, timing, feedback, success/failure, and exception recovery. Behaviors that screenshots cannot prove are marked as undefined, and are not inferred independently.
4. Only when V1 requires proving structure, interaction, or pacing, establish an isolated runnable graybox, recording stable IDs, hierarchy, interaction zones, and resource dependencies. A frozen structure is not repeatedly grayboxed for formality; a graybox must not serve as evidence of scene completion.
5. In the foundation-only phase, first complete the scene-independent SHARED/MODULE; after the scene V4 sketch is confirmed, start the formal SCENE code in V5. Scene implementation only closes the loop on gameplay, formal resources, scene-owned UI/persistent HUD, cleanup, and scene evidence. Modals/popups and other popups must be split into independent DISPLAY_LAYER Work Items, read their own V2/V3 evidence, and be accepted in their own V5; popups do not belong to the lobby or other host scene implementation, nor do they block its acceptance.hostSceneId is only used for public interfaces and runtime context wiring.
6. Only use resources bound to the current scene_id or compliant shared and V3 accepted resources to enter formal feature implementation. Assemble structurally with independent GameObjects, named containers, and layers, according todisplay object anchors and display layer layeringexplicitly set the default center for objects that can have an origin set (0.5, 0.5), record non-center exceptions per object, and declare the composition order and input ownership of the background, world, effects, HUD, and transient layers; UI is computed from the phaser4-game-ui-layout layout contract, distinguishing coordinate spaces, resource origins, layout docking points, and animation offsets, and idempotently reflowing through a single entry point after viewport, safe area, orientation, state, and content changes. Ordinary tests verify relative relationships and do not treat absolute screen coordinates as a universal acceptance standard.
7. In V5, replay the dynamic playable trajectory with art, checking recognition, warning, hit/hurt/reward feedback, occlusion, responsiveness, performance, and functional contracts. Faithful reproduction provides a complete viewport under the same conditions at the frozen target viewport/state and updates the per-state, per-region fidelity matrix; other viewports verify layout relationship invariants; gameplay handles rule/interaction failures, art handles pure presentation failures, and cross-domain issues enter F3.
8. After the formal structure passes, gameplay removes low-fidelity code, texture keys, resources, fallbacks, and runtime references, and reruns tests and the production build. The current scene can be marked complete after scene functionality, resources, integration, scene-owned display layers, placeholder cleanup, and verification are closed; independent popups are accepted separately.

Evidence

Screenshot comparisons record the same viewport, device pixel ratio, state, operation trajectory, language, time point, ROI, predefined project tolerance, stable frames, and masking notes. The complete viewport is the primary evidence; ROI, overlays, and pixel diffs are supplementary only; generative content, animation, and VFX must not be judged by pixel diffs alone. Unexplained or out-of-tolerance differences, missing same-condition evidence from both sides, missing approved exceptions, or subjective conclusions alone must not be reported as complete; source code, fixed coordinates, type checking, successful builds, and element existence can only prove structure or engineering status.

F0 only verifies task scope and process, F1 checks the established specification, F2 has a non-author verify gameplay domain quality, F3 binds current candidate engineering evidence, and F4 only approves A4-A6 integration/release operations with side effects. Behavioral or acceptance changes create a Change Request and record the user's decision. New or modified classes, functions, entities, and complex logic use Simplified Chinese comments.