PartyVR is a co-located mixed-reality party game platform built with Godot Engine 4.5.
The goal is to turn a shared physical room into a multiplayer arena where many VR players compete in short chaotic minigames while spectators watch the action on a large screen.
Instead of isolated VR experiences, PartyVR is designed as a live social event.
Typical session setup:
- 10–30 VR players in the same room
- multiple short competitive minigames
- a large spectator screen for bystanders
- LAN-based multiplayer with a server-authoritative model
The project started after discovering that a school lab had 30+ Meta Quest headsets unused.
Rather than using them individually, the goal became creating a room-scale multiplayer experience where everyone plays together.
2026-01-27.13-21-41-compressed.mp4
A short gameplay clip showing player movement or a dodgeball round will eventually go here.
PartyVR is designed around several principles.
Players win by moving, reacting, and interacting with others in the room rather than by mastering complex controller inputs.
Rounds are short and chaotic. Losing should still be fun to watch and participate in.
A spectator screen shows the game to bystanders.
The game is intentionally designed so that people outside VR can easily understand what is happening.
Clients send intent only (poses, actions, interactions).
All gameplay validation and state transitions occur on the server.
Most games are expected to last 30–120 seconds so players quickly rotate through different experiences.
PartyVR is a multi-executable system consisting of several independent processes that communicate over LAN.
The architecture prioritizes clear system boundaries and server authority.
+-------------------+
| Server |
| (authoritative) |
+-------------------+
/ | \
/ | \
+-----------+ +-----------+ +-----------+
| VR Client | | VR Client | | VR Client |
| (Quest) | | (Quest) | | (Quest) |
+-----------+ +-----------+ +-----------+
|
v
+-------------+
| Spectator |
| Client |
| (Desktop) |
+-------------+
The server owns:
- world state
- validation
- scoring
- match lifecycle
- collision validation
- object ownership
Clients never decide gameplay outcomes.
VR clients:
- capture headset and controller intent
- render minimal mixed-reality content
- send interaction requests to the server
They never simulate gameplay authority locally.
The spectator executable:
- reconstructs the arena from server snapshots
- renders cameras, overlays, and scoreboards
- provides a readable broadcast view for bystanders
It is completely non-authoritative and disposable.
A desktop Host Supervisor app launches and monitors the server and spectator processes.
It provides minimal controls for managing games and monitoring the session.
core/
Shared headless logic used by all executables.
server/
Headless authoritative host.
vr_client/
Meta Quest OpenXR client.
spectator/
Desktop spectator visualizer.
host_app/
Host Supervisor application that launches and monitors the system.
tools/
CLI utilities for provisioning, testing, and streaming.
Important rule:
core/ must remain headless and engine-agnostic.
It contains shared protocol definitions, gameplay logic, and math utilities but no rendering or XR code.
All gameplay follows a strict server-enforced lifecycle.
Rest
↓
Game Selection
↓
Setup
↓
Countdown
↓
Active
↓
End
↓
Cleanup
↓
Rest
Gameplay effects are only allowed during the Active phase.
The lifecycle ensures:
- predictable state transitions
- clear spectator presentation
- consistent server authority.
PartyVR is currently in gameplay prototype development.
Implemented systems include:
- server-authoritative multiplayer networking
- shared physical-space calibration
- spectator reconstruction
- deterministic snapshot broadcasting
- VR client pose streaming
Prototype games:
- Dodgeball
- Tag
Both are implemented with server-authoritative interaction validation and elimination logic.
The current focus is:
- gameplay clarity
- reliable multiplayer behavior
- spectator readability
- system stability
Running large multiplayer VR sessions in a single physical room introduces several unusual engineering challenges:
All headsets must agree on the same real-world coordinate system.
30 simultaneous VR clients require efficient snapshot distribution.
The spectator client must rebuild the entire world state from server snapshots without affecting gameplay.
Managing dozens of standalone headsets requires automation for:
- APK installation
- wireless ADB connections
- streaming
- monitoring.
Several command-line tools assist with development and event setup.
Examples include:
- headset provisioning and APK installation
- device monitoring
- scrcpy-based video streaming
- test runners for deterministic systems
These tools are intentionally non-authoritative and interact with the server through read-only tooling interfaces.
The project is organized into strict phases to avoid architectural drift.
Examples of completed phases include:
- server authority and deterministic tick loop
- spectator snapshot reconstruction
- VR client networking
- LAN transport layer
The current development phase focuses on gameplay prototypes and shared gameplay systems.
Most VR games isolate players inside their own headset.
PartyVR explores the opposite idea:
What if the entire room became the controller?
Instead of separate experiences, everyone shares the same physical space, competing and reacting to each other in real time.
The goal is something closer to a LAN party in VR.
MIT License