rfc: networkscenemanager refactoring and additive scene loading #31
Conversation
This is still a work in progress. Trying to distinguish between guided and reference level related content.
Adjusted some of the wording. Still trying to distinguish between guided and reference level...moved everything into guided but I think there should be a better separation still.
style
Migrated some sections to the reference level and added some additional code snippets.
updated the title.
NoelStephensUnity
requested review from
mattwalsh-unity,
LukeStampfli,
0xFA11 and
jeffreyrainy
text/0000-additivescenes-and-networkscenemanager-refactoring.md
Outdated
Show resolved
Hide resolved
|
|
||
|  | ||
|
|
||
| With the existing netcode architecture NetworkObjects are always associated with the currently active scene and are serialized in no specific order nor grouped by any form of scene dependencies. The above diagram outlines one problematic scenario where NetworkPrefabHandler spawn generators are additively loaded in **Scene_A-1** and **Scene_B-2**. On the server or host side, there would be no real issues as the scenes would be loaded in the appropriate order and the NetworkObjects would not need to be synchronized locally. However, on the client side issues arise when NetworkObjects that were dependent upon either **Scene_A-1** or **Scene_B-2** are instantiated before their dependent additive scenes are loaded. |
There was a problem hiding this comment.
However, on the client side issues arise when NetworkObjects that were dependent upon either Scene_A-1 or Scene_B-2 are instantiated before their dependent additive scenes are loaded.
I'm not sure whether this problem needs to be solved by us or not. I'd expect the developer who implements "spawn pools inside additively loaded scenes" to solve this problem for themselves. Though I might be narrowly-minded here.
There was a problem hiding this comment.
Yeah, I looked at various possible approaches for this by playing the role of a user and trying various scenarios where a user has a dependency for a NetworkObject that is instantiated in the current active scene (i.e. single loaded mode) by some user code (component) in a NetworkObject/GameObject within an additive scene. I used NetworkObject pools that use custom Network Prefab handlers since that too was a new feature in this milestone (i.e. make sure the two feature play nice with each other). Without the NetworkSceneManager knowing about any form of scene dependencies the issue only arises when a player is joining a game session in progress.
The initial implementation that did not have any form of scene dependency functionality I tried several approaches from the "user code side" and it resulted in a very complex set of code the user would be required to write to detect any NetworkObjects instantiated, determine if they belong to a NetworkObject pool, inserting the NetworkObject into the pool (and releasing the NetworkObject in the pool's position it took), but in the end it ended up being a high user pain threshold that didn't work "smoothly".
The primary issue boils down to order of operations:
When do you instantiate NetworkObjects and should other additive scenes be loaded first before those NetworkObjects are instantiated?
By adding the ability to set a NetworkObject's scene dependency and making the NetworkSceneManager aware of this potential setting, the user only has to make sure NetworkObjects that have a scene dependency are marked as such (NetworkObject.SetSceneAsDependency) so the assets that a NetworkObject are dependent upon are instantiated before or with the dependent NetworkObjects.
We don't completely automate this process for the user, but we provide the option to at least assure a NetworkObject is not instantiated until a specific scene is loaded.
NetworkSceneManager only groups NetworkObjects to the scenes they are associated with or have a dependency with and will deserialize them in that order. We do not migrate NetworkObjects to scenes or the like, that is left up to the user, but we do provide a way to assure that when a NetworkObject is being deserialized it is done only after the scene it is associated with (GameObject.scene) or it is dependent upon (NetworkObject.DependentSceneName) is loaded first. What happens from there is up to the user.
There was a problem hiding this comment.
This was resolved by updating the way I approached how things are loaded.
Now we load all scenes first (not spawning or soft synchronizing during the loading), and then once all scenes are loaded we handle local spawning and soft synchronization. Made updates to the RFC to reflect these changes.
|  | ||
|
|
||
| In order to set a scene dependency for a NetworkObject that has a dependency in a different scene (in this case the spawn generator), the user is only required to set the scene as a dependency for the dependent NetworkObject as such: |
There was a problem hiding this comment.
here again, I'm not sure why we care about scene dependencies of networkobjects. if a developer wants to implement an object pool, put that into a separate scene, load that scene at runtime and spawn objects by that spawnpool to manage — why "netcode" needs to care about that at all? I'd say, that's something for implementor to figure out, if they have strong dependencies between objects being spawned/pooled and the spawnpool implementation. well, I think we could chat about that :)
There was a problem hiding this comment.
(see the previous response above)
There was a problem hiding this comment.
We no longer care about scene dependencies. We now only care when certain NetworkObjects are soft synchronized or spawned, but that is only the special case of NetworkPrefabHandler related stuff. In terms of scenes and dependencies that has been addressed in the most recent update in PR-955 and is reflected in this RFC.
|
do you think this RFC is up-to-date and good to go by now @NoelStephensUnity ? |
Cleaning this up to be aligned with pre-3 release.
Updating the tracking event notification description to provide context of usage.
This is the RFC for MTT-820
Link to view the RFC
Summary
In order for users to be able to effectively use additive scene loading and benefit from multi-scene editing workflows there are some additional features and refactoring needed with NetworkSceneManager.
Acceptance Criteria
Users should be able to implement various additive scene usage patterns commonly used in Unity today with the only distinguishing differences revolving around the requirements of the NetCode implementation.