PlanetKit is a game programming library for building interactive virtual worlds, most of which will probably involve friends trying to kill each other in one way or another. I'm writing it in the Rust programming language, which I'm finding delightful to work with, and a great fit for the task.
About a year ago I packed my life into a bag and flew off to the other side of the world to find myself. Or something like that. And while I did get back to working at least a little bit on PlanetKit when I got back, it's taken me this long to start blogging again.
I want to dive into some really specific things in my next post, so I'm going to clear the way for that with a quick summary of what I've been working on over the past year.
Small steps toward making PlanetKit usable as a library
I published version 0.0.1 of the planetkit crate, primarily as an exercise in getting something out there. I would be really surpised if anyone is actually attempting to use it for anything at this point. (I assume the few downloads are things like docs.rs, crates.io, mirrors, etc.) But if you do happen to tinker with it for anything at all, please say hi!
To aid with untangling the "library" part of PlanetKit from the "application" part, I added boilerplate for a small single-player game I intend to make involving a shepherd rescuing sheep who have fallen into holes. I deviated from this as soon as I realised that whatever I do for loading and saving levels will inevitably be influenced by the approach I take to networking. So I figured I need to have a think about networking before putting much effort into any individual game.
Networking
Network nodes listen for TCP connections if they are the "master" of the game. Once a connection is established, both client and server will also accept messages over UDP, for the kinds of messages where reliability can be happily traded for lowering latency — e.g. player position updates. They all end up in the same queues at the other end, regardless of transport.
Messages are encoded using Serde, currently as JSON for ease of inspecting them on the wire, but I'll probably switch to something like Bincode.
I don't think I built much more than I need for my networking code, but there ended up being a surprising amount to it anyway.
This is my first go at building something like this, so it definitely leaves a lot to be desired. And I might have missed a crate that does all this for me. But if there does turn out to be a gap in the ecosystem for a basic game-oriented networking library, then I'd be happy to either extract this from PlanetKit as a starting point (or at least straw-man proposal), or contribute to something else.
Token multiplayer game
Out of the networking experiments came a technically playable game: "Kaboom". At this point you can wander around the globe, fire grenades which explode on a timer, and win points if your grenade explodes close enough to another player.
All of this is pretty bare-bones right now. By "grenade" I mean the same three-axes placeholder model used for players. By "explode" I mean that it disappears, and maybe causes another player to be respawned. But you can win points by playing better than your opponent, so I guess it counts as a game!
Trying to run in a browser
I spent some time trying to get PlanetKit running in the browser using Emscripten. I think it's pretty close now. I'm a long way off being able to run any meaningful portion of it using the wasm32-unknown-unknown target, but I might actually be only a single shader compilation quirk away from getting something running using the wasm32-unknown-emscripten target.
What's next?
As I mentioned up top, I want to start diving in to some more specific things as I work on them, rather than just doing occasional summaries. So in my next PlanetKit post I'm going to document the process of debugging something that's been bothering me for a while.
As always, the source for everything I'm talking about here is up in the planetkit repository on GitHub.