Phaser 4 Game Art Production and Integration

Global Control Integration

Control Plane Boundaries: Proposals, reviews, and modifications are allowed within the scope of Work Item task authorization or explicit approval, and must return to the

$phaser4-game-workflow-control

risk gate.

Within this domain, proposals and reviews are allowed, and resources can only be produced or integrated within established and task-validated Work Items, Implementation Packages, Level A and paths; all conclusions are subject to audit and state migration in

phaser4-game-workflow-control

. V0-V5 are

stageId

s, and bypassing global states, Level A4-A6 precise operation approvals, diff audits and evidence gates is prohibited.

Workflow

Scene Reconstruction Contract (effect-image Mandatory)

effect-image

refers to the faithful reconstruction of a complete formal Scene, not independent PNG production. A

scene_reconstruction_contract

must be in place before entering V3: freeze target conditions, full-screen composition, visual facts per coverage region (runtime-data/runtime-rendered/runtime-program must also have

fidelity_obligations

), target-bound layout, responsive relationships, pre-declared tolerances and resource/layout/runtime object/composition implementation plan. If the contract is missing or the layout contract is not bound to the current target SHA, it must return to

V1/PROPOSAL

V4 requires pre-acceptance of same-screen composition using formal Scene structure; V5 requires structured fidelity cases, region-by-region measurement and difference evidence, deterministic machine F2, F3 runtime replay and formal Scene consumption evidence. Resources loaded/used, missing=0, and stable resize are only part of engineering sub-gates and cannot independently drive COMPLETE.

Read project configuration, GDD, visual-design, TDD, control plane and resource registration; execute V0-V5 Visual Production Pipeline.
At V0, first determine whether the task belongs to atomic resources, components/resource sets, or scenes/complete UI/visual systems/reference reconstruction. Atomic resources can skip V1/V2 only if their structure, layout, interaction and viewport behavior remain unchanged, and there are applicable visual contracts,
```
AUTO
```
or
```
USER_DECISION
```
records, visual deliverable conclusions and budget baselines.
At V1, establish gameplay visual contracts, necessary low-fidelity/graybox and budget; at V2, execute direction benchmarks, dynamic samples, machine structured checks and a single human visual direction approval. When the Work Item specifies a render as the reconstruction target, enable faithful reconstruction mode according to Visual Reconstruction, freezing the reference identity, comparison conditions and observable visual facts as visual targets; adaptations within tolerance that do not change visual facts can be
```
AUTO
```
, and any visible deviation or substantial trade-off must record an accurate
```
USER_DECISION
```
and approved exception. Do not automatically change frozen visual targets under the pretext of professional fixes or enhancing game feel.
Schema 1.5
```
visual-assets.json
```
first declares
```
effect_image_reconstruction
```
: ordinary assets are
```
not-applicable
```
, no reconstruction artifacts required; render reconstruction is
```
effect-image
```
. For the latter, after freezing the target and before entering V3, complete contract alignment and coverage with
```
v3-ready
```
, and fidelity cases can be absent in V3/V4; only after V5 verification is completed can it be marked as
```
v5-complete
```
with all cases required to pass. For render coverage, register
```
annotation_number
```
and
```
implementation_plan
```
region by region, first complete ownership/implementation classification, then conduct
```
state_analysis
```
with evidence SHA, frozen target SHA, analysis ID and completion time, strictly complete this before component inventory, and finally fill in
```
component_inventory
```
, placements and
```
expected_assets
```
by unique atomic parts; numbers are not units of asset quantity. State analysis must cover normal, selected/active, disabled, pressed/hover, victory/defeat/paused, mark
```
required
```
for applicable states, and
```
not-applicable+reason
```
for inapplicable ones. ② The 6 top buttons must be 6 components; ⑧ The 3 identical bottom surfaces can be registered as 1 component + 3 placements; ⑨ Action icons are registered according to actual reuse relationships; ③, ④, ⑦ can remain as single images only if they are clearly single parts and other states are not applicable. Default individual mode prohibits horizontal sprite sheets; ImageGen unconditionally requires
```
individual + atlas_allowed=false
```
, its
```
expected_assets.width/height
```
is automatically calculated by the validator as
```
ceil(max placement width/height × intended_scale_range.max × 1.5)
```
in logical pixels, which must be the exact minimum size;
```
scene_asset_usage.max_dpr
```
must be strictly the number
```
1.5
```
,
```
padding_policy
```
must be
```
none
```
, and the size contract itself does not require human_review. Here 1.5 is the maximum production DPR; the actual runtime DPR is dynamically read by the device and capped at 1.5. Only non-ImageGen methods such as authored-raster/authored-svg/reuse can use complete
```
atlas_slice
```
atlases under explicit contracts. Each placement must declare
```
interaction_required
```
, and real
```
interaction_hotspots
```
can only be bound one-to-one by placement and are not counted as visual assets. The confirmation image still displays
```
generate-now
```
,
```
reuse-existing
```
and
```
runtime-program
```
simultaneously, but the PNG only draws the user summary and the labels "Generate This Time / Reuse Existing Resources / Program Implementation"; placement ID, coordinate size, component/state/asset technical fields do not appear in visible rows. When running
```
--proposal
```
, these technical fields are fully written into the disassembly analysis technical JSON, and bound to PNG metadata, region definition SHA and existing confirmation fields. ImageGen is only enabled when the contract explicitly declares
```
image_generation_required=true
```
, and must use
```
imagegen+raster-image
```
, complete prompts/generation records, output metadata and runtime consumption evidence;
```
independent-production
```
and
```
generate-now
```
do not make any ImageGen inferences. At V3, select the route according to Asset Production Routes.
At V3, run
```
node scripts/validate_visual_manifest.mjs docs/visual-assets.json --stage V3
```
; for formal acceptance at V4, run
```
node scripts/validate_visual_manifest.mjs docs/visual-assets.json --stage V4 --check-files --project-root .
```
, and for formal acceptance at V5, run the same command with
```
--stage V5
```
. Both stages verify real files, authorization, budget, frozen baseline, coverage,
```
production_contract_audit
```
, two types of machine evidence for F2, F3 runtime replay and freshness-bound fidelity cases item by item. The root node of the render list must be bound to a single camelCase
```
workItemId
```
and
```
candidateVersion
```
, and consistent with
```
candidate_identity.sha256/diff_fingerprint
```
and the current implementation package.
Complete the V3-V5 closed loop for all gameplay scenes first according to the G1 scene sequence, then complete supporting scenes; public formal resources are only allowed to be stably reused by at least two scenes or required for runtime. Only V4
```
accepted
```
resources are integrated into V5, and grayboxes, placeholders and fallbacks are cleared before joint acceptance of the current scene.
V1 graybox, V2 playable visual slices and V5 formal scenes use the same production Scene entry/skeleton for gradual reconstruction; prohibit one-time screenshot Scene, full-screen image laying, hiding overlays and absolute stacking to match pixels. At V5, collaborate with gameplay to complete structured integration, dynamic acceptance and low-fidelity cleanup; any change to fidelity case targets, code, layout or baseline identity must invalidate and re-collect.

