4 ms·

As a fairly high rated AoE2 player (~1800), I can attest that the network architecture has not stood the test of time. Lockstep causes tonnes of problems. Desyn

by ddek 5y ago

As a fairly high rated AoE2 player (~1800), I can attest that the network architecture has not stood the test of time. Lockstep causes tonnes of problems. Desynchronisation is still possible, when that happens the simulation needs to backtrack (I think?), which can cause units to jump multiple tiles. Because your machine is resolving the movements of other players, you run into problems with more players. The wire protocol is widely known and easily hacked, in a way that's hard to detect in game. AoE2 DE is still lockstep, but through a server. All players are connected to the same server. This has slightly improved on the previous P2P, but not really addressed anything.

Jare 5y ago
> Desynchronisation is still possible, when that happens the simulation needs to backtrack (I think? Sounds more like client-side prediction to smooth things, than actual simulation desync. I have a hard time believing a deterministic game with such a large state was able to backtrack and resync the sim back to determinism. I did not think that lockstep RTS games would need client-side prediction (the indirect and long-term commands in RTS helps hides latency), but I guess if your gameplay lends itself to high APMs then it becomes necessary.
- marginalia_nu 5y ago
  Well you could just have state snapshots taken at regular intervals and then verify that both sides' hashes agree. It's only a couple of thousand entities so it's really not so bad. For you can probably ignore those that haven't deviated from the previous snapshot (and that would account for a state reconstruction taking time). RTS games have a replay mechanisms at least as far back as StarCraft: Brood War, so a journal of player inputs are likely going to be recorded anyway.
  - Jare 5y ago
    Yes the journal of player inputs sure, but the intermediate states is a different matter. AoE2's state size is peanuts for a modern machine, but I would say that at the time, it was quite significant and it would be too costly to store it on the fly. I certainly did not dare try that in the RTS-like deterministic games I worked on (Commandos and Praetorians)
    - marginalia_nu 5y ago
      We're still talking about a few dozen kilobytes of data here. A dozen or so bytes worth of global state per player, up to 200 units per player with a few bytes worth of state (position, order, action, action target, hitpoints), maybe a hundred projectiles, order of 1000 static entities with just hitpoints. Gotta keep in mind that these games were written in languages that did not have modern garbage collection, so almost certainly stored entity information in arrays to avoid heap fragmentation and malloc costs. A few dozen Kb is far beyond what you can push over a modem in real time for sure, but memcpy:ing a couple of kilobytes' worth of arrays was still plenty fast in the late '90s/early 2000s. They weren't running these games on a 6502.
      - Jare 5y ago
        I think you're severely underestimating the task and the level of detail required, but happy to leave it at that.
      - alternatetwo 5y ago
        It's actually a lot more, an uncompressed world state from a recorded game is 1.6MB - compressed (aoe uses deflate) it's only 153kb, but that's still a lot.
  - alternatetwo 5y ago
    I think they have checksums every once in a while over their world state, fog of war state etc, and if these checksums don't match it desyncs. Then it creates an out of sync save, probably for just before the desync occured.
    - PicassoCTs 5y ago
      Nah, the desync is when two floating point operations do not produce the same outcome, the checksum is detecting when that butterfly has caused a thunderstorm of diverging game states that is measurable. That can happen fairly late , depending on what is hashed. The strategy of occasional save-game storage and backtracking only works, if the cause is rare and not deterministic.
      - alternatetwo 5y ago
        I'd need to look into it again but I think pretty much everything object state wise gets hashed. Edit: The checksum for the player includes the content of each attribute of the player, the object state for each object owned by the player, the master object id of that object, the amount of attributes they carry (which is I think resources that villagers carry for example) and the world x/y/z position.
Macha 5y ago
Aren't all other RTS also lockstep?
- NortySpock 5y ago
  Total Annihilation was asynchronous, Supreme Commander was synchronous lockstep (sending user interactions only), Planetary Annihilation said they were client-server, with the server only sending updates for units a player could see. Still a Total Annihilation fanboy at heart. https://www.pcgamer.com/planetary-annihilation-interview/2/ https://www.pcgamer.com/planetary-annihilation-interview/2/ https://www.forrestthewoods.com/blog/tech_of_planetary_annihilation_chrono_cam/ https://www.forrestthewoods.com/blog/tech_of_planetary_annih...
  - PicassoCTs 5y ago
    Lucky you. https://www.beyondallreason.info/ https://www.beyondallreason.info/ http://zero-k.info/ http://zero-k.info/

by ddek 5y ago

Jare 5y ago

> Desynchronisation is still possible, when that happens the simulation needs to backtrack (I think? Sounds more like client-side prediction to smooth things, than actual simulation desync. I have a hard time believing a deterministic game with such a large state was able to backtrack and resync the sim back to determinism. I did not think that lockstep RTS games would need client-side prediction (the indirect and long-term commands in RTS helps hides latency), but I guess if your gameplay lends itself to high APMs then it becomes necessary.

marginalia_nu 5y ago
Well you could just have state snapshots taken at regular intervals and then verify that both sides' hashes agree. It's only a couple of thousand entities so it's really not so bad. For you can probably ignore those that haven't deviated from the previous snapshot (and that would account for a state reconstruction taking time). RTS games have a replay mechanisms at least as far back as StarCraft: Brood War, so a journal of player inputs are likely going to be recorded anyway.
- Jare 5y ago
  Yes the journal of player inputs sure, but the intermediate states is a different matter. AoE2's state size is peanuts for a modern machine, but I would say that at the time, it was quite significant and it would be too costly to store it on the fly. I certainly did not dare try that in the RTS-like deterministic games I worked on (Commandos and Praetorians)
  - marginalia_nu 5y ago
    We're still talking about a few dozen kilobytes of data here. A dozen or so bytes worth of global state per player, up to 200 units per player with a few bytes worth of state (position, order, action, action target, hitpoints), maybe a hundred projectiles, order of 1000 static entities with just hitpoints. Gotta keep in mind that these games were written in languages that did not have modern garbage collection, so almost certainly stored entity information in arrays to avoid heap fragmentation and malloc costs. A few dozen Kb is far beyond what you can push over a modem in real time for sure, but memcpy:ing a couple of kilobytes' worth of arrays was still plenty fast in the late '90s/early 2000s. They weren't running these games on a 6502.
    - Jare 5y ago
      I think you're severely underestimating the task and the level of detail required, but happy to leave it at that.
    - alternatetwo 5y ago
      It's actually a lot more, an uncompressed world state from a recorded game is 1.6MB - compressed (aoe uses deflate) it's only 153kb, but that's still a lot.
- alternatetwo 5y ago
  I think they have checksums every once in a while over their world state, fog of war state etc, and if these checksums don't match it desyncs. Then it creates an out of sync save, probably for just before the desync occured.
  - PicassoCTs 5y ago
    Nah, the desync is when two floating point operations do not produce the same outcome, the checksum is detecting when that butterfly has caused a thunderstorm of diverging game states that is measurable. That can happen fairly late , depending on what is hashed. The strategy of occasional save-game storage and backtracking only works, if the cause is rare and not deterministic.
    - alternatetwo 5y ago
      I'd need to look into it again but I think pretty much everything object state wise gets hashed. Edit: The checksum for the player includes the content of each attribute of the player, the object state for each object owned by the player, the master object id of that object, the amount of attributes they carry (which is I think resources that villagers carry for example) and the world x/y/z position.

Macha 5y ago

Aren't all other RTS also lockstep?

NortySpock 5y ago
Total Annihilation was asynchronous, Supreme Commander was synchronous lockstep (sending user interactions only), Planetary Annihilation said they were client-server, with the server only sending updates for units a player could see. Still a Total Annihilation fanboy at heart. https://www.pcgamer.com/planetary-annihilation-interview/2/ https://www.pcgamer.com/planetary-annihilation-interview/2/ https://www.forrestthewoods.com/blog/tech_of_planetary_annihilation_chrono_cam/ https://www.forrestthewoods.com/blog/tech_of_planetary_annih...
- PicassoCTs 5y ago
  Lucky you. https://www.beyondallreason.info/ https://www.beyondallreason.info/ http://zero-k.info/ http://zero-k.info/