How can I achieve an exact same Physics projectile twice?

Post reply
0 favourites
  • 5 posts
From the Asset Store
Physics Ragdoll for Construct 3
$5.95 USD
Simple yet very life-like rag doll made with Physics!
dop2000's avatar
dop2000

  • Hi !

    Context: A real-time 1-on-1 Multiplayer game, imagine Golf.

    Player 1 hits, both players see the ball projectile at the same time. So, ball is synced. I'm using Photon, so I'm doing the syncing manually. Player 1 sees the actual motion, and Player 2, as long as both connections are decent, I could sync the ball nicely, and even interpolate x,y and add velocities to smooth out the motion near-perfectly.

    Problem: Often, players lag a little too much and it starts to glitch/skip. I want to get rid of lag-based problems completely by showing Player 2 an imitation (a projectile) of what Player 1 has hit.

    Although it's a real-time turn-by-turn game, but there could be a couple of seconds delay, which is fine as long as it looks smooth!

    Question: How can I re-create the exact same projectile of the Ball on the other end? There are many factors, especially after it lands and rolls on grass (the decrease in velocities, etc.). I assume there is no way to make the ball stop at the exact same position, twice, despite the same initial impulse/location.

    I was thinking is there any other way to improvise? e.g. I would do an Object-time scale and see exactly what happens in the future (within just 1 second). But how to re-create that on the other end?

    Or any other ideas?

    Thanks!

  • If the physics had a fixed time step and always did the same number of steps per second, then the same impulse would give the same result. Barring any differences in the number calculation from one machine or js engine to another.

    That said I’m not sure how close you can get to doing that. I think you can specify a fixed stepping with physics, but the number of steps per second is frame rate dependent.

    The term is called deterministic when the same result happens each time. Might help for googling general solutions.

    Off hand the solution I can think of is to do the physics with events. We just need a way to do a fixed time step, and always do x amount of frames per second. There’s an article online called “fix my timestep” that gives a way. The physics is beyond that. Anyways that’s probably the roll your own solution. There may be features that make that simpler.

  • One option, given that player 2 doesn't actually know when player 1 hit the ball in real life, is to not send the shot information to player two until it's completed. Then you'd be able to send information about the complete trajectory and end location all at once for player 2 to replay, in a sense.

    Another option is to not sync the ball location at all. Let player two run his own simulation based on the input of player one, and then update the final location to the actual one upon (or right before) coming to rest, whenever that information is available. The difference should be mostly imperceptible if both users are running the same physics engine.

    Basically instead of syncing the ball location at all times, only sync it at key moments, wherever it would be most effective to hide latency (I imagine the final resting position is the only real value of importance here). You can even add an ease/lerp/tween upon syncing the final location, to hide any unnatural looking jumps that might occur.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Thanks R0J0hound and Thank you oosyrag

    This gives me a lot of tricks to try.. I really like the idea to not sync at all until at the end, and/or if necessary sync at key intervals, perhaps on landing?.. I'm going to try these improvisations.

    Thanks again!

  • Even if you call it a real time game, as long as the players have no direct interaction with each other at any given time it is in effect no different than a turn based game. Which means syncing becomes a much lower priority, and you have tons of options to hide latency.

    Even if they do have to interact at some point though, it always helps to break down what information is most important to be consistent across players, and when is it necessary? Anything that has the potential to interrupt or change what is expected to happen from any players point of view needs consideration.

Post reply
  • 5 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)