I want to allow my users to go to different rooms for different experiences, and load in scenes additively to facilitate the game logic. Of course, I want their current avatars to persist as well. What I would like is information on spawn points, best practices for handling the room switch, and any snags I might run into while using additive scenes.
Great question! There’s a few parts here, let me try to answer them individually:
Persisting avatars between scene loads
This one is fairly straight-forward, and something we’ve done in our own titles. At the core of it, you’ll want to have a Realtime instance that connects to a room for your party that sticks around between scene loads.
If you’re additively loading/unloading scenes on top of a scene that holds the party Realtime instance you’ll be good to go, but in some cases Realtime and the avatars can get unloaded during a scene switch. If that’s happening to you, you’ll want to make sure both Realtime and your avatar root game object are tagged with DontDestroyOnLoad.
Additively loading scenes
This will work out of the box too, but the only piece you’ll need to implement yourself is the logic to ensure all clients load the same scene. I typically recommend creating a custom RealtimeComponent that stores the name of the scene to load.
If you’re additively loading a scene that, for example, is its own minigame, I’d recommend putting a Realtime instance in that scene that connects to its own room for the game. That way, when the scene is additively loaded, it can connect to a fresh room, and once the game is over, you unload the scene, which will disconnect you from that room and automatically clean up any state related to the the game.
Spawn points
The absolute simplest approach is to use the realtime.clientID property to position your avatar. This will allow you to choose a unique spawn point regardless of who else is in the room.
That said, a slightly better, but more involved approach would be to use StringKeyDictionary. When you want to assign yourself to a slot, you insert a model to the dictionary for that slot, when the completion handler fires, if the server confirmed the change, then you’ve successfully taken that slot, if it rejects it (because another client inserted a model under that key first) then you re-evaluate and try to assign yourself to the next available slot)
Let me know if you have any questions 
Max
1 Like
If you’re additively loading a scene that, for example, is its own minigame, I’d recommend putting a Realtime instance in that scene that connects to its own room for the game.
Thanks, this was perhaps the most confusing aspect of it. If I have a Realtime instance in my loaded minigame, will it cause conflicts with the other instance in my main room? Will “join room on start” initiate a new room upon the scene being additively loaded? In that case, what will new users join - the original room or the new one, since there are now two Realtime instances.
That said, a slightly better, but more involved approach would be to use StringKeyDictionary
A sample of this would be very helpful.
Normcore supports joining multiple room simultaneously, and when multiple Realtime instances are present in the scene, you’ll need to specify which one you want to use when calling Realtime.Instantiate() in order to ensure the prefab is created in the correct room.
If you’re additively loading a scene with your minigame, Normcore will correctly connect all RealtimeViews from that scene to the Realtime instance in that scene too.
The system generally just works how you would expect. I highly recommend trying it out. If Normcore is unsure what to do with multiple Realtime instances, it will tell you and fail immediately instead of trying to make any assumptions.
Thanks Max. One last question. You’re right, I and I am planning on sandboxing a few experiences, but in general this approach would work:
Start in a main room with a Realtime instance.
Instantiate avatars into a persistent scene.
When users go into a minigame, load the minigame with its respective Realtime instance.
Users are now in two rooms.
Unload main room.
Users are now in one minigame room.
Are all of my assumptions sound?
Looks good to me!
Max