Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: I made a browser-based RTS game

battle-of-flags.com

Post reply on HN
Print view View original

61–65 of 65 posts

Re: Show HN: I made a browser-based RTS game

#61

Post by jlokier »

boredtofears wrote: post #53
bmacho wrote: post #39

Earlier quoted context omitted.

> 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, javas…

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

Re: Show HN: I made a browser-based RTS game

#62

Post by Gluten »

smegma2 wrote: post #44

Hi Gluten, I never wrote a real-time game, so I'm curious about a lot of things. * Does the server have a tick rate and it updates clients at a set interval, or does it only update when things happen? * Did you ever run into any issues getting enough throughput from the server? e.g. maybe too many events happening at once to update everyone? * Do you have to manage situations where two clients have a different view o…

The server runs at ~100 FPS, but things like worker updates and attacks happen at a 1.5 second interval. Only the changes (like walking a step, collecting a resource) are sent to the client(s). There is no client side prediction. There is no specific aiming on targets like in FPS games, just need the opponent id, so don't really need to do that Team Fortress thing.

Re: Show HN: I made a browser-based RTS game

#64

Post by visox »

crickcreek wrote: post #42
visox wrote: post #3

remind me of my old old abandoned side project where i tried to create a diablo clone in browser with scala.js does not work in most browsers, think in safari it works :D http://diablo-forever.com/

Awesome dude

Thx, did you find the second máp? :D

Re: Show HN: I made a browser-based RTS game

#65

Post by mizzao »

rnd420_69 wrote: post #60
smegma2 wrote: post #47

Earlier quoted context omitted.

This is interesting, thanks! So sounds like there is too much data to send the entire game state every time.

In 2022 the bandwidth requirement is actually easily doable with some compression of the sent data. But an architecture that uses prediction (cool kids seem to call this 'rollback networking' nowadays) has other benefits, like zero latency for player input.

For folks who are reading, the "simultaneous simulation" architecture used in almost all RTS games is still a very different beast than the "rollback networking" architecture used in some FPS (and fighting) games referred to by the above post.
Post reply on HN