Hacking together a Network Model
First serious networking test = grand success.
Second network test = monumental failure leading to scrapping the design planned from the first test.
Unity’s physics and player-controller systems rely on simulations in the engine. That’s fine for networking a game where players load all into the same map together, but having players on different maps (scenes/levels, ahh the cross-breed terminology) screams out for an authoritative server.
The server cannot reasonably have every map open all at once. I’ve noticed some third-party solutions do tricks like virtualizing multiple instances of Unity, but that seems overly complex and I don’t want to rely on an external service.
So I tried a non-authoritative solution that relied on TNet, a master-server asset / addon for Unity which manages multiple game rooms. With TNet a channel = a game. I tried to convert that to channel = level, which could work (TNet loads levels as “games” already), but my fumbling in my second test convinced me that I was pushing a square peg into a round hole to squish into TNet’s model.
I’ll still use TNet as a convenient packet-manager shortcut, .but I’ll stick to one channel and juggle TNet’s RFCs with my own network manager. If I have the resources later (IE: either I improve my coding skills or have access to a network coder), I can always swap out TNet for a native packet manager.
The results will be semi-authoritative, with each player managing a sort of bubble around them to account for physics, collision, etc., but checking in with the overall host for sanity, syncing between players and top-level AI. I have a vague roadmap in my head so far, so I won’t claim it works until I’ve hashed it all out and test, test, test.