Librarian of Alexandria

A friend of mine who does some streaming has recently been streaming his progress following a roguelike-making tutorial, and I've been backseat programming as he does so. This has resulted in a couple of things so far.

For one, it really struck me how repetitive definitions of specs systems can be. Accordingly, I've been working on a small macro that can make those less tedious by cutting down on repetitive boilerplate: for reasons of both typedness and efficiency, the specs implementation of systems requires some modest verbosity (like plumbing through lifetime parameters and lining up SystemData declarations with their uses) that, with the help of a little bit of convention, can be cut down a lot.

This in turn has been making me ruminate—albeit idly, with no specific work yet—on the idea of a programming language built from the ground-up around entity-component systems, a topic I have considered before but still have not done anything with. If nothing else, I'm going to write a series of notes and thoughts on what an entity-component language designed for immediate practical use might look like: that is to say, how I can imagine building such a language so that it can be used in practical projects despite not having a large library ecosystem or user community.

In a different vein, I also had previously been poking at the game programming framework ggez, which (despite the off-putting name) is a very well-designed and thoughtful framework for building games quickly and easily. I like a lot of the ggez abstractions and it's been very pleasant to get up and running. I've consequently decided to follow the same roguelike tutorial, but instead of using the roguelike library the tutorial uses (RLTK, by the same author as the tutorial, and a port of the author's earlier C++ library of the same name) I'm working on my own, a relatively thin and heavily subject-to-change layer over ggez and specs, which I'm currently calling carpet on the grounds that carpets are ruglike. I'm not terribly far in, but after my work today, I'm comfortable that I'm not starting off on completely the wrong foot, so I am putting the work-in-progress repo on my personal gogs instance.

Finally (and annoyingly pedantically, I know) I had a conversation with my aforementioned friend about how I would have structured parts of the code produced by the tutorial differently—in particular, I felt the tutorial author could have used more systems, both in the sense of splitting larger systems into more single-purpose ones and in the sense of taking code that was not expressed as a system at all and putting it into one. In order to express more clearly what I meant, I decided to put my money where my mouth was and do a refactor of one specific chapter of the tutorial to explain where my design sense would have pushed it; right now, this is also just on my personal gogs instance without any particular commenting or guide as to what I did, but I might write another blog post that talks about the process just to give a better guide to my thought processes.

I'll try to jot notes as I do more of the work around this area, 'cause I think it'd be fruitful even if some of these avenues don't go anywhere. Negative results are results too, after all!