What's the point of using Token instead of properties of state?
Options
SPF
✭
in Photon Bolt
What's the point of using Token instead of properties of state?
I know that properties of State will be replicated automatically if changed. And tokens are more like constants variables of an Entity that are assigned when it's initiated. Are tokens more "light weighted" compared with properties that are only assigned one time in its lifetime(so they don't have any overhead to replicate)?
I know that properties of State will be replicated automatically if changed. And tokens are more like constants variables of an Entity that are assigned when it's initiated. Are tokens more "light weighted" compared with properties that are only assigned one time in its lifetime(so they don't have any overhead to replicate)?
0
Comments
-
Don't know how to delete this post. I've found the doc page that's related with this topic. It might help others in the future.
https://doc.photonengine.com/en-us/bolt/current/in-depth/reliability0 -
Hello @SPF ,
Protocol Tokens are intended to be used when you want a set a data be transported together, and in most cases, you should be using them only for a few actions, like when instantiating an entity, and you need some information to go with it when attaching, for example.
In terms of performance, there is not much difference between using Token and Properties, but in terms of networking, you should consider use properties, as they can be synchronized atomically, meaning that changing one property will trigger the synchronization only of that particular field, on the opposite side, you can only change a Token field if you replace the Token entirely, so you would need to sync another completely new Token in order to update only one field, for example.
Also, Tokens are serialized as one block of data, if it overflows that Bolt packet size, the data will certainly delay to be transmitted, as it needs to fit the packet to be sent.
Keep in mind that each Bolt packet can be used by different channels, like for Events and Commands.
Read more about this here: https://doc.photonengine.com/en-us/bolt/current/reference/boltpacket
--
Ramon Melo
Photon Bolt Team0 -
Thank you @RemoboarmaG , that's very informative and helpful!
Could you also look into this please? https://forum.photonengine.com/discussion/17128/should-i-use-bolt-or-pun-making-a-hearthstone-like-card-game/p1?new=1
I'm planning to make a Hearthstone like game. I plan to use Bolt, to maintain a game data model on the server client, and use mainly 'reliable events' to transfer users' abstract input 'e.g. play x card to y slot', and then transfer back the result via events and the client then play animations accordingly. I won't use state properties or commands(because it's not 100% reliable).
In this case would Bolt be the proper choice? Or in your opinion if I choose using Pun instead, the game will run much smoother, using much less bandwidth?
Thank you!0 -
Hello @SPF ,
Either solution would work fine. Photon Bolt was designed for fast-paced games, so using it for a card game is more than fine.
The points that you need to keep in mind, is that by using Bolt, you need or a dedicated server to run the session or let one of the players be the server and the authority over the game state, someone needs to hold the truth.
Also, Bolt only synchronizes the state when necessary, so if it does not change, there is no major network usage, it's well optimized in this sense.
--
Ramon Melo
Photon Bolt Team0 -
@ramonmelo Thank you! I've discussed this with other users on discord too. It's a relief to hear from your official confirmation.
I want to extend this discussion a little bit, just out of curiosity. People always reminds me that using Bolt I need to design it in a way that there's an authority server. However even if I use Pun, I would still design my game that way (not exactly the same of course, but on the logic level, codes for master client are very similar to an authoritative server).
Another design pattern is what you called "deterministic" or "lockstep", but that goes with Quantum. So what kind of pattern were you referring to when using Pun, if not to use a "master host" to deal with the main game logic?0 -
Hello @SPF ,
Yes, the "master client" would have the authority over the entities, but as far I know, that is not enforced by the SDK in the case of PUN. On Bolt, if a certain peer (either the server or one of the client), ONLY that peer is able to modify its state and it being replicated over the wire (read more here).
You are right about Quantum, it uses a different approach, while Bolt uses a State Transfer approach.
--
Ramon Melo
Photon Bolt Team0 -
The reason I abandoned my previous 3rd party SaaS service is just because they lack such a good community support. Thank you for your time and help! @ramonmelo0
