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.4---56# Real-Time Game Graphics78Engineer a coherent image from camera to presentation while keeping visual intent, GPU work, memory traffic, synchronisation and target-device evidence visible.910## Prerequisites1112Load the approved visual direction, `game-math-and-simulation`, `game-3d-asset-pipeline`, `mobile-game-performance`, and the selected engine's current rendering documentation.1314<!-- dual-compat-start -->15## Use When1617- Selecting or configuring a render pipeline, graphics API, colour/HDR policy, lighting model, shadow strategy or post stack.18- Writing or reviewing shaders, materials, render features, compute work, command/resource lifetimes or frame-graph passes.19- Diagnosing overdraw, draw submission, bandwidth, shader variants, GPU stalls, visual instability or renderer-specific device defects.2021## Do Not Use When2223- The request is only to model, texture, rig or import assets; use `game-3d-asset-pipeline`.24- The request is a general performance investigation without a GPU/rendering diagnosis; start with `mobile-game-performance`.25- Native Vulkan/OpenGL work is proposed inside a Unity/Godot title without a measured engine limitation and ADR.2627## Inputs2829| Artefact | Produced by | Required? | Why |30|---|---|---:|---|31| Visual direction and readability hierarchy | art/game direction | yes | Defines the image the renderer must protect |32| Camera, coordinate and lighting contract | `game-math-and-simulation` | yes | Prevents transform and shading ambiguity |33| Representative scenes and device matrix | performance owner | yes | Grounds budgets and API support |34| Engine, render-pipeline and package versions | engine owner | yes | Controls valid features and diagnostics |3536## Workflow37381. Write the visual promise and the gameplay information the frame must communicate.392. Map the frame from simulation snapshot through culling, geometry, lighting, transparency, post-processing, UI and presentation; name every intermediate resource and owner.403. Choose engine pipeline and graphics API from target-device evidence, tooling, feature needs and failure recovery, not novelty.414. Establish material, shader keyword/variant, light, shadow, transparency, render-texture and post-effect contracts.425. Build a representative scene and a worst-case stress scene before content scale-up.436. Capture CPU render submission, GPU timings, render passes, bandwidth proxies, overdraw, residency and shader compilation evidence on physical devices.447. Remove unused passes/resources, reduce the limiting cost, and re-run the same capture. Preserve before/after evidence and visual-regression images.458. Define quality tiers and safe fallbacks that protect silhouette, UI, navigation cues and cultural/art-direction essentials.4647## Quality Standards4849- Treat visibility, lighting, material response, transparency and post-processing as an ordered system; a beautiful isolated shader does not prove a frame.50- Keep shader inputs, coordinate spaces, colour spaces, texture formats and precision explicit.51- Use validation layers and GPU debuggers where the active API/toolchain supports them; warnings require disposition, not suppression by habit.52- Measure stable frame pacing and sustained thermal behaviour, not only a short peak frame rate.53- Verify current Unity, Android, Vulkan, OpenGL or platform guidance in primary documentation before encoding API/version claims.5455## Decision Rules5657| Evidence | Choice | Failure avoided |58|---|---|---|59| Engine pipeline meets visual and device gates | Stay within engine abstractions | Native-plugin complexity without product value |60| GPU fragment/bandwidth bound | Reduce overdraw, sampled data, attachments, resolution or expensive lighting/post | Triangle-only optimisation misses the bottleneck |61| CPU submission bound | Reduce state changes, renderers, variants and draw submission cost | Lowering texture quality does not help |62| Shader variant growth is unbounded | Constrain keywords and build a used-variant policy | Build size, warm-up and runtime hitch risk |63| Essential cue disappears on low tier | Redesign the tier; do not disable the cue | Performance option makes gameplay inaccessible |6465## Capability Contract6667Read/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.6869## Degraded Mode7071If 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.7273## Anti-Patterns7475- Choosing Vulkan because it is lower level. Fix: prove a feature, stability or measured performance need.76- Adding post effects before base lighting/readability works. Fix: validate the unprocessed frame first.77- One material instance per object by default. Fix: define sharing, instancing and property-override policy.78- Transparent layers covering the screen. Fix: inspect overdraw and redesign effect coverage.79- Unlimited shader keywords. Fix: own a variant matrix and strip only with evidence.80- Hiding synchronisation or resource-lifetime defects behind extra waits. Fix: model hazards and ownership explicitly.81- Optimising away navigation, subtitle or interaction cues. Fix: make readability a non-degradable tier constraint.8283## Outputs8485| Artefact | Consumed by | Acceptance condition |86|---|---|---|87| Rendering architecture and frame-pass map | engine/graphics team | Passes, resources, dependencies, spaces and fallbacks are explicit |88| Shader/material/lighting contract | art and engineering | Inputs, variants, precision, colour and acceptance specimens are defined |89| Graphics profile and tier plan | `mobile-game-performance` and QA | Same-scenario device captures support every budget decision |90| Visual regression pack | `game-testing-polish` | Intended differences and protected cues are reviewable |9192## References9394- [Rendering pipeline and shader contracts](references/rendering-pipeline-shader-contracts.md)95- [Mobile graphics budgets and diagnostics](references/mobile-graphics-diagnostics.md)96<!-- dual-compat-end -->9798## Read Next99100Use the selected engine skill for implementation, `mobile-game-performance` for the full device budget, and `game-testing-polish` for visual and compatibility gates.
peterbamuhigire