Hacker News Reader

Comment by aetherspawn | Hacker News Reader

The latency is a little intense from Australia … but surprisingly not as bad as I thought it would be.

It was playable.

I wonder if you can use speculative execution to play the game a few frames ahead and then the client picks what to display based on user input, or something like that.

Each frame is 16ms, so you’d have to work ahead 6 frames to conquer the nominal latency of around 100ms, which may actually be 200ms round trip.

(In that case, something like Haskell would be a good candidate to build a DSL to build the decision tree to send to the JS client…)

View on HN

What you’re describing is called “rollback netcode”. It’s a pretty cool chunk of theory, usually used for fighting games which are extremely sensitive to latency. This explainer has some nice graphic demos

https://bymuno.com/post/rollback

It's a common misconception that this is only used in fighting games. This technique was developed first in Duke Nukem, and then exploited heavily by Carmack in Quake, and subsequently refined and built upon in other AAA FPS games, specifically for the local player movement and shooting.

I don't think it's quite the same. Rollback netcode is like lockstep netcode, where the entire game is simulated locally and only inputs are networked. Since it's still only input being networked, network drops (or slow computers) affect everyone, requiring the simulation to slow down. Not just fighting games, but RTS games would do this. If you've ever played Starcraft/Warcraft 3 where it would freeze when a player disconnected.

With rollback/lockstep, there's no need for a server simulation at all. Most games are not doing that: the client's local simulations are less important than the server's simulation, even missing information (good to prevent wallhacks). Any dropped packets are handled with the server telling the client the exact positions of everything, leading to warping. Dropped packets and latency also only affect the problem player, rather than pausing everyone's simulations.

This is awesome and exactly what it needs, but good luck creating a language that’s “signal driven” enough to encode it and then send all the possible states to the client.

If you were able to make it, it would be kind of a Hail Mary moment for making easy server games without the latency.

It could help visually but you'll still have 200ms between you and your next door neighbor's actions

Reply on news.ycombinator.com