Hi!
I already know that you are working in an UDP protocol for the near future, but because right now we rely on TPC, i was wondering what kind of modifications you have implemented over TCP protocol in order to make it reliable for a fast action game.
I already know that this game Tiny Royale is implemented in Nakama and is using TCP, the game support up to 30 players per game, it is not a very fast action game but at least it has lot of players, if some players in a match start losing packets, won’t packet retransmission cause a saturation of the bandwith? If TCP is slower than UDP, won’t this affect to the current high latency that we can expect of a game played over 4g networks (our game is a mobile game)?
Right now because we are focusing in the soft launch an we will only support 2 players in coop mode i think we can work with TCP, but for a future PVP mode with 6 or 8 players i think we will need UDP.
We are not an expert in networking and multiplayers games so don’t hesitate in explaining details in depth :P, thank you very much!
If a client falls behind and cannot keep up with the message rate for any reason (including packet retransmission) the server will terminate the connection - so a client cannot saturate the server bandwidth. It’s one of a number of quality of service and flow control mechanisms in the server.
TCP tolerates latency very well, you won’t really notice additional latency compared to UDP. What you may notice is head of line blocking caused by retransmission/reordering of packets. If that happens the experience will only degrade for the player with a poor connection, not for everyone else and not for the server in general.
When your game is on a cellular network you need to build in tolerance for a considerable amount of lag regardless of protocol. Do you use a client-side receive buffer? How do you currently handle lag compensation?
Why does your number of players drastically change the protocol requirements? Each player should ideally only send/receive one packet to and from the server per tick, regardless of player count.
We will have a client-side buffer and we will try to compensate the lag with interpolations (in the future we would like to start adding some predictions) .
Honestly i have asked about UDP and TCP because i have always read that UDP is the recommended protocol for games similar to ours. If you have a character moving with direct input in a non predictable way (fast paced action games) you need to send position, rotation, etc at a high frequency rate and i have always read that UDP is the protocol for that.
I suppose the reason is just avoid problems with packet retransmission because in the moment one packet was lost, we have to wait and while that happens, lot of packages start to get accumulated.
I see what you mean. For that use case usually UDP is recommended, but TCP will still do the job. Accumulation of packets in itself is tolerable, it’s more about the consequence of waiting for now-stale packets to be retransmitted while holding up newer data which is more important.
I recommend you proceed with the current socket implementation and switch when we reintroduce UDP support. If you use our client libraries they’ll be updated to support any new protocols and you’ll be able to switch with a one-line code change. Keep an eye out for protocol changes as we release new versions of Nakama.
i wanted to be sure we are in the right way