Phaser 4 Image Resource Optimization

Global Control Access

$phaser4-game-workflow-control

phaser4-game-workflow-control

Execution Boundaries

• Only propose the task when the user explicitly calls

  $phaser4-game-image-optimization

  ; A0-A3 writes use task authorization from independent Work Items, and only actual A4-A6 operations require precise approval. It must not be automatically invoked due to large package size, entering the release phase, executing builds, or running tests.
• Treat this task as an explicitly triggered resource domain task, and incorporate it into A0-A3, local phases, and unified gates according to actual actions; it must not be automatically added to build scripts, Git hooks, or CI, nor implicitly triggered by release status.
• By default, only process PNG, JPEG, and WebP files referenced by runtime code, resource manifests, or loading configurations within the project. Design source files, reference images, audit evidence, screenshots, test fixtures, build artifacts, caches, and unused runtime materials are excluded.
• GIF, APNG, texture atlases, normal maps, pixel art, nine-slice images, and images with special color spaces are high-risk resources; retain their frames, pixel grids, channels, boundaries, and metadata semantics, and only process them when corresponding verification is executable.

Optimization Process

1. Determine the user-specified directory, target channel, allowed formats, image quality baseline, and volume target. When no directory is specified, reverse-engineer actual runtime images from resource loading code, resource manifests, and build entries, and do not perform broad scans of paths outside the project or the entire disk.
2. Establish a pre-compression baseline, recording path, reference location, format, byte count, width and height, transparency channel, animation or atlas attributes file by file, and summarize the total size. Use content hashing to identify duplicate files, but do not merge or delete them without reference analysis.
3. Generate results in an independent candidate directory; direct overwriting of original files is prohibited. Record the optimization tool, fixed version, complete parameters, and exit status; prioritize reusing existing project tools and do not add runtime dependencies for one-time tasks.
4. Keep the original format, size, orientation, and file name by default:
   • For PNG, prioritize lossless metadata cleaning and lossless compression; only use lossy palette quantization when the image quality baseline allows and verification of transparent edges, gradients, and pixel differences is complete.
   • For JPEG, only process images that do not rely on transparency, use controlled-quality progressive compression and remove unnecessary metadata, without changing EXIF orientation presentation.
   • For WebP, first determine if it is already near optimal; retain the original file if repeated lossy encoding provides no clear benefit.
   • Only convert to WebP or AVIF when the user allows format migration, and the target channel, Phaser loader, and downgrade strategy have all been verified; synchronously modify references, resource manifests, and loading configurations, and do not retain duplicate runtime resources without references.
   • Sprite sheets, texture atlases, nine-slice images, and pixel art must not be scaled, cropped, padded, rearranged, or have their frame coordinates changed; only compression of their image containers is allowed.
5. Perform structure and image quality verification on each candidate: successful decoding; consistent width and height, orientation, transparency, frame count, and atlas coordinates; compare decoded pixels for lossless candidates; check transparent edges, gradients, text, thin lines, pixel grids, and representative zoom differences for lossy candidates. Retain the original file and mark it as "unverified" if evidence is insufficient.
6. Actually load the affected resources in Phaser and verify at least one reference scenario; verify the corresponding runtime status when atlases, nine-slice images, pixel art, or animations are involved. Then run affected tests and production builds to confirm no loading errors, path errors, sampling anomalies, or candidate files entering the build by mistake.
7. Replace the original file only if the candidate has a smaller volume and all applicable verifications pass; retain the original file if any verification fails, volume does not decrease, or the benefit does not offset the risks of image quality and compatibility. After replacement, recheck references and version control differences to ensure the modification scope only includes approved resources and necessary references.

Result Report

• Optimization scope, exclusions, target channels, tool versions and parameters;
• Original size, optimized size, bytes saved and ratio for each file, as well as reasons for retention or rejection;
• Overall volume comparison before and after, listing actual changes in source resources and production builds separately;
• Evidence of structure, image quality, Phaser runtime, testing, and production builds;
• Reference modifications caused by format migration, unverified items, remaining risks, and rollback methods.