Syncing Deterministic Events
Author
I'm having trouble keeping weapon shots/hits in sync.
My client runs ahead of the server. It keeps a command history, and when it receives an update, it snaps me back, resims my commands, and smooths out any errors. Works fine.
For missiles, I don't want to sync them. So, each update I roll the weapon state back to where it was after the last update, sim my command history as usual, and save the weapon state for next tick.
Unfortunately, the prediction errors that are no problem to smooth out even with high ping and a low update rate are glaringly obvious with fast-moving projectiles.
What should I do here? Should I just let the client think it's missiles are accurate? Playing around with 400ms fake ping, moving around shooting a stationary target, I'm getting approx 1 false-positive hit in 10 on the client. No doubt that'll be more with 2 moving players.
Is it a big deal to see the occasional missile hit your target without exploding? Or explode and do no damage? It's a persistent world, so I want as many clients as possible--so strict bandwidth limits.
Why don't you want to sync missiles? Because they're moving too fast? I presume you treat slower weaponry objects like grenades and perhaps rockets as standard objects to be synced?
I think most games don't bother to sync bullets and just accept that you will get some false hits/misses at high latency. You don't notice that unless you're a developer and looking out for it :p. If it's an action game no-one's going to be playing it with a ping over 250 anyway (because they'd get raped and not enjoy it).
I think most games don't bother to sync bullets and just accept that you will get some false hits/misses at high latency. You don't notice that unless you're a developer and looking out for it :p. If it's an action game no-one's going to be playing it with a ping over 250 anyway (because they'd get raped and not enjoy it).
Author
Well I'm trying to avoid sending even slower projectiles over the net. Since each projectile can only ever interact with the environment once (to explode or die), I was hoping to get away with it. Something like grenades that bounce around would be synced. Managing updates for 100 players is one thing...when they can each have a dozen projectiles in the world at once...
Quote:Original post by CadetUmfer
Well I'm trying to avoid sending even slower projectiles over the net. Since each projectile can only ever interact with the environment once (to explode or die), I was hoping to get away with it. Something like grenades that bounce around would be synced. Managing updates for 100 players is one thing...when they can each have a dozen projectiles in the world at once...
If projectiles don't interact with the environment does this mean that their fate is predetermined? That you can know at launch, whether they will explode or die?
Why not just send this with the projectile state when it launches, and just do it when the time comes? Or is it not that simple?
Quote:Original post by gamedev199191
Why not just send this with the projectile state when it launches, and just do it when the time comes? Or is it not that simple?
Ya, just notify when the projectile fired to each client. Each client simulates it & the resulting explosion. Server sends out an official notice of who took damage, in case the client simulation was off.
If it's a seeking projectile, target would be part of the initial notification.
-me
Quote:Managing updates for 100 players is one thing...when they can each have a dozen projectiles in the world at once...
Is it likely that all 100 players would be in the same region of the map and therefore need to see each other's updates? Standard FPS mechanics can handle at least 32 players so I doubt there is a problem here.
Alternatively, if you're running a client side simulation you could run a completely deterministic simulation on all clients and send commands around. See that infamous '1500 archers on a 28.8 modem' article which is linked from the FAQ. I don't think this works that well for a FPS type game though, and I don't think you'll use enough bandwidth to need it.
Author
Quote:Original post by PalidineQuote:Original post by gamedev199191
Why not just send this with the projectile state when it launches, and just do it when the time comes? Or is it not that simple?
Ya, just notify when the projectile fired to each client. Each client simulates it & the resulting explosion. Server sends out an official notice of who took damage, in case the client simulation was off.
Yeah, that's what I was doing. But each client would predict its own shots (not the hit, just launch the projectile immediately and wait for the server to confirm the hit).
Problem is it's too sensitive to prediction error. If my client position is even a little bit off when I fire, by the time the server corrects it (by giving me the correct position so I can resim the projectile), the missile could be quite far off.
Hm. Guess I need to either take a bandwidth hit, let the client rendered missiles be a little off, or make the client wait and not predict its shots.
400 ms is kinda high. I wouldn't play Quake III with anything more than 100-150ms latency. How does it behave with those sort of latencies?
With the deterministic prediction / command stack rewind, you should get better accuracy in a static environment though.
EDIT :
Well, that seems to be the problem. The thing with the prediction / correction, is that the deviation, without external influences, should be infinitesimally small (if you run sims on different CPUs), to either non-existent (if the two machines are identical, i.e. consoles).
The determinism is quite important, although not 100% necessary, to get a good prediction. If your client and server simulation deviate with no introduction of external factors (other players), even under large latency, then you may have a problem with getting accurate results, as well as the server having to send corrections much more often.
I've played with a similar system before, the first thing we did was to get the prediction / server simulation 100% in sync. They deviated only with the introduction of other player / unpredictable events.
With the deterministic prediction / command stack rewind, you should get better accuracy in a static environment though.
EDIT :
Quote:
Problem is it's too sensitive to prediction error. If my client position is even a little bit off when I fire, by the time the server corrects it (by giving me the correct position so I can resim the projectile), the missile could be quite far off.
Well, that seems to be the problem. The thing with the prediction / correction, is that the deviation, without external influences, should be infinitesimally small (if you run sims on different CPUs), to either non-existent (if the two machines are identical, i.e. consoles).
The determinism is quite important, although not 100% necessary, to get a good prediction. If your client and server simulation deviate with no introduction of external factors (other players), even under large latency, then you may have a problem with getting accurate results, as well as the server having to send corrections much more often.
I've played with a similar system before, the first thing we did was to get the prediction / server simulation 100% in sync. They deviated only with the introduction of other player / unpredictable events.
If your letting you client run ahead of your server this is inevitable since the authoritative event will always occur after your local simulation and your best guess is that it will match up somewhat with the authoritative simulation.
You can mitigate this by letting your clients send as much initial state information as possible about the event so the sever can simulate it as closely as possible, but this gives the client too much power IMO and is prone for haxing.
Why not run your clients behind the server and let the server be the one running in the future time. This can all be covered up with animation and interpolation tricks of course so the local user cannot tell that the event hasn't even started on his local machine. A missile launch animation can take about 1 sec, gives you time to sync with the server, which will not delay the event like the local user. It then can simulate the event which on the users machine is in the future time. So when the event terminates on the server it shouldn't have happened yet on the local users machine. When they receive the hit message form the server it should, if you've done your timing right, arrive just in time or close too it.
It's all smoke and mirrors really, tricks with timing, animation, strategic delays to give the underlying mechanics working time within an asynchronous latent messaging scheme.
Good Luck!
-ddn
You can mitigate this by letting your clients send as much initial state information as possible about the event so the sever can simulate it as closely as possible, but this gives the client too much power IMO and is prone for haxing.
Why not run your clients behind the server and let the server be the one running in the future time. This can all be covered up with animation and interpolation tricks of course so the local user cannot tell that the event hasn't even started on his local machine. A missile launch animation can take about 1 sec, gives you time to sync with the server, which will not delay the event like the local user. It then can simulate the event which on the users machine is in the future time. So when the event terminates on the server it shouldn't have happened yet on the local users machine. When they receive the hit message form the server it should, if you've done your timing right, arrive just in time or close too it.
It's all smoke and mirrors really, tricks with timing, animation, strategic delays to give the underlying mechanics working time within an asynchronous latent messaging scheme.
Good Luck!
-ddn
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
