Photon Bolt vs. PUN

hyhy2018

I briefly looked into Bolt and PUN. In terms of technology, looks like Bolt is more superior since it is peer to peer. But PUN looks like more widely used. How can the user choose between those two? what is the pros and cons? I am currently building a RPG Game, the worlds and game content will be constantly added in. Can anyone help me decide which technology i should use?

JohnTube

Hi @hyhy2018,

Thank you for choosing Photon!

Our PUN vs. Bolt doc is being updated currently.

Here is a preview that should answer your question:

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

1. Bolt automatic state replication vs PUN Flexibility
   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.
   
2. Bolt bit compression vs. PUN message efficiency
   Since Bolt code generation takes care of objects state serialization, it benefit from state of the art compression, which greatly reduces the bandwidth 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 serialization 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).
   
3. PUN lite authoritative-server possibilities vs. Bolt client-side prediction + lag compensation
   Normally to avoid cheating, writing authoritative server code is something every game network developer has to face from time to time.
   Bolt greatly simplifies the implementation of an authoritative server game with its built in client-side prediction architecture (commands + results) and lag compensated shooter first raycasts (based on server-time approximative hitbox buffers). This means the developer automatically benefit from years of industry experience with FPS and action games in a very comprehensible API.
   The issue with such fully authoritative (often dedicated) server approach is cost. Hosting Unity headless servers that need to cope with high CPU loads and 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 serialization 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.
   

Both tools have their advantages and caveats, and in reality there's no single approach to develop netcode anyway, so deciding between the two is a matter of using what fits best to your's gameplay design.