Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Like Warcraft of World, there is a clock to display the time of server rather than local time of the client.

How to do this?

If this can be done by server send only one package to tell client the current timestamp of server, then client based on this timestamp and goes tick on it, what if client have not a "reliable clock" such as Flash(clock will slow down when the FPS slow down)

share|improve this question
How accurate do you want the time to be? – Luis Estrada Feb 13 '13 at 14:21
theres actually a game called "warcraft of world" or is that a flipped name? – GameDev-er Feb 14 '13 at 0:30
-1 for "What if". Ask the question you care about. If you're making a game in flash and maintaining clock sync with a remote host is a problem for some reason, then ask that question. Don't append it as a "what if" on some other question. – Trevor Powell Feb 14 '13 at 1:20
up vote 0 down vote accepted

According to Adobe, Flash has a "Date.getTime()" function which returns the current local time, as set on the computer running the Flash application.

This should make it trivial to show the server time, regardless of frame rate or other factors. When you know the server's time, subtract the local time from that in order to know the offset from local time to server time. Then whenever you want to know the server time, you can just add that same offset to the local time. Frame rate doesn't come into it at all.

share|improve this answer
What if user change system datetime manually? Is there a way to get a new offset value between server and local? If there is a callback function or event to tell app, that will be easy – jean Feb 14 '13 at 8:15

Ok I don't know about World of Warcraft or their implementation. Taking average network jitter and delays into account you don't get a very accurate reading about time from the server. (That is why NTP is difficult.)

If all you want to display is the server time, you just need to send the server's time and add the current round trip time to get a rough but around 100ms accurate time. From there you use the systems clock. Sure the systems clock drifts, but we are talking a few seconds a day at worst.

If you are thinking about actually using the servers clock for more accurate time reading or logic, I would strongly discourage you from that. You should use the local system clock as time of reference and work with time deltas based on that.

I am not sure what you mean by reliable clock. Everything above 1s is handled by the system clock with is a separate timekeeping IC which runs of of a quartz, like any other clock. Anything below 1s runs of the CPU ticks and they are very reliable, the CPU would not work if it was not the case. We are talking picosecond accuracy. You get reliable time readings down to 1ms easily. Just so I don't get grilled for it, the system clock IC actually runs more acuratly and the CPU uses that to sync up it's tick rate, wich is a multiple of the system clock tick.

So why does the time slow down while low frame rate? Do you mean simulation time as opposed to real (wall) time? In that case you have other problems to handle, like what happens when different clients have different time dilation. But the way I see it is that the server is the only authorative instance and the client only do prediction. The prediction is off by multiple 100ms anyway through network jitter, so time keeping is the least problem. It also helps to make client prediction and effect simulation frame rate independent. Sure it reduces accuracy, but on the client any simulation should be only for a smother experiences.

share|improve this answer
I say slowdown because some flash programmer tell me timer in flash is not accurate. After I read flash doc I found it is irrelative to maintain a datetime. As you said the datetime retrieved from OS should be reliable. – jean Feb 14 '13 at 8:10

The packet to update the clock doesn't need to critically match the FPS of the client. Depending on the network protocol, or the packet structure itself, it would be enough to send a tick once every second. In most cases, the timestamp of the packet itself can be used to match the second tick of the server.

So, async or sync packets who have a timestamp, where the part identifying the "second" can be used to inform the client. Even if there are multiple packets sent each second, any of them can be used to extract the timestamp of the server.

There doesn't need to be a specific time update packet from the server each second, is what I'm trying to convey.

share|improve this answer

Generally the server clock is there for convenince to the user so being out by 30 seconds to a minute is not so bad.

If your building a game with say 1000 users, the last thing you want to be doing is sending 1000 NTP style messages every second or minute (unless you want to be super accurate).

Seeing as every computer has its own clock. When a user logs on, you can send your own time to the user, determine the offset between the server clock and their clock. and then just use thier clock + the offset to show the server clock.

I would not use timezone calculations as a clients computer may be fast or slow or just wrong. however if you calculate an offset, unless they go and change their clock, it will always show the correct time.

share|improve this answer

Your Answer


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.