Quick Look at Unity Multiplayer with PUN2

Now that my version of Xevious is a reasonably good approximation of the original, it is time to start enhancing it. My first port (pun intended, ah that pun wasn’t intended) of call is to add multiplayer support, even if it is just two players at a time.

What is involved in a multiplayer game?

There are certain aspects of a multiplayer game that are specific to it, e.g. Match Making, Lobbies, Connections, etc. Whilst these do have an effect on the game we write they are relatively isolated from it. However, other challenges are far more entwined.

If you take a 1000 foot view of what is involved in a stand-alone single player game it would look something like:

These requirements do not change for a multiplayer game but we now have to consider how each player’s, ‘single game’ affects every other player.

Consider a player shooting a gun in a First Person Shooter game.

What, if any, of the information above should the other players be aware of? Do they see the whole animation sequence at exactly the same time? Do they see the bullet at exactly the same position? The answer may or may not be yes depending on the type and fidelity of the game in question. However, something needs to keep all this information in sync between the players, and this is where a Multiplayer framework comes in.

Photon PUN v2

Whilst PUN gives you code for Lobby, Matchmaking, etc the real benefit for me is providing the game synchronization. To test it out I followed the PUN tutorial.

PUN Tutorial

Photon Views

At the core is the concept of a Photon View. A view is specialized focus over a subject. In the case of the robots there are two main views used; Photon Transform and Photon Animator.

Photon Views

In the example you can see that the transform is declared to synchronize the position & rotation but not the Scale. This means that those values will be sent over the network to the players in the game. Since the Scale is not changed in the game, we can save some network overhead by not sending it. Similarly the Animator View allows is to declare what we want to be synchronized from the animation perspective (view). In this example we are not sending over any layer information or the parameter called “Hi”. The others params are being sent over in ‘Discrete’ mode. I.e. not only can we declare if we want a param synchronized but also the fidelity/frequency of the updates.

The choice is a trade off between network overhead/processing and 1:1 fidelity between the players.

The Observer

Whilst the Transform & Animator views make looking after their respective charges relatively easy, PUN uses an overarching component to observe the other views and carry out the actual synchronization.

Photon View

The nice touch here is the ‘Auto Find All’, it is scanning for Photon Views to observe. If you notice on the picture there is a third component it is watching called ‘Player Manager’. Why is that there?

Extending Components with IPunObservable

PUN does not confine you to using View components. You can extend your own components to synchronize custom data. In the example of the robot these include the ability fire their laser eyes and to keep track of their health.

Implementing MonoBehaviourPunCallbacks and IPunObservable
Custom data

When a Robot prefab is instantiated it is either going to be your player or an opponent. Regardless of the player the state information, such as health, needs to be maintained. OnPhotonSerializeView is the opportunity to send or receive that data.

Takeaway

The demo tutorial is good. I did successfully get the demo game up and running. If the only thing I have to complain about is their VERY strange coding style and horrible robot controls then I consider that a win.

PUN does come in two flavours, a free and Pro version. There are various network/hosting costs involved so they need to be examined and compared with alternatives. But I am quite happy to give it a try with Xevious.

Unity, VR, Enterprise and .Net Developer