3 ms·

I am one of the authors of Fire Fight game, which had the same multi-player model as Doom. Main source of multi-player sync loss was a different number of rand

I am one of the authors of Fire Fight game, which had the same multi-player model as Doom. Main source of multi-player sync loss was a different number of rand() calls between machines e.g. a different animation sequence for own character vs enemy. If own animation calls one rand() too many, the next common rand will return diff values on own vs enemy machines. And you essentially start playing two different games together ;-) That being said, we fixed all bugs. There were no additional checks to synchronize state other than keyboards. It was way easier than we anticipated! Good times!

TheLoneWolfling 12y ago
That was what, 1996? Unfortunately, many of the edge cases that cause non-deterministic behavior have gotten substantially more exploited by compilers since then.
- limaoscarjuliet 12y ago
  I really want to disagree. Assuming the code is correct: - proper handling of system calls and EINTR, - do not call illegal functions in signal handlers, - proper synchronization to avoid race conditions, - etc. it will work just fine. The problems with today's systems does not lie in compilers. It lies in vastly increased complexity of the code itself. Back in 96 we had a few sprites, with some animation sequence, sound effects. State of an object was kept in a few integers. Collisions were done using really stupid algorithm that would probe special mask in level builder with a circle consisting of 16 points, so we can get a vector pointing away from the wall. Etc. Today, collisions, physics, presentation - all this is thousands of times more complex. More code, more bugs, more issues. For that reason, it would be very difficult to write keyboard-state driven multiplayer today.
  - TheLoneWolfling 12y ago
    Ah, you weren't using floating-point. That makes things substantially easier. W.r.t. floating-point, good luck. See https://news.ycombinator.com/item?id=9430958 https://news.ycombinator.com/item?id=9430958
    - limaoscarjuliet 12y ago
      Ah, yes, you are correct. We built our own fixed point library.
megablast 12y ago
Couldn't you reset the rand every now and again, without too much of an effect. Such as every 10 seconds? For every machine.
- limaoscarjuliet 12y ago
  Nope. Once the sync was lost, you were playing two different games: player A on machine A is in room 1, player A on machine B is in room 2. Resetting rand sequence would not correct the introduced error. The only way to correct such error would be to change model to sync the actual state among machines. But that means completely different code. All in all, I remember we added the multiplayer code at the very end. If we decided to sync state rather than exchange keyboard+mouse, we would not finish on time.

TheLoneWolfling 12y ago

That was what, 1996? Unfortunately, many of the edge cases that cause non-deterministic behavior have gotten substantially more exploited by compilers since then.

limaoscarjuliet 12y ago
I really want to disagree. Assuming the code is correct: - proper handling of system calls and EINTR, - do not call illegal functions in signal handlers, - proper synchronization to avoid race conditions, - etc. it will work just fine. The problems with today's systems does not lie in compilers. It lies in vastly increased complexity of the code itself. Back in 96 we had a few sprites, with some animation sequence, sound effects. State of an object was kept in a few integers. Collisions were done using really stupid algorithm that would probe special mask in level builder with a circle consisting of 16 points, so we can get a vector pointing away from the wall. Etc. Today, collisions, physics, presentation - all this is thousands of times more complex. More code, more bugs, more issues. For that reason, it would be very difficult to write keyboard-state driven multiplayer today.
- TheLoneWolfling 12y ago
  Ah, you weren't using floating-point. That makes things substantially easier. W.r.t. floating-point, good luck. See https://news.ycombinator.com/item?id=9430958 https://news.ycombinator.com/item?id=9430958
  - limaoscarjuliet 12y ago
    Ah, yes, you are correct. We built our own fixed point library.

megablast 12y ago

Couldn't you reset the rand every now and again, without too much of an effect. Such as every 10 seconds? For every machine.

limaoscarjuliet 12y ago
Nope. Once the sync was lost, you were playing two different games: player A on machine A is in room 1, player A on machine B is in room 2. Resetting rand sequence would not correct the introduced error. The only way to correct such error would be to change model to sync the actual state among machines. But that means completely different code. All in all, I remember we added the multiplayer code at the very end. If we decided to sync state rather than exchange keyboard+mouse, we would not finish on time.