Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Synchronizing physics, when physics is ran client-side?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 pjuke   Members   -  Reputation: 126

Like
0Likes
Like

Posted 24 April 2013 - 06:45 AM

I'm developing a web-based networked game using HTML5 and Box2D as physics engine.

The network communication is by Web Sockets.

 

Player A can spawn objects in the world, while Player B controlls an actor that can interact with them (jumping on them and such).

 

But here's the problem I've come across:

How do I synchronize the spawning objects from Player A, to Player B?

 

I mean. Imagine if Player B is running across the screen, and Player A spawns an object that is falling to the ground.

Now, due to the latency, the actor is running a bit behind on Player A's screen, and therefore, the spawning object might collide with the actor on Player A's screen. But in reality, the actor on Player B's screen have already run pass that point, and therefore, no collission.

 

It's a very basic game, but now I just realized I'm stuck and don't know how to solve it really.

 

I guess I have to do something with the server.

At the moment, the server only relays the messages between the clients, no physics or so is ran at the server-side. All physics is on client-side.

 

Thanks in advance! :-)



Sponsor:

#2 hplus0603   Moderators   -  Reputation: 5723

Like
0Likes
Like

Posted 24 April 2013 - 12:10 PM

There's no perfect solution, because the web introduces latency.
One common work-around is to make player movements have lag that depends on server round-trip time.
Thus, the player doesn't start (or stop) moving on the local screen until it gets the command from the server to do so.
This way, you know that the state on the server is always correct, and the state on the client simply mirrors the state on the server.
enum Bool { True, False, FileNotFound };

#3 pjuke   Members   -  Reputation: 126

Like
0Likes
Like

Posted 24 April 2013 - 12:44 PM

There's no perfect solution, because the web introduces latency.
One common work-around is to make player movements have lag that depends on server round-trip time.
Thus, the player doesn't start (or stop) moving on the local screen until it gets the command from the server to do so.
This way, you know that the state on the server is always correct, and the state on the client simply mirrors the state on the server.

So if I got this correct, both players needs the server to tell the player to move. That is, even when the user press' the forward key, the actor wont start to move until it gets the response from the server? Like the first Quake game, with no client-side prediction?

 

I see that solution would work, but I need immediate response from inputs tho. Especially from the player which spawns objects.

I'm currently using a jitter-buffer on the receiving side, so it is already a little bit of excessive latency going on.

 

Thank you very much for replying anyway.

Do you know any other 'common' solution?



#4 hplus0603   Moderators   -  Reputation: 5723

Like
0Likes
Like

Posted 25 April 2013 - 12:43 PM

The other common solution is to detect inconsistencies and "snap" the player.
enum Bool { True, False, FileNotFound };




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS