Game Visual Production

Use with the chosen gameplay architecture and sce-preview-verify. The result should read as the requested game in a real playable view, with clear actors, space and feedback. A successful build, loaded resource or non-black frame establishes only part of that result.

In generated projects, canonical SDK documents live under docs/sdk/. If a guide link from a mirrored .codex/skills or .cursor/skills folder does not resolve, open the corresponding docs/sdk/guides/ file or this skill under docs/sdk/ai/skills/game-visual-production/; sibling skill links remain discoverable in the mirrored skills root.

Establish a representative scene

Before producing many assets or adding levels, write a short visual direction in the project: setting/style, player/enemy silhouettes, ground and prop materials, main/accent lighting, camera framing, HUD treatment, and hit/defeat/restart cues. Infer reasonable choices from the user's reference and existing art; ask only when a material product choice is missing.

For a supplied game/reference project, inspect its actual normal gameplay image and source asset assignments. Record the player, enemies, weapon and scene props by role and runtime resource path. Distinguish generated art, official art, placeholders and import-test assets. Match the requested cast, not whichever imported model is easiest to find. Reuse verified assets when appropriate; generated assets are optional and should serve a missing visual role.

Select a small playable scene that shows the main mechanic and visual direction together. Use wasicore-game-scaffold to locate a sample. Unit/Ability, GameGraph and Canvas can all produce intentional games; choose them by gameplay/authority needs and validate the result on its actual rendering path. Do not promise complete UrhoX parity from similar API names.

Produce a coherent image

Area	Concrete decisions and checks
Scene	Define playable routes, spawn/entry points, cover or landmarks, readable boundaries and a quieter gameplay floor. Place props with a purpose and scale hierarchy. Use markings or material detail to reinforce the setting rather than oversized diagnostic grids/rings.
Actors	Separate player, enemies and interactive objects by silhouette/value/color. Verify their actual resource identities, material slots and textures in both normal view and close-up. Keep articulated-part pivots and rig contracts when importing.
Camera	Frame the playable space, threat approaches and landmarks at the target aspect ratio. Tune camera follow/offset with actor speed and size. Check both center and edge positions; a close-up for asset review is not the gameplay camera.
Light	Establish readable key/environment illumination, then add motivated local accents. Inspect shadow softness/coverage, contact and bright/dark transitions. Compare local lights on/off in the same state; verify effects by rendered difference.
HUD	Use one project palette/shape/typography/spacing system. Group health, weapon and mission/score. Reserve aiming/action space and respect safe areas. Inspect the smallest intended window, long text and important state changes.
Action	Choose a projectile/beam/effect that suits the weapon and world. Connect muzzle, travel or tracer, impact, enemy response and score feedback; do not leave diagnostic lines as final art unless that is the intended style.
Round end	Clearly show success/defeat and the next action. A central result/restart panel and an appropriate tint/dim transition are useful choices. Check that gameplay follows the intended ended-state policy and that UI remains usable.

Follow ui-layout-api for actual GameUI layout/text semantics and UI font sizing for screen readability. For an industrial arena, industrial-hud.md supplies concrete palette, layout and state treatment. Adapt it rather than imposing it on unrelated art directions.

For model generation/import, use taptap-maker-assets, model import and, only for rigged humanoids, humanoid workflow. Static mechanical parts with procedural joints can be appropriate when the product allows that style; they do not verify skeletal retargeting or automatic weapon attachment.

Combat feedback and death timing

Connect sound to visible shot, impact, destruction and restart events where appropriate to the game's style. Inspect these in actual play: a loaded sound or a spawned effect does not establish that the player can hear or read it. Reuse suitable reference audio with its provenance and project-local resource paths.

When defeat freezes gameplay, keep timed death effects and result UI updating independently of movement, aiming, attacks and spawning. Give the burst a readable interval before a central panel obscures it when that fits the design. Reset should stop old voices, clear transient fragments/lights/projectiles, restore hidden bodies and remove the result overlay. Check both the first death and a subsequent round for stale effects or growing source counts.

Keep changes diagnosable

Preserve a working screenshot and its camera, scene state, material/resource paths and light/effect setup. During external-asset replacement or a rendering failure, change one suspect factor per comparison:

1. Replace one prop/character while retaining other known-working assets, camera and lighting. Check all material slots, textures, units, axes, bounds and floor contact.
2. Adapt floor/detail and scene layout after the individual asset renders.
3. Adjust camera and lights separately, with matched-state before/after images. Changing projection also requires matching clip planes, fog, shadows and input mapping.
4. Enable fullscreen effects individually with their resource dependencies. A vignette switch without its mask can invalidate the whole image even when models are correct.
5. Apply the HUD style, then inspect it with active gameplay and the critical result state.

Use this sequence to isolate a failure, not to force every harmless artistic edit into a formal experiment. If rendering becomes intermittent, capture the state/logs and perform one normal restart when appropriate. If the baseline recovers, resume one-factor comparisons; do not spend the whole game task speculating about adjacent engine features.

Use debug.list_tools to discover available Runtime MCP tools. When present, scenegraph.render_snapshot provides main-camera, candidate Zone, fog, vignette and light configuration; combine it with scenegraph.materials / material.probe for bound resource/technique state and ui.snapshot / ui.get_rect for layout. The effective native Zone and resolved vignette mask remain explicitly unknown; never treat candidate configuration as proof of the final render. Inspect the actual screenshot as well: successful loading, correct control rectangles and exposed shader flags do not prove a correct image. Follow the live schemas and runtime-mcp-target-routing when multiple clients/Gameplay targets exist.

Assess play, not only the opening frame

Capture and actually inspect evidence appropriate to the mechanic:

• A normal gameplay view with the representative scene and complete HUD.
• A close-up that shows actor/material/weapon details; keep its identity and purpose distinct from the normal camera.
• A short motion sequence/contact sheet: move sideways and backward while aiming/shooting for split-body games; inspect several animation phases and visible projectile travel, not one frozen pose. Record intervals/state so the sequence is interpretable.
• A gameplay transition: enemy attack/hit/death and the intended spawn/reinforcement location. Confirm behavior with state/inputs, not a posed screenshot.
• A failure/result image plus an actual restart-button interaction and keyboard restart when supported. Check ended-state input, overlay removal, projectile cleanup, round counters and restored play.

Compare references at the same window size and comparable scene density/camera purpose. Report concrete differences in composition, materials, lighting, HUD and motion, and make at least one visual improvement pass for a game deliverable. Use new evidence filenames for revised casts or lighting so stale images cannot be mistaken for the final version.

When tools cannot exercise a requested transition, name the unverified behavior and the missing operation. Do not call it verified because the API or a test script exists. Windows evidence establishes Windows behavior; use device evidence for platform-specific rendering/controls claims.

Reusable example

map_templates/gamegraph_top_down_pve_template contains an industrial arena, coherent actor cast, partial camera follow, lit materials, scene-space projectiles, peripheral HUD groups, edge reinforcements and a central defeat/restart panel. Its README and docs/visual-comparison.md explain both successful changes and rendering limits. Read the source for its patterns; do not transfer its client-local authority, centimeter-scale constants, static-part rig or camera workaround as universal requirements.