Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Synchronizing Time Across Network RTS

Author
Message
bobba
16
Years of Service
User Offline
Joined: 10th Apr 2008
Location:
Posted: 2nd May 2008 06:34
I am working on an 8 player RTS. Players will communicate lock-step style with a peer to peer network. (I have a basic version working).

I currently need a method of running synchronized timers with millisecond accuracy on each player’s computer. I know how to get the system time using clock() and can convert it to milliseconds etc. I can start the timers in time by using the ping as a time difference to get them going in sync.

The problem I have is that the times are prone to drift meaning that timers running on septet computers will need to be kept in sync throughout the game.

In short how can I keep timers in sync on all computers playing the game?

Thanks in advance for any help or suggestions.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 2nd May 2008 16:56
I have an idea... but it might be stupid. Find a list of those Nuclear Clocks... online, and figure out how to get the time from those... You the difference between the user's system and the nuclear clock as a "GAUGE" and make all the clients use the same nuclear clock.

Each User would have their own time "offset"... and this can occassionally be "updated" by another call to the nuclear clock thing... say, every 15 minutes or even more.. because I don't think clocks drift that much... not enough for a game to get totally screwed.

Just rememebr you might want to implement such a device to work on more than one kind of nuclear clock server as one might go down etc.. and the user's shouldn't be aware the "Nuclear Clock of Choice" changed - it should be transparent...

If all the nuclear clock servers fail.. then resort to your home-rolled time syncer.

Just ideas - not necessarily the best idea. Frankly, your ping method is reasonable, and frankly, just doing a resync once in awhile might be more than enough and more reliable! (as you don't have to worry about the nuclear clock thing at all.)

Sephnroth
21
Years of Service
User Offline
Joined: 10th Oct 2002
Location: United Kingdom
Posted: 2nd May 2008 18:06
in network scenarios timers being wrong is not an issue because, usually, they just are. the trick is making people belive they are not. IE - doesnt matter if the timer isnt perfect as long as its the /same/ for everyone.

You need to have one person dedicated to time keeping. Usually this would be the game host. Obviously, with peer to peer, this would change if the designated host left - thats okay as long as there is just one person at a time designated as your time keeper. Then just sync to whatever that dude is running. Use your ping method and keep regular checks to make sure people are running in line properly and if they arnt request a sync update from the time keeper.

bobba
16
Years of Service
User Offline
Joined: 10th Apr 2008
Location:
Posted: 3rd May 2008 22:47
I had a look at the Nuclear Clocks thing. Unfortunately I could not work out the C++ commands. I saw this thing called NTP (network time protocol) on Google but could not make sense of it. Any c++ examples of how to use the NTP would be appreciated.

This is what I am going to try based on Sephnroth suggestion.

The player with the lowest player number will be master clock.

I am going to try making all players send out a time message to every player every 60 seconds. But players will discard the ones not from the lowest player.

When a time message is sent it will add half the ping to the time so that when the recipient receives the message it will show the time the recipient should have.

The recipient will then compare its time and the received time. Then it will record whether it was slow, spot on or fast It will then look at this result and the previous 2 recorded in the same way and if all 3 are slow it will add 1 ms and - 1 ms if all are fast.

This should allow the clocks to correct by 1ms per 60 seconds; I do not think clocks will drift by more than that so hopefully this should work.

Thanks to both of you for the suggestions BTW

Login to post a reply

Server time is: 2024-09-29 19:13:30
Your offset time is: 2024-09-29 19:13:30