It finally hanged when the 16-bit sequence number used in every reludp packet was overflown 
I need to figure out something or grow it to 32-bit.
1 Like
I would just grow it to 32-bit since it would make it near impossible for a game to overflow at that point. Incrementing this number by 1 every millisecond is just shy of 50 days.
1 Like
I might also do it so that if the received seqnum value is too much smaller than the previous one it is interpreted as overflown. That would mean dedicated comparison functions which consider that.
1 Like
I agree with Tuxinator’s strategy since it’s the most straightforward.
Otherwise, if you go to want to test if your strategy works properly, 8-bit sequence numbers are excellent candidate to test the robustness 
1 Like
The only downside is that it increases the udp traffic by 2 bytes per the data packet and 2 bytes per the ack packet. That is for 30 fps and 4 players, the data and the ack packet for each: 30 x 4 x 2 x 2 = 480 bytes per sec (minimum, if there is a need for resend that will be more).
If we think that an average data&ack packet is about 100 bytes, and the increase is 4 bytes, that is about 4% increase. Maybe not so much after all.
1 Like
A short status update.
Now the missing packets bug in RelUdp was really fixed (in server). Have not seen that bug in two weeks so I suppose it has been fixed.
The only bug holding off the multiplay test session is that my demo game is not fully deterministic yet. I made an own random generator class to make sure the problem isnt that some code somewhere uses the standard random() method also. It still goes out of sync after few thousand frames.
I think the reason is that, in the game object array, the players are in different order in different clients. It depends on the order clients are registering.
Lets see tomorrow if fixing that helps. 
4 Likes
When I get a chance I’ll need to run some tests with Fruit Frenzy and see how it performs.
1 Like
Over 200 random numbers raffled and still all clients perfectly in sync
To be more clear. All the game objects in all clients are in exactly the same position: fishes, food, jellyfish. Only the key events are being send to each client, not any position data. That is taken care by the deterministic game engine, which quarantees that every frame looks identical across the clients.
The random number count is a good measure of the synchronization as if the fish is not in the right position in certain client device, the fish could miss the tiny chip of food which the same fish in other client devices would hit. Then a new position for a new food item is raffled for all but that particular client.
3 Likes
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