PUN vs. Bolt

Introduction

PUN and Photon Bolt are two powerful game networking middlewares.
Choosing between the two is no easy task.
The goal of this document is to provide a comprehensible summarised comparison between these two tools to help the developers decide which one best fits their needs.

PUN

PUN (Photon Unity Networking) is a clone of the original Unity networking API, powered by the reliable Photon infrastructure.
Besides the omnipresent matchmaking, PUN basic building blocks are: serialization of game object states (with built in support for transforms, etc); and remote procedure calls (RPC).
PUN gives the developer direct and complete control of what to send/receive, and, coupled with its flexible multicast-like room relay communication model, is a powerful game networking workhorse.

Photon Bolt

Photon Bolt is a higher level API, which lets the developer define the networkable gamestate through a set of data structures (called bolt assets: states, objects, events and commands) and associate these assets to game objects prefabs.
Augmented by callbacks and triggering of events and commands, Bolt's networking model brings state of the art compression, client-side prediction and lag compensated raycasts to Unity with minimum effort from the developer.

Quick Comparison

Features Comparison

Both Photon Bolt and PUN approaches have their strengths and reasons to be.
Here we try to explain important differences between them by comparing individual features of each one that impact similar areas of game networking.

Host Client (Bolt) vs. Dedicated Server (PUN)

With PUN, you already have a real dedicated server you can connect to and where rooms actually exist.
The client that creates a room is the first one to join it.
It will be marked as a Master Client known by everyone inside the room.
A Master Client is not a host nor a server but just a special client that can do extra stuff (pseudo-authoritative).

In Bolt however, one of the Bolt clients needs to act as a server, a true dedicated server or real host.
This can be a bit confusing, so let's clear things up:

• With PUN, if the Master Client quits, another actor -if available- will become the new Master Client.
  And so on, until there are no more clients.
• With Bolt, on the other hand, the server is "static"; the "client" that starts up the game and choose to become the server, will stay as the server.
  If the host client (server) quits, none of the other clients will become a server (and all of them will be disconnected, of course.)

So to sum up, in Bolt, if host disconnects the game is over.
Also ping and latency will depend on the connection to the hosting player.

Events (Bolt) vs. RPCs (PUN)

A notable difference between PUN (and many other networking solutions for Unity) and Bolt is that Bolt doesn't have the notion of RPCs, or ''Remote Procedure Calls''.
In PUN, and RPC is a way of telling all - or selected - client to "please, run this method now."
Bolt, on the other hand, uses ''events'' to achieve the same functionality.

Automatic State Replication (Bolt) vs. Flexibility (PUN)

With Bolt, you don't have to write serialisation code.
Everything is generated by Bolt's compiler based on the assets you create to represent the game state.
This is a great time-saver, and also means you benefit from other features out of the box such as compression.
However, it also means you don't have total control of what goes to the network and how.

With PUN, you write your own serialisation routines, deciding what to send and what to receive.
This way, you can write custom dead-reckoning functions, and decide which clients receive each piece of information with your own code.

Bit Compression (Bolt) vs. Message Efficiency (PUN)

Since Bolt code generation takes care of objects state serialisation, it benefit from state of the art compression, which greatly reduces the traffic for networking a complex gamestate.
However, Bolt's messages must always pass through the hosting machine, even when running a game through relay and not using authoritative server logic.
This adds a bit more latency to Bolt-based games.

PUN doesn't suffer from that caveat, as it's serialisation code sends data from a client to all the other peers through the relay by default (without having to pass through the master-client).
The issue for PUN here is that since the developer writes his own serialisation code, state of the art compression can not be achieved out of the box (the programmer may have to implement it himself).

Client-Side Prediction & Lag Compensation (Bolt) vs. Lite Authoritative-Server Possibilities (PUN)

Normally to avoid cheating, writing authoritative server code is something every game network developer has to face from time to time.
This means that you can have your server control the input from the client(s), and - if necessary - correct the data you send back to the client(s).

Bolt greatly simplifies the implementation of an authoritative server game with its built in client-side prediction architecture (commands + responses) and lag compensated shooter first raycasts (based on server-time approximative hitbox buffers).
This means the developer automatically benefit from years of industry experience from FPS and action games with a very comprehensible API.

The issue with such fully authoritative (often dedicated) server approach is cost.
Hosting servers that need to cope with the high CPU loads of complete simulations might render the game economically impractical.

With PUN, it is possible to write server-side plugins that match 1-to-1 every custom serialisation message from the clients, which can be intercepted and either blocked or modified before passed through to the others.
This is a very flexible API to implement only the minimum logic needed on the Photon servers themselves, leading to a much smoother scaling of servers costs.

Bolt's message packing and compression (a benefit in its own right) makes such approach impractical, if not impossible.

In thoery, it is possible to achieve pseudo authoritative functionality with PUN without server plugins and based on Master Client.
This require Master Client (and maybe all Master Client candidates) to maintain a 100% true state of each client, which is tricky.
Bolt solves this by introducing exactly that; client states.

In an FPS game, a typical "player state" would contain information about each player's position, velocity, camera pitch, etc.
With Bolt, these states are defined in Bolt's own Unity editor extension, which makes everything user friendly and type-safe to work with.
Bolt takes care of synchronizing states over the network for you, with the server being in charge of each client's real state, thereby hindering cheating.