Gastrotale- a multiplayer roguelike

Hi all! For the past few months, I’ve been working on a game called Gastrotale, a multiplayer roguelike that’s powered by babylon.js. Gastrotale is a multiplayer roguelike ARPG (i.e. Risk of Rain or Hades) that runs in a standard web browser. I’ve always been a big believer in the web platform, and I think web technologies are finally mature enough for a project like this.

I have some grand ideas of an overarching story and zany gameplay mechanics, but I’ll keep it brief for now. The project is just too early in development, and I don’t want to waste your time with baseless promises of what may be. I’ll update this post as I implement more features, but in the meantime, enjoy this devlog for a first look at the game:

Devlog 2: Combat mechanics and netcode
Devlog 1: Introductions and the map editor

Features
Over the past few months, I’ve implemented a lot of the core networking stack, game loop, and rendering. As of today, multiple people can connect to the server and move around in the same map:

Tech
I’ve incorporated a lot of really cool tech in Gastrotale so far (besides, of course, babylon.js itself).

I use a client-server networking model via an approach that’s well-documented on the internet. For those of you unfamiliar with game networking, the gist is that clients are untrustworthy and all actual game logic should happen on the server. Clients broadcast their input state (e.g. keypresses, mouse position) every tick, the server acts on this information, and the server updates all clients with the authoritative game state every tick. Of course, this introduces additional latency (the client won’t see the results of a button press until a full roundtrip to the server), so most games attempt to hide the lag with client-side prediction and reconciliation.

Client-side prediction lets the client preemptively act on local inputs before the server responds. If the client and server are running the same game loop, there should be no difference between the final game state on either the client or the server in the vast majority of scenarios.

Of course, this requires that the client and server run the exact same game loop as differences in implementation will result in bugs. In many networked games, this is not an issue- both the client and the server are written in the same language, so we can just share a library. In Gastrotale, however, I want to implement the server in C++ for performance, but the client needs to run JavaScript. To solve this, I implement the game loop in C++ and use WebAssembly to export a module. I can then invoke this module on the client to advance the game loop using the local game state.

Also, most networked games use UDP instead of TCP for networking. Unfortunately, the easiest way to set up a bidirectional connection in the browser is with the TCP-based WebSockets. If you want unreliable and unordered packets, your best bet is WebRTC, an API for peer-to-peer connections between multiple web browsers. WebRTC was designed for P2P media sharing (i.e. video calls), but you can fake a client-server model by just running a WebRTC client on your server and have it connect to all clients. To do this in C++, I compile Chromium’s WebRTC implementation into my game server.

Thanks for reading!

14 Likes

@brkho whoa this is amazing :smiley: I love how you’re pushing the limits of performance using a C++ server with WebRTC. Your networking looks incredibly smooth, and I’m excited to see where you go with Gastrotale!

@brkho great devlog writeup and video!

I can’t even contemplate using C++ server side and native level editor app, so respect and kudos to you.

Pretty impressive and I love the artistic direction!

Thanks for the kind words, all!

@brkho I was reading a bit about networking earlier today and came across QUIC It looks like guys at google already worked out UDP for web.
It seems too complex for my prototype so I’m still going forward with Web Sockets but thought QUIC looks pretty interesting, especially since it is already being used in production for years.

@brkho, that’s nice!

1 Like

@MarkBevels Sorry, somehow I missed your post a month ago. QUIC looks super interesting, and I’d love to try it out. Thanks for the pointer!

Also, I just uploaded the second installation of the Gastrotale devlog! This time, I focus on combat mechanics and all of the fussy netcode that comes with it:

Devlog 2: Combat mechanics

1 Like

This is great stuff! Your “programmer graphics” look better than most browser games I’ve seen, I bet they load really fast too.

I’m in the early planning stage of my own multiplayer browser game and the lack of UDP had me worried. This is the first time I’ve seen WebRTC being used this way, now I’m excited to give it a try with a NullEngine/Node backend.

Looking forward to your next devlog :smiley:

1 Like

Hi all, I’m back with a bit of a smaller update this time. I’ve been focused on art over the past month, so unfortunately, I don’t have enough new featurework for a full devlog. Instead, please enjoy this in-game render of the first playable character:

For more details, please check out my posts on Twitter or Reddit!

1 Like