website: publish devebruary part 2

infra/website/content/blog/122_devebuary_part2.md

@@ -0,0 +1,65 @@
+Title: Devebruary (Week 2)
+Category: Blog
+Date: 2021-02-22
+Tags: /dev/diary, hackerthon
+
+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].
+
+[week 1 here]: /blog/devebruary-week-1/
+
+
+## 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](/images/rst-node-week2.png)
+
+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