Jump to content
  • Advertisement
Sign in to follow this  
XiotexStudios

Sync to level start

This topic is 4574 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, Has anyone come up with a good solution to sync to level start on a peer-to-peer net connection? What I want to achieve is that when the client and server are ready to go and actually play the game they both start at exactly the same point and that on both sides the level is completely loaded. The game I am working on is an 'arcade' type game so the initial sync is important. The current mechanism I have is both client and server send a 'level ready' packet out. On reciept both sides bounce this message back, when the bounced message is recieved each side proceeds to play the game. All was fine until I turned on my 'bad network' emulator and the server never got its bounced message but the client did and it proceeded to play the game without the server... Has anyone come up with a good way of getting around this?

Share this post


Link to post
Share on other sites
Advertisement
One really really really hacky way of getting around this problem I have come up with is that if I have a message that I really really want to get through then I send multiple copies off in the hope that one of them gets through. But tbh this stinks.

Oh, I forgot to mention that I am using UDP - but you should have been able to derive that :)

Share this post


Link to post
Share on other sites

what you would need is an UDP equivalent of TCPs ACK to check if the ready packet is received correctly. Or simpler: do the initial handshake over TCP, since the sync should be reliable anyway and is not time critical

Share this post


Link to post
Share on other sites
Well.. I am kind of emulating the ACK using UDP.

I would go down the TCP route except I don't want to deal with the TCP stack handling the timeout for me. By using UDP I can at least make a detirmination early.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
What you are describing is a rough problem.. you could do something like this:

Synchronize time between clients:

1. One client (the client who hosted the game) keeps a "master timer"
2. Before connecting a client starts his own timer.
3. When a client connects he sends out a "Time Sync" packet to the host.
This packet contains the value in the client's timer.
4. When the host recieves the time request packet, he sends a time response packet that contains: the value of his timer (the master timer), as well as the timer value that the client originally sent.
5. The client recieves this time packet from the host, and compares his current timer value, to the value that he originally sent (which the host sent back to him).
6. Subtracting his current timer, from the timer in the packet, the client can determine the round trip time of that packet.
7. The Client divides the round trip time in half (to get an approximation of the one-way latency)
8. The client then adds this one way latency to the host's timer value sent in the packet(the master timer value). This new value will be pretty close to the host's current time.
9. The client sets his current timer value to the master time value he has computed.

The client will keep sending requests until he gets a response from the host. Because all the info the client needs is in the response packet from the host, he doesn't really have to worry about dropped packets, he just keeps sending time requests until he recieves a response.

So.. when you want to start a game:

1. The host sends a message out saying he wants to start the game at a certain time in the future (some time in the future sufficiently greater than the average latency).
2. When the client recieves that message, he sends an ack that he will start at that time.
3. The host sends a response confirming the whole process.
4. the game starts at the predetermined time.

In this process, everyone needs to keep transmitting until they recieve the appropriate responses. You still may run into a false start condition, but if you give the clients several seconds to establish a start time, you will handle most cases.

Share this post


Link to post
Share on other sites
I've always thought this problem was interesting. It's basically a version of The Byzantine Generals Problem. The fundamental issue is that you can never be 100% certain that both sides are ready. You end up in infinite loops of "does A know that B knows that A knows that B knows...".

Share this post


Link to post
Share on other sites
Typically, you'll synchronize time by sending timestamps and measuring latency in each packet, and then agree on a start time a few steps into the future; when time synchronizes to that point, you start the game. This only needs a rough agreement on the progress on time, and will give you a start synchronization that's as good as your time synchronization (which is equivalent to your movement position synchronization).

Note that if the link is so unreliable you can't even synchronize time, then you can't play over the link, and thus the issue is moot.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!