If I make sure that the FPU always runs in single precision mode (24 Bit), will I be able to assume that the results will be equal?
I know that the physics engine which I use (Newton) and also Direct3D switch to that mode.
If it's not going to be deterministic that way, then I got a serious problem.
Multiplayer Physics
Quote:Original post by vokuhila
b)
If the clients receives an update that is let's say 100 ms behind real time, the simulation that the player sees has to rewind to that position. Based on the inputs he did the last 100 ms, the simulation then has to catch up to real time again (everything happening in one frame).
I know that sounds like quite expensive, but I run the physics constantly at 60 fps, so in the worst case there would be 180 updates per second, which should be OK for modern CPUs.
Could you please explain that to me? I use a similar System, but is your worst case only 180 Updates per second? Assume, for example, that two players on the server have a ping of 500ms, so it takes about half a second for their inputs to reach each other (if you also send the inputs to each other, it would take a less time, but higher pings than 500 are also possible).
You would have to rewind their simulations for 30 steps each time they receive a new input, which would mean (if you also sample client input at 60Hz) that you have to do 60*30 = 1800 Updates per second. Did I get something wrong?
No, I think you are right. I didn't think about it in detail, the 180 fps were just a quick estimation. *feel ashamed*
However, you don't need to re-simulate the game whenever you got one single frame from the other computers. It might be sufficient to do this every 500 or 1000 ms. Depends on how good the extrapolation works.
I'm not good at planing things (you guessed it), so will just have to try it. I'm sure there will be a lot more problems with this technique that I don't see yet.
However, you don't need to re-simulate the game whenever you got one single frame from the other computers. It might be sufficient to do this every 500 or 1000 ms. Depends on how good the extrapolation works.
I'm not good at planing things (you guessed it), so will just have to try it. I'm sure there will be a lot more problems with this technique that I don't see yet.
Quote:I use a similar SystemCan you tell a little bit about that?
Quote:I'm not good at planing things (you guessed it), so will just have to try it.
I don't want to sound snarky, but if you haven't actually finished the system, and haven't actually solved the hard problems with it yet, how come you recommend the approach to another poster? You might want to qualify your recommendations with why you're recommending them, and how much of it you've actually done yourself, when you post. People will find that helpful when trying to make a decision of their own.
In general, you don't want to re-simulate. Instead, you have to accept a round-trip latency before commands take place (used in RTS games), or do really fancy things with time frames (and time travel) during interactions (such as the system we patented for There). An alternative is to accept the simulation being out of sync, and instead send state snapshots every so often. You probably want to "trend towards" the state of the snapshots, rather than "snap to" that state, btw, to avoid too much snapping.
I'm sorry, I just re-read my first post and it really sounds like an advertisment for the solution. But it was just meant to be an idea for physics in network.
However, at least I got some useful information from the discussion :p
However, at least I got some useful information from the discussion :p
How about updating objects whenever their velocity changes? This could be when a player moves an object or when objects collide.
If you have a deterministic model, the objects should smoothly interpolate to that new state.
It might also be neccesary to update object states at a low rate when their velocity doesn't change, to make sure they don't get out of sync too much.
If you have a deterministic model, the objects should smoothly interpolate to that new state.
It might also be neccesary to update object states at a low rate when their velocity doesn't change, to make sure they don't get out of sync too much.
@ronkfist: That's the traditional DIS model. DIS is an international IEEE standard, although I wouldn't recommend it for game development.
Quote:
or do really fancy things with time frames (and time travel) during interactions (such as the system we patented for There).
Never heard about these time frames and how they apply to lag hiding in multiplayer games... any pointer to where I could find more info about that technique?
Quote:Original post by Anonymous PosterQuote:
or do really fancy things with time frames (and time travel) during interactions (such as the system we patented for There).
Never heard about these time frames and how they apply to lag hiding in multiplayer games... any pointer to where I could find more info about that technique?
I think it's pretty well described here.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
