Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (806)
Games in Android Showcase (239)
games submitted by our members
Games in WIP (868)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Multiplayer lag, where dose it come from and solutions  (Read 3292 times)
0 Members and 1 Guest are viewing this topic.
Offline Ed_RockStarGuy
« Posted 2014-12-29 00:50:20 »

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?
Offline theagentd
« Reply #1 - Posted 2014-12-29 01:13:57 »

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).

Here's some really good information: http://gafferongames.com/networking-for-game-programmers/

Myomyomyo.
Offline CTucker1327
« Reply #2 - Posted 2014-12-29 02:13:26 »

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?

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. 
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline nuggetags

Innocent Bystander





« Reply #3 - Posted 2015-06-19 15:21:37 »

Ah this famous Lag friend is back.

I think their is not much to invent in sync players since Valve undisclose the only good way to go iMO. https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

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.

HTH




Pages: [1]
  ignore  |  Print  
 
 

 
Riven (587 views)
2019-09-04 15:33:17

hadezbladez (5532 views)
2018-11-16 13:46:03

hadezbladez (2410 views)
2018-11-16 13:41:33

hadezbladez (5793 views)
2018-11-16 13:35:35

hadezbladez (1233 views)
2018-11-16 13:32:03

EgonOlsen (4669 views)
2018-06-10 19:43:48

EgonOlsen (5688 views)
2018-06-10 19:43:44

EgonOlsen (3205 views)
2018-06-10 19:43:20

DesertCoockie (4104 views)
2018-05-13 18:23:11

nelsongames (5125 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!