Conversation
LukeStampfli
left a comment
There was a problem hiding this comment.
Clean and decoupled API, I like it!
|
|
||
| N/A: We need to have this, other systems such as network tick, network variable snapshotting and others will be relying on this pipeline. | ||
|
|
||
| # Rationale and alternatives |
There was a problem hiding this comment.
I'm a bit dubious about instituting a structured loop concept that lives on top of the PlayerLoopSystem. It feels like, if executed poorly, it could limit flexibility in the PlayerLoopsystem. Maybe it's OKAY because enough other parts of the engine break if you customize the system beyond where we're hooking in, but it feels wrong that the entire system might stop working if you change your player loop enough for special case without giving the user any way to remedy it by composing their own network loop.
There was a problem hiding this comment.
Perhaps an alternative approach is to model this as a series of helpers/extensions, along with some default settings, rather than a system-unto-itself.
There was a problem hiding this comment.
we're modifying the existing player loop system, we are not building a new one from scratch. users are still able to modify the player loop system after we inject our methods into the existing one — they might even unplug our systems! I believe our approach is right here but I will reconsider where we inject network methods as you suggested above.
There was a problem hiding this comment.
looking at this one more time again, I think I got what you were saying. however, I still think "we" should decide where we would inject our network loop methods because it will also have implications on the framework itself. I believe I went a little bit too far without considering and fully understanding what are the existing steps (systems running under player loop systems) the player loop currently takes (injecting after MemoryFrameMaintenance doesn't sound right). I will investigate more and elaborate reasons why certain places are selected to inject network loop methods. awesome feedback, thank you very much Jesse :)
There was a problem hiding this comment.
I'm trying to unpack 'you' and 'your' in @JesseOlmer's comment:
it feels wrong that the entire system might stop working if you change your player loop enough for special case without giving the user any way to remedy it by composing their own network loop.
Do you mean the system will stop working if Unity makes changes to PlayerLoop? Or if the SDK team makes changes that break existing users? Or (my guess) that users that are already aware and using Player Loop now have to sidestep this system?
There was a problem hiding this comment.
If I understand the concern here, maybe we offer a way for users to adjust where the Network Update Loop registers its hooks? Perhaps this could be a new MLAPI tool within the editor that allows one to visualize where the network update loop is registered and make any adjustments relative to their own registered player loop systems? This provides the user with the ability to make adjustments if needed, and of course the tool would have to have a way for the user to "reset back to default settings" in the event they fiddle with it too much.
See rendered RFC document →