Mobile immersion begins with a phone's ordinary limits
A phone can host the game, camera, account tools and network at once. A call or switch from Wi-Fi to cellular can interrupt all of them. Before adding AR or headset features, design for small screens, battery limits, suspension and changing signal.
Define the task first-view a table, follow a host, see a guide or enter a room. Specify required sensors. A 3D table may need no camera; a room-anchored overlay does. Ask for permission when the feature is opened and keep a regular route if declined.
Browsers vary in camera permission, motion support, graphics and background handling. Preserve core account and game access if immersion cannot start, and test the actual New Zealand device set. Explain fallback and keep pending state intact.
Keep the first screen light and useful
Load rules, balance, history, time and safer-play tools before large scene files. Start with account shell and essential controls; defer high-detail textures, background sound and effects until immersion is selected. If GPU access or scene startup fails, the standard interface should remain usable.
Mobile loading priority
- 1 Content:Account state, game rules, limits and exit controls.Reason:Must be available even when graphics fail.
- 2 Content:Current game state, stake and confirmation.Reason:Required before a financial action.
- 3 Content:Core table geometry and control targets.Reason:Supports the chosen spatial task.
- 4 Content:Decorative textures, particles and ambient sound.Reason:Enhances presentation but can be reduced.
A mobile WebGL scene may need a lower-detail mode; WebGPU availability still varies by browser and runtime. Detect capabilities and use a tested fallback, rather than guessing from a user-agent label or asking people to weaken security.
Design touch controls for one hand and interruptions
Phones are used one-handed, rotated between views, interrupted by calls and moved across networks. Use large targets, stable balance and stake positions, and separate browser navigation from irreversible actions. Back, close and pause must not sit on wager controls.
Do not use phone tilt to submit a bet or pinch to start a round. Label each action, show its amount and ask for explicit confirmation. Keep keyboard and screen-reader support on the non-immersive route.
When the app backgrounds or screen locks, stop nonessential motion. On return, fetch game state from the service. If a transaction was pending, show its response before enabling another. Local animation and balance cannot establish what the server accepted.
Manage battery, heat and mobile data
Camera, graphics, tracking and streaming all use battery. Heat or power-saving mode can reduce speed. Measure frame time and temperature over a realistic session, then lower motion, resolution, shadows and effects as the device nears its limit.
Use compressed assets and adaptive streaming so basic state loads on weak networks before detailed visuals. Match video quality to bandwidth and label feed delays. A smooth local overlay cannot make old video current.
Map data by scene and feature. Check whether audio, camera upload or remote textures serve the task and minimise raw frame transfer. If local analysis can anchor the table without sending room imagery, verify that no image leaves the device.
Safer-play controls must remain easy on a small screen
Keep limits, time-outs, breaks, alerts, self-exclusion and live support reachable outside menus. Use account-level controls that survive rotation, headset pairing and reload. Show time in full screen when the status bar is hidden.
In narrow mobile layouts, keep time and a direct settings route above the game layer. Recheck portrait, landscape, keyboard-open states and screen-reader focus so camera or fullscreen modes do not bury controls.
Use NZD and label stake, payout, balance and net position. Apply one time format across daylight-saving changes. Flat fallback must keep the same account rules and controls.
Consider privacy at the point of permission
For mobile AR, explain how camera, motion and location data place an object and whether images are stored. Ask only for relevant permissions and provide a way to disable camera use and view a normal table.
Biometric processing has a separate scope. New Zealand's code covers automated biometric use to verify, identify or categorise people; entertainment face or hand tracking may fall outside some provisions, while Privacy Act duties can still apply. Identity, demographic or emotion inference needs its own legal and privacy assessment.
Review SDKs that send crash, analytics, voice or camera-derived data. Vendors can collect more than the visible function needs. Compare actual production network calls with the documented data map.
Test in the New Zealand use context
Test phone sizes, OS and browsers, permissions, mobile-data handoff and daylight-saving display. Include low battery, heat and poor signal. New Zealand users may not have home Wi-Fi; validate the task on real network conditions.
- Record load time to the first usable control and first rendered scene.
- Measure battery and thermal change during a full session window.
- Test camera denial, device rotation, app switching and screen lock.
- Verify no duplicate wager occurs after a timeout or reload.
- Check text zoom, screen reader labels, touch target size and reduced motion.
- Compare mobile AR with a conventional flat interface for task success.
Device testing does not establish market approval. Keep New Zealand store copy, account access and product classification in the mobile release checklist, and review them when a wager or promotion is added.
Mobile release scorecard
| Area | Evidence |
|---|---|
| Feature coverage | Browser, device, graphics API and immersive-mode matrix. |
| State integrity | Server-accepted actions, reconnect results and duplicate-request tests. |
| Accessibility | Touch, screen reader, zoom, keyboard and reduced-motion routes. |
| Privacy | Permission map, sensor data flow, retention and vendor inventory. |
| Safety | Limit, time, break, self-exclusion and support access on every layout. |
| Performance | Load time, frame time, temperature, battery and data use on target devices. |
Mobile immersion depends on graphics and camera access as well as screen dimensions. Flat mode must remain complete if frame timing is unstable or the user refuses camera permission.
Use an interruption-aware mobile state model
Define responses for calls, lock screen, background tabs and network changes. Keep state server-side and restore it when focus returns. Never resend an action because local animation was interrupted.
Request camera access when AR begins. If permission is later removed, pause camera content and show a non-camera path while preserving game and account controls. Do not repeat permission prompts after a clear refusal.
Repeat recovery in both orientations. Keep confirmation panels clear of the browser bar and onscreen keyboard.
Recover cleanly after a phone call or app switch
Calls, locked screens, assistive tools and app switches can suspend a mobile session. On return, show the server's last state, stop timed animation and say whether a round is still resolving. Reauthentication may follow a security timeout, but reload must not duplicate an action. Test older supported phones, where memory can close a tab; check audio, controls and account state after recovery. A concise return screen is more useful than rebuilding the full scene.