Show HN: I made a browser-based RTS game • Hacker News Board

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

#51

Post by Sebb767 » Sun, May 08, 2022, 1:16 AM UTC

bmacho wrote: post #39

iWillOffshoreU wrote: post #4

Nice, big fan of browser based multiplayer stuff. I think there's so much potential now to make some crazy browser based games given current state of web apps. Edit: How long did it take you to create?

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

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.

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

#52

Post by oneoff786 » Sun, May 08, 2022, 1:41 AM UTC

mLuby wrote: post #36

I'm curious if it's reasonable to push more processing to the browsers to save on server costs. I know multiplayer games generally need a server to "referee" (and to matchmake) but I wonder if games ever offload most of that work so the client does the heavy lifting (e.g. find a path from A to B) and then submits its work for the server to validate (e.g. this path from A to B works) and broadcast rather than the serv…

This is the idea behind prediction. It’s used to reduce delays between client inputs and seeing the actions happen. More important in high reaction time things like fighting games.

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

#53

Post by boredtofears » Sun, May 08, 2022, 1:46 AM UTC

bmacho wrote: post #39

iWillOffshoreU wrote: post #4

Nice, big fan of browser based multiplayer stuff. I think there's so much potential now to make some crazy browser based games given current state of web apps. Edit: How long did it take you to create?

> 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

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

#54

Post by holografix » Sun, May 08, 2022, 1:47 AM UTC

This is so cool! Is there a dev blog?! I’m particularly interested in the netcode and things like path finding and object collision detection at scale.

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

#55

Post by [deleted] » Sun, May 08, 2022, 3:42 AM UTC

bytehowl wrote: post #14

I would recommend allowing people to just pick a name and hop in. One of the keys to the success of web games is that there's (often) literally no barrier to entry, including the need to create an account.

[deleted]

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

#56

Post by vvanders » Sun, May 08, 2022, 4:22 AM UTC

bmacho wrote: post #39

iWillOffshoreU wrote: post #4

Nice, big fan of browser based multiplayer stuff. I think there's so much potential now to make some crazy browser based games given current state of web apps. Edit: How long did it take you to create?

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

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

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

#57

Post by ttty » Sun, May 08, 2022, 4:47 AM UTC

Related to multiplayer rts games this is also done with same tech but node.js only to reuse code between client and server side https://bitplanets.com/

I wonder what performance issues you had with node.js that justified a bridge to c++ (including the increase of complexity of the architecture). Pathfinder is not terrible in node.

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

#58

Post by Matheus28 » Sun, May 08, 2022, 5:10 AM UTC

mLuby wrote: post #36

I'm curious if it's reasonable to push more processing to the browsers to save on server costs. I know multiplayer games generally need a server to "referee" (and to matchmake) but I wonder if games ever offload most of that work so the client does the heavy lifting (e.g. find a path from A to B) and then submits its work for the server to validate (e.g. this path from A to B works) and broadcast rather than the serv…

There are games that run exclusively on the clients by being deterministic. Like Starcraft 2. Server is just proxying packets back and forth, but doesn't actually know what's going on with the game.

It works really well with RTSes because of the number of things moving around. Unfortunately the drawback is that the client knows everything that's going on in the game. So fog of war is entirely client-side too. Another drawback is that rejoining a game (or a new player joining) is much harder (need a way to encode/decode the entire game state, or client needs to replay the game inputs up until that point to be able to play).

It has some really elegant side effects (tiny replay files, easy to reproduce most bugs, easy to check if a bug is fixed by playing a replay file with a new version, etc.)

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

#59

Post by aliswe » Sun, May 08, 2022, 7:04 AM UTC

Looking real good!

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

#60

Post by rnd420_69 » Sun, May 08, 2022, 8:00 AM UTC

smegma2 wrote: post #47

mizzao wrote: post #45

Earlier quoted context omitted.

It's probably a completely different architecture, see the classic article "1500 archers on a 28.8": https://www.gamedeveloper.com/programming/1500-archers-on-a-...

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.