The formal render annotation command must include

--proposal <file>.json

; omitting this parameter will directly fail, and no successful product with only user illustrations will be generated.

Reference Conditions

Reference screenshots, screen recordings, running projects or source code reconstruction: read Visual Reconstruction.
Decorative full-screen background in screen space: read Full-Bleed Background; for world space levels, Tilemap or gameplay environment, read Asset Production Routes instead.
UI: read the layout contract, Phaser adapter and evidence matrix of
```
phaser4-game-ui-layout
```
simultaneously; resource origin, layout anchor and animation offset are separated according to the contract, and resource integration must not reinvent layout rules.
QA measurement, dynamic resize, full viewport screenshot and read-only Hook: read Responsive Visual Validation, and do not copy its fields or thresholds in asset documents.

Audit and Delivery

All candidates must pass F0-F3 first, and F4 is only used for A4-A6. Deterministic machine checks for V1/V2 must be executed; user selection is conditional. Automatic paths record the basis for

AUTO

decisions, and substantial trade-offs record one

USER_DECISION

and write back to authoritative artifacts. Each delivery package records task authorization or A4-A6 operation approval, candidate identity, baseline, source, budget and evidence.

Unique Visual Human Approval Hard Gate

Only one structured human approval

visual_human_approval

is required when freezing the visual direction at V2 throughout the V0→V5 chain. It does not collect

reviewer_type

reviewer_id

or reviewer strings, and only expresses a human approval event with

review_id/reviewed_at/evidence/evidence_sha256

, PASS and frozen target, V2 candidate, diff, baseline SHA; if any binding drifts, the approval becomes invalid and returns to V2. V2 must still have complete screens, dynamic samples and structured machine checks. V4 actual asset/component×state/same-screen composition and V5 full viewport, overlay, diff, region-by-region fidelity, F2 visual consistency and production contract checks all use deterministic machine evidence bound to the current identity, and no further human approval can be required or forged. Root node PASS, boolean values, AI reviewer fields or subsequent repeated

human_review

cannot replace this unique V2 approval.

phaser4-game-asset-integration

NPX Install

Tags

SKILL.md Content (Chinese)