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:
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:
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.
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!