Actually, the jellyfish is not in sync! If that is because the client is rendering a different frame that is ok. I need to print the current frame on screen. The clients can have delays, but the output of the certain frame must be identical.
Yes, they seem to vary a bit on which frame each client is rendering. So I hope that is because of it.
I once again tried to investigate the reason for hiccups in receiving huge number of udp packets. I find out that it happens with normal udp also if the traffic is high. Not only with RelUdp. I can be that the incoming udp stack in ESP is jammed temporarily, ESP is busy with something else and do not give cpu to my Arduino run() function, or the serial port between ESP.and MCU is jamming.
3 Likes
I will now prepare the test game for the multiplay test session 
4 Likes
Now I have confirmed that the system works also with a remote server (Kamatera), not just my local server.
Still need to make it more like a game.
3 Likes
Slowly getting there!
Now, I have only to make a timer to limit the game round (because otherwise I run out of RelUDP sequence numbers 
) and select the winner when the time is up. Using Kamatera server for the test.
3 Likes
Now it is a game 
4 Likes
Thanks for everyone participating the online multiplaying test session! It was a great fun!
Nice to meet some long time community members virtually in the game 
Now I would like to hear comments how it went? Is this, delay-based multiplay, a good way to make this kind of game? Did you face any troubles?
4 Likes
Even when it was runnning smoothly, it wasn’t. There was always input lag, or rather display lag, meaning it was very difficult to know where you actually were at any one time.
1 Like
True, there is always a delay. That is about 250 ms (8 frames). That is always there.
In addition, there are occasionally stalls for the whole game, caused by a client which has greater netlag than 250 ms. The netlag is about 2 x ping time.
Also there is that weird hiccup in the Pokitto networking system which occurs in a period of 3-5 seconds.
Still, I would like to understand if this delay-based networking is better suitable for some other type of games than this “Fishlife”?
1 Like
Did anyone see the “out-of-sync” icon during the session?
never did see the out-of-sync!
Most of the time I had this kind of “slide-lag”, which weirdly feels like the fish has inertia so it’s actually not so bad. I think an artificial lag could actually be enjoyable if it’s fit properly into the theme (e.g. ice).
It’s quite intense otherwise, and fun! I had to rest my hands after doing that 57 points 
It could use a sound to signal the start of a game too - more than once I was busy looking at the discord chat or discussin, and the game was already starting.
1 Like
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