threejs-gameplay-development

three.js gameplay development

Global stages, visual hard gates, and scene prerequisites are based onControl Model、States, stages, and stop gatesand the corresponding Schema. This domain is only responsible for gameplay rules, states, interactions, and dynamic acceptance; scenes use the V1→V2→V3→V4 chain of the same Work Item, and V2's breakdown and layout confirmation are executed separately.

Global control access

Control plane boundaries: can propose, can review, can modify within the Work Item scope of the current user task, and must return to $threejs-game-workflow-control audit and state transition; only A4-A6 operation requests involving external writes, payment, real devices, destructive or external deletion, and release side effects request approval.

This domain can propose, review, and modify within the current user task, frozen Implementation Package, A level, and path scope; before any implementation run threejs-game-workflow-control preflight, after implementation execute diff-audit and evidence-check, then return to central control audit and state transition; only A4-A6 operation requests involving external writes, payment, real devices, destructive or external deletion, and release side effects request approval.

Ownership

Gameplay exclusively owns gameplay rules, states, collision, interaction code, functional graybox, 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; V4 is completed by gameplay and art collaboratively for joint runtime acceptance. 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 professional review; only grill 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 states.

Implementation

Player-visible content complies withIn-game copy: the formal interface only binds the visible expression of the current scene/state, short labels/localization keys, and dynamic values, and does not directly display rule paragraphs, feature descriptions, or acceptance fields from the GDD/brief. This rule covers no-effect graphics paths, HUD, buttons, pop-ups, Toast, and reward floating text; necessary guidance and operation consequences are retained under defined conditions.

1. Read the GDD, TDD, control plane, central control's review funnel, and game implementation rules. Visual tasks also read the visual quality gates and gameplay visual contract; UI reads threejs-game-ui-layout; reference reproduction reads the visual reproduction rules.
2. Advance gameplay delivery according to the stage gates of the current scene Work Item: V1 freezes functional specifications and necessary graybox, V2 freezes breakdown and layout facts, V3 accepts formal resources, V4 directly consumes V2/V3 artifacts to implement the formal SCENE/DISPLAY_LAYER, and completes joint functional and visual acceptance. foundation-only basic capabilities and cross-scene INTEGRATION are scheduled by the control plane plan; this domain must not place gameplay implementation ahead into the foundation package or create a separate scene lifecycle.
3. For the current scene, clearly define observable player behavior, state transitions, timing, feedback, success/failure, and exception recovery. Behaviors that screenshots cannot prove are marked as to-be-defined and are not inferred on one's own.
4. Only establish an isolated, runnable graybox when V1 needs to prove structure, interaction, or pacing; record stable IDs, hierarchy, interaction zones, and resource dependencies. An already frozen structure is not repeatedly grayboxed merely for form; a graybox must not serve as evidence of scene completion.
5. In the foundation-only phase, first complete the scene-independent SHARED/MODULE; after V2 layout confirmation and V3 resource acceptance pass, directly start formal SCENE code at V4. Scene implementation only closes the loop on gameplay, formal resources, scene-owned UI/persistent HUD, cleanup, and scene evidence. Popups such as modal/popup must be split into independent DISPLAY_LAYER Work Items, read their own V2/V3 evidence, and be accepted at their own V4; 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 enter formal feature implementation. Use Object3D/Group hierarchy, models, meshes, and cameras for structured assembly, according todisplay object anchors and display layer layeringdistinguish model local pivots, collision proxies, and Sprite.center; record coordinate units, transformations, and necessary exceptions, and declare the composition order and input ownership of background, world, effects, HUD, and transient layers. UI is computed from the threejs-game-ui-layout layout contract, distinguishing coordinate spaces, resource origins, layout docking points, and animation offsets, and idempotently rearranges 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. At V4, replay dynamic playable trajectories 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, then 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, pre-defined project tolerance, stable frames, and mask description. The complete viewport is the primary evidence; ROI, overlays, and pixel differences are only supplementary; generative content, animation, and VFX must not be judged by pixel differences alone. Unexplained or out-of-tolerance differences, missing evidence from both sides under the same conditions, missing approved exceptions, or subjective conclusions alone must not be reported as complete; source code, fixed coordinates, type checks, successful builds, and element existence can only prove structure or engineering state.

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