Multiplayer Is On by Default
There's no multiplayer feature to enable and no networking code to write. Every experience you publish is a shared space: two people who open your URL at the same time see each other, moving and animating in real time, from any combination of desktop, mobile, and VR. This page explains what that gives you for free, what it means for how you build, and where you need to think about it.
💡 Why this is the default
A world with someone else in it is a different thing from a world alone, and retrofitting multiplayer into a finished project is famously miserable. Having it on from the start means the choice is always yours to make: build for company, or build something solitary that simply never has company arrive.
What Syncs Automatically
The pieces that ship with the template already know how to network themselves. You don't mark anything, register anything, or write anything:
Objects you spawn at runtime can be networked too. The Object Spawner has a Networked Spawn option, on by default, that makes spawned items appear for everyone rather than only the player who triggered them.
The U3D Core Prefab
Multiplayer, publishing, and player spawning all live in the U3D CORE - DO NOT DELETE prefab, at Assets/U3D/Prefabs/, and it needs to be in every scene you publish. Add it from the Game Systems tools if a scene doesn't have one. It's safe to click twice, since the tool won't add a second copy.
⚠️ Don't delete the Core Prefab
If it isn't in your scene, players won't spawn, multiplayer won't connect, and publishing won't work correctly. It's the one object in a U3D scene that has to be there. If you ever delete it by accident, adding it back from Game Systems is the whole fix.
How Rooms Work
Visitors who open your experience land in the same room and see each other. It happens on load, with nothing for them to join, no lobby, and no code to enter.
One room per scene. Each scene of your experience is its own room, so two scenes of one product are two rooms. Loading a scene additively keeps everyone in the same room, and a single scene load moves the visitor to the new scene's room.
A room holds up to 64 people. Every visitor connects to every other visitor, so how many people feel smooth together depends on the weakest device in the room. If the room is full, a visitor who can't connect to multiplayer can still explore the experience solo.
💡 Designing for events
If you're running something where everyone needs to be in one room together, size the guest list to the room, and to the devices your guests are likely to bring. For a larger crowd, a design that works well is several linked scenes people move between on purpose.
How Visitors Connect
Visitors in a room connect browser to browser. Firebase sets up those connections, and when a network blocks a direct connection, a relay carries the traffic instead. There's no multiplayer account to create and no credentials to put in your project.
Connecting browser to browser is how this kind of web multiplayer works, and it means each visitor's browser can see the IP addresses of the other visitors in the same room. The Privacy Policy covers this.
What Doesn't Sync
- Video and audio. A video player isn't synchronized between visitors, so two people watching the same screen may be at different points in it. Sound plays for each visitor on their own.
- Blend Shape Control. It plays for the player who sets it off.
- Scores for newcomers. Each visitor's machine counts from events every machine sees, so players who are present stay in step. Someone who arrives later starts at zero.
- Destroying placed objects. Make Destroyable works for objects created during play, not for objects placed in the scene.
Known Limitations
- There's no text or voice chat yet. Pair a room with Discord for now.
- The Enter VR button doesn't come back after leaving VR until the page is reloaded.
- Touch players can't remove an attachment or leave a steerable.
- An object resting on something doesn't fall when what it rests on moves away.
- Past about 1,800 spawned objects, a room can't describe itself to a newcomer.
Building for Shared Spaces
A few habits that make a world better with people in it
None of these are requirements. They're the differences between a space that happens to allow visitors and one that's actually pleasant to be in with strangers.
- Leave room at the entrance. Everyone arrives at the same spawn point. A tight corner or a narrow doorway there turns a small crowd into a pile.
- Assume objects will be moved. If something is grabbable, kickable, or throwable, a visitor will eventually put it somewhere you didn't intend. The Trash Handler tool exists for exactly this: it can respawn objects that leave the area rather than letting your scene slowly empty out.
- Give people something to do together. Two visitors standing in an empty room look at each other and leave. A ball to kick, a puzzle needing two hands, a thing to sit on, or a quest to chase gives them a reason to stay.
- Watch your volume. Ambient audio that's charming for thirty seconds becomes tiring across a long visit. The Settings UI lets players adjust it, which is a good reason to include one.
Testing Multiplayer
Play mode in Unity is not networked, so it shows you one player, which is enough for most work but tells you nothing about how the space feels with company. The most reliable way to test the real thing is to publish and then open your live URL in two browser windows, or on a computer and a phone at once. That's genuinely how it behaves for visitors, including the timing and the network conditions.
Since republishing is unlimited and keeps the same URL, testing this way costs nothing but a few minutes. Publish, open two windows, walk one into the other, and you'll immediately know whether your spawn area is roomy enough and whether your interactive objects behave the way you pictured when two people reach for them at once.