Hacker News Reader

Comment by bmacho | Hacker News Reader

> I think there's so much potential now to make some crazy browser based games given current state of web apps.

I believe that this could have be done ~20 years ago with about the same effort.

Websocket is maybe minimally easier than AJAX + 20 years old javascript, and the newer ECMA standards also have some nice syntactic sugars, but nothing radical. Objects, classes, closures, passing and modifying functions, javascript was so powerful and easy to work with from the beginning. People just didn't used it back then.

I remember playing e.g. travianer 15 years ago, different genre, but the technology was given.

View on HN

Head of line blocking in TCP is what made/makes this hard. I've seen some approaches stagger multiple sockets to mitigate but it is highly dependent on packet loss.

I would argue WebRTC is where this really became possible, although last I looked at the spec it made a best-effort at using UDP for datagram based messages but would fallback to TCP in some cases.

It's a fun domain and lots of really interesting approaches(like lockstep called out above as well as other fun things like dead reckoning).

Latency is far worse with AJAX. Also, browsers nowadays are much more powerful, both in rendering capabilities and Javascript engines. Servers have become a lot cheaper, too, which makes hosting this for free far more viable. Lastly, while a lot of stuff added to JS was just syntactic sugar, the whole ecosystem and tooling improved massively, which makes developing something like this a lot easier.

I'm not saying this was impossible 15 years ago (in fact, Flash-based MMOs existed back then), but it would've taken a lot more effort.

There’s no way you could do anything real time with full HTTP request round trips for updates

The trick was to run many HTTP requests in parallel, using different subdomains so they wouldn't be subject to the browser limit on number of parallel connections to a domain, a dummy first request per subdomain so the interesting messages went over established persistent connections, and decoupling outbound from inbound messages to make a set of "short-long-polling" connections.

That resulted in real-time message throughput close to the game frame rate, bidirectional, and no connection setup latency per message, just the transmission latency even over TLS (SSL back then).

Reply on news.ycombinator.com