Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
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  
   Suggestions to reduce time lag...  (Read 1313 times)
0 Members and 1 Guest are viewing this topic.
Offline moogie

JGO Knight


Medals: 13
Projects: 6
Exp: 10 years


Java games rock!


« Posted 2005-03-06 01:51:22 »

I have made a snake clone with the purpose of allowing many people playing as possible. This game will most likely be played at a Local LAN party i attend regularily with a usual attendace of about 400 people. I want to have the ability for at least 64 people playing at one time, however i am wanting to have about 200 players at once. This is because the game will likely be used as a fun competition for hardware prizes dontated to the LAN.

The game can be downloaded here: http://goldenstudios.or.id/forum/index.php?act=Attach&type=post&id=1267

You will have to edit the config.xml to the ip address of the computer which will be running the server. And edit how many players must be connected before the game starts.

Controls:

Left - turn snake left
Right - turn snake right
Space - turbo speed


I am alittle concerned about the lag that is felt by players who connect to another computer running the server ( if the server is run on the same computer as the player there is no lag).

The nework protocol used in this game:

C = client
S = server

start up

C connects to S
S returns unique ID
C sends userName
S waits until sufficent players connected then sends inital game state to every C

playing

C sends change in keys being pressed flags to S
S adds this message to a buffer to send
S sends the buffer every 20 msec (if the buffer has at least one message) to every C


The keyboard input rate is 16.7 hz
The underlying game state rate is 50 hz
The incomming network msg handling is 50 hz
The outgoing network msg is 16.7 hz

The video frame rate is independant.

So assuming a 20 msec network delay  then the message round trip should be approx: 20 delay to server + 20 delay at server + 20 delay to client which is about the 16.7hz mark and so should be not noticable by the user.

Is this thinking above incorrect? How would i go about reducing this delay?

Initally i thought what it is my update rate of the server (20 msecs) however that would mean that there should be lag even if the server and the client are on the same computer so it must be the delay caused by the network.

Any help would be greatly appreciated.

Offline moogie

JGO Knight


Medals: 13
Projects: 6
Exp: 10 years


Java games rock!


« Reply #1 - Posted 2005-03-06 02:55:30 »

Oh, i forgot to mention that you can use the page up and page down keys to zoom.

The game is not finished yet so dont expect too much Wink
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #2 - Posted 2005-03-06 07:14:44 »

Basically: if you want to work in frequencies, you'll find that latency == "the sum of the greatest frequency periods + all the other sources of latency in the system which you're ignoring because you chose to think in frequency".

Unsurprising, therefore, that you are experiencing a lot of lag. You've set it up so that the latency = 60 ms + 20 ms + 20 ms + 60 ms + network latency (just summing up what you've written). i.e. 160ms, in addition to any RTT for the network. Obviously, on a *good* LAN, RTT should be only another 10ms max.

PS: I don't believe those figures, but IF they were true, then the above would be true.

My advice is to forget about frequencies entirely. F's are for when you're thinking about making a smooth animating game, they are not for thinking about making a network layer.

Instead, just work in latency. Go through the control flow adding up the latency each time you delay. This will pick up the other causes of latency.

The most obvious problem in your desing is that it keeps waiting *for no reason* at several stages. Looks like most of the latency is put there by the fact that you wrote code that deliberately sits around doing nothing.

What you ought to be doing is:
1. player presses key; keypress is discovered IMMEDIATELY (or as close as you possibly can get) and transmitted to the server. No-one cares about the keypress taking a little while to be picked up by a screen paint, but they do care about you sitting around waiting before sending it to the server.

2. when keypress arrives at server, it is timestamped and IMMEDIATELY sent out to other players. If you can't handle this performance, you can batch up a few keypresses, but because they were timestamped, the client can at least use interpolation, dead-reckoning, etc to hide some of the latency. (google if you need to).

Side note: I don't understand why people tend to talk about "hz" when thinking about network lag. Not only has it nothing to do with the real problems of latency, but it can ONLY encourage you into making the wrong decisions.

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline moogie

JGO Knight


Medals: 13
Projects: 6
Exp: 10 years


Java games rock!


« Reply #3 - Posted 2005-03-06 09:50:32 »

Quote

The most obvious problem in your desing is that it keeps waiting *for no reason* at several stages. Looks like most of the latency is put there by the fact that you wrote code that deliberately sits around doing nothing.

What you ought to be doing is:
1. player presses key; keypress is discovered IMMEDIATELY (or as close as you possibly can get) and transmitted to the server. No-one cares about the keypress taking a little while to be picked up by a screen paint, but they do care about you sitting around waiting before sending it to the server.

2. when keypress arrives at server, it is timestamped and IMMEDIATELY sent out to other players. If you can't handle this performance, you can batch up a few keypresses, but because they were timestamped, the client can at least use interpolation, dead-reckoning, etc to hide some of the latency. (google if you need to).

Side note: I don't understand why people tend to talk about "hz" when thinking about network lag. Not only has it nothing to do with the real problems of latency, but it can ONLY encourage you into making the wrong decisions.


i think you mis understood my 60 msec time calculation, I am immediately sending the key press when it is registered... it is just that the key press is registered every 60 msec.

The 20 msec on the server side is to allow the collection and batch sending of messages received. Is this not correct? i would have thought that having no delay on the main thread would cause the other threads to starve.

I guess i will have to look at more sophisticated techniques as suggested by you.

those hertz values are only used to indicate the frequency of the sperate game processes. I dont mean to use frequency for latency...

Cheers the for input!
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #4 - Posted 2005-03-06 10:32:28 »

Quote


i think you mis understood my 60 msec time calculation, I am immediately sending the key press when it is registered... it is just that the key press is registered every 60 msec.


Either you are getting each key press immediately, or you are sampling them every 60 ms. If the latter, you are personally adding up to 60 ms delay for each keypress.

malloc will be first against the wall when the revolution comes...
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (38 views)
2014-10-17 03:59:02

Norakomi (29 views)
2014-10-16 15:22:06

Norakomi (24 views)
2014-10-16 15:20:20

lcass (28 views)
2014-10-15 16:18:58

TehJavaDev (56 views)
2014-10-14 00:39:48

TehJavaDev (55 views)
2014-10-14 00:35:47

TehJavaDev (46 views)
2014-10-14 00:32:37

BurntPizza (64 views)
2014-10-11 23:24:42

BurntPizza (36 views)
2014-10-11 23:10:45

BurntPizza (78 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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!