XR: after the first run
What to check on the device and how to choose the next stage without unnecessary dependencies.
Choose the next stage from a working result. Establish stable startup and understandable input first; passthrough, body tracking and extra packages are not prerequisites for a simple XR game.
Check the first run
| Check | Expected result | If it differs |
|---|---|---|
| Settings and startup | No FailureReason; headset receives an image | XR setup |
| Focus | HasFocus matches interaction availability; focus loss does not break menu pause | Startup controller |
| Hands | Correct tracker/pose and current tracking data | Terms and rig |
| Selection | select works on both intended hands | Action map |
| Restart | Saved map is used; required resources belong to the project | Action map |
Perform these checks on the device. Script compilation and .rdata saving without a headset do not establish completion.
Choose the next task
| Task | Continue with |
|---|---|
| Account for physical movement | Room scale |
| Add game movement | XR locomotion |
| Select external interaction tools | XR Tools |
| Show physical surroundings | AR/passthrough |
| Use hands or body data | Hand tracking, body tracking |
| Build a stable XR menu | Composition layers |
| Check effects and GPU budget | XR effects, VRS |
| Prepare a standalone device | Deploy to Android |
Add extensions when needed
For a feature, check three distinct requirements: resource/module availability in the build, project configuration and target-runtime extension support. A class or documentation page does not mean an extension is active. Test feature rejection and a fallback path as well as successful startup.
Do not assume a separate vendor plugin or universal XR toolkit ships with the engine. Before integrating a third-party package, check its source, license, version, dependencies and actual API. Preserve a simple working project first, then check the package addition separately.
Assess movement and graphics
Move the game origin while preserving camera tracking. Check character collision separately from the user’s physical play area: runtime boundaries are not finished game physics. Evaluate rotation, acceleration, teleportation and effect comfort on the device.
Measure GPU frame time and frame stability at the target resolution. Do not enable every effect or select maximum display frequency without measurement. Do not change physics frequency solely from a refresh-rate API number. VRS may reduce shading detail; first establish useful gains and acceptable images in your scene.
Check the build separately
Editor behavior does not establish exported behavior. Test the action map, resources, startup, focus, stopping and re-entry in the final build. Record device, runtime and renderer when reproducing an issue.
This route reuses earlier action-map resource and startup-failure checks. No new headset, movement, package, export or image-quality acceptance was performed here.