Last week a friend and I decided to spend four weeks more seriously hacking on our games and blogging about it. We called this event "Devebruary", even though February had already started. This is my first post.
The current state
I've been working on a game called "RST Node" (read "Reset Node") for the last few years, albeit only conceptually. It is a 2D (top down) RTS, set on a computer network. A match consists of multiple players starting with a single node on this network, attempting to capture as many of the surrounding computers as they can. As part of this they need to build compute clusters to gain resources, and attack the enemy with various exploits.
I started programming on this game last year in January, but only worked on it for about a month before running out of time and energy (did something else happen in 2020? Can't remember). The game is written in Rust and AGPL-3.0, seeing as it uses a component from my research project (Ratman), which is also licensed under the AGPL-3.0.
What I've done this week
The code up to this week was entirely backend focussed. I had layed
out the basic structure of units, abilities, and matches. Nothing was
being drawn yet. To render a client I'm using the [
crate, which is a Rust clone of the [
love] framework. I'm not a
huge fan, and if the game was any more graphically ambitious I'd
want to find something else. But seeing as I'm only really drawing
simple 2D graphics and doing some camera (i.e. viewport) manipulation,
this will do.
The following screenshot demonstrates the current client state. Sexy, I know!
The asset loading probably took the most effort in this demo. I'm
creating art assets in inkscape as SVGs, loading them at game start,
and converting them into sprite textures with
librsvg. This way the
game can scale across many resolutions while not requiring a very
large assets directory.
On the server side I looked into using QUIC for client-server
communication, but the only crates I could find were either
synchronous, or used tokio. The rest of the game is built on
async-std, and I didn't feel like either adding a second runtime or
porting the game. So instead for now I'm using the async-std
UdpSocket abstraction, and if I run into packet delivery problems
later, I'll either switch to
TcpSocket, or write an async-std
wrapper with the [
What I'm planning for next week
So far the rendering is largely disconnected from the backend map types. Ultimately the renderer needs to be able to render a mesh of nodes that are distributed through a 2D space, with links between them. Each link also needs to have a length based on the distance between two nodes, that determines how long it takes packets to traverse it.
I already defined a structure of how maps work (as sets of nodes and links), although currently without x/y coordinates. In the next week I want to integrate map loading into the asset loader (and also make the asset loader available to the server which ultimately needs to load the map configurations)
Maybe I'll also make enough progress to have a first packet traverse a link. But we'll see!