It is a good news that no-one seems to have had sync problems. Even better that nobody has reported permanent hang problems in the middle of the game. That means that RelUDP really do not lose packets 
Even in stressed situations.
1 Like
Regarding to sliding. That could be fixed by implementing the “rollback netcode” system which conveniently uses the delay-based netcode as a base. That would give immediate response to local controls. The downside is that remote player movement is predicted for the during of the netlag, and that can cause unexpected jumps if the frames are rolled back and replayed. It is also much harder to implement.
That is why I plan to use only the delay-based netcode for the first version of “easy-to-implement” networked games. There are some smaller adjustments for the current system that can be made. One is having a bigger delay buffer for players with bigger net lag, so they do not slow down other players. That can be acceptable for certain game types.
And I need to change the sequence numbers in RelUDP to be 32-bit so they do not run out 
2 Likes
I have a little problem which I do not know how to handle it. In RelUDP protocol the packets can come out-of-order from server to client but the RelUDP protocol layer (in ESP HW) takes care of putting incoming packets to the queue and provides the packets to the client app (the game in MCU side) from the queue in the correct sequence number order (thought the client app do not know about the sequence numbers). This works well.
The problem occurs when the very first RelUDP packet is received by the device which has just joined to the game. How do we know if that packet is really the “first” one? What if, after a new client has joined, the next two packets have flipped the order when going from the server to the client? When can we be sure about the first packet identity, and can start delivering packets to the game app?
Note that the clients can join to the game session at different times and part of the packets might have already been send to other clients when the new client joins. So the first RelUDP packet for that client do not necessarily have the seqnum 0, but it can be anything like “12” or “201”.
This could be solved by modifying the join response to return the next expected RelUDP sequence numbers (the server should already be keeping track of this info anyway), or if we determine altering the returned values from the JOIN command would cause compatibility problems we could introduce a new command to get the RelUDP sequence numbers (I prefer this option). Doing the latter would make it an optional for games that allow other clients to join after the host has “started” the session (typically most games will have the host create the session then wait for everyone to join before starting the session with RelUDP packets not being sent until the session starts). For my games that use the RelUDP the “START SESSION” from the host is done as the first RelUDP packet (Fruit Frenzy then waits until all clients have sent a subsequent “ready” RelUDP packet).
TL;DR add a command to the server for a client to get the next RelUDP sequence number since it’s only used for games that would allow clients to join mid-session. We should also have a command for the host to disable joining so they can “start” a session and automatically prevent new clients from joining in (spectate is different).
Very good suggestions. Those are viable options to handle the situation.
One option that came to mind was also just to decide that the first RelUDP packet that comes to the client is the starting point. If packets with a smaller seqnum come after that, those are not delivered to the MCU client app. Instead those are just ACK’ed to the server so that the server can remove them from the resend queue.
2 Likes
(moved all car game related posts under an own main topic: “Mad Mobiles”.)
In the future, if you want to branch to a new topic, click on the “post time” value at the upper right of the post you want to branch from. You can then choose “+ New Topic” to start a new topic and automatically link the current topic to this new one.
2 Likes