[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)