[HN Gopher] How to beat lag when developing a multiplayer RTS game
       ___________________________________________________________________
        
       How to beat lag when developing a multiplayer RTS game
        
       Author : AshleysBrain
       Score  : 42 points
       Date   : 2023-01-15 18:15 UTC (4 hours ago)
        
 (HTM) web link (www.construct.net)
 (TXT) w3m dump (www.construct.net)
        
       | vore wrote:
       | I don't think there's usually need to have a separate ping timer:
       | just have each client send the sequence number of the last
       | received packet in their response, and the receiver can subtract
       | what they think the game state should be at vs what they're
       | really at to determine the difference in time every packet
       | without having to only be able to sync up the time every ~2
       | seconds.
        
       | dpeck wrote:
       | A "classic" paper in the space that might give some historical
       | context to anyone interested,
       | https://www.gamedeveloper.com/design/the-internet-sucks-or-w...
        
       | loxias wrote:
       | Very nice. Hadn't seen such a clear explanation of PDV and the
       | solution with synthetic delay before. I've designed several
       | latency critical protocols using these techniques and some that
       | build on this, but haven't before seen such a clear explanation.
       | My own "slides" were harder to follow, when I had to explain once
       | how the protocol works.
       | 
       | Could have saved me months of thought 10 years ago if one had
       | existed. ;)
       | 
       | It's always validating to see someone else arrive at similar
       | conclusions when facing a challenging technical problem. To the
       | author, I encourage you to keep pushing (if you want to), it's
       | possible to replace the fixed synthetic delay with a control
       | loop. :D This makes both the PDV _and_ the system latency
       | approach their minima over time.
        
       | gxs wrote:
       | As someone who plays fps games, I always have two responses when
       | I see some BS happen during the game with things like lag, hit
       | reg, etc.
       | 
       | As a consumer, my first reaction is fuck activision this is
       | bullshit, bunch of incompetent dimwits.
       | 
       | The flip side however, as someone who knows better, sympathizes
       | and says, wow it's amazing this works as well as it does.
       | 
       | Awesome article, especially for anyone who plays games and does
       | technical work.
        
       | tareqak wrote:
       | Wouldn't it be better for estimated latency to be calculated for
       | each direction?
       | 
       | The ping message could have the client's current time, and the
       | pong message would have this client time and the server time.
        
       | pmalynin wrote:
       | Trailing State Synchronization
        
       | gamblor956 wrote:
       | The old trick (circa AOE2 and SC) is to delay execution of the
       | user input long enough to account for most latency in propagating
       | input to other players (usually 100 to 500 ms), and to hide the
       | delay through audio or visual acknowledgements of the input.
       | Input was executed on "ticks" which did not directly correspond
       | to time.
        
         | 10000truths wrote:
         | You don't even necessarily need to mask the latency. You can
         | just accept inputs at a low but consistent tick rate, and
         | players will be able to adjust as long as packet loss and
         | jitter are minimal.
        
       | jmyeet wrote:
       | This is a surprisingly difficult problem. It's also what leads to
       | a lot of cheats, dupes and hacks in online multipler games: you
       | basically have to trust the client at some point.
       | 
       | The starting point for any such discussion is (as in this
       | article) where all updates are done on the server. You then have
       | to deal with packet loss and latency spikes but the real problem
       | is subjective: it just doesn't _feel good_.
       | 
       | Imagine you're playing Fortnite and when you pressed your trigger
       | you had to wait 50ms for it to acknowledge that your gun fired.
       | That bullet has travel time so there may be another update if you
       | hit someone.
       | 
       | So instead the client gives you immediate feedback and proceeds
       | as if that shot actually happened. This may well include
       | calculating if you hit the target. That target's position may be
       | interpolated too, not the location you last got an update for.
       | This feels way more responsive.
       | 
       | What if your target actually stopped moving after you shot. You
       | get into an ordering canondrum. Now imagine if shooting that shot
       | had recoil (which could affect both aim and position) and getting
       | hit moved the target (eg getting hit by an explosive of some
       | kind).
       | 
       | Doing all of this when latency can easily be >100ms and having it
       | feel good is incredibly difficult.
        
         | amelius wrote:
         | Isn't this more or less the same problem as cooperative editing
         | of a document?
        
         | charcircuit wrote:
         | >You then have to deal with packet loss and latency spikes
         | 
         | And fake packet loss and latency spikes introduced by cheaters.
         | 
         | For example, when a cheater gets killed they could send a
         | packet from the "past" saying that they killed the other person
         | first.
        
       ___________________________________________________________________
       (page generated 2023-01-15 23:00 UTC)