Devebruary (Week 1)


⇠ back | date: 2021-02-14 | tags: /dev/diary, hackerthon | duration: 03:00 minutes

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

Relay concept part

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.

Compute node concept art

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.

Attack node concept part

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 [ggez] Rust 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!

Current game state screenshot

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 [quinn-proto] crate.

What I'm planning for next week

General node design

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.

Packet and trail designs

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!