Visual Work

Visual work is ordinary game delivery. Inspect and tune it through the real engine or game path that owns the content. Do not begin by building a parallel review site, detached renderer, contact sheet, or evidence package.

This guide applies to rendered appearance, animation, VFX, UI, lighting, camera composition, audio presentation, procedural readability, and other qualities whose truth depends on presentation over time.

Start With One Product Question

Name the subject, state or beat, production consumer, material context, and failure condition. A whole-project art audit or polish pass is valid when that is the requested outcome; otherwise, avoid inventorying unrelated content in search of something to review.

Examples:

• Does the Audience Member arrival read clearly at gameplay distance?
• Does this attack animation stay grounded on steep ramps?
• Do terrain materials remain readable under the production lighting rig?
• Does controller focus match the visible upgrade-card highlight?

Use The Smallest Truthful Native Surface

Choose the smallest existing surface that contains the production consumer and every context material to the claim:

Claim	Useful native surface
Import, mesh, material, rig, or local clip	Asset editor, prefab mode, or animation/VFX editor
Audio source or authored event	Middleware or engine authoring preview
Actor, prop, or effect in representative presentation	Existing scene, development route, or game-owned gallery
Camera, HUD, input, pause, loading, density, or post-processing	Actual game route or development player
Audio playback, spatialization, mix, ducking, or handoff	Actual game route with production bank/media, backend, listener, and emitter
Procedural layout or material variation	Production generator with fixed, exploratory, and promoted failure seeds

Being inside the engine is not enough when the chosen view omits the changed consumer. An isolated actor preview cannot establish gameplay-scale motion. A gallery without the HUD cannot establish HUD feedback. A still cannot establish continuous motion, and a video cannot establish input feel.

Resolve content through canonical catalogs, assets, scenes, prefabs, factories, rendering, animation, and runtime composition. Missing or unresolved content should fail visibly. Do not silently replace it with capsules, cubes, generic materials, synthetic animation, silent placeholder events, or detached replicas.

Exercise The Real Audio Chain

Audio presentation follows the same consumer-complete rule as rendering. A source file or middleware authoring preview can establish that authored audio exists. It cannot establish that generated bank or media is current, the runtime backend posts the right event, the listener and emitter are placed correctly, pause or UI states apply the intended mix, or menu/loading/gameplay handoffs start and stop the right music.

Include only the links material to the claim: authored source or event, generated output when applicable, runtime backend, listener/emitter state, mix or bus state, scene and lifecycle handoff, and target device or platform. Use logs for routing and lifecycle diagnosis, but listen through the real game for presentation. Human judgment owns loudness relationships, spatial feel, emotional effect, and taste. A recording can carry a remote mix decision; it does not prove the consuming runtime or interactive state that produced it.

Inspect The Material Context

Use only the context dimensions that can expose the named problem:

• close, gameplay, and distant framing;
• intended and diagnostic lighting;
• representative backgrounds and contrast;
• continuous playback, pause, scrub, and reset when time matters;
• sparse and dense gameplay composition;
• target aspect ratio, resolution, quality, and platform; and
• fixed, exploratory, and promoted failure seeds for procedural content.

Repeated presentation controls should be human-editable. A human may own camera presets, free orbit, distance, field of view, background, lighting, playback, quality, density, and seed. Automation may fill absent defaults, but should not overwrite deliberate authored choices.

Production-Integrated Gallery Pattern

When players, authors, or developers repeatedly need to inspect many subjects, an in-game almanac, codex, bestiary, model viewer, world previewer, or editor gallery can be the right product feature. Its value is that it improves the project itself while reusing the same content and rendering path. It is not a STAGE subsystem or maturity step.

A useful implementation usually provides:

• canonical subject identity and content resolution;
• meaningful states or beats such as idle, attack, hit, death, arrival, open, consumed, or generated;
• uninterrupted production animation and VFX playback;
• camera presets plus direct human framing controls;
• representative lighting, backgrounds, distances, quality, and density;
• fixed seeds and bounded random exploration for generated content;
• visible loading, missing-content, and unsupported-state failures;
• complete pointer, keyboard, and controller input when it ships to players;
• explicit reset, teardown, and temporary-object ownership; and
• no second catalog, substitute renderer, or preview-only behavior when the production path already owns the answer.

The feature supports only the consumers and context it actually contains. It may be excellent for actor art and animation while remaining unsuitable for combat readability, HUD, loading, input feel, or platform performance. Use the ordinary game route for omitted claims.

Do not build this feature solely because an evidence workflow asks for it. Build it when its player, authoring, or recurring development job independently justifies the maintenance cost. Once it exists, both humans and agents may use it through normal project controls or an earned project-owned operation.

Human And Agent Roles

Automation can open a subject, set a known state, choose a seed, position a camera, change diagnostic lighting, replay motion, inspect references, and check objective properties such as bounds, topology, focus, leaks, reset, or shader support.

Rendered observation and acceptance remain separate claims. An operation can change state without proving the visible result. An agent can report what it observed, but the accountable human judges composition, readability, motion feel, atmosphere, and taste.

When the owner can inspect the engine directly, leave the relevant live view or playback ready. That is already a useful review handoff; it does not need to be wrapped in a report product.

Export Only For A Named Consumer

Screenshots, motion clips, comparisons, and HTML are exports. Produce them when a remote reviewer, CI check, audit, release, cross-platform comparison, or retention decision needs portable output that the live engine cannot provide. Prefer project- or engine-owned capture of the same production content.

Retain only the views the consumer uses. More angles, distances, backgrounds, or contact-sheet cells do not compensate for an unclear question or missing production context.

Recorded Lesson

The Circussy detached-rehearsal experiment produced technically valid capture manifests, screenshots, video, and a contact sheet. The package was still less useful than Unity and the game. The one valuable result was a coherent Enemy Arrival motion preview using real authored content to answer one concrete question. The lesson is not to improve the detached package; it is to keep visual work in the production engine and invest persistent effort in the game or authoring surface when that surface has an independent user.

See the retained Circussy visual-workflow lesson for the bounded evidence and limitations.