Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Say I'm having a multiplayer RTS game. There's a main server for each individual game and several clients connected to it. All packets are sent to server first and then server retransmits them back to specified clients.

I'm thinking of 2 ways:

  • List of Client-Server pings, which will be the same, no matter which Client asked for it
  • List of Client-Client pings, which will vary for every Client

My question is how should I calculate and display ping info to players?

I will add more details to my question if necessary

share|improve this question
add comment

1 Answer

up vote 4 down vote accepted

Client to Server ping: This one's pretty easy. Simply timestamp your packets and find the difference between the times when the packets arrive. Take the average of these times over some period (say 1 second) and that's your lag from Client to Server. As far as display, that's totally up to you and your game layout. In general, it's a good idea to display lag as part of the "score breakdown" screen, where each player's public information can be accessed. Also, you may consider color-coding lag levels; such as green for <100ms, yellow for <200ms, and red for 200ms+.

Client to Client ping: I'm not sure this is implemented very often, and probably for good reason: it's unimportant. Actually, ideally, there is no Client to Client ping because there is no Client to Client interaction; all interaction takes place on the Server. If you did have Clients connecting to each other, you would probably display that information in much the same way you would as a Client to Server connection. However, if you wanted to display ALL of the pings between ALL of the Clients, a table would work.

Hope that helps!

share|improve this answer
    
there is just a thing about client-server ping time, when you want to calculate client latecy, it's common to send a packet and check when it's respons returns, it's called responce time and that's what accualy matters. and by the way since all your packets run through a single server there's no benefit knowing client-client ping times since it's always sum of the two client's ping times. –  Ali.S May 14 '11 at 12:45
    
Means total game lag will be sum of two biggest pings. I can use it for gameplay flow control. Nice. –  Krom Stern May 14 '11 at 15:21
1  
Well, there you go. To sum up once again: send a packet from Server to Client and track it's round trip time. Average over some finite interval, and there you have it. Client to Client time is unimportant but can be approximated by summing Client pings. –  Grimless May 14 '11 at 20:11
1  
If you use the "Simply timestamp your packets and find the difference between the times when the packets arrive" approach, you will still get to solve the problem of sync between the client and server clocks. It's not better to send a packet to server, wait for reply, and then calculate the delay of the client-server-client communication? Please, correct me if I'm wrong. –  user11012 Nov 7 '11 at 13:10
    
Indeed it is better to track round trip time instead of timestamping because of syncing issue. Nice catch Yuri. –  Grimless Nov 7 '11 at 19:30
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.