Metaverse Development

Metaverse and virtual-world development means building persistent, multi-user 3D spaces – for events, training, showrooms, collaboration, or games. Software Splash builds these in Unity and Unreal, with the realtime multiplayer and 3D experience that make a shared space feel alive rather than empty.

A Virtual Space Needs a Reason to Exist

The metaverse projects that fail are the ones built because the word was trending. The ones that work solve a real problem: training that is safer or cheaper in a virtual environment, a product experience you cannot get on a flat website, an event that reaches people who could not travel. We start from that reason – and if there is not one, we will say so.

What We Build

  • Persistent multi-user 3D environments with realtime presence and interaction
  • Avatars, voice, and the social mechanics that make a space feel populated
  • VR and AR access alongside desktop and mobile, so people join however they can
  • Integration with your systems – commerce, identity, content, and data

Tell us what the space is for – who gathers there and why. We build virtual worlds around a purpose, not a buzzword.

The Empty Room Problem

A persistent multi-user space is only alive when people are in it. It is easy to underestimate how difficult concurrency is to sustain outside a launch event. Visitors arrive at different hours, find an empty world, and do not return, and the space that felt ambitious in the pitch becomes an expensive screensaver.

Design against that from the beginning. Scheduled events, hosts or guides present at known times, and asynchronous traces that show the place has been used, meaning notes, builds, recorded messages, and visible changes, do more for the feeling of a populated world than avatar fidelity ever will. If the real use case is a single scheduled gathering, you may be building an event, which is a smaller and far more achievable thing.

Custom World or Existing Platform

Existing platforms already solve hosting, avatars, voice, moderation tooling, and discovery, and several arrive with an audience attached. If your requirements fit inside one, publishing there gets you running sooner and leaves the operational burden with someone else.

The trade is control. Their content rules, their monetization, their roadmap, and the risk that a platform update changes something you depended on. Build custom when you need integration with your own systems, control over your data, a private space that cannot sit on a consumer platform, or an interaction model their tooling cannot express. Those are real reasons. Confirm you have one before committing to a build.

Moderation Is a Launch Requirement

Any space with voice and strangers needs a harassment plan before it opens. That means muting and blocking that work immediately, a reporting path, the ability to remove someone from a space, a record for whoever handles complaints, and a published policy people can be held to.

If minors may be present, the requirements rise and there are legal questions for your counsel in every market you operate in. This is design and staffing work as much as engineering, and someone in your organization has to own it as an ongoing responsibility.

Persistence Has an Operating Bill

Servers hold state whether anyone is logged in or not. Persistence implies backups, data migration when the model changes, capacity for peaks that arrive with an announcement, monitoring, and a clear answer to who gets called when the space is down during an event.

Settle who carries that load at contracting: your team, ours under an agreement, or a managed platform. It is a much easier conversation before launch than after it.

Count the Steps Between Interest and Arrival

Every step between hearing about a space and standing in it loses people: creating an account, downloading a client, finding a headset, updating a driver, entering a code. For an internal training audience you can absorb some of that, because attendance is expected and IT can prepare devices.

For a public or customer audience, an entry path that works on a normal laptop in a browser usually matters more than the visual quality of the space itself. That is why we build flat access alongside immersive access wherever the design allows it. AR and VR Development covers the headset side.

How Many People Fit in One Instance

The number of people who can share a single copy of a world is set by per-client work, not by server capacity. Every participant has to receive updates about every other participant they can see or hear, so naive broadcast makes traffic and client CPU rise with the square of the population. Interest management is the standard fix: the server sends each client only what is relevant to its position, through network relevancy and the replication graph in Unreal, or network visibility in Netcode for GameObjects and the equivalent mechanisms in Photon on the Unity side. Tick rate, snapshot interpolation, and client-side prediction then decide how that reduced stream feels once it arrives.

