Live presence is a service architecture problem
A dealer reveals a card while the virtual table still shows the previous hand. The stream, XR scene and game service may each use different clocks, but the player sees one product. Define authoritative action and outcome sources, and show when a result is delayed, interrupted or pending.
Use the game service for wagers, rules, phase and outcome; the stream for dealer and table; and XR for spatial layout and navigation. Expose each layer's status. A frozen stream must not show an active dealer, while loss of a headset anchor must leave the round record available in text.
A live room needs a practical purpose. Spatial seating may clarify shared attention, and a host room may make rules demonstrations easier to follow. A lobby that only places a menu in 3D adds setup and performance cost without improving Inspection.
Synchronise video, game events and spatial cues
Keep separate times for video capture, game event and player display, then measure the offsets. The dealer may have completed a move while video still shows the prior frame. An overlay reacting before the dealer appears can look inconsistent even when both feeds are accurate.
Live casino data source and player-facing use
- Game service
- Authoritative for:Accepted actions, rules, round state, outcome and account record.· Visible status:Pending, active, settled, interrupted or awaiting review.
- Dealer video
- Authoritative for:Visual presentation of the live table and host.· Visible status:Stream live, delayed, degraded or unavailable.
- XR scene
- Authoritative for:Position, controls and optional spatial presentation.· Visible status:Tracking active, anchor lost, recentered or in fallback mode.
- Account service
- Authoritative for:Identity, limits, time-outs, support and self-exclusion state.· Visible status:Current control status and any action blocked by a rule.
Use one time source and monitor drift. Show delayed-feed status instead of an animated live badge. Define behaviour for late frames, missing audio, service outages and reconnects so a player can tell whether a wager was accepted.
Build a room around the dealer's actual role
A virtual dealer may guide turns, explain play or add social context. Keep the host in a stable position without covering values or controls. Caption speech and show round state without sound. Muted players still need to identify the turn and available actions.
Avatars can clarify seats and turn order. Distinguish them from the live dealer and automated systems, and say whether an opponent is human or computer. Do not present a scripted character as a live player or expose another user's balance, ID documents or private profile.
Shared presence needs moderation controls. Put mute, block, report and personal-space tools where users can predictably reach them. Explain audio recording and incident evidence. Let someone leave the social layer while keeping account controls or any permitted game accessible.
Preserve game information in more than one channel
Place stake, balance, result, net position and rules in text beside the relevant action. A chip stack can illustrate value but cannot be its only form. Caption dealer speech, label sound cues and provide gesture controls explicitly. Keep a stable rules-and-odds panel beside the table.
Before launch, show a flat-view option for browser rooms. If focus is lost, controller input stops, or camera or microphone access is withdrawn, give the dealer feed and account a clear status. Test native and browser clients through each session change.
WCAG 2.2 addresses web accessibility across devices, including keyboard use, pausing, flashing and motion actuation. Headset play also needs comfort tests. Support seated interaction, text scaling, controller and pointer input, and do not require rapid head movement.
Connect safer-play controls to the live room
Keep time and the break route visible while the dealer is on screen. Opening a compact status panel must not hide whether a round is pending or settled. Players need to mute and exit without losing its record.
Apply limit-change waits and self-exclusion checks in the account service before another action is allowed. The studio only needs the current status and an explanation, not a second rule engine. Verify recovery after stream interruption and device switch.
Require a deliberate input for every new round. Holding a controller button must not start another game. New Zealand's standards set a minimum interval before the next round is available; keep its control disabled until the service confirms readiness.
Design for reconnect, interruption and fairness
Connection can fail at headset, stream, browser or game service. Define handling at each point. For a pending wager, show status and query the service before allowing another. For a settled round, display its recorded outcome. If play cannot continue, apply the published rule and keep the event recoverable.
New Zealand minimum standards require timely recovery and retention of enough information to restore events where possible. They also specify a customer-protective result for games that cannot continue. Recovery is therefore part of fairness as well as engineering.
- Test a dropped video feed while the game service remains active.
- Test a game-service failure while video and spatial rendering continue.
- Test reconnecting with a different headset or browser.
- Verify that one action identifier cannot create two accepted wagers.
- Check that a time-out and self-exclusion persist across every client.
New Zealand release context
Before opening a room in New Zealand, confirm the operator and product classification, then align the studio runbook with that decision. Separate promotion from game entry and name an owner for review when hosts, avatars or wagering change.
Measure clarity of tasks, recovery, state disagreements, Inspection of time controls and support access. Long sessions or repeat rounds do not prove value. The room should make rules, state, host role and controls easier to understand.
Match spatial input to each headset's tracking, but keep it separate from game authority. A hand or gaze may select a control; the service still has to confirm consequential actions.
Prepare a runbook for the live floor
Write studio procedures for camera alignment, feed restart, dealer handoff, delay, audio loss and service outage. Assign who pauses play, contacts support and explains unresolved events. Moderators and game-integrity staff need authority defined outside headset roles.
Before play, check camera ID, stream time, game version, table rules, captions and account controls. Afterward, review open events and apply the approved retention schedule to incident clips.
For New Zealand users, test mobile networks as well as fixed broadband. If latency exceeds the supported window, mark the feed delayed and prevent stale input from appearing current.
Use the same incident language across teams
A live room brings together dealer, supervisor, streaming engineer, game operations and support. Different terms for one disruption can leave players unsure whether a round continues. Use shared states such as connection interrupted, result pending, settled and support review; give each an owner, time and player-facing explanation. Support may see deeper diagnostics, but should reference the same event ID and outcome.