Start with the supported player task
The same headset experience changes when it moves from a tethered PC to a browser or standalone device: input, launch time, display quality and support all differ. Choose the route by starting with a player task, such as reading rules or joining a host, then test the smallest setup that can complete it.
Choosing hardware also determines support work. Each headset adds combinations of runtime, firmware, controllers, browser, graphics API, network and accessibility settings to test. A vendor logo list proves little. Maintain a capability table with observed behaviour, limitations and the date each combination was checked.
Separate device compatibility from permission to serve a New Zealand market. A successful headset build does not confirm that an online gambling service may be offered or promoted during the licensing transition. DIA's October 2026 guidance describes staged implementation, the advertising prohibition and the planned 2027 licensed regime. Product and marketing need a distinct market-clearance step.
Compare delivery models by operational burden
| Approach | Strength | Cost or limitation |
|---|---|---|
| Standalone headset app | Self-contained spatial input and direct access to supported headset features. | Store review, device-specific testing, larger software update cycle and local performance limits. |
| PC-tethered app | Access to desktop-class rendering and a wider peripheral set. | Requires a capable computer, stable runtime configuration and more customer setup. |
| WebXR experience | Distribution through a web page with familiar account and content infrastructure. | Immersive API support and browser policy vary; WebXR remains on a standards track. |
| 2D interface in headset | Can reuse an existing account or game surface with limited spatial adaptation. | Headset presence adds little if controls remain small or hard to operate from a virtual screen. |
A browser headset session adds its own permissions and lifecycle to device support. Record which setups can enter immersive mode, which inputs they expose and how users return to the standard account interface. Test browser and native builds as separate releases even if both share 3D assets.
OpenXR reduces one kind of fragmentation
OpenXR connects an XR application with a runtime, letting engines access supported headset functions without a fully separate path for each device family. Khronos provides the specifications, reference material and conformance resources. Passing conformance can reduce API mismatch, but does not standardise controller comfort, display clarity, passthrough quality, speed or store distribution.
Set a baseline of required features, such as six-degree-of-freedom tracking, controller input, hand tracking or passthrough. Keep optional capabilities as enhancements, with a safe fallback when absent. If one headset has eye tracking and another does not, the main menu must still work without gaze. Test a route that remains available if an extension changes.
Track engine documentation by version. Unreal's current XR guidance covers OpenXR headsets, handheld AR and performance profiling; Unity provides interaction components and input abstractions. Log engine, plugin, runtime and firmware versions for every release. Updates can alter build settings or plugin behaviour even when gameplay code is unchanged.
Hardware classes lead to different design constraints
Standalone headsets combine display, processing, battery and tracking in one portable unit, but all functions share a limited thermal and power budget. A PC-connected device can support more complex scenes if the computer and link allow it, at the cost of setup, compatibility and latency. Passthrough cameras and spatial mapping add permission and privacy questions as well as rendering choices.
Resolution alone does not determine readability. Angular size, contrast, optics, lens fit, interpupillary adjustment and panel distance also matter. Measure key values on the actual device, including near the supported field-of-view edge, with glasses and under a reduced-graphics mode the battery-limited headset can sustain.
Input choice changes how mistakes happen. Controllers offer tactile buttons but may be unavailable during charging or handoff. Hand tracking frees the hands yet relies on camera visibility, pose detection and reach. Gaze can speed pointing but risks accidental dwell. Voice helps navigation and social features, but varies by room and should never control a financial action. Provide one reliable, deliberate route for each critical task.
Plan the runtime support matrix
Replace a broad claim such as “all VR headsets” with a minimum supported configuration. Name the headset, OS or runtime, engine build, controller, browser, API, display modes, hand tracking, network and test date. Mark each condition supported, degraded or unsupported; the compatibility statement expires when its last test becomes stale.
- Launch with no headset connected and confirm that the interface still explains the available route.
- Open a session with controllers, then disconnect one after a non-financial action.
- Repeat setup with hand tracking off, controller battery low and the headset in seated mode.
- Check text and number contrast at multiple display settings and user-adjusted panel scales.
- Test the account and game-state recovery path after sleep, runtime restart and network loss.
New Zealand players use varied devices, networks and comfort settings. Break support data out by headset family and browser instead of comparing flagship frame-rate averages. If a device cannot keep the money panel or safer-play control stable, disable immersive mode there and retain the regular web route.
Separate local graphics from the authoritative service
A headset may draw a table and animate a result locally, but the trusted service owns wagers, balances, eligibility, self-exclusion and settlement. Send a deliberate, identifiable request, show it as pending and wait for the authoritative response before enabling another round. A client crash or GPU reset must neither duplicate a bet nor erase its event record.
New Zealand's minimum standards cover game information, visible time, account identity, customer location and continuity across the operator's platform. A headset does not remove those requirements. Verify that its browser or app supports the required identity and location checks without confusing the user or weakening account controls.
Keep account and safety screens simple enough to remain usable at low rendering quality. They still need balance, net position, limits, time and support. If the scene fails, offer a predictable exit and state whether any submitted action is pending, settled or cancelled.
Cost the device lifecycle, not only the first build
Include SDK maintenance, runtime variation, store-policy changes, engine upgrades, security patches, accessibility checks and customer support in the operating budget. Plan device replacement and end-of-support dates. A headset can age out before a regulated platform; core account services must still work when an old app cannot be updated.
Estimate platform operations in a support table, not as one engineering figure. Include builds and certification, hardware lab time, rendering checks, on-call diagnostics, privacy review, runtime regression and user-device troubleshooting. Track failed launches, device-specific defects, unresolved sessions and Inspection of safety controls; headset minutes alone are a poor success measure.
Platform selection scorecard
- Task fit
- Question:Which part of the experience benefits from spatial placement?· Evidence:Observed task completion against a 2D control version.
- Compatibility
- Question:Can target users access the required mode?· Evidence:Tested device matrix with dated support records.
- Safety
- Question:Can account and limit controls work in every runtime?· Evidence:Cross-device test of limits, self-exclusion, time and reconnect behaviour.
- Lifecycle
- Question:Can the experience be patched and supported through its intended life?· Evidence:Release, support and deprecation plan with named owners.
For every supported setup, record launch time, input type, session recovery, account-control access and the team responsible for device support. If any check fails, return the user to the standard interface rather than silently abandoning the task.