Jump to content
  • Advertisement
Sign in to follow this  
Idov

Mobile multiplayer game

This topic is 921 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,
I want to develop a mobile multiplayer game. (P2P - clients will communicate directly).
There won't be much data sent from one player to the other, but when there will, I'd like the change to appear in the devices at exactly the same time.

 

If player 1 presses a button, I thought  to change his game state only after player 2 received and confirmed that he received the data, but then player 2's will be updated before player 1's...

Is there a way to get the state to change at exactly the same time?

Thanks! smile.png

Edited by Idov

Share this post


Link to post
Share on other sites
Advertisement

There are two problems here. One is to synchronize wall clock time, either by using a centralized reference (say ntp), or to guessing from the round-trip time between the clients. The other is synchronizing simulation time, which is solved by using a lookahead. If player 1 presses a button at simulation time T, the change is scheduled to take place at time T+D where D is sufficiently large to be sure that this information has been transmitted to player 2.

Share this post


Link to post
Share on other sites

There are two problems here. One is to synchronize wall clock time, either by using a centralized reference (say ntp), or to guessing from the round-trip time between the clients. The other is synchronizing simulation time, which is solved by using a lookahead. If player 1 presses a button at simulation time T, the change is scheduled to take place at time T+D where D is sufficiently large to be sure that this information has been transmitted to player 2.

Ok, but don't I need to make sure that player 2 received that message?
(I read that multiplayer games usually use UDP and not TCP...)

Share this post


Link to post
Share on other sites

Yes, that's a third problem to take care of. If you use UDP you need to detect missing messages and make sure to resend them, while TCP takes care of this and guarantees to deliver the message eventually. But note that even if you use TCP you don't actually know *when* the message will be delivered, only that it will. So if absolute wall-clock synchronization is a requirement, you're right, you need to wait for that acknowledgement. (For games this requirement is usually relaxed, consistency and responsiveness is usually more important than absolute synchronization.)

Share this post


Link to post
Share on other sites
The people are in different parts of the universe, and thus there exists no "exact same time." This is a simple matter of general relativity.
You might think the speed of light (and electrons) is fast, but once you involve the internet, it turns out, you have to design for this.
If the game is of the form "let whomever reacts first, wins," then you have to pre-schedule the presentation time, and measure it on each client, and send that measurment back.
If the game is of the form "let whomever runs over the health pickup first, gets it," then you will likely want to involve a central game server, and use various kinds of latency compensation to make the game mostly appear fair -- but there will be cases where some player sees something that didn't happen.
Only if you can accept a full round-trip-time of latency before the game simulation results show an actual action from a given game command, can you avoid those discrepancies.
Most RTS games do that -- they hide the latency with a "Yes, Sir!" animation before actually moving the commanded units.

So, what, exactly, is your gameplay? You have to design your game networking and simulation to match the gameplay you want, and there are game kinds that cannot be built over the internet, unless you accept that some player will sometimes see "snapping" or "impossible events."

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!