This weekly debrief is for paying supporters of my work. Please only read if you’ve paid. Thanks!
→ Click here if you've paid ←
This week has been spent finishing off the Patreon account and then starting on the preliminary stages of the Bedrock Public Library.
Patreon
I’d been interested in the idea of starting a Patreon account for a while now, so I’m glad that I finally got around to setting everything up for it.
I’ve been working in the public eye for only a few months now, it was in April of this year that I first released Torque to the world. A lot of that time has been spent figuring out how I can share what I’m working on, how to get out of that mindset of toiling away in a dark room, emerging only once or twice a year to share the fruits of my labour. I never really grew up with social media, and I used to be more nervous about posting my work to the internet
I feel like I’ve stumbled into something good with this format here. I’ve been enjoying the rhythm of posting short updates to Mastodon every week, but there’s only so much I can talk about before a post is just too big. With these debriefs, I can share work-in-progress photos and little anecdotes, digging into the reasons behind the design and structure of each project. In exchange, people can throw a coin my way to keep things ticking along between releases.
Anyway, most of the work with setting this up was in all of the small details: writing an introduction, writing descriptions, making a banner and logo and images for the tiers. I had some fun going on a small photoshoot, I needed some photos to let people know that I’m a real person.

I enjoyed working on the component images that I used for the tiers, especially the part where I figured out the general aesthetic to aim for. I ended up going for a gritty, beat-up look, building up layers of textures that interacted with the lighting in interesting ways. I really do love Blender, it’s a magical tool.

The Bedrock Public Library
This was the most interesting part of the week by far, I’m really excited to finally be starting work on this project.
The idea behind the Bedrock Public Library is to create a sort of community hub, somewhere that all of the people who are interested in Bedrock can come and share code and ideas, instead of working away in solitude. The website will be a big index of programs and libraries written for Bedrock, with popular programs being showcased, and then with some kind of forum eventually being added on for discussions. Something like a cross between the PICO-8 BBS and a package manager (npm, pip, take your pick).
The package manager idea is worth diving into a little. One of the big obstacles with learning Bedrock is that it comes with no standard library, so there’s no simple way to just jump in and start printing strings and drawing sprites and all of those standard programming tasks without first sitting down to really learn the whole system. It’d be so much better if people could play around with a standard library of functions and see some results, to convince themselves that the effort of learning the system will be worth it. It also doesn’t make sense for every person who uses Bedrock to have to come up with their own implementations of basic functions themselves, when a perfectly good implementation probably already exists on someone else’s computer.
I really like the metaphor of borrowing books from a communal library. The more confident programmers among us can implement efficient and sensible versions of common macros and functions, and then anyone who visits the library can check out a copy to use in their own projects. We can go further by working together.

Breaking ground
I used to work on REST APIs and JavaScript front-ends at a previous job, so I’m fairly familiar with how to tackle this kind of thing, but I’ve always used Python for the back end code. I no longer use Python for anything serious these days; it might be fast to throw together, but you’ll pay the piper at runtime. No, this job calls for Rust.
There are a lot of moving parts to this endeavour:
- the front end
This will be written using a JavaScript framework, it’ll involve rendering a lot of components from dynamic data served over an API. I’ve used Vue at work in the past, but after a quick glance it seems like it might have changed a lot (grown a lot) since then. I want to find something relatively simple and lightweight. - the back end
The API is going to be a single executable written in Rust. I’m using Diesel (an ORM) to query the database, Actix Web as the HTTP server framework, and Serde to marshal data to and fromJSON. I’ve never had much of a chance to play around with massive libraries like these, it feels like I’m using a totally different language. There’s so much to learn. - the database
All state is stored in a PostgreSQL database, except for the uploaded program and library files (which will be kept compressed on disk, with references stored in the DB). The database and the API will be running from my little server box that lives beneath the couch, with daily (or hourly?) backups in case something goes horribly wrong.
I’ve been working at this for the past two days, and it’s all going really, really well so far. It’s been a few years since I did any full-stack stuff and I’ve never used any of these libraries before, so I’ve just been devouring huge amounts of documentation. I’ve reached the point now where I’ve got a real API serving real data from the database, which is just fantastic.

One thing I’ve been loving in particular is the static type-checking that I get from Diesel. I don’t really understand how it works under the hood, but Diesel is able to reason about the schema of your database (declared using macros in Rust) to prevent almost every query-related error at compile-time. I stumbled across a conference talk a few years ago called Type System Tips for the Real World where the lead developer of Diesel talks about some of the advanced compile-time reasoning that Diesel is able to perform using the Rust type system, and it blew my mind. It’s great stuff, I love that I finally get to play around with it.
Thanks
Time to sign off, it’s been a busy day. Thank you so much for your support, I’m really looking forward to sharing more progress on this project with you next week. See you later!