I guess another possible way to do it would be to Network.Instantiate another seperate object and just use that to synch all your other network views after connecting. I'm going to branch my code and investigate changing things to work demoras way, it sounds a lot cleaner (and probably the way it's intended that it be done). It works, but as I say, having just been thinking after reading demoras post I don't think it's a good way to go. Frame processing times Memory efficiency Texture memory bandwidth usage. All initial handshaking communication and general network management related communication is done via RPCs over the network managers view (sending player names, synching the network view ids of all other objects, etc). Integrate asset delivery (Unity) Target texture compression formats.Client and server both have a network mamager instantiated before connection, the view ids on both are unassigned (and remain that way through the whole course of my applications execution).So a summary of my (almost certainly bad) way: (Maybe that's the way Unity communicates Network.Instantiates behind the scenes anyway?) Just using Network.Instantiate as demora indicated seems like a much better solution. I don't know if this is intended behaviour that can be relied upon. So if you don't assign a view id to an object on both the client and server they seem to communicate using the "unassigned" id. The Unity reference says unassigned "Represents an invalid network view ID." However, invalid, as in "will not work" (which is what I would have guessed) doesn't seem to be exactly what it means. I just tested it in my code and NetworkViewID.unassigned is = to the default state of the NetworkViewID (which is view id 0) when a NetworkView is created. Reading this thread and having a bit of eureka moment I can see that was incorrect. So I was automatically able to communicate using the first view instantiated on each side. At the time I thought the first NetworkView on each side always got the view id 0. Without any interpolation, the movement will appear very laggy and jerky, as positions are sent a fixed number of times per second (15 by default in Unity Networking) in order to save on bandwidth, so snapping to the position 15 times per second will look jerky. My solution was to not allocate view ids before connecting on either the client or the server for the connection manager objects (this was the only network view I had setup before connecting). (The same senario I have when connecting in my game at the moment.) If you don't Network.Instantiate the manager. Boss Room is a small scale cooperative game sample project built on top of the new Unity Networking Core library designed to help you explore the concepts and patterns behind a multiplayer game flow. Click to expand.If you Network.Instantiate the manager the initial view id allocation will be handled by Unity.
0 kommentar(er)
