5 ms·

That's not intrinsic to this style of netcode, though. Company of Heroes, for instance, just keeps the game running and your input is delayed until you can comm

That's not intrinsic to this style of netcode, though. Company of Heroes, for instance, just keeps the game running and your input is delayed until you can communicate it to the server. You'd generally want an authoritative server to accomplish this. Having it also execute the inputs prevents most cheating, too.

Emjayen 4y ago
It is, in fact, inherent to this model. While there will be some tolerance threshold as to how far behind in the simulation a machine may fall, it still must be rather conservative (generally a few seconds), as elsewise the context (state-) sensitive inputs start frequently failing -- if I issue a command given at world-state time t, will it be meaningful/valid at state t2? The answer is where you get your threshold and it's always just a conservative approximation.
- reitzensteinm 4y ago
  If it's not valid, just throw it out! I've built and licensed a time traveling variant of this model (GGPO style) and spent years with thousands of concurrent users playing my games. And they operated just as I describe. Company of Heroes is more of a traditional AoE style and will happily queue up unit orders for a minute or more while it attempts to reconnect or catch up.
  - Emjayen 4y ago
    Are these players interacting in any way? If they aren't then it could be more tolerable, but one player being more than several seconds behind others is going to lead to a rather undesirable experience, especially in the middle of a battle (and having most of their commands dropped due to being invalid equally so)
    - reitzensteinm 4y ago
      Giving the undesirable experience to one player is strictly superior to giving it to all of them. There just aren't many modern multiplayer games where slow players can negatively impact the experience of others, and that's because the industry has learned how terrible the experience is. And that's for players playing in good faith on bad connections - abuse by inducing latency was a big thing in the past. Think a player that runs out the clock when they're a move away from being checkmated. Basically the only time you'd ever want to operate the system to pause if a player fell behind is during a tournament, where fairness is more important than player experience and they know that going in. And even that, IMO, is questionable.
      - Emjayen 4y ago
        I'm of the opinion that it's an acceptable concession that a brief pause occurs in gameplay to permit another player to recover from transient issues (network hiccups, brief machine resource starvation, or generally: stalling) in favor of fairness rather than punishing the player too harshly for factors that are frequently out of their control. Consider for instance the situation where-in one player's simulation enters the spiral-of-death, under the policy that you're proposing this player is effectively removed from the game; I would say this is a substantially worse trade-off -- I know that I would personally prefer some mild annoyance of brief pausing as opposed to a player leaving the game (and in session-based games, as RTS's generally are, a team-mate leaving often ruins the entire game) Abuse is indeed a problem that most games I've seen of this nature don't address, and while there's no perfect solution, it can be quite effectively curtailed. In the systems I've designed, the basic principle is that each participating player has an allocated amount of wait time which serves as a quota that is charged while-ever the game can progress/run, but cannot, due to them being in a wait-state (connecting/loading/reconnecting/stalling/explicit pausing/whatever). There's some extra logic for handling the oscillation of wait-state.
        reitzensteinm 4y ago
        The spiral of death trade-off does not happen as you describe. While a client is catching up, you run the sim in a loop and don't render the game. The deterministic simulation code is only a small part of the overall game logic, and you can run it much faster than real time. If a client is slow enough to genuinely experience a spiral of death, the game will not be playable for them, and "mild annoyance of brief pausing" is not remotely what the other players will experience if they're forced to stay in sync. Wait time is the common solution in older games to prevent abuse, yes. But it doesn't prevent somebody with high ping making a game run at half speed. Go play Company of Heroes 2 with a packet loss simulator. Even as the bad client, it's totally playable. For everyone else, it's silky smooth. I don't think you'll come back and tell me you prefer the implementation in AoE II Definitive Edition.
  - hot_gril 4y ago
    You could probably build something better than what the AoE2 remake has now. I don't know if it'd be viable in 1998, though. Wasn't like today's constantly self-updating games; each patch risked fragmenting the community, and they only released like 2 patches across 15 years of activity. They chose something simple that'd work well enough without having to tweak it. And old PC specs, and no dedicated servers. You said it's better to disadvantage laggers than to punish everyone, but that requires some balancing to ensure it's fair enough. AoE model is always fair and can be lag-free. Yes it relies on the players trusting each other a little to avoid extreme lag, but there are plenty of ways to ruin this kind of game besides lagging. It's not like CoD where a few useless teammates won't make a big difference, while it didn't have automated ranked play like Csgo. (but the recent DE remake does, and yes it needs better netcode) Time-traveling netcode... I know Slippi does this, and it works great.
hot_gril 4y ago
> You'd generally want an authoritative server to accomplish this That makes it very different from this model in my eyes. You wouldn't have every client running the game in sync. The AoE devs had this dilemma and chose the other path.
- reitzensteinm 4y ago
  No, it's the same model - the clients run the game in sync and the server does too. Only inputs are transferred. It wouldn't surprise me if the AoE remakes do this to work out who won the game.
  - hot_gril 4y ago
    Don't you have to handle the situation where one client falls behind? That means asking for the latest state and figuring out what happens to the stale inputs it sent. It's a nontrivial difference. Definitive and HD Edition both seem to use nearly the same netcode as the original game. And the whole thing lags if one player lags. Yes it handles situations where all players leave, so there's a server doing something, but the glitches in Elo changes hint to some weird edge cases. I even found an easily triggered bug in HD Edition where both players would gain Elo at the end of a ranked game.
    - reitzensteinm 4y ago
      You definitely can build out functionality in the authoritative server, like drop in. I did that with my games. But you could keep it strictly as cheat prevention, which keeps it very close to the AoE model. I wouldn't start a game in 2023 trusting any input from players, including win reporting - but I understand if their hands are tied by a legacy system, and the players vote on outcomes.
      - hot_gril 4y ago
        Dropping in a server like another client might be what they did in HD/DE remakes to allow the game to continue without a player host present. It doesn't help with cheating, cause other players are already interested in enforcing the rules. And doesn't help with lag ofc. Yes, the remakes should've had new netcode. They had full freedom to redo it, no legacy compatibility to deal with. Maybe they wanted to totally emulate the old experience, but ya know, I can just play the old game. DE at least seems to be working out the kinks better; HD was a total mess even after years of patching.

Emjayen 4y ago

It is, in fact, inherent to this model. While there will be some tolerance threshold as to how far behind in the simulation a machine may fall, it still must be rather conservative (generally a few seconds), as elsewise the context (state-) sensitive inputs start frequently failing -- if I issue a command given at world-state time t, will it be meaningful/valid at state t2? The answer is where you get your threshold and it's always just a conservative approximation.

reitzensteinm 4y ago
If it's not valid, just throw it out! I've built and licensed a time traveling variant of this model (GGPO style) and spent years with thousands of concurrent users playing my games. And they operated just as I describe. Company of Heroes is more of a traditional AoE style and will happily queue up unit orders for a minute or more while it attempts to reconnect or catch up.
- Emjayen 4y ago
  Are these players interacting in any way? If they aren't then it could be more tolerable, but one player being more than several seconds behind others is going to lead to a rather undesirable experience, especially in the middle of a battle (and having most of their commands dropped due to being invalid equally so)
  - reitzensteinm 4y ago
    Giving the undesirable experience to one player is strictly superior to giving it to all of them. There just aren't many modern multiplayer games where slow players can negatively impact the experience of others, and that's because the industry has learned how terrible the experience is. And that's for players playing in good faith on bad connections - abuse by inducing latency was a big thing in the past. Think a player that runs out the clock when they're a move away from being checkmated. Basically the only time you'd ever want to operate the system to pause if a player fell behind is during a tournament, where fairness is more important than player experience and they know that going in. And even that, IMO, is questionable.
    - Emjayen 4y ago
      I'm of the opinion that it's an acceptable concession that a brief pause occurs in gameplay to permit another player to recover from transient issues (network hiccups, brief machine resource starvation, or generally: stalling) in favor of fairness rather than punishing the player too harshly for factors that are frequently out of their control. Consider for instance the situation where-in one player's simulation enters the spiral-of-death, under the policy that you're proposing this player is effectively removed from the game; I would say this is a substantially worse trade-off -- I know that I would personally prefer some mild annoyance of brief pausing as opposed to a player leaving the game (and in session-based games, as RTS's generally are, a team-mate leaving often ruins the entire game) Abuse is indeed a problem that most games I've seen of this nature don't address, and while there's no perfect solution, it can be quite effectively curtailed. In the systems I've designed, the basic principle is that each participating player has an allocated amount of wait time which serves as a quota that is charged while-ever the game can progress/run, but cannot, due to them being in a wait-state (connecting/loading/reconnecting/stalling/explicit pausing/whatever). There's some extra logic for handling the oscillation of wait-state.
      - reitzensteinm 4y ago
        The spiral of death trade-off does not happen as you describe. While a client is catching up, you run the sim in a loop and don't render the game. The deterministic simulation code is only a small part of the overall game logic, and you can run it much faster than real time. If a client is slow enough to genuinely experience a spiral of death, the game will not be playable for them, and "mild annoyance of brief pausing" is not remotely what the other players will experience if they're forced to stay in sync. Wait time is the common solution in older games to prevent abuse, yes. But it doesn't prevent somebody with high ping making a game run at half speed. Go play Company of Heroes 2 with a packet loss simulator. Even as the bad client, it's totally playable. For everyone else, it's silky smooth. I don't think you'll come back and tell me you prefer the implementation in AoE II Definitive Edition.
- hot_gril 4y ago
  You could probably build something better than what the AoE2 remake has now. I don't know if it'd be viable in 1998, though. Wasn't like today's constantly self-updating games; each patch risked fragmenting the community, and they only released like 2 patches across 15 years of activity. They chose something simple that'd work well enough without having to tweak it. And old PC specs, and no dedicated servers. You said it's better to disadvantage laggers than to punish everyone, but that requires some balancing to ensure it's fair enough. AoE model is always fair and can be lag-free. Yes it relies on the players trusting each other a little to avoid extreme lag, but there are plenty of ways to ruin this kind of game besides lagging. It's not like CoD where a few useless teammates won't make a big difference, while it didn't have automated ranked play like Csgo. (but the recent DE remake does, and yes it needs better netcode) Time-traveling netcode... I know Slippi does this, and it works great.

hot_gril 4y ago

> You'd generally want an authoritative server to accomplish this That makes it very different from this model in my eyes. You wouldn't have every client running the game in sync. The AoE devs had this dilemma and chose the other path.

reitzensteinm 4y ago
No, it's the same model - the clients run the game in sync and the server does too. Only inputs are transferred. It wouldn't surprise me if the AoE remakes do this to work out who won the game.
- hot_gril 4y ago
  Don't you have to handle the situation where one client falls behind? That means asking for the latest state and figuring out what happens to the stale inputs it sent. It's a nontrivial difference. Definitive and HD Edition both seem to use nearly the same netcode as the original game. And the whole thing lags if one player lags. Yes it handles situations where all players leave, so there's a server doing something, but the glitches in Elo changes hint to some weird edge cases. I even found an easily triggered bug in HD Edition where both players would gain Elo at the end of a ranked game.
  - reitzensteinm 4y ago
    You definitely can build out functionality in the authoritative server, like drop in. I did that with my games. But you could keep it strictly as cheat prevention, which keeps it very close to the AoE model. I wouldn't start a game in 2023 trusting any input from players, including win reporting - but I understand if their hands are tied by a legacy system, and the players vote on outcomes.
    - hot_gril 4y ago
      Dropping in a server like another client might be what they did in HD/DE remakes to allow the game to continue without a player host present. It doesn't help with cheating, cause other players are already interested in enforcing the rules. And doesn't help with lag ofc. Yes, the remakes should've had new netcode. They had full freedom to redo it, no legacy compatibility to deal with. Maybe they wanted to totally emulate the old experience, but ya know, I can just play the old game. DE at least seems to be working out the kinks better; HD was a total mess even after years of patching.