Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (541)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
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  
  Gameserver performance  (Read 2414 times)
0 Members and 1 Guest are viewing this topic.
Offline Reck

Senior Newbie





« Posted 2012-12-03 20:35:04 »

Hello again.

I've made a gameserver using KryoNet. It's currently broadcasting play positions once every half second, and it really feels a bit laggy.

How often can i make it broadcast still being reasonable?
Offline princec

« JGO Spiffy Duke »


Medals: 437
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2012-12-04 00:15:35 »

Try 20Hz.

Cas Smiley

Offline theagentd

« JGO Bitwise Duke »


Medals: 366
Projects: 2
Exp: 8 years



« Reply #2 - Posted 2012-12-04 04:26:17 »

Depends on the game. If it's a shooting game or another twitch-based game, I'd say 60Hz. If it's just a strategy game, set it to 20. No matter which update speed you choose, using interpolation makes it lot smoother.

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline namrog84

JGO Ninja


Medals: 46
Projects: 4


Keep programming!


« Reply #3 - Posted 2012-12-04 04:58:39 »

Depends on the game. If it's a shooting game or another twitch-based game, I'd say 60Hz. If it's just a strategy game, set it to 20. No matter which update speed you choose, using interpolation makes it lot smoother.
I don't think 60Hz is necessary.  you want 60fps or more, but you don't need 60hz update packets sent

I think most people would agree CounterStrike is a twitch based game and I think they only did approximately 20 broadcast/pulse/packets. But they do some fancy delay/interpolation for lag and packet loss compensation
source: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking


"Experience is what you get when you did not get what you wanted"
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 847
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #4 - Posted 2012-12-04 08:49:37 »

Even if you can technically send / receive 60Hz over the internet, you shouldn't.

In my experience, at those rates, it triggers your (well, my) ISPs abuse-protection algorithm, and your entire connection will be severely throttled, with latency consistently over 1000ms, even after the game is closed and you're pinging some 'neutral' server like google.com.

AS Cas said, 20Hz networking is the maximum update rate you should consider.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline saifix

Senior Newbie


Medals: 1



« Reply #5 - Posted 2012-12-04 09:11:02 »

I haven't seen your code, but judging from your other thread I'm going to assume you are still updating every player on each broadcast? Serialization is very costly and isn't exactly something you should be doing on a List of objects twice a second. Something you could consider is to have the client maintain a list of local players and have 2 packets for adding and removing players from this list. For example:

1  
2  
3  
4  
5  
public class RegisterLocalPlayerPacket {
    protected Player player;

    protected int identifier;
}

1  
2  
3  
public class DeregisterLocalPlayerPacket {
    protected int identifier;
}


Then when you want to update something such as a players position you could have yet another packet!
1  
2  
3  
4  
5  
public class UpdatePlayerPositionPacket {
    protected int identifier;
   
    protected float relativeX, relativeY;
}


Note: identifier is just a unique ID for an online player.

However, this means on the server end you need to update players separately from one another. What I'd do is create event listeners (I'm not exactly sure how your server works so this may not apply!) for players entering a new area. Upon entering that region I'd broadcast a RegisterLocalPlayerPacket to everyone in that area. When the player leaves the area you then just broadcast the opposite packet to everyone in that area.

Now you have the task of updating player positions. That's easy, you just take the players current position and subtract their last position. You can now do:
1  
player.setPosition(x - diffX, y - diffY);


Hope that helped.
Offline Reck

Senior Newbie





« Reply #6 - Posted 2012-12-04 09:42:11 »

Thank you all for some really great answers!

@saifix
I would really prefer not having such lists on the clients, it doesn't suit me very well that the client handles anything on its own.
The position system doesn't float, a player can jump from 1,1 to 16,15 at any time instantly, and the opposite as well :-)
However, your answer was in-depth, and i'm going to look more into your suggestions. Thank you!
Offline saifix

Senior Newbie


Medals: 1



« Reply #7 - Posted 2012-12-04 09:56:45 »

I understand your concerns, but, the client isn't handling anything on its own! The idea is that the position is kept server-side, here's pseudo-code for it:
1  
2  
3  
4  
5  
oldPosition = player.position;
player.position = get_new_position(player, input);
relativePosition = player.position - oldPosition;
updatePositionPacket.position = relativePosition;
player.send(updatePositionPacket);


The server is telling the client where to move to, not the other way around! You just feed the client data.
Offline theagentd

« JGO Bitwise Duke »


Medals: 366
Projects: 2
Exp: 8 years



« Reply #8 - Posted 2012-12-04 13:38:53 »

Even if you can technically send / receive 60Hz over the internet, you shouldn't.

In my experience, at those rates, it triggers your (well, my) ISPs abuse-protection algorithm, and your entire connection will be severely throttled, with latency consistently over 1000ms, even after the game is closed and you're pinging some 'neutral' server like google.com.

AS Cas said, 20Hz networking is the maximum update rate you should consider.

Wow, I seem to be having some pretty severe misconceptions about network coding... I've gotta say that I've never heard of an ISP ever do that though. I'm pretty sure when I'm seeding my, uhm, Linux kernels at 1MB/sec I'm sending more than 60 packets per second to the same IP. Seems more like a "problem" with your ISP than a universal problem. =P Still, sending updates that often might not be necessary. I'd still say that 20Hz is too slow for a twitch-based game. At 20Hz, you could get a maximum additional input delay of 50ms*2 (average 50 I guess). In total:

Keyboard/mouse delay (they usually only poll at 100Hz): 0-10ms.
20Hz send: 0-50ms
Network delay: 0-50ms.
Server processing: Say 0-5ms.
Server broadcasting at 20Hz: 0-50ms.
Rendering delay: 16.6 per GPU (usually 16.6*3 ms more due to the pipeline)
Monitor delay: 2-5ms.

Best case: Single GPU with a fast monitor on LAN and everything timed perfectly: 0+0+0+0+0+16.6+2 = ~20ms
Worst case: 10+50+50+5+50+16.6+5=186,6ms.

The worst case could be improved by 60ms to 126.6ms with a broadcast rate of 60Hz instead of 20Hz...

Myomyomyo.
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 847
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #9 - Posted 2012-12-04 14:33:27 »

About your worst-case: the input-delay doesn't have to go round-trip, so "Server broadcasting at 20Hz: 0-50ms" should not be added to input-delay. It's fire-and-forget. The client immediately takes action, it doesn't wait for the server to ACK the action (in FPS/realtime games).

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd

« JGO Bitwise Duke »


Medals: 366
Projects: 2
Exp: 8 years



« Reply #10 - Posted 2012-12-04 16:10:58 »

The client isn't allowed to damage other players in an shooting game. If they did, almost every fire-fight would end in both players killing each other which should be impossible with infinite speed ray bullets since both will be able to shoot a few shots at each other before the message that they've been killed reaches them. That's actually what a game called Wolfteam did. It was a horrible lagfest: You kill lagger. Someone else kills you. You respawn 5 seconds later. Lagger kills you instantly since his damage was so delayed.

In the CoD games this is impossible because you cannot damage an enemy if you're dead (with bullets, rockets and grenades obviously aren't affected). It's very easy to notice how they ensure that since hit-markers (a confirmation of your hit) appears after a very noticeable delay on laggy servers. In other words, a round trip is required for such a case. During that time, the enemy can run around and kill one or two of your friends even though he's already "dead". There's also the shooting around corners problem which will be severely enhanced by having delay.

Myomyomyo.
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 847
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #11 - Posted 2012-12-04 16:58:49 »

Very true points, but you're addressing a different problem. What you're describing seems like badly written server logic.

If the server deems player X killed by you, then the serverside logic shouldn't send any events (movement, bullets fired, etc) to any clients - it shouldn't process it at all. That way, you cannot be killed by a lagged bullet, after you respawn.

Anyway... clientside 'input latency' is visually not effected by network latency at all, but from the server's perspective, the 'client input latency' is increased by one-way latency (not round-trip). The 'gameplay latency' (when you see the (persistent) effect of what the server did) indeed involves round-trip latency, but that is not the same as 'input latency'.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline theagentd

« JGO Bitwise Duke »


Medals: 366
Projects: 2
Exp: 8 years



« Reply #12 - Posted 2012-12-04 19:17:23 »

Very true points, but you're addressing a different problem. What you're describing seems like badly written server logic.

If the server deems player X killed by you, then the serverside logic shouldn't send any events (movement, bullets fired, etc) to any clients - it shouldn't process it at all. That way, you cannot be killed by a lagged bullet, after you respawn.

Anyway... clientside 'input latency' is visually not effected by network latency at all, but from the server's perspective, the 'client input latency' is increased by one-way latency (not round-trip). The 'gameplay latency' (when you see the (persistent) effect of what the server did) indeed involves round-trip latency, but that is not the same as 'input latency'.
Yes, of course. That was obviously a server logic problem. I just spun off on a tangent for a bit. =S

I know that they aren't exactly the same, but I wanted to show you how big part that additional latency would be for the client. Of course a good game won't wait for the server to acknowledge things like looking around with the mouse or walking since that would be ridiculous, so "gameplay latency" is what is mostly affected by a low network send frequency. With proper interpolation you could make even 2Hz look smooth and fluent. Well, until you start actually interacting with the world and people start shooting you after you've run around a corner or killing you before they run out from a corner.

The current network model used by FPS games strongly promote aggressive game play since the one running around a corner coming out of cover has a considerable time advantage before his position is updated there. I should know, I am (or at least was) a master of abusing this in CoD.

Myomyomyo.
Offline pitbuller
« Reply #13 - Posted 2012-12-04 21:54:25 »

http://www.gdcvault.com/play/1014345/I-Shot-You-First-Networking

This presentation give really good overview of network latency and how to hide it. There is lots of good diagrams where is the lag and what ramifications it have in gameplay. There is also powerpoint version some where at http://www.bungie.net/inside/publications.aspx
Offline ra4king

JGO Kernel


Medals: 356
Projects: 3
Exp: 5 years


I'm the King!


« Reply #14 - Posted 2012-12-05 20:26:15 »

I guess I have to link my favorite article too now? Grin

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

Offline namrog84

JGO Ninja


Medals: 46
Projects: 4


Keep programming!


« Reply #15 - Posted 2012-12-05 22:07:21 »

I guess I have to link my favorite article too now? Grin

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

check reply#3, I had already beat you to it  persecutioncomplex
 Pointing  Tongue

"Experience is what you get when you did not get what you wanted"
Offline ra4king

JGO Kernel


Medals: 356
Projects: 3
Exp: 5 years


I'm the King!


« Reply #16 - Posted 2012-12-06 02:57:51 »

Gah! You thunder thief! Grin

Offline princec

« JGO Spiffy Duke »


Medals: 437
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2012-12-06 09:38:01 »

The devil is in the detail. The articles in question largely make it sound like you just do bish bash bosh and Bob's your uncle, instant networked game. It turns out that it's not really all that easy. Riven and I spent over two months just getting a couple of guys to run around on a gridbased map shooting at each other.

Cas Smiley

Offline masteryoom

JGO Coder


Medals: 5
Projects: 2


If you look closely, you might see it turning...


« Reply #18 - Posted 2012-12-06 10:02:31 »

You mean lightning thief?  Grin

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

Mr.CodeIt (24 views)
2014-12-23 03:34:11

rwatson462 (55 views)
2014-12-15 09:26:44

Mr.CodeIt (45 views)
2014-12-14 19:50:38

BurntPizza (86 views)
2014-12-09 22:41:13

BurntPizza (110 views)
2014-12-08 04:46:31

JscottyBieshaar (81 views)
2014-12-05 12:39:02

SHC (91 views)
2014-12-03 16:27:13

CopyableCougar4 (98 views)
2014-11-29 21:32:03

toopeicgaming1999 (157 views)
2014-11-26 15:22:04

toopeicgaming1999 (154 views)
2014-11-26 15:20:36
Resources for WIP games
by kpars
2014-12-18 10:26:14

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
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!