Turn particle polish into a visual acceptance contract

An artist can reject an effect that passes every code check. The timing can feel wrong, the focal point can disappear, or the effect can compete with the reward label. A technical test and a visual decision answer different questions.

This tutorial proposes a small acceptance contract for a fictional coin pickup effect. It is deliberately about the evidence an artist receives, rather than a particular renderer or particle tool.

Define the visual decision first

Use an approved reference from your own project. Record its revision, viewport, camera, background, and the instant at which the pickup event occurs. Compare the delivery with that reference under the same conditions.

For an example contract, the pickup starts at time zero. A ring becomes visible by 80 milliseconds, reaches its largest radius by 240 milliseconds, and is absent by 600 milliseconds. Those numbers are proposed art-direction requirements. They are not measurements of an existing effect.

The artist should approve the reference and timing before execution. Otherwise, the runner is being asked to invent the acceptance test as well as the implementation.

Write the technical brief separately

task: coin-pickup-polish
reference:
  source: approved project reference, revision recorded in task
  viewport_css_px: [390, 844]
  camera: fixed gameplay camera
  trigger_seconds: 0
scope:
  - adjust pickup ring timing and opacity only
  - preserve coin award logic and event count
capture_seconds: [0.08, 0.24, 0.60]
proposed_visual_checks:
  - ring visible at 0.08 seconds
  - ring reaches approved maximum radius by 0.24 seconds
  - ring absent by 0.60 seconds
  - reward label remains readable throughout
stop_if:
  - reference is unavailable or contradicts timing
  - implementation requires changing gameplay logic
review:
  engineering: lifecycle, event count, cleanup, regression risk
  art: timing, shape, focal hierarchy, reference match

The person preparing the task fills in the real reference and component locations. The authorized implementer uses their own environment and tools. An engineer reviews event handling and resource ownership. The artist judges the visual result. Expert supervised AI execution requires all four responsibilities even when two are held by the same person.

Make the capture process repeatable

The review scene should have a fixed trigger, a fixed camera, and a way to return to the same initial state. If the effect is randomized, record the seed. Avoid comparing a bright result on a dark background with a muted reference on a light background.

A review controller can expose the following adapter contract:

// Implement these methods using your project's existing test scene.
async function captureForArt(scene, captureFrame) {
  const samples = [0.08, 0.24, 0.60];
  const receipts = [];
  for (const seconds of samples) {
    await scene.reset({ seed: 461 });
    await scene.triggerPickup();
    await scene.advanceTo(seconds);
    receipts.push(await captureFrame({ seconds }));
  }
  return receipts;
}

This is an integration sketch, not a drop-in engine API. advanceTo must advance the real simulation using the project's time units. captureFrame must capture the rendered scene. Naming these methods does not mean screenshots or tests have been produced.

The reset before every sample avoids a common mistake: advancing from 80 milliseconds by another 240 milliseconds and labelling the result “240 ms.” A receipt should record the absolute sample time and the tested revision.

Give the artist a decision form

Revision:
Reference revision:
Camera / viewport / seed:
80 ms: visible? yes / no
240 ms: approved radius and shape? yes / no
600 ms: completely absent? yes / no
Reward label readable? yes / no
Art decision: accept / request changes
Correction, if any: state the failed criterion and frame
Engineering reviewer:

If the artist asks for a slower expansion, revise the requirement and capture again. If the ring stays on screen because a cleanup callback fails, keep that as an engineering correction. Both deserve a precise reason; neither should be hidden inside “needs polish.”

For the broader arrangement of art, implementation, and review tools, Wagglet's AI-native studio stack discussion provides related context. The contract here remains usable in a plain repository issue: the useful artifact is the agreed reference and decision record.

State what the contract cannot prove

Still frames cannot prove smooth motion. Add a short clip for temporal judgment, and retain stills for specific timing checks. Performance needs a separate device and rendering budget. A synthetic review scene can miss gameplay clutter, localization, and overlapping effects.

The artist's sign-off means the scoped visual request is acceptable under the recorded conditions. It does not replace engineering review, integration testing, or release approval.

Disclosure: This draft was prepared with AI assistance for a Wagglet-related content task. The contract and timing values are illustrative; no project screenshots or performance results are claimed.