#Unity networkview enable code#

Using this setup, EACH player will have its own chatty NetworkView sending out information to everyone else more or less continuously. If you start digging through LOTS of other Unity Networking tutorials, they'll follow the 'standard route' of adding a NetworkView to your player prefab and then relying on Unity to decide when to send updates, and how much data will be sent. Unity Networking Sample Using One NetworkView So, what does that leave us with? It leaves us with.

#Unity networkview enable code#

Update: I recently found a good way to do Server Discovery for the LAN, please post a comment if you'd like me to post that code as well :) I really wanted to do this as a true peer-to-peer, but Unity's built-in networking is geared strictly for client-server networking.

And finally, RemoveRPCs (RPC = 'Remote Procedure Call') only works when you are using Network.Instantiate, so it goes out the window as well. Network.Instantiate also generates so much network traffic that the game can pause and skip every time a new player joins. I picked these three because NetworkViews (even when set to 'Unreliable') can create a lot of unnecessary network traffic if they are not managed very carefully. The components I decided to avoid were NetworkViews, Network.Instantiate, and RemoveRPCs.

Avoid (as much as possible) the 'exotic' Unity networking components.

I set out to make a simple peer-to-peer FPS sample project with two goals in mind: Networking is definitely one of those parts. Unity is a great tool for Indie developers, but there are parts of it that can really make you spin around in circles. This Unity Package can be downloaded here (updated): fps_sample_2013_02_21.unitypackage