I’m trying to figure out if the server just sends it’s queue of updates from clients on individually per tick — the queue of updates since the last tick— just as it would in a client relayed setup without server side code, or if it sends one message out with the game’s entire current state in it to update everyone?
Hi @VastView! I assume you’re talking about Nakama’s authoritative multiplayer feature.
Nakama’s authoritative matches do not broadcast any state automatically. It’s up to your match handler code to use the dispatcher.broadcast_message(...)
function to send state to one or more client. This gives you total control over when to send state updates, what data they should contain, and whether to send them to all players currently in the match or only a subset.
We generally recommend sending at most one message to each player per tick. This might be the same message to all players or a different one to each one, but nonetheless we recommend one update per player and for the message to be as small as you can make it.
Hope this helps!
Thank you so much for the help! I think I’ll try to send the entire state of a match to all players as one message every tick then, under one op_code Ideally I think I should only send changes to the state to keep message small, maybe along with a checksum for clients to see if their state still matches the server’s.
However, if you could please explain, why is it better to send one big message out over the internet, rather than multiple smaller ones? Don’t the smaller ones travel faster?
Also, if you send small messages out emmediatly as you recieve player inputs —as in relayed multiplayer— wouldn’t that be faster than bundling them all together into one big message that waits to be sent on the next tick? Or does client relayed multiplayer also internally work with a tick rate anyways, bringing this back to my previous paragraph’s question?
Thank you again for your kind help. If it’s too much of a hassle to explain, don’t feel bad to leave me to my own devices
God bless.