Comment by NelsonMinar | Hacker News Reader

Comment by NelsonMinar | Hacker News Reader

I've been playing Path of Exile again lately and it has the most straightforward approach to network code, it's sort of refreshing. The game works via a TCP stream to a server. By default the screen only updates when your client receives a packet from the server; if there's a hiccup the client freezes. This means it's immediately obvious when a network problem is causing trouble and you're never misled by prediction. Also looks crappy on a bad connection. There's a "Client predictive" mode you can enable but it's off by default. Details: https://www.poewiki.net/wiki/Networking_mode

I'm on Starlink so I get a lot of hiccups. It's pretty annoying. But then, it's also transparent. Lately the game is working as a diagnostic of Starlink's various failures. It helps the game has a very simple lag meter. https://imgur.com/a/S0VMjUM

PoE is a lot less demanding than a fighting game; it's mostly single player. Occasional 500ms latency and rubberbanding isn't game-destroying (just annoying). Just an interesting different approach.

Street Fighter IV does that, only advances when both clients have advanced. There's never bullshit surprises. It does suck on a bad connection, but that's just how it has to work. Street Fighter V has rollbacks and it's absolutely terrible.

This is also how Kaillera works. :)

Kaillera is legendary. Let me play Smash 64 with friends online as a teen.

Many games before SFV used rollback netcode without issues. SFV in their implementation somehow managed to implement rollback in a way in which sometimes it was purely one sided.

Given delay based netcode, or rollback netcode, I'll always pick rollback. Played alot of SF4 purely online and in a game with plenty of 1-2 frame links, delay based netcode really advantages the player mashing reversal within your string.

I don't see what benefit TCP would have over UDP in your example, aside from increasing the lag over your unstable starlink connection.

A constant UDP stream of updates is typically the best way to ensure all clients have the correct state.

I don't think it's literally TCP, but you're right that it's very much TCP-like behavior. I kept having stuttering in PoE, and eventually realized that NetworkManager was doing wifi channel scans way more often than it should be! Genuinely useful as a tool for diagnosing network conditions.

PoE oddly enough does use TCP for all of its netcode, its somewhat unique in this way compared to similar titles. I know they use a few different outgoing ports so its possible they deal with head-of-line blocking issues with parallel streams (not sure about that, just conjecture).

It's literally TCP, I was looking at packet dumps yesterday. I was surprised! ENet is common for this kind of game.

Wow!! I wouldn't have imagined they could have gotten tolerable latency while using TCP. Cool!

there isn't much difference in the happy path. the problem comes when you lose a packet and have to recover. so that's at least one additional round trip.

TCP_NODELAY to the rescue

https://en.wikipedia.org/wiki/Nagle%27s_algorithm#Operating_...

Head of line blocking is still an issue even after disabling Nagle's algorithm as ideally you don't want the lack of reception of older data in the stream delaying newer updates. Sometimes it's better to simply blast out all unacked state, and if intermediary packets get occasionally lost, it doesn't really matter. You can see this in live audio/video as well. If you missed your window you don't want the media data that's already arriving too late to actually play delaying the reception of newer data in the stream.

Reply on news.ycombinator.com