Real-Time Game Graphics
Engineer a coherent image from camera to presentation while keeping visual intent, GPU work, memory traffic, synchronisation and target-device evidence visible.
Prerequisites
Load the approved visual direction, game-math-and-simulation, game-3d-asset-pipeline, mobile-game-performance, and the selected engine's current rendering documentation.
Use When
- Selecting or configuring a render pipeline, graphics API, colour/HDR policy, lighting model, shadow strategy or post stack.
- Writing or reviewing shaders, materials, render features, compute work, command/resource lifetimes or frame-graph passes.
- Diagnosing overdraw, draw submission, bandwidth, shader variants, GPU stalls, visual instability or renderer-specific device defects.
Do Not Use When
- The request is only to model, texture, rig or import assets; use
game-3d-asset-pipeline.
- The request is a general performance investigation without a GPU/rendering diagnosis; start with
mobile-game-performance.
- Native Vulkan/OpenGL work is proposed inside a Unity/Godot title without a measured engine limitation and ADR.
Inputs
| Artefact |
Produced by |
Required? |
Why |
| Visual direction and readability hierarchy |
art/game direction |
yes |
Defines the image the renderer must protect |
| Camera, coordinate and lighting contract |
game-math-and-simulation |
yes |
Prevents transform and shading ambiguity |
| Representative scenes and device matrix |
performance owner |
yes |
Grounds budgets and API support |
| Engine, render-pipeline and package versions |
engine owner |
yes |
Controls valid features and diagnostics |
Workflow
- Write the visual promise and the gameplay information the frame must communicate.
- Map the frame from simulation snapshot through culling, geometry, lighting, transparency, post-processing, UI and presentation; name every intermediate resource and owner.
- Choose engine pipeline and graphics API from target-device evidence, tooling, feature needs and failure recovery, not novelty.
- Establish material, shader keyword/variant, light, shadow, transparency, render-texture and post-effect contracts.
- Build a representative scene and a worst-case stress scene before content scale-up.
- Capture CPU render submission, GPU timings, render passes, bandwidth proxies, overdraw, residency and shader compilation evidence on physical devices.
- Remove unused passes/resources, reduce the limiting cost, and re-run the same capture. Preserve before/after evidence and visual-regression images.
- Define quality tiers and safe fallbacks that protect silhouette, UI, navigation cues and cultural/art-direction essentials.
Quality Standards
- Treat visibility, lighting, material response, transparency and post-processing as an ordered system; a beautiful isolated shader does not prove a frame.
- Keep shader inputs, coordinate spaces, colour spaces, texture formats and precision explicit.
- Use validation layers and GPU debuggers where the active API/toolchain supports them; warnings require disposition, not suppression by habit.
- Measure stable frame pacing and sustained thermal behaviour, not only a short peak frame rate.
- Verify current Unity, Android, Vulkan, OpenGL or platform guidance in primary documentation before encoding API/version claims.
Decision Rules
| Evidence |
Choice |
Failure avoided |
| Engine pipeline meets visual and device gates |
Stay within engine abstractions |
Native-plugin complexity without product value |
| GPU fragment/bandwidth bound |
Reduce overdraw, sampled data, attachments, resolution or expensive lighting/post |
Triangle-only optimisation misses the bottleneck |
| CPU submission bound |
Reduce state changes, renderers, variants and draw submission cost |
Lowering texture quality does not help |
| Shader variant growth is unbounded |
Constrain keywords and build a used-variant policy |
Build size, warm-up and runtime hitch risk |
| Essential cue disappears on low tier |
Redesign the tier; do not disable the cue |
Performance option makes gameplay inaccessible |
Capability Contract
Read/search access to project settings, shaders, materials and captures is required. Execute profiling and image comparisons when available. Network access may verify current official documentation. Without physical-device/GPU evidence, issue a provisional design and block production-budget claims.
Degraded Mode
If the renderer, API, device or representative scene is unknown, produce the frame contract and experiment plan only. Do not prescribe fixed polygon, draw-call, texture or shader budgets from books.
Anti-Patterns
- Choosing Vulkan because it is lower level. Fix: prove a feature, stability or measured performance need.
- Adding post effects before base lighting/readability works. Fix: validate the unprocessed frame first.
- One material instance per object by default. Fix: define sharing, instancing and property-override policy.
- Transparent layers covering the screen. Fix: inspect overdraw and redesign effect coverage.
- Unlimited shader keywords. Fix: own a variant matrix and strip only with evidence.
- Hiding synchronisation or resource-lifetime defects behind extra waits. Fix: model hazards and ownership explicitly.
- Optimising away navigation, subtitle or interaction cues. Fix: make readability a non-degradable tier constraint.
Outputs
| Artefact |
Consumed by |
Acceptance condition |
| Rendering architecture and frame-pass map |
engine/graphics team |
Passes, resources, dependencies, spaces and fallbacks are explicit |
| Shader/material/lighting contract |
art and engineering |
Inputs, variants, precision, colour and acceptance specimens are defined |
| Graphics profile and tier plan |
mobile-game-performance and QA |
Same-scenario device captures support every budget decision |
| Visual regression pack |
game-testing-polish |
Intended differences and protected cues are reviewable |
References
- Rendering pipeline and shader contracts
- Mobile graphics budgets and diagnostics
Read Next
Use the selected engine skill for implementation, mobile-game-performance for the full device budget, and game-testing-polish for visual and compatibility gates.
1---2name: real-time-game-graphics3description: Use when designing or diagnosing a game's render pipeline, shaders, materials, lighting, shadows, visibility, post-processing, GPU resources, frame graph, graphics API, or visual-performance trade-offs; use game-3d-asset-pipeline for content and mobile-game-performance for measured budgets.4metadata: {portable: true, compatible_with: [claude-code, codex]}5---67# Real-Time Game Graphics89Engineer a coherent image from camera to presentation while keeping visual intent, GPU work, memory traffic, synchronisation and target-device evidence visible.1011## Prerequisites1213Load the approved visual direction, `game-math-and-simulation`, `game-3d-asset-pipeline`, `mobile-game-performance`, and the selected engine's current rendering documentation.1415<!-- dual-compat-start -->16## Use When1718- Selecting or configuring a render pipeline, graphics API, colour/HDR policy, lighting model, shadow strategy or post stack.19- Writing or reviewing shaders, materials, render features, compute work, command/resource lifetimes or frame-graph passes.20- Diagnosing overdraw, draw submission, bandwidth, shader variants, GPU stalls, visual instability or renderer-specific device defects.2122## Do Not Use When2324- The request is only to model, texture, rig or import assets; use `game-3d-asset-pipeline`.25- The request is a general performance investigation without a GPU/rendering diagnosis; start with `mobile-game-performance`.26- Native Vulkan/OpenGL work is proposed inside a Unity/Godot title without a measured engine limitation and ADR.2728## Inputs2930| Artefact | Produced by | Required? | Why |31|---|---|---:|---|32| Visual direction and readability hierarchy | art/game direction | yes | Defines the image the renderer must protect |33| Camera, coordinate and lighting contract | `game-math-and-simulation` | yes | Prevents transform and shading ambiguity |34| Representative scenes and device matrix | performance owner | yes | Grounds budgets and API support |35| Engine, render-pipeline and package versions | engine owner | yes | Controls valid features and diagnostics |3637## Workflow38391. Write the visual promise and the gameplay information the frame must communicate.402. Map the frame from simulation snapshot through culling, geometry, lighting, transparency, post-processing, UI and presentation; name every intermediate resource and owner.413. Choose engine pipeline and graphics API from target-device evidence, tooling, feature needs and failure recovery, not novelty.424. Establish material, shader keyword/variant, light, shadow, transparency, render-texture and post-effect contracts.435. Build a representative scene and a worst-case stress scene before content scale-up.446. Capture CPU render submission, GPU timings, render passes, bandwidth proxies, overdraw, residency and shader compilation evidence on physical devices.457. Remove unused passes/resources, reduce the limiting cost, and re-run the same capture. Preserve before/after evidence and visual-regression images.468. Define quality tiers and safe fallbacks that protect silhouette, UI, navigation cues and cultural/art-direction essentials.4748## Quality Standards4950- Treat visibility, lighting, material response, transparency and post-processing as an ordered system; a beautiful isolated shader does not prove a frame.51- Keep shader inputs, coordinate spaces, colour spaces, texture formats and precision explicit.52- Use validation layers and GPU debuggers where the active API/toolchain supports them; warnings require disposition, not suppression by habit.53- Measure stable frame pacing and sustained thermal behaviour, not only a short peak frame rate.54- Verify current Unity, Android, Vulkan, OpenGL or platform guidance in primary documentation before encoding API/version claims.5556## Decision Rules5758| Evidence | Choice | Failure avoided |59|---|---|---|60| Engine pipeline meets visual and device gates | Stay within engine abstractions | Native-plugin complexity without product value |61| GPU fragment/bandwidth bound | Reduce overdraw, sampled data, attachments, resolution or expensive lighting/post | Triangle-only optimisation misses the bottleneck |62| CPU submission bound | Reduce state changes, renderers, variants and draw submission cost | Lowering texture quality does not help |63| Shader variant growth is unbounded | Constrain keywords and build a used-variant policy | Build size, warm-up and runtime hitch risk |64| Essential cue disappears on low tier | Redesign the tier; do not disable the cue | Performance option makes gameplay inaccessible |6566## Capability Contract6768Read/search access to project settings, shaders, materials and captures is required. Execute profiling and image comparisons when available. Network access may verify current official documentation. Without physical-device/GPU evidence, issue a provisional design and block production-budget claims.6970## Degraded Mode7172If the renderer, API, device or representative scene is unknown, produce the frame contract and experiment plan only. Do not prescribe fixed polygon, draw-call, texture or shader budgets from books.7374## Anti-Patterns7576- Choosing Vulkan because it is lower level. Fix: prove a feature, stability or measured performance need.77- Adding post effects before base lighting/readability works. Fix: validate the unprocessed frame first.78- One material instance per object by default. Fix: define sharing, instancing and property-override policy.79- Transparent layers covering the screen. Fix: inspect overdraw and redesign effect coverage.80- Unlimited shader keywords. Fix: own a variant matrix and strip only with evidence.81- Hiding synchronisation or resource-lifetime defects behind extra waits. Fix: model hazards and ownership explicitly.82- Optimising away navigation, subtitle or interaction cues. Fix: make readability a non-degradable tier constraint.8384## Outputs8586| Artefact | Consumed by | Acceptance condition |87|---|---|---|88| Rendering architecture and frame-pass map | engine/graphics team | Passes, resources, dependencies, spaces and fallbacks are explicit |89| Shader/material/lighting contract | art and engineering | Inputs, variants, precision, colour and acceptance specimens are defined |90| Graphics profile and tier plan | `mobile-game-performance` and QA | Same-scenario device captures support every budget decision |91| Visual regression pack | `game-testing-polish` | Intended differences and protected cues are reviewable |9293## References9495- [Rendering pipeline and shader contracts](references/rendering-pipeline-shader-contracts.md)96- [Mobile graphics budgets and diagnostics](references/mobile-graphics-diagnostics.md)97<!-- dual-compat-end -->9899## Read Next100101Use the selected engine skill for implementation, `mobile-game-performance` for the full device budget, and `game-testing-polish` for visual and compatibility gates.
peterbamuhigire