3 ms·

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

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.
    - reitzensteinm 4y ago
      The specific way running the simulation on the server helps with cheating is if client A and client B both claim they've won. As you describe, during the game the clients are enforcing the rules, so a player can't eg teleport their units.
      - hot_gril 4y ago
        Yeah, you're right, so maybe HD edition had no such authority cause I mentioned that bug where both players can win. Or they didn't check that.
- Sohcahtoa82 4y ago
  I was writing a real-time multiplayer game a couple years ago. The netcode was written so that players only send their inputs along with a timestamp (The "timestamp" actually being a frame counter). The server would then relay those inputs with the timestamp to other players. The client maintains snapshots of the game state and would then re-run the game logic from that timestamp given the new input. I handled clients falling behind by making the server reject any inputs that were more than 500ms (Really, 30 frames) behind the current time. The server would send a message to the client that essentially said "You're lagging, here's the current frame counter and current state of the game" Granted, this approach really only worked for my game because the entire game state could be squished to ~300 bytes. But it had the added benefit that it prevented players from cheating using a lag switch. They couldn't have a malicious client that sat and listened to what other players were doing and then send a bunch of back-dated inputs to put itself in an advantageous position.

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.
  - reitzensteinm 4y ago
    The specific way running the simulation on the server helps with cheating is if client A and client B both claim they've won. As you describe, during the game the clients are enforcing the rules, so a player can't eg teleport their units.
    - hot_gril 4y ago
      Yeah, you're right, so maybe HD edition had no such authority cause I mentioned that bug where both players can win. Or they didn't check that.
Sohcahtoa82 4y ago
I was writing a real-time multiplayer game a couple years ago. The netcode was written so that players only send their inputs along with a timestamp (The "timestamp" actually being a frame counter). The server would then relay those inputs with the timestamp to other players. The client maintains snapshots of the game state and would then re-run the game logic from that timestamp given the new input. I handled clients falling behind by making the server reject any inputs that were more than 500ms (Really, 30 frames) behind the current time. The server would send a message to the client that essentially said "You're lagging, here's the current frame counter and current state of the game" Granted, this approach really only worked for my game because the entire game state could be squished to ~300 bytes. But it had the added benefit that it prevented players from cheating using a lag switch. They couldn't have a malicious client that sat and listened to what other players were doing and then send a bunch of back-dated inputs to put itself in an advantageous position.