Devebruary (Week 2)


⇠ back | tags: /dev/diary, hackerthon | duration: 02:19 minutes

At the beginning of the month a friend a I decided to spend four weeks seriously hacking on our games, and blogging about it. We called this event "Devebruary": this is entry for week 2. You can find week 1 here.

Current state of the project

This post will undoubtebly be much shorter than last week's. I didn't get to work on the game as much as I would have liked to. I did however spend a bunch of time working on basics that I need to continue.

I wrote a map file loader for the server (and client too I guess), which wasn't too hard. The next problem I had was that I didn't just want to write one of these files by hand (which is certainly possible), but already felt like I needed to have a way to edit maps in-game. So I started working on a map editor. You can launch this state by passing --editor to the client as an argument.

As part of this I also needed to deal with the fact that the ggez crate doesn't expose any sort of UI element system. It bundles the lyon crate with some utilities to draw meshes, which I decided to use to write UI elements.

I started with a simple button which can be clicked.

RST Node button example

Next up I tackled the input and event system in ggez. There is a central trait called EventHandler, which provides a set of functions that should be called during update, render, and other event times. The problem is that there's no mechanism to provide the main event loop with more than one of these objects, meaning that a lot of user-space code ends up just passing these objects around and calling the correct function on something.

So instead of doing that I wrote an EventLayer abstraction which takes a set of event handlers (which can also be created during runtime!) and proxies events to them. This obviously adds some run-time overhead, but the effect on code quality has so far been very positive.

So this week then...

I hope to finish my input refactoring today, and hook up the UI initialisation code to it. Then I can start building UI building blocks that automatically react to events as they happen.

The same input trait that buttons implement should also be implemented by all other game elements: nodes need to be selectable after all...

I'm wondering if there should be a management type in between the input events and the game entities, or if its sufficient to have them each be managed on their own.

Also hopefully I'll have more screenshots next week