rshdhere/metaverse: When a 2D Game Loop Becomes a Virtual Office

A self-hosted collaboration stack that uses proximity, WebRTC, and a browser game engine to make remote work feel spatial, persistent, and strangely tangible.

8 to 10 min read • View on GitHub • More from rshdhere

A top-down office floor drawn like a game map, with two small avatars walking toward each other across tiled space. Their movement activates a ring of connection lines and audio cues, turning the room from dispersed to clustered. The image explains how spatial proximity becomes a product control surface. — In this project, walking close to another person is not cosmetic. It changes the communication state.

Key Takeaways

This repo treats proximity as infrastructure, so location in the world directly controls when people hear, see, and join each other.
The browser is split into a game engine, a typed API, and a world service, which makes the virtual office feel like production software instead of a demo.
Its stack choices point to operational intent: self-hosting, identity control, and deployment discipline matter as much as the avatar layer.
Compared with other open virtual spaces, the project is less about spectacle and more about a 2D collaboration system that is easy to own and run.

The moment proximity becomes product

The most interesting thing in rshdhere/metaverse is not that it looks like a metaverse. It is that movement itself becomes a control surface. Walk close to someone and the system can fade music, open voice, and start media consumption without making you switch modes.

That is a sharper idea than a generic virtual office. In most collaboration tools, calling, joining, and sharing are separate actions. Here, the room decides for you. Distance is not decoration. It is product logic.

A browser room, a network layer, and a media stack. The diagram makes the proximity-to-media pipeline legible.

Why this is really a collaboration system, not a game

The repo is built like work software that happens to use game mechanics, not a game that borrowed a chat feature. That distinction matters. The interface is spatial, but the job is coordination: find people, join them, listen in, speak up, and keep the room intelligible.

That is also why the project feels more serious than a toy. The code is not just about rendering avatars. It is about persistence, media state, auth, deployment, and the rules that keep a shared room useful when real people enter it.

How the browser and the world engine split the job

The monorepo is organized around a clean division of labor. `apps/client` owns the browser experience, including the Next.js app, Phaser scene, and UI. `apps/world` appears to handle the higher-throughput spatial and connection side, while shared packages keep the client and backend in sync through tRPC, schemas, and config.

apps/client     -> Next.js, Phaser, UI, local interaction
apps/world      -> world service, spatial logic, connection orchestration
packages/api    -> tRPC routers and shared schemas
packages/store  -> Prisma + Neon data access
packages/config -> shared environment and constants

That split is practical. The browser gets the lowest-latency interface it can use, while the world service can focus on concurrency and real-time state. The result is not a pile of front-end state hacks. It is a system that looks designed to keep the client thin and the world authoritative.

The clever part is not presence tracking. It is rule-based media orchestration.

The communication trick

The real design move is that calls are not a separate destination. They are a consequence of location. `ArenaPage` and the network layer translate player coordinates into media behavior, so the product can decide when a person is nearby enough for audio, video, or other shared states to activate.

That changes the emotional feel of the space. Remote work often asks people to choose between silence and interruption. This design tries to create a middle ground where conversation emerges from shared context. The room becomes the interface for deciding whether a meeting is happening.

It also keeps the UX honest. Proximity has a threshold. Thresholds are legible. Users can understand why something happened because they can see where they are in relation to others.

The stack says a lot about the team

Bun, Go, Next.js, Phaser, Mediasoup, Prisma, Neon, Docker, Kubernetes, and ArgoCD do not read like an experiment built to impress hackers. They read like a team trying to own the whole lifecycle, from local dev to cluster deployment. The architecture favors control over convenience.

That shows up in identity too. The auth flow uses manual OAuth handling, JWTs, and token checks instead of outsourcing the hardest edges of user state. In a product built around presence, that choice makes sense. Identity is part of the system, not a plug-in.

signal: browser event -> spatial threshold -> network decision -> Mediasoup transport -> UI state

This is why the repo feels operational:
- the client renders the room
- the world layer decides what proximity means
- the media layer turns state into audio/video
- deployment tooling assumes a real service, not a demo

Project	Spatial model	Client type	Self-hosting	Communication model	Best fit
rshdhere/metaverse	2D browser room	Web app	Yes	Proximity-driven media activation	Self-hosted collaboration space
Gather.town	2D office map	Web app	Limited	Always-available social rooms	Fast team gatherings
Mozilla Hubs	3D web space	WebXR/browser	Yes	Spatial voice and avatars	Browser-based social worlds
Ethereal Engine	3D engine	Web app	Yes	General multiplayer and XR	Custom spatial web apps
Vircadia	3D distributed world	Native client	Yes	Decentralized virtual worlds	Performance-heavy virtual world hosting

The important axis is not who has the most features. It is what each project optimizes for. `metaverse` sits in a narrow but interesting niche: browser-first, 2D, self-hostable, and explicit about operational ownership.

Why this feels more serious than most open virtual worlds

Compared with Gather.town, this repo looks less polished but more controllable. Compared with Mozilla Hubs, it gives up XR ambition in favor of a simpler interface model. Compared with Ethereal Engine and Vircadia, it seems less interested in an expansive platform story and more interested in a practical collaboration environment that a team can actually run.

That tradeoff is the point. A lot of open metaverse projects chase breadth: more avatars, more worlds, more device support. This one appears to optimize for intimacy and deployability. It wants remote work to feel local without surrendering the stack to a hosted product.

That is a credible niche. If you want spatial presence as a work primitive, a 2D room plus real media orchestration may be enough. In some cases, that is the advantage.