Metaverse Development: Cross-Platform VR & PC Case Study

Hong Kong Metaverse is a multiplayer social space where headset users and desktop users occupy the same room at the same time; with hands, voices, eight things to actually do, and a working web browser floating in the middle of it.

Project Summary

ClientHongKong Token
TypeMultiplayer social VR and PC environment
EngineUnity3D
PlatformVR headset and desktop PC, one shared space
Timeline10 months, progressive development
NetworkPhoton Fusion
Our RoleFull-cycle development

The Brief

Build a shared virtual environment that people would come back to.

That last part is the whole difficulty, and it’s where most projects in this category fail. A metaverse is easy to build and almost impossible to make worth visiting – the graveyard of empty virtual worlds is enormous, and every one of them was technically fine.

Two decisions shaped everything: it had to work for people without headsets, and there had to be things to do.

The Hard Part: Parity Between Two Different Users

A VR user has two tracked hands, six degrees of freedom, and a body that leans. A PC user has a mouse, a keyboard and a monitor. Putting them in one room and making both feel legitimate is the central engineering problem, and it can’t be solved after the fact.

Every interaction has to be authored twice. When a PC user picks up a basketball with a mouse click, the VR user standing next to them needs to see a plausible pair of hands doing it, not an avatar teleporting the ball into place. When a VR user leans over a billiards table to line up a shot, the PC user has to be able to do the equivalent with a camera and a cursor without it feeling like a lesser version of the same game.

Get this wrong and you end up with two audiences who technically share a space and functionally ignore each other. It’s an architecture decision made in week one, exactly like the cross-platform choices in our other multiplayer work, not something you retrofit.

Presence

The features that make a shared space feel inhabited rather than rendered:

Physical hand interaction in VR, so objects are grabbed and thrown rather than selected. Hands are the fastest route to presence in a headset and the first thing users test.

Voice chat, because a social space without voices is a screensaver.

Character customization, so people arrive as someone rather than as a default.

Presence isn’t a graphics problem. A convincingly-thrown ball does more for it than another million polygons.

Things to Do

Basketball, tennis, bowling, ice hockey, billiards, card and table games, a cinema, and a Polygon area.

This list is the actual product. Activities are what give people a reason to be there at a specific moment and something to do with the person standing next to them, a shared object beats a shared room every time.

The cinema does particular work: it turns co-presence into an event, which is the thing virtual spaces are genuinely better at than a video call.

AI NPCs, or: the Empty Room Problem

Every social virtual world faces the same cold start. Nobody wants to be somewhere alone, so the first visitors leave, so it stays empty, so the next visitors leave.

AI-driven NPCs mean the first person through the door arrives somewhere that feels populated; someone to interact with, something happening. It’s the same problem we solve with bots in our .io and casual multiplayer titles, where a match that can’t fill is a match nobody plays. Different genre, identical failure mode, and one that gets solved before launch or not at all.

A Working Browser, Inside the World

Users can open a browser in-world and watch YouTube inside the space.

This sounds like a small feature and is one of the more awkward things on the list to build: rendering live web content into a 3D environment, keeping it interactive, keeping it performant, and doing it without the headset frame rate dropping which in VR isn’t a quality issue but a comfort one.

It’s also the feature that turns the space from a place you visit into a place you can stay in, because it lets people bring the rest of the internet with them.

What We’d Bring to Your Project

  • Decide cross-platform on day one. A headset-first build with PC bolted on afterwards is a rebuild, not a port.
  • Design for the empty room. NPCs, activities and scheduled moments are launch requirements, not polish.
  • Give people something to do together. A beautiful empty lobby is the most common and most expensive mistake in this category.
  • Treat frame rate as a health requirement. Every feature is judged against it, including the ones nobody expects to cost anything.

Work With Us

If you’re building a shared virtual space for events, training, a brand activation, a community, or a product that needs people in the same room without a flight; the difficult parts are cross-platform parity, presence, and giving visitors a reason to return. We’ve built all three.

More on VR and XR development, or how a project runs with us from scoping through handover.

Tell us who the space is for and how they’ll arrive. Scope, team and a fixed quote come back within two business days.

Multiplayer FPS Game Development

Got a Game That Needs to Ship?

Send a design doc, a build, or three sentences and a reference game. We’ll come back with scope, team and a number.

Let’s contact