PUN vs. Unity Networking (Legacy)

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.

Content

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.

2. Connectivity

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).

3. Performance

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.

4. Price

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.

Back to Content

Offline Mode

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.otherPlayers Always empty.
  • PhotonNetwork.time: returns Time.time.
  • 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. PhotonNetwork.room will, 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.

Either set PhotonNetwork.offlineMode = false; or simply call Connect() to stop offline mode.

Back to Content

Limitations

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.

Back to Content

Groups and Scoping

The PhotonNetwork plugin supports real network groups but no scoping yet. While Unity's "scope" feature is not implemented, the network groups are currently implemented.

 To Document Top