Same-room Quest apps need several agreements, not one magic multiplayer switch. Here is how to separate spatial alignment, session networking, anchor persistence, and full room sharing before the architecture hardens.
The first decision is alignment or room understanding
Colocation bundles together four different jobs that are easy to mistake for one feature. The anchor identifies a stable physical point. MRUK uses that point to align coordinate systems and compensate for drift. Networking handles discovery, connection, and synchronized app state. Space sharing transfers a more detailed Scene model so another headset can reason about the host’s room.
These layers can work together, but they are not interchangeable. An anchor does not create a multiplayer room. Photon does not tell a headset where the physical table is. World locking does not automatically deliver wall and furniture semantics to a guest. Treating them as separate contracts makes failures easier to explain to the person waiting inside the headset.
Host state
The host creates and shares an anchor, then publishes its UUID and host-side pose through the chosen network path. That pose is the reference other devices must match.
Peer state
The peer receives the UUID and pose, resolves the shared anchor, and passes both to SetCustomWorldLockAnchor. The important state is not merely “connected”; it is “connected and spatially aligned.”
Before: asking one anchor to carry the whole experience
A spatial anchor has a real lifecycle: create, save, load, erase, destroy, and share. Its UUID remains the identifier used to find persisted or shared content. Loading is also a sequence rather than a single instant; Meta describes loading an unbound anchor, localizing it, then binding it to an OVRSpatialAnchor. Those details matter when a returning user expects an object to remain where it was left.
Persistence, however, does not answer who joins the session, who owns state, or how a late peer receives the current game board. Sharing an anchor makes the spatial reference available to another device. The application still owns the social and network workflow around it.
After: assign each layer one job
Meta’s World Lock Colocation path is deliberately lightweight. Available from MRUK v83, SetCustomWorldLockAnchor lets a peer align its coordinate system to a host-created shared anchor and host pose. With world locking enabled, MRUK then compensates for tracking drift. Meta contrasts this with space sharing: one path shares a single anchor and pose for alignment; the other shares detailed Scene data such as room geometry and semantic labels.
The network is the connective tissue, not the spatial truth. Meta’s Photon Fusion sample divides colocation into matchmaking, connection, and alignment. Nearby players are discovered, a networked session is established, and Shared Spatial Anchors align the devices. The sample’s architecture also separates network data and messaging behind interfaces, a useful signal that the network backend is a replaceable implementation choice.
| Decision | Before | After | Official evidence |
|---|---|---|---|
| Coordinate alignment | Assume a networked session makes objects line up. | Use one shared anchor plus the host pose; peers call the MRUK world-lock API. MRUK v83 or later is required. | Meta’s World Lock Colocation documentation, updated March 2, 2026 |
| Session flow | Treat colocation as one connection step. | Model matchmaking, connection, and alignment as three observable phases. | Meta’s Photon Fusion colocation sample, updated May 10, 2026 |
| Sharing route | Assume every group needs the same account and network path. | Evaluate user-based sharing with Photon PUN2 or group-based sessions discovered over Bluetooth. | Meta’s Shared Spatial Anchors sample, updated May 11, 2026 |
| Persistence | Keep content alive because an anchor was created once. | Design explicit create, save, load, localize, bind, erase, destroy, and share states. | Meta’s Spatial Anchors lifecycle guide, updated December 4, 2025 |
Use one anchor when the room is scenery
Choose the lighter path when the experience needs shared placement but not shared room intelligence: a board game centered on a table, a collaborative object at a known spot, or media positioned around one common origin. The host creates the reference; peers resolve it and align. You still need to design recovery for a peer that cannot resolve the anchor or receives the wrong pose.
This is where MRUK world locking earns its place. It is not a replacement for the anchor-sharing setup or the network. It is the alignment layer that keeps virtual content tied to the agreed physical frame. Meta warns that MRUK owns the tracking-space transform when world lock is enabled, so additional offsets should use MRUK.TrackingSpaceOffset rather than modifying the tracking space directly.
Add richer space sharing only when geometry changes behavior
Space sharing is justified when a guest needs the host’s Scene model: walls should block a projectile, furniture should become cover, or content must attach to labeled surfaces. That is a different product promise from “we see the same object in the same place.” It carries more room data and more synchronization complexity because the room itself becomes application state.
The practical filter is human, not architectural. If an inaccurate wall changes safety, instructions, or gameplay, the room model is essential. If the room merely surrounds a shared object, transferring its full geometry may add setup and failure modes without improving the moment people came for.
Build the failure states before the demo path
A clear status model should distinguish discovered, connected, anchor shared, anchor localized, and world aligned. “Multiplayer ready” hides too much. A peer may be in the Photon room but looking at a displaced object; another may have the UUID but fail localization because the relevant part of the environment is poorly mapped.
Design prompts around the next recoverable action: wait for anchor creation, retry localization, guide the user to look around, or leave and rejoin the session. Meta’s samples are implementation references, not proof that a particular room, lighting condition, network, or product flow will work without validation. Teams should test those conditions on their supported headset and software matrix before release.
Sources and method
This analysis uses only the four linked Meta Horizon OS developer documents, checked August 13, 2026. It synthesizes their documented architecture and sample behavior. No independent headset test, interview, benchmark, or hands-on product claim is presented.
