SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsphaser4-game-architecture

phaser4-game-architecture

General & other

View repository

Updated 10-16 01:29

About this skill

Phaser 4 Technical Architecture

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, payments, real devices, destructive or external deletions, or release side effects are approved.

This domain may propose, review, and modify within the scope of the current user task, Implementation Package, A grade, and path; any result must return to phaser4-game-workflow-control risk gate. Within-task plan and path changes can continue by simply updating the plan; first-time module or boundary changes close the facts first, and only substantive architectural trade-offs stop and go to grilling.

Establish maintainable, testable, buildable boundaries and explicitly handle the differences among mini games, iOS, and Google Play.

When dynamic feedback genuinely involves public events, time coordination, or lifecycle boundaries, refer as needed toJuiciness Engineering Boundary; reuse existing capabilities first, do not introduce a public framework for a single effect, and keep rules, presentation, and audio ownership separate.

Inputs and Boundaries

Read the global Work Item, module audit, dependency capability profile, service boundaries, and project authoritative artifacts. Submit results according to F0 scope and process, F1 specification consistency, F2 architecture quality, F3 engineering verification, and F4 integration/release decisions, without changing global state on your own.

  • Implement the web core with Phaser 4, TypeScript, and Vite; for new projects, prefer the official current create-phaser-game workflow.
  • Use Capacitor to host iOS and Android only when the mobile platform profile is triggered by actual requirements, and encapsulate each adopted plugin in the platform adaptation layer; initialization must not install non-essential plugins by default.
  • Mini games must be verified separately; optional commercial capabilities must have explicit interfaces and approved switches.
  • During the foundational module phase, establish a unified audio service and lifecycle adaptation, according toBackground Pause and Resume ConstraintsImplement background pause and foreground resume from the original position; retain manual pause and mute state, prevent duplicate resumes, stale sound effect catch-up playback, and revival of destroyed instances, and include them in the foundational package and TDD.
  • Foundational module implementation must completeFoundational Display Constraints: the game fills the actual available viewport; the Android host has no window title bar or ActionBar from the first launch frame through the entire runtime, and implements immersive fullscreen and foreground/focus recovery. Startup theme, runtime theme, window configuration, and viewport/safe area adaptation are included in the foundational package and TDD, and are not deferred to the scene implementation phase.

Execution and Handoff

When creating a new game project, implementing foundational modules, or adjusting directory and module boundaries, first readGame Project Directory Specification, organize code by entry/foundational service layering and scene feature aggregation, clarify the ownership of assets, platforms, tests, and artifacts, and write the actual paths and ownership into the TDD and implementation package.

  1. Before implementation, divide and audit modules, recording responsibilities and non-goals, public inputs/outputs, state ownership, lifecycle, allowed/forbidden dependencies, failure boundaries, tests, and implementation order; for first-time modules, complete the module gate and grilling first, then write into the TDD according to F0-F4. Global phases, visual hard gates, and scene prerequisites are based onControl model、States, phases, and stop gatesand the corresponding Schema shall prevail; this domain only supplements module boundaries.
  2. In the TDD, mark foundation-only SHARED/MODULE scope, scenario SCENE/DISPLAY_LAYER ownership, and cross-scenario INTEGRATION dependencies. The foundation package only provides stable contracts and does not implement specific scenario gameplay, UI/layout, formal visible asset consumption, or Boot→formal visible Scene integration; modules may proceed in parallel with mutually exclusive ownership, while shared contracts/entry points remain serial. Scenarios collaborate only through public services, state repositories, or message contracts, and must not directly access the internal state of other Scenes.
  3. When adding modules, splitting responsibilities, or adjusting the implementation approach within a task, update the plan and ownership synchronously, and perform targeted verification of the affected parts. Create a Change Request and request a decision only when the goals, external behavior, or substantive design trade-offs that the user needs to decide change; only A4-A6 operations with side effects enter the F4 approval gate.
  4. Establish a single adapter for decorative screen-space full-bleed backgrounds, covering creation, wake-up, restoration, orientation, and canvas size changes; specific scaling, focus, and cropping rules are defined by the project contract. World-space levels, Tilemaps, collisions, or gameplay environments must use independent objects, maps, and layer data, and must not use the decorative background adapter or be flattened. In the scenario TDD, according toDisplay object anchors and display layer layeringdeclare named render root layers and the back-to-front composition order, covering the actually used background, world background, world main body, foreground/effects, persistent HUD, and transient layers; each layer records Camera/coordinate space, scrolling, cropping, input, lifecycle, and owner. Display objects that can set an origin default to explicitly using center (0.5, 0.5), and non-center exceptions record the reason and conversion; layout docking points and Camera origins do not replace object origins. The front-to-back relationship of different root layers must not be inferred solely from local depth values or creation order.
  5. When UI is involved, use phaser4-game-ui-layout to define the single logical coordinate and layout entry point, and fully record in the Work Item/Implementation Package/TDD logicalViewportSpace、designResolutionPolicy、canvasBackingPolicy、runtimeDprPolicy、maxRuntimeDpr=2、scaleMode, Camera viewport/zoom/origin, input coordinates, safe area, resize, orientation, text/asset resolution, performance budget, representative viewport, and runtime evidence fields. CSS logical dimensions are used for gameSize, layout, safe area, breakpoints, click areas, and programmatic text; Canvas backing must be CSS dimensions × effective DPR, and physical pixels must not directly become layout coordinates. DPR must be dynamically read from the device, invalid values fall back to 1, and when it changes, refresh CSS/backing and clean up listeners; asset production 1:1 baseline is separated from runtime DPR. Portrait uses a 1080×1920 design baseline and adapts by width, landscape uses a 1920×1080 design baseline and adapts by height; Canvas uses RESIZE or equivalent custom to fill the real viewport, the background scales proportionally to cover, leaving no black bars, and the bidirectional mapping of Camera and input must be proven. Popups/DISPLAY_LAYER inherit the host viewport, DPR, Camera/input, and safe area, and must have an independent runtime trajectory and evidence. Layout recalculation starts from contract values and remains idempotent; asset origin, layout anchors, and animation offsets are separated from each other, and it is forbidden to scatter screen coordinates without referential semantics across multiple lifecycle callbacks. Contract validators belong to F3 engineering verification; when fixed values or absolute positioning are fully justified, trigger the layout-specific F2.
  6. Separate core rules, presentation, platform, and third-party services. Public code and public formal assets must be stably reused by at least two confirmed scenarios, or be required for operation; unbounded common/utils and the public asset library. In the foundation-only phase, the SHARED only provides minimal startup, public contracts, and the Boot/Preload lifecycle,MODULE only provides scene-agnostic data/state/input/platform/asset infrastructure and test support; specific scene business logic, UI/layout, and formally visible assets are still completed in the corresponding scene phase. Each scene completes gameplay, formal visuals, all UI/popup display layers, cleanup, and joint evidence together in its own phase. Gameplay exclusively owns rules, state, collision, and interaction code; art may maintain pure presentation asset configuration, layout/presentation prefab data, and visual integration adjustments, but must not change gameplay rules, collision semantics, or state ownership. Define verification strategies for collaborative integration, touch, safe areas, pause/resume, background switching, and network disconnection.
  7. For components/asset sets and scene paths, define in V1 the per-scene textures, atlases, frame counts, animation sampling, texture memory, overdraw, Draw Calls, and maximum texture budget; in V3 write the budget into the machine manifest, and in V5 only verify. Atomic assets must reference an existing applicable and valid gameplay visual contract and budget baseline, otherwise escalate the path; do not relax them temporarily during acceptance.
  8. In the TDD, record as needed the core, mobile platform, data/API, complex gameplay, advanced visual, and commercial capability tiers; each item includes the reason for enabling, the rejected lightweight option, runtime performance and platform risks, verification commands, and owner. When services are involved, record contract version, authentication/authorization, idempotency/retry/timeout, compatibility, migration/rollback, testing, monitoring, and backup recovery; when the server side is out of scope, record only external dependencies, owner, and client boundaries.
  9. In the TDD, define the local service identity, default mode, host/port, and health check. Before starting the development or preview service, check the listening process, command line, project root directory, and health status; if the identity matches and it is healthy, reuse it directly and do not start it again.
  10. After the shared foundation is complete, provide representative Vite/Phaser startup, Boot/first scene, assets, and applicable plugin smoke tests; after the key gameplay flow is complete, provide a smoke test run on the primary target platform; only final integration/G3/release executes the full platform matrix. Do not claim all-platform pass based on partial evidence, and do not automatically initiate real-device acceptance.
  11. After F0 is complete, submit scope and process facts; F1 submits specification mapping; F2 submits independent architecture conclusions; F3 submits the candidate SHA, actual command evidence, and uncovered items.

Hand over to gameplay development the module entry points, data flow, and test entry points; hand over to testing the build commands, versions, and log location methods. Add Simplified Chinese comments explaining design boundaries to all newly added or modified classes, functions, and entity definitions.