Choose the engine around the product surface
An engine choice is tested after the prototype: when art changes a room, the OS updates its XR runtime or compliance needs a new control on every screen. Unity and Unreal can both support immersive products; production cost depends on team skills, assets, plugins and the releases actually maintained.
Compare engines with a vertical slice. Complete one task from launch through table, rules, harmless input, disconnect recovery, account controls and exit. Measure loading, frame time, input effort, memory, build size and QA. Fast rendering of a sample room does not guarantee reliable release builds or accessible menus.
Keep regulated functions outside presentation code where practical. Trusted services should own identity, limits, time-outs, self-exclusion, random outcomes and settlement. The engine can show status but should not become its only record.
Compare the production fit
| Area | Unity evaluation | Unreal evaluation |
|---|---|---|
| XR interaction | Check package version, input system, interaction components and device profiles. | Check OpenXR plugin path, platform plugins, input and headset-specific support. |
| Visual target | Prototype the required lighting, materials and scene complexity on target devices. | Profile the intended quality level on the lowest supported headset or phone. |
| Team workflow | Assess C# skills, package management and existing Unity asset pipeline. | Assess C++ or Blueprint skills, build automation and current project structure. |
| Browser delivery | Verify current export path and performance for the chosen version. | Verify browser delivery and graphics requirements against the target use case. |
| Maintenance | Check upgrade cadence, package compatibility and long-term support needs. | Check engine upgrades, plugin compatibility and project migration effort. |
Unity documents XR Interaction Toolkit as a component-based framework for VR and AR; Unreal's XR material covers OpenXR headsets, handheld AR and profiling. Treat these as starting capabilities, not proof that a particular engine, plugin and device combination will pass release testing.
OpenXR can help, but it is not a universal portability switch
OpenXR lets applications access supported runtime features through an API, and engine plugins can reduce device-specific code. The runtime still controls extensions and input profiles. One headset may offer hand tracking, another controllers only, and a third different passthrough or system menus.
Define required features separately from optional ones. Test runtime Inspection, controller mapping, recentering, pause/resume and hand-tracking permissions. An optional feature should have a fallback; missing vendor extensions cannot block account access or safer-play functions.
Use a platform adapter for inputs, permissions, haptics, account links and display settings. This makes device differences visible to QA and keeps assumptions out of game logic. Version each adapter and record its tested runtime.
Rendering quality has to survive the actual hardware
A casino need not render cinematically. Prioritise readable numbers, reliable controls and a coherent table. Profile on the least powerful supported device and test startup, transitions, heat and long sessions. Headsets may throttle; mobile browsers can reclaim memory or lose graphics context.
Set quality tiers for asset density, shadows, textures, light and effects. Preserve contrast and text size. If the device slows, remove background detail before shrinking balance or safer-play controls. Keep a flat route to rules, limits, account status and support; pausing the engine scene must not lose service state.
Plan build size and patch delivery. A minor fix that forces a full headset download may arrive too late. Use compatible asset bundles and versions so a client update does not break a round begun on an earlier build.
Accessibility and safety need engine-level components
Provide seated and standing options, adjustable reach, text scaling, reduced motion, remappable input and alternatives to voice or gaze. Support controller and pointer navigation, plus system pause and reliable exit. Test with hardware disconnected instead of assuming both controllers are present.
New Zealand's online-casino standards require account and game functions across platforms. Serve limits, breaks, time-outs, alerts, self-exclusion, time and round starts from shared account services. Engine events must not override a limit or start a round without deliberate input.
Check accessibility at both scene and companion-page levels. Accessible components inside a 3D engine do not make the whole product accessible. Provide alternatives for movement, sound, effects and hand tracking.
New Zealand compliance remains outside the engine
An engine does not establish whether a product may operate in New Zealand. DIA's October 2026 information describes a current online-casino transition, advertising restrictions and changes ahead of the licensed regime expected in 2027. Product, marketing and legal owners should verify status and release timing.
Put compliance settings in services and release checks: server-side location, eligibility, game rules, logs and self-exclusion rather than client-only gates. Separate promotion from game rendering so an art change cannot bypass advertising rules. Record source and date for legal decisions.
Review engine packages for analytics, crash data, voice, hand tracking and vendor connections. Record each data flow, disabling control and update owner. A plugin that adds a sensor, identifier or recipient should prompt privacy review.
Use a weighted prototype decision
- Write target devices, browsers, platforms, user tasks and operating horizon.
- Build the same small scene and account panel in each candidate engine.
- Measure performance, interaction errors, build size and implementation time.
- Test accessibility, session recovery and account-control integration.
- Review package support, security updates, licensing terms and upgrade path.
- Select the engine with the stronger evidence for the full service, not the most attractive demo.
Choose evaluation weights before scoring. XR applications may prioritise input and rendering; web-first games may put more weight on bundle size, browser compatibility and DOM integration. Attach measurements and list what the slice did not test.
Prototype acceptance measures
- Time to first usable control
- Why it matters:Shows the cost of engine startup and asset loading.
- Input error and recovery
- Why it matters:Tests controller, hand and pointer reliability.
- Memory and frame-time percentiles
- Why it matters:Indicates stability on target hardware, not only a workstation.
- Account-control completion
- Why it matters:Proves limits, time and self-exclusion can be reached in the client.
- Patch and rollback time
- Why it matters:Measures how quickly the team can recover from a production defect.
Runtime choice matters alongside engine. Browser graphics APIs constrain rendering, while cross-device state handling determines whether rules, balances and round status persist when a player changes screen.
Include production ownership in the engine decision
Assign owners for engine updates, XR plugins, signing, assets, crash handling and certification. Record supported versions and last test dates. A plugin may work in a sample yet conflict with production authentication, store policy or another runtime component.
Estimate content costs as well as code. Detailed rooms need models, textures, lighting, animation, localisation and accessibility variants; simpler scenes can reduce upkeep and load time. Budget time to update rules and safer-play controls in full-screen engine builds.
Use the same network and account contracts in prototypes and production. Label fake local balances and replace them with service data before public testing. A finished-looking scene must not conceal missing authentication or player controls.