there are networked games that use determinism and lock-steps to reduce bandwidth. It's also a great anti-hack, since everyone will share the same deterministic state, you can verify data checksums and make sure everyone's in sync.
So really, there is a case for having all players share the same FPU precision and making sure they achieve the same result. And the innacuracies you see with floating point will not matter when that is the case, they will all share the same innacuracies, but they will remain in sync, they'll all be 'wrong; equally.
.01f != 0.0099999998 !!!!!!!!!!
Quote:Original post by WashuQuote:Original post by Daniel MillerQuote:Original post by HodgmanQuote:Original post by Daniel Miller
If you need to keep two clients in sync without a central server, is fixed point the only option?
No. There's no problem with using floats, as long as you don't make assumptions that require them to be exactly perfect to X decimal places. Does it matter if one client thinks an object is 0.0000003 metres to the left of where it actually is?
Very much so, if that causes a shot to become out of range so a unit doesn't die. That unit might kill a third unit, which would have killed a fourth unit, etc. In a RTS, things could spiral out of hand quickly.
That should all be computed on the server, which would know the true values (since the server should be in charge of those values, not the client).
RTS games don't have a central server that deal with that information, each game runs in parallel on all players' computers.
Quote:Original post by Daniel MillerQuote:Original post by Washu
That should all be computed on the server, which would know the true values (since the server should be in charge of those values, not the client).
RTS games don't have a central server that deal with that information, each game runs in parallel on all players' computers.
No. That's simply a design decision that was opted to be made by most RTS games, it is not a requirement at all. Never the less, the issue isn't nearly as bad as you think, since you should be using deltas for comparison. Thus even if the unit thought it was 0.0000003 off from where it really was, the delta would more than make up for that.
As for the OP: Some numbers cannot be represented in base 2 systems, just like some numbers cannot be represented in base 10 systems. 1/3 is a prime example of a number that cannot be represented exactly in a finite decimal notation. (note that when you extend this to an infinite number of digits you find that you can represent any rational number in either system).
I would wager that even RTS games give server authority over hits and deaths. Most it probably wouldn't matter, but a game like Supreme Commander that simulates every shot it probably does.
Quote:Original post by DrEvil
I would wager that even RTS games give server authority over hits and deaths. Most it probably wouldn't matter, but a game like Supreme Commander that simulates every shot it probably does.
Because there are so many units, having a central "server" that deals with logic would be too expensive. Supreme Commander uses the same approach as all other RTS games.
Washu: I would think that even if you use an epsilon, the discrepancy could (after a long game) cause everything to de-sync. Plus, if something lies on the "edge" of the epsilon, it could de-sync rather quickly. You are obviously a more knowledgeable programmer than I am, so am I wrong here?
Quote:Original post by Daniel Miller
Washu: I would think that even if you use an epsilon, the discrepancy could (after a long game) cause everything to de-sync. Plus, if something lies on the "edge" of the epsilon, it could de-sync rather quickly. You are obviously a more knowledgeable programmer than I am, so am I wrong here?
You forget that the errors will work both for and against each unit. In the long run the cummulative effect of these errors will cancel out. Some basic precautions should be taken to prevent things the error delta from growing, such as calculating new positions from an absolute origin (instead of moving relative to the last position, which would cause the error of the last move to accumulate with the error of the latest move).
Quote:Original post by WashuQuote:Original post by Daniel Miller
Washu: I would think that even if you use an epsilon, the discrepancy could (after a long game) cause everything to de-sync. Plus, if something lies on the "edge" of the epsilon, it could de-sync rather quickly. You are obviously a more knowledgeable programmer than I am, so am I wrong here?
You forget that the errors will work both for and against each unit. In the long run the cummulative effect of these errors will cancel out. Some basic precautions should be taken to prevent things the error delta from growing, such as calculating new positions from an absolute origin (instead of moving relative to the last position, which would cause the error of the last move to accumulate with the error of the latest move).
What do you mean "will work for and against"? If I unit is killed when it shouldn't have been, I don't see how anything can make that up.
Sorry for all of the questions, I'm not trying to be annoying.
Quote:Original post by Daniel MillerQuote:Original post by Washu
You forget that the errors will work both for and against each unit. In the long run the cummulative effect of these errors will cancel out. Some basic precautions should be taken to prevent things the error delta from growing, such as calculating new positions from an absolute origin (instead of moving relative to the last position, which would cause the error of the last move to accumulate with the error of the latest move).
What do you mean "will work for and against"? If I unit is killed when it shouldn't have been, I don't see how anything can make that up.
Sorry for all of the questions, I'm not trying to be annoying.
The chances of an error being such that one critical shot will be the one that kills the unit is fairly small, but even assuming that happens... there will also be a time such that a shot would have killed a unit but was off by just enough that it lived. Again, the errors cancel out in the long run.
In networked games, when you solve the latency issue you simultaneously solve this "problem."
What I believe Washu is saying, and I was going to chime in and say is..
Let's say at one point, the position is .000003 more than it should be, then the next move might be .000003 les than it should be, thus balancing things out.
It works like this for my game... I update the 'target position' of the unit, and it automatically walks to that location, moving its true position by the given speed. It doesn't work out to be perfect, and so it will get 'close enough' and either be a bit less or a bit more, and it fluctuates all the time.
edit:
See how it will be 0.0084 off, but this little cycle is guranteed to close enough to the target position (within the move distance, in this case, 0.1233)
Let's say at one point, the position is .000003 more than it should be, then the next move might be .000003 les than it should be, thus balancing things out.
It works like this for my game... I update the 'target position' of the unit, and it automatically walks to that location, moving its true position by the given speed. It doesn't work out to be perfect, and so it will get 'close enough' and either be a bit less or a bit more, and it fluctuates all the time.
edit:
true position target positionframe 1 0.0 1.0frame 2 0.1233 1.0frame 3 0.2466 1.0frame 4 0.3929 1.0frame 5 0.5152 1.0frame 6 0.6385 1.0frame 7 0.7618 1.0frame 8 0.8851 1.0frame 9 1.0084 1.0See how it will be 0.0084 off, but this little cycle is guranteed to close enough to the target position (within the move distance, in this case, 0.1233)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
