When using Photon with Unity there are some advantages you can utilize if you decide to use the Photon middleware. The following list should give you a quick overview why Photon might be the right tool for your needs.
Differences to Unity Networking
1. Host Model
Unity networking is server-client based (NOT P2P!). Servers are run via a Unity client (so via one of the players).
Photon is server-client based as well, but has a dedicated server; No more dropped connections due to hosts leaving.
Unity networking works with NAT punch-through to try to improve connectivity: since players host the network servers, the connection often fails due to firewalls/routers etc. Connectivity can never be guaranteed, there is a low success rate.
Photon has a dedicated server, there is no need for NAT punch-through or other concepts. Connectivity is a guaranteed 100%. If, in the rare case, a connection fails it must be due to a very strict client-side network (a business VPN for example).
Photon beats Unity networking performance wise. We do not have the figures to prove this yet but the library has been optimized for years now. Furthermore, since the Unity servers are player hosted latency/ping is usually worse; you rely on the connection of the player acting as server. These connections are never any better than the connection of your dedicated Photon server.
Like the Unity Networking solution, the Photon Unity Networking plugin is free as well. You can subscribe to use Photon Cloud hosting service for your game. Alternatively, you can rent your own servers and run Photon on them. The free license enables up to 100 concurrent players. Other licenses cost a one-time fee (as you do the hosting) and raise the maximum limit of concurrent users.
5. Features & Maintenance
Unity does not seem to give much priority to their Networking implementation. There are rarely feature improvements and bugfixes are as seldom. The Photon solution is actively maintained and parts of it are available with source code. Furthermore, Photon already offers more features than Unity, such as the built-in load balancing and offline mode.
6. Master Server
The Master Server for Photon is a bit different from the Master Server for plain Unity Networking: In our case, it's a Photon Server that posts room-names of currently played games in so called "lobbies". Like Unity's Master, it will forward clients to the Game Server(s), where the actual gameplay is done.
Offline mode is a feature to be able to re-use your multiplayer code in singleplayer game modes as well.
Mike Hergaarden: At M2H we had to rebuild our games several times as game portals usually require you to remove multiplayer functionality completely. Furthermore, being able to use the same code for single and multiplayer saves a lot of work on itself.
The most common features that you'll want to be able to use in single player are sending RPCs and using PhotonNetwork.Instantiate. The main goal of offline mode is to disable null references and other errors when using PhotonNetwork functionality while not connected. You would still need to keep track of the fact that you're running a single player game, to set up the game etc. However, while running the game, all code should be reusable.
You need to manually enable offline mode, as PhotonNetwork needs to be able to distinguish erroneous from intended behaviour. Enabling this feature is very easy:
You can now reuse certain multiplayer methods without generating any connections and errors. Furthermore there is no noticeable overhead. Below follows a list of PhotonNetwork functions and variables and their results during offline mode:
PhotonNetwork.player: The player ID is always -1.
PhotonNetwork.playerName: Works as expected.
PhotonNetwork.playerList: Contains only the local player.
PhotonNetwork.isMasterClient: Always true.
PhotonNetwork.AllocateViewID(): Works as expected.
PhotonNetwork.Instantiate: Works as expected.
PhotonNetwork.Destroy: Works as expected.
PhotonNetwork.RemoveRPCs/RemoveRPCsInGroup/SetReceivingEnabled/SetSendingEnabled/SetLevelPrefix: While these make no sense in single player, they will not hurt either.
PhotonView.RPC: works as expected.
Note that using properties or methods other than the ones above can yield unexpected
results and some will simply do nothing. E.g.
obviously, return null. If you intend on starting a game in
single player, but move it to multiplayer at a later stage, you might
want to consider hosting a 1 player game instead; this will preserve
buffered RPCs and instantiation calls, whereas offline mode
instantiations will not automatically carry over after connecting.
PhotonNetwork.offlineMode = false; or simply call
to stop offline mode.
Views and players
For performance reasons, the PhotonNetwork API supports up to 1000 PhotonViews per player and a maximum of 2,147,483 players (note that this is WAY higher than your hardware can support!). You can easily allow for more PhotonViews per player, at the cost of maximum players. This works as follows:
PhotonViews send out a viewID for every network message. This viewID is an integer, composed of the player ID and the player's view ID. The maximum size of an int is 2,147,483,647, divided by our MAX_VIEW_IDS(1000) that allows for over 2 million players, each having 1000 view IDs. As you can see, you can easily increase the player count by reducing the MAX_VIEW_IDS. The other way around, you can give all players more VIEW_IDS at the cost of less maximum players.
It is important to note that most games will never need more than a few view ID's per player (one or two for the character...and that's usually it). If you need much more then you might be doing something wrong! It is extremely inefficient to assign a PhotonView and ID for every bullet that your weapon fires, instead keep track of your fire bullets via the player or weapon's PhotonView.
There is room for improving your bandwidth performance by reducing the int to a short( -32,768, 32,768). By setting MAX_VIEW_IDS to 32 you can then still support 1023 players Search for "//LIMITS NETWORKVIEWS&PLAYERS" for all occurrences of the int viewID. Furthermore, currently the API is not using uint/ushort but only the positive range of the numbers. This is done for simplicity and the usage of viewIDs is not a crucial performance issue in most situations.
Groups and Scoping
The PhotonNetwork plugin does not support real network groups and no scoping yet. While Unity's "scope" feature is not implemented, the network groups are currently implemented purely client side: Any RPC that should be ignored due to grouping, will be discarded after it is received. This way, groups are working but won't save bandwidth.