Developing VR Multiplayer Modules for Shared Experiences

Imagine two players in Quest 3 headsets grabbing the same virtual cube simultaneously. Without proper networking synchronization, one sees a snap, the other a position mismatch, and joint interaction becomes chaos. We've been solving this for over 5 years, with dozens of commercial VR multiplayer projects under our belt. Reach out to discuss your scenario in detail.

We engineer custom multiplayer modules for shared VR experiences. Synchronizing two hands, head, grabs, and physics objects with a latency of 50–80 ms is our specialty. On Quest's mobile hardware with limited bandwidth, we maintain stable 72 FPS even with 4–8 players. A typical budget for such a module ranges from $10,000 to $25,000, including load testing.

Off-the-shelf networking solutions—Photon Fusion, Photon PUN2, Mirror, Netcode for GameObjects (NGO)—each have their trade-offs for VR. We select the stack for your project: Mirror for small indie titles, Photon Fusion in Server Mode for larger ones. We assess your project free of charge and propose the optimal architecture.

Why Server Mode is Better than Shared Mode for VR

Photon Fusion offers two modes: Shared (peer-to-peer with one host) and Server (dedicated Photon server). For VR, Server Mode is preferable even for smaller projects.

In Shared Mode, one player acts as host, routing all traffic. In VR this means: if the host moves their hands (which happens 72–90 times per second), their own data is processed locally, while other players receive it with the host's RTT. With an unstable host connection, the entire session suffers. Server Mode eliminates this single point of failure—Photon Cloud handles relay and authoritative state management.

A concrete setup: NetworkRunner with GameMode.Server, FixedUpdateNetwork instead of Update for deterministic physics. For hand transforms, we use NetworkTransform with InterpolationDataSource.Predicted—client-side prediction reduces perceived latency.

According to Photon documentation, Server Mode provides the lowest latency for real-time shared experiences.

How to Synchronize Avatars with Minimal Bandwidth

The core technical challenge of VR avatars in multiplayer is that remote players have a full-body avatar with animation, while the local player sees only hands in first person. We need to sync head and two hand positions, then reconstruct the body pose for others.

Our solution is Full Body IK with a limited number of control points. In Unity, we use the Animation Rigging package with TwoBoneIKConstraint for arms and MultiParentConstraint for the torso. The head (HMD position) drives the torso via a heuristic downward offset (~0.3 m), then arms via IK to controller positions. This is not physically precise but looks convincing under normal motion.

Network traffic: three transforms (head + two hands) × 7 floats (pos + rot) × 90 fps = ~7.5 KB/s per player uncompressed. With NetworkTransform and quantization in Photon Fusion, it drops to 1.5–2 KB/s. With 4–8 players, bandwidth remains manageable.

How to Implement Pickup Interaction in Multiplayer: Step-by-Step

1. Create a NetworkObject with Rigidbody and NetworkTransform.
2. On the client, subscribe to the pickup event (e.g., OnTriggerEnter).
3. Request StateAuthority via RequestStateAuthority for that object.
4. Simulate movement on the authoritative side; other players interpolate the position.
5. On release, return StateAuthority to the server.

Synchronizing Physics Objects

Grabbable items, throwable objects, doors—all are physics rigidbodies. The fundamental problem: two clients simulate physics independently, and results diverge. One player throws a cube at a wall—it bounces right on their side, left on another's.

Approach 1: Authoritative physics on the server. All Rigidbody are simulated only on the StateAuthority (in Photon Fusion terms, the one who grabbed the object). Other players interpolate the position. When grabbed, the object 'transfers' to the new holder via RequestStateAuthority. Downside: a slight teleportation is visible on transfer if positions have drifted.

Approach 2: Client-side physics with reconciliation. Each client simulates physics locally; the server periodically broadcasts authoritative state. If discrepancy exceeds a threshold, a soft Lerp moves the object toward the authoritative position. This looks better but is harder to implement without artifacts.

In practice, VR games with physical interactions use approach 1, augmented with a 'ghost' object—a thin semi-transparent copy showing the authoritative position while the main mesh interpolates. Our optimizations reduce cloud server costs by 30–40%.

What's Included in the Work

• Network logic architecture and stack selection
• Basic transform and avatar synchronization with IK
• Physics object synchronization (grabbable, throwable)
• Traffic optimization (quantization, avatar LOD)
• Load testing (up to 8 players)
• Documentation and team training

Development Process

A multiplayer module is a separate task best designed into the architecture from the start, rather than retrofitted into a finished single-player game. Retrofitting multiplayer into an existing single-player VR project typically adds 50–70% more effort compared to initial design with multiplayer in mind.

Stages: networking stack and architecture selection → basic transform synchronization → avatars with IK → physics object sync → game logic (scores, states, rounds) → load testing → traffic optimization.

Pricing is determined after requirements analysis: number of players, interaction type, platform (Quest standalone, PCVR, cross-platform). Contact us to discuss details and timelines for your project. Request development of a module—we will assess your project free of charge.

We have been developing VR multiplayer for over 5 years, with more than 10 commercial projects for Quest and PCVR.