Which is a better design? Lots of events with small data or one event with large data?

Options
SPF
SPF
edited December 2020 in Photon Bolt
I'm making a Hearthstone like game with Bolt. I use events to send and synchronize data between server and client.

Every time the client makes a move (for example play a card), the server side data changes a lot(for example Hero health changes, units data changes, card in hand and deck changes).

I have two plans to synchronize these changes to all clients. Plan A is to send events with small piece of data for each small changes within one move. Plan B is to send one events with large chunk of data for each move. Which one is recommended? Thanks!

Comments

  • SPF
    Options
    I'm planning to use Plan A for now. But I'm not sure if the overhead for each event would be a big concern. If anyone knows about this, please share your view on this. Many thanks!
  • JohnTube
    JohnTube ✭✭✭✭✭
    Options
    Hi @SPF,

    Thank you for choosing Photon!

    I would also go for option A.
    Big messages is not something we recommend (see here).
    Of course, it's relative (how big is the message, how often, etc.).
  • SPF
    Options
    Thank you @JohnTube , this is helpful. This is a doc under PUN, but I guess it's the same with Bolt, since both are built on RealTime, I assume.
  • JohnTube
    JohnTube ✭✭✭✭✭
    Options
    Ah I see!
    I've moved the discussion under Bolt category then.
    It was under PUN originally and I missed the "Bolt" keyword in the post.
    But you guessed right this is shared but Bolt may have more about this.
    In any case, I still believe A plan is the way to go.
  • ramonmelo
    Options
    Hello @SPF ,

    For large data, you can use the built-in Stream System, but how "big" is the data you are trying to send?

    Please, take a look here: https://doc.photonengine.com/en-us/bolt/current/in-depth/streaming-bytes

    But for your case, we would recommend that you use some kind of bit serializer in order to send as minimal data as possible.