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