All projects

Spatial Venue

The Spatial Venue status page during a test session: a "Stop all" button with tick count and uptime, and a table with one session, Floor A, Ready on hole 1 of 3, and four headsets, each Aligned with 100% battery, tracking ok, and a heartbeat under one second.
The read-only status page served by the venue server. Captured in testing with simulated participants.

A Rust server that runs shared sessions for several headsets in the same room, with a live status page, a command-line control tool, and a DASP control socket for automation.

What it is

Location-based XR puts several people with headsets in one physical room. Spatial Venue is the server that keeps them in one session: it owns the roster, phases, scores, course, props, and settings, validates what each headset reports, and gives floor staff one place to start, pause, and reset a group.

What we built

A deterministic, server-authoritative session model in Rust, streamed to each headset as bit-packed snapshots 30 times a second over UDP, with reconnect tokens so a dropped headset rejoins in place. A client library as a Rust cdylib with a C ABI, shipped as a Unity package for Quest and Windows. An HTTP control plane with venue tokens, health, Prometheus metrics, a read-only status page with a WebSocket feed, and an operator guide. A DASP node with 22 venue capabilities, every frame validated against pinned schemas. Headset discovery by UDP broadcast and mDNS with battery, tracking, and frame-rate telemetry. A command-line tool with a JSON mode for people and for LLM agents. Load tests run 48 simulated players across 8 sessions at 30 Hz on about a tenth of a CPU core, and the decoders are fuzzed.

How it is used

Puttscape’s mixed-reality mini-golf connects to Spatial Venue through the client package. Automation tools drive a session through DASP instead of patching the game client, and the status page opens in any browser on the venue network.

Evidence

What it shows

What changed

Several headsets in one room share one server-authoritative session that staff run from a status page and a command-line control tool.

  • Session model

    Deterministic, server-authoritative state streamed to each headset as bit-packed snapshots 30 times a second over UDP, with reconnect tokens that put a dropped headset back in place.

  • Operator tooling

    A read-only status page with a WebSocket feed, a command-line control tool with a JSON mode, and an operator guide served by the server.

  • DASP node

    22 venue capabilities over a control socket, every frame validated against the DASP schemas.

  • Load and fuzz

    Load tests run 48 simulated players across 8 sessions at 30 Hz on about a tenth of a CPU core, and the decoders are fuzzed for 600 seconds.

  • Device handshake

    A real Quest 3 completed the native client handshake with the server.

Context

The status page was captured in testing with simulated participants. Puttscape is the first game connected to the server.

Next step

Have a similar problem?

Describe it in a few sentences. You get a draft brief to review before anything is sent.

Get in touch

Farwhen

Behind the experience

The systems this project uses, grouped by the part of Farwhen they belong to.

Our technology

What it runs on

  • Spatial Venue

    This is the server itself.

  • DASP

    The server is a DASP node with 22 venue capabilities.

  • Venue devices

    Headset discovery and telemetry on the status page.

Built with

  • Rust
  • renet
  • UDP
  • axum
  • WebSocket
  • DASP
  • Unity
  • Meta Quest 3
  • SQLite
  • Prometheus
  • cargo-fuzz

Credit

Designed and built by Dream Awake Labs. Private repository.

Get in touch

Tell us what you have in mind.

Describe it in a few sentences. You get a draft brief to review before anything is sent.