If you have been working with Photon Unity Networking (PUN) previously, and consider switching to Bolt, there are certain differences you should be aware of it.
The most important difference is of course that with Bolt, you are responsible for managing your own server, while with PUN you can connect to any of our cloud servers. This is not so much big of an issue with version 0.4.1 of Bolt, as it still can't work as a true standalone server - it still requires Unity to run as a server - but in a future version of Bolt, you will have the ability to run so-called headless servers, i.e. servers without Unity "in them", making it possible to host your game on cheap virtual servers at Amazon, Digital Ocean, or whatever provider you prefer.
While this makes it a bit harder to just jump in and get started with Bolt, there are several major advantages with this, one of them being that you can have your server be authoritative. 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). In many cases this isn't necessary, but if you want to avoid cheating in your game, you definitely need to go down this road. Yes, it's extra work and all that, but it's a requirement if you don't want your game to be vandalised by cheaters.
Comparison of PUN/PUN+ and Bolt Networking
PUN: 20 free CCU
PUN+: $95 once = 100 free CCU for 60 months
|20 free CCU, $95 once = 100 free CCU for 60 months|
|Hosting Service||Photon Cloud, Photon Enterprise Cloud||.|
|Platforms (WebGL excluded)||Almost every platform||
All major platforms
|Authoritative Server||(Photon On-Premises)|
|Custom Authentication||(not built-in)|
|Webhooks and WebRPC|
|Server Plugins||(Enterprise Cloud only)|
|Automatic Mecanim Networking|
|Unity Networking Compatible||(Old Unity Networking only)|
|Unity 4 FREE: Web, Standalone|
|Unity 4 FREE: iOS, Android||(PUN+ required)|
|Host Migration||(not built-in)|
|MatchMaking (Room and Lobby Support)|
|Player Quality of Service (QoS)|
Bolt's authoritative state mechanism
I should note, though, that it should be ''theoretically'' possible to achieve some kind of authoritative server-functionality with PUN because each client knows if it's the server or not, and each non-server client (sic) could update itself, it would be impossible for the server to ever maintain a 100% true state of each client. Bolt solves this by introduction 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. And - of course - 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.
RPCs vs. events
Another 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.
Bolt-ifying the PUN intro
This is an attempt to go over the PUN intro and achieve the same things with Bolt. One thing worth mentioning is that Bolt doesn't support ''rooms'' out of the box; there is nothing stopping you from implementing your own room logic in Bolt, of course, but for the sake of keeping it simple, we will skip that part altogether for now.
Creating the server
With PUN, you already have a cloud server you can connect to. With Bolt you have to create it yourself. With PUN, the first client joining a room, will also act as the server. This is kind of similar to Bolt, as one of the Bolt clients also will act as a server, but as a dedicated server. This can be a bit confusing, so let's clear things up:
- With PUN, the first client joining a room will become the server. If that client quits, the next client that joined the room will become the server. 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 that client (server) quits, none of the other clients will become a server (and all of them will be disconnected, of course.)
But let's not put too much work into the server part; Bolt comes with a simple solution which lets you choose if you want to start up as a server or as a client;
- Create a new scene and call it "Login".
- On that scene's "MainCamera", attach a script component called "Bolt Init".
That's all you need, as long as you don't need anything fancy. And you don't at this point. With this you have a user interface where can choose if you want to create a server or a client "version" of your game.