Voice scales differently and is usually the first thing to break. A peer-to-peer WebRTC mesh has every client uploading a separate stream to every other client, which a typical home uplink stops tolerating past a handful of participants. Beyond that you need a selective forwarding unit, which takes one uplink per speaker and forwards it, and spatial audio then means mixing only the nearest few speakers per listener rather than all of them. That mixing rule is also a design decision, because a room where you hear everyone is a different social space from one where you hear the three people standing next to you.

So worlds cap an instance and run copies of it. The limit depends on the build, but the pattern is the same: a population ceiling per copy, new copies started as it is reached, and a rule for which copy a person lands in. That last rule is the part that gets forgotten. If two colleagues click the same link and arrive in different copies, they will conclude the product is broken, so parties, follow-a-friend, or reserved instances for named groups have to exist before the first event rather than after it.

How Flat Access Is Actually Delivered

Flat access is not one build. The first option ships the client to the browser: a Unity WebGL build, or a web-native runtime such as three.js, Babylon.js, or PlayCanvas, running on WebGL2 or WebGPU. Everything the first frame needs has to arrive before anything appears, so the entry cost is download size plus shader compilation, and memory is bounded by what the browser allows a WebAssembly heap. Mobile browsers are the tightest target, and a build that is comfortable on a laptop can fail outright on a three-year-old phone.

The second option runs the engine on a GPU host in a data center and streams rendered frames as video over WebRTC. Unreal ships Pixel Streaming for exactly this. Visual quality is whatever the desktop build produces and the client only has to decode video, but you are paying for a GPU session per concurrent viewer plus several Mbps each, and responsiveness is bounded by the round trip to the nearest hosting region.

The two fail in ways that are easy to tell apart. A long wait before anything appears, followed by smooth movement, is a downloaded build with a payload problem. Fast arrival followed by input that lags behind the mouse, or video that softens whenever the camera moves, is a streamed build hitting round trip time or bandwidth. Headset entry from a browser is a third case again, since it goes through WebXR and requires a secure context.

The Weakest Device Sets the Art Budget

If a standalone headset is on the support list, it sets the ceiling for the whole world. A standalone device renders the scene twice, once per eye, and has to hold 72 or 90 frames per second on a mobile-class chip to avoid making people ill. The limits that bite there are draw calls, overdraw, and texture memory rather than triangle counts on their own, which is why a scene that runs at 200 frames per second on a desktop GPU can be unusable on the headset without looking any better.

This is why source assets matter more than they appear to. A product model exported from CAD carries solid geometry, millions of triangles, and no usable UV layout, so it has to be retopologized, unwrapped, and given an LOD chain before it can appear in a realtime scene. Repeated props get instanced, separate materials get atlased so they draw together, and lighting gets baked wherever it does not need to change. That work is usually the largest single block of a world build, and none of it is visible in the finished space.

For delivery, glTF 2.0 and its binary form GLB are the common interchange for realtime and web content, with Draco or meshopt compressing geometry and KTX2 with Basis Universal compressing textures. KTX2 matters more than download size suggests, because those textures stay compressed in GPU memory instead of expanding on load, which is precisely the constraint on a standalone headset. USD is the more likely interchange when the source pipeline is film or heavy CAD.

Identity, Integration, and What the World Records

How people are identified at the door changes nearly everything downstream. Guest entry with a typed nickname is the shortest path in and the one that costs you accountability, since a removed guest can return under a new name immediately. Account-backed entry through OIDC or SAML against your existing identity provider gives you a stable subject identifier to act on, lets internal audiences reuse credentials they already have, and makes roles possible: presenter, staff, moderator, visitor. Many builds run both, with a guest path for the public and SSO for the people who run the place.

Integration usually means the world is a client of your systems rather than a system of its own. Catalog, entitlement, content, and booking data come from the services that already hold them, over your APIs, and events from the world travel back the same way. The decision worth making early is which side is the system of record for each piece of state, because a world that lets people leave notes, place objects, or build something has just become the only place that state exists.

A multi-user space also produces data as a byproduct of running: who arrived, how long they stayed, where they walked, what they looked at. With guest entry that is session data. With SSO in the entry path it is movement and attention traces attached to named individuals, which in most jurisdictions makes it personal data, and that is worth knowing while the analytics are being specified rather than afterward.

What This Depends On From You

The parts of a world build that stall are rarely the engineering. They are the inputs that have to come from your side, and two of them arrive late almost every time. The first is source art: teams assume a usable 3D model exists because a render of it exists, and the render came out of a scene nobody kept. The second is access to the systems the world integrates with, since credentials for a test environment usually require a security review on your side that runs longer than the modeling does.

Before scope can be fixed, these need answers.

  • The devices your audience already owns, since the weakest one on the support list sets the performance budget for everything else
  • Source 3D assets in an editable form, such as CAD, DCC scene files, or scan data, or agreement that models will be built from reference
  • Brand and environment references, and one person who can approve how the space looks
  • An identity decision: guest entry, SSO against your identity provider, or both, and who administers the accounts
  • The systems the world has to talk to, with API documentation, a test environment, and a technical contact who can answer questions about them
  • Where participants will physically be, and any constraint on where their data may be held, since together those fix the hosting regions and therefore the latency floor

Frequently Asked Questions

How do we know we need a multi-user world rather than a single-user 3D application?

Ask whether the presence of other people changes the experience. If the value is that visitors see each other, talk, work on the same object, or are led by a live host, that is a multi-user world. If each visitor's session would be identical whether or not anyone else was online, what you want is a 3D web application or a configurator, and a single-user realtime 3D application will deliver the same thing. Training is the usual dividing case: individual skills practice is often single-user, while team coordination and communication drills are not.

Is this different from building a multiplayer game?

Technically it overlaps almost entirely: the same engines, the same client-server authority model, the same interest management, the same voice infrastructure. The difference is in what holds attention.

What does a persistent world actually run on?

A running world is several services rather than one server. There is a realtime simulation process per instance and something that allocates and tears those instances down, a database holding the state that survives a restart, a voice forwarding service, a CDN for assets, and an identity provider if entry is account-backed. If frames are streamed rather than downloaded, add GPU-backed hosts in every region you serve. If the world ships to standalone headsets, add a store listing or a device management channel to get builds onto the hardware.

How does a build like this proceed, and how does it get released?

Networking first, art last. A greybox world with real entry, movement, avatars, voice, and instance allocation proves the hard parts while they are still cheap to change, and it can be driven by synthetic clients to find the population ceiling before a real audience does. Final assets, lighting, and interaction polish follow, tested against the weakest device on the support list rather than the workstation they were made on. Release then differs by target: a browser build is a deploy you control, while a standalone headset build goes through store review or an enterprise device management channel, each with its own lead time and its own rules about what may ship.

Can we start on an existing platform and move to a custom build later?

Partly. Source art moves, since models, textures, and audio are yours and export through glTF or FBX. What does not move is the platform-specific layer: scripting written against their SDK, their avatar system, their moderation tooling, and their monetization hooks all have to be rebuilt. Accounts, purchases, social connections, and anything visitors made inside the platform generally stay there, so treat a platform launch as a test of whether people show up, not as phase one of the custom build.

Unity or Unreal for this kind of build?

The target device usually decides it. Unreal is the stronger default when fidelity and large environments matter and when frames will be streamed from a data center, since Pixel Streaming ships with the engine and the replication and dedicated server workflow is mature. Unity is the more common choice when one world has to reach standalone headsets, mobile, and a browser build, because its device and XR platform coverage is broader. Existing assets and any code your team already maintains are the other half of the decision, and often the deciding half.

What happens to voice and chat data?

By default, voice is forwarded between participants and never written to disk, so no audio artifact exists once a session ends. Recording changes both the engineering and the obligations: participants have to be told, consent requirements vary by jurisdiction and some require every party to agree, and the audio becomes something you now hold and have to protect. Text chat sits in the middle, since it is cheap to store, easy to search, and far less sensitive than a recording of someone's voice, which is why many spaces keep chat and event logs while leaving voice unrecorded.