Streams vs Match Update Dispatcher

Hello everyone,
I am currently investigation an approach how to better or let say faster sync states of n objects.
If i have understood correctly using standard approach of match dispatcher is not sutaible to send more than 1 or 2 rpcs packets within seconds or execution loop.
So taken that in mind i have some questions regarding streams:

  • Do streams follow same principle, not to send more than 1 message per stream or we can send unlimited in same execution loop?

What i am trying to accomplish is something like “Networked” state sync where on client side objects marked that have “Networked” State would occasually poll or check state, or when ever server pings those objects that there are state changes.
Dispatching standard message with dispatcher could provide not efficient or not fast enough thus while remaining current one visable solution it would require for game to get paused for at least one or two match loops.

Thanks.

There is a few questions here;

  1. What is a “standard approach” and why is it considered not suitable to send more than 1/2 dispatch calls within execution loop?
  2. The dispatcher uses the streams underneath it. All Nakama realtime functionality ends up using Streams at some point.
  3. What kind of gameplay are you building that 1/10th of a second delay in processing (assuming tick-rate of 10, can even be more frequent but ~10 should be enough for most games) is considered slow?

I think you are solving the wrong problem here and we need more info to help solve the architectural problem you are trying to solve.

Thank you for replaying :slight_smile:
I will try to example a bit better my use case:

  • The game is turn based with somewhat real time components
  • At some point the game user is able to spawn something we call “buildings”
  • These builds have its own state, which is server managed and then update clients with its data.
  • User may have n buildings, and these buildings can be removed through gameplay.
  • Building it self have some stats static, some dynamic which depends on user state / match mode and a bit of RNG thus these stats are handled on server authorative side.

What i want is a way to sync always these dynamic stats. How many stats there are per building is undefined it can be 1 or it can be 100, it shouldn’t really matter to packet, as building it self needs to broadcast these stats to clients occasually, like on some intervals.

First approach what i have tried is to have one gigantic object within state called “buildings” and on some intervals broadcast this to clients.
Since it can grow, obviously it may cause hog at some point in gameplay session. The hog may also happen if user performans too many actions at same time.
So broadcasting this huge packet started to become an issue :confused:

Next idea is to split this, by having each building send its own data separetly but if there are 10 buildings or even more at some interval within same loop executing i can have more than 20 different broadcast messages.

So what i am looking is away to keep sending this building broadcast message, and not to hog main broadcast of match state…

Maybe something i have miss understood regarding limit of dispatcher message broadcast per match execution loop.

if i understand correctly, you may try and reduce your “server sent events” to a minimum - say, only broadcast values that have changed.

I do have a game state object that i broadcast that may eventually be 4 MB large. This is not a problem at all (of course set respective config value). I run with a tick rate of 10 and ensure that i broadcast the state only if necessary only once at the end of one loop.

I do notice, that with large amount of players (100 i.e.) the broadcasting including network-delay may take a little time and may result in 1-2 seconds delay between the users.

Hey @dela
Thank you for replay :slight_smile:
Currently i keep my data at low and highly compress/optimized atm we are at 2.64KB of data (match state )

But instead of broadcasting state once per loop, during the loop i may broadcast a larger amount of smaller package messages like for instance:

  • When card is casted it may send up to 4 different packets such as:
    – Which card was casted, and was cast successful and who casted it
    – Will card get discarded or replaced or thrown out of game
    – Different card effects may procs additional card packets
  • Where is possible i managed to combine packets and organised a bit differently data like:
    – If effect needs to stun 10 units, instead to send 10 diff packets i send only 1 which contains all the data that is necesserly
  • Game tick currently is at 20 i am planning to lower it as soon as possible, and delay atm we haven’t noticed it. We did notice that game is a bit lagging and like drop down in fps, but that is because of client code and not networking.

But it is great thing that you managed to run match/game data at 4MB and haven’t noticed issues. I do wonder is it mobile or pc, and have you tried it on well 4g/3g networks?
Thanks :slight_smile: