Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm writing a game that has a lot of time based aspects. I use time to help estimate player positions when the network stalls and packets aren't going through (and the time between packet's being received and not). It's a pacman type game in the sense that a player picks a direction and can't stop moving, so that system makes sense (or at least I think it does).

So I have two questions: 1) How do I sync the clocks of the games at the start since there is delay in the network. 2) Is it okay NOT to sync them and just assume that they are the same (my code is time-zone independent). It's not a super competitive game where people would change their clocks to cheat, but still.

The game is being programmed in Java and Python (parallel development as a project)

share|improve this question
7  
look up ntp –  ratchet freak Jun 17 '13 at 1:56
5  
I'm sure this question is covered already on gamedev.stackexchange.com, or at least it belongs there. –  congusbongus Jun 17 '13 at 2:06
1  
@CongXu: I am not so sure. While this is task usually done for games, it is not inherently specific to game development. Many other distributed systems need synchronized clock. –  Jan Hudec Jun 17 '13 at 9:27
2  
Have you already tried to use the IPv4 option TIMESTAMP? More info is at linux.die.net/man/7/socket from there to linux.die.net/man/3/cmsg and then a small example program at pdbuchan.com/rawsock/rawsock.html the last one before the IPv6 section. –  ott-- Jun 17 '13 at 11:22
2  
Games (applications) should not touch the system clock. –  Martin Schröder Jun 18 '13 at 10:39

3 Answers 3

I think it is definitely not OK to synchornize the clock in the system. User does not expect you to touch the system settings and many systems won't even let you to.

All you need is to have a correlation to convert timestamp from one side's clock to the other side's clock. On the other hand you need this correlation to be rather precise, say at least to a hundredth of a second, if you want to use it for predicting player positions. System clock won't ever be this well correlated between random machines. So you should establish the correlation yourself, using some variation on the NTP theme, probably embedded in your other messages to conserve network bandwidth.

The basic idea might be that with each packet you sent out timestamp you sent it and sequence number of and timestamp when you received last packet from the other side. From this you calculate the roundtrip: For example if packet Q says it was sent at 1000 and packet P was received at 500, than given you sent packet P at 0 and are receiving Q at 800, the round-trip is (800 - 0) - (1000 - 500) = 300. There is no way to know the assymetry, so you just assume the packet takes half (150) ticks in either direction. And that remote timestamp is ahead of local by 1000 - (800 - 150) = 350 ticks. The round-trip will vary. If you assume the clock are reasonably precise, you should use a long-term average of the correlation.

Note, that you don't want to use system clock for the clock either. They may get resynchronized midway, throwing you off track. You should use clock(CLOCK_MONOTONIC) on Unix or GetTickCount on Windows (not sure how those APIs are wrapped in Java or Python right now).


Note: The SO_TIMESTAMP socket option (see socket(7) mentioned by ott-- in comment on the question) would be useful for separating out the effect of latency of the event loop that receives the packets. Whether it's worth the effort depends on just how good precision you need.

share|improve this answer

How do you know which player's clock is correct? You don't, so use a reference clock.

NTP is overkill here - you only need ~1 second accuracy - so use rdate or pick something from one of many clock synchronisation algorithms.

One you've chosen a method, get each player's machine to pick up the time per that method (without changing their system clock). Whatever difference there is between the reference UTC time and the players' system clock UTC time is their effective offset. Any time you do time-related calculations to e.g. extrapolate bot movements or ray-trace bullets, you factor in this offset after getting the system time. Using UTC will eliminate timezone factors.

share|improve this answer

I second statements that you should not be using NTP or going near the system clock for this. If you actually examine this requirement, you're going to find that you have the following needs:

  • How much time has elapsed since the previous frame so that you can advance any time-based stuff. This may be different on client and server if both tick at different rates (e.g. you may sometimes see servers that run at a fixed 20Hz (or whatever) but clients that are allowed to run as fast as they wish).
  • How much time has elapsed since the current map started. This is a zero-based timer (just init it to 0 on both client and server when they start up) and the server time is considered the "master", so the server sends it's current view of this time to the client for each frame that runs on the server. This can be got by either taking the current server time and subtracting the time at which the server started, or by accumulating the per-frame times above. The client-side per-frame time above can also be used to generate interpolation points between any two consecutive server frames.
  • A reference "base time" from which all other time advances; this can be (but does not absolutely need to be for all game types) the same on both client and server and is initialized at the start of the game (or current map) but never changed after (unless a new game - or new map - is started).

This is a simplified outline - I don't attempt to deal with issues such as latency/dropped packets/etc - but it is the basic framework on which the whole thing should be based.

None of this needs to go near the system clock or be concerned with matters such as different time zones, although the last item may use a time zone if desired. The important thing is that the actual elapsed times are measured using a high-resolution zero-based timer, so they're completely agnostic to time-zone differences. Want to find actual current time on the server? Just add it's elapsed time to it's reference base time and you've got it. Likewise for the client.

share|improve this answer

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.