One thing that has been on my mind today and was wondering what the community had to say is about multiplayer lag when the server is slowing down. I am currently working on a ‘always online’ game currently and have not experienced this yet but i know it can be a big issue for dev’s and players alike, now this is my thoughts.
The lag we all experience in games when we get FPS drops or stuttering in your player movements seems to be when a your client sends data to the server to make the player move and the server replies to say there ok to move (this is to stop players moving to fast with hacked clients or wall hacking) and if the server gets too overloaded it begins to slow down this process causing jitters in the movement or full on player lag, but i may have a easy fix (not been done yet since i have not got there but its a brain teaser).
What if when the client detects lag and packets are getting lost then why not make a array for every packet is lost and then send the array and if the array is not sent keep building it up until it gets a ping back and when that has happend clear the array and continue as normal. and through all this allow the player to move freely (only using client based block collision so hackers could temp move through walls but now untill the data has been processed by the server).
Any thoughts on this? i understand that this is a head ach and there is a few holes in the idea that can be fixed but what are your thoughts?
You’d be reinventing a lot of things that already exist. TCP, although maybe not optimal for games, handles resending and stuff like that, but not in a way that’s good for fast-paced games where information is quickly outdated.
FPS and client performance is unrelated to network lag. Your example is weird, as the cause of network lag is an unreliable and/or slow connection to the server.
Almost all games that need even remotely snappy controls do not wait for the server to allow an action. They do local checking (collision detection, etc) and have the server verify the action once it has been notified of it. If the server deems the action illegal, it sends the client a correction, causing him to snap to its correct position. This is the cause of the infamous “teleporting” if the client simply immediately corrects its position, or “rubber banding” where the client is pulled towards the position its supposed to have.
Resending packets is not always necessary. For example, there’s no reason to resend for example a single lost position update of one player, as by the time the package is assumed missing the next position update has already arrived, rendering all previous updates outdated. On the other hand, you DO want reliability for certain game events, and to achieve that with UDP you need certain techniques, some of which are pretty similar to your packet array idea (for example where all presumably lost messages are packed into a single UDP packet and sent together, and with similar redundancy for sending back ACKs of received packets).
Part of the problem that comes with using TCP Networking is going to be Jitter, however the last paragraph you stated is basically TCP functionality anyway. This is what causes the “fast-forward lag” that you see on a lot of games, Runescape used to be a great example of this. Things could freeze for 2-3 seconds, then all of a sudden everything is rediculous fast for the next few seconds, then everything goes back to normal, that’s the client playing catch-up, which simulates fast-forwarding.
What you’re describing when it comes to movement is usually referred to as “rubberbanding”, and is hated with a passion by Aion players everywhere. Server lag should not effect your FPS at all, however, some people suggest Non-blocking IO solutions, while others suggest thread related solutions, I typically follow the second and handle all of my networking on a second thread. This is not feasible for some platforms (Mobile devices)*.
If you’re doing server-authorized movement, I always do “lag calculations”, basically there’s an “allowed” latency limit that’s accounted for based on vector math. Using basic math you can find out if the player is/should-be/or even could be somewhere in 500ms, easily. For example, if the player is at position 4, and they normally move 1 position per second, if they’re randomly at position 12 a second later(on the client), that’s not possible, even if they’re lagging at the maximum allowance of 500ms. However if the client was at position 5.5, and the server expected position 5, it will take that 500ms into consideration and see that 5.5 is within the allowed range. Anything other than that should be rubberbanded, imo.
Mobile devices may support multithreading now; However about three years ago when I was looking into it, they did not.
There is so many articles on internet about the pro/con about TCP vs UDP , … , world position us UDP and for player command use TCP , … etc
My own opinion and by experience in realtime games TCP is good enough for Realtime game nowaday. That is due to quality of network and also the latency are very low now <50 ms per continent so even if some packet need to be re-emitted due to lose it’s very few of them due to the quality of networks.
We are able to make working FPS and fighting simulation Realtime with TCP without considering UDP and all the overhead we have to implement on top of it have guaranty delivery factor.
There is so many factors that can cause latency and bandwith consumption : message size (MTU?) , frequency etc…
We are close to have all fiber at home and on mobile what he have at home so TCP vs UDP is on dying problem imo.
Feel free to try this Free Nio Java Multiplayer game server http://nuggeta.com and let me know if it saves your time from TCP VS UDP problem.
