Initial results were promising. It takes just a couple of lines of script to make get the players to spawn on the network and only pay attention to their own input. The new type NetworkBehaviour is pretty much a MonoBehaviour that plays nice with the network. Its got some cool little helper members that make networking easy.
So I moved onto the water. My assumption was this would be just as simple. Convert a few scripts to NetworkBehaviours. Add a couple of components and then be done with it.
Unfortunately its not quite that easy. The water design in Pond Wars uses some reasonably involved physics. Its basically a series of rigidbodys bound together with spring joints. There is a bug (duly reported) in the networking system that means joints on objects already in the scene are ignored for network objects.
The solution was to switch the water over to procedural generation. Fortunately I had an editor script to do that. Connecting up 200 joints by hand wasn't my idea of a fun time. So I converted that script over to a NetworkBehaviour and problem solved, right?
Not exactly. Unity networking still had a few more curve balls to throw at me. Joint configurations aren't passed over the network. Thus each client was trying to run its own simulation, and getting conflicting results. NetworkBehaviour came to the rescue again, if its not the server, delete the joints.
The network also didn't play nice with the parenting set up. This was kind of critical to rebuilding the mesh. No good having a bunch of colliders running around if the player can't see what is happening. I settled this by having each collider register itself with the water when it turns up in the scene.
But its finally all come together. Its still pretty hacky, but I'm now convinced getting multiplayer running is plausible.
Check out this screen shot.
No comments:
Post a Comment