The origins of Alkemion's Crucible

The Origins of Crucible

I love brainstorming new scenarios, sourcebooks or backstories. Starting with a blank page, setting some constraints, adding random pieces, finding connections, and pulling the thread until something cool emerges. This process is one of my favorite parts of practicing RPGs. It can almost be a game in itself. After all, solo roleplaying is built upon this brainstorming and writing feedback loop.

I started RPGs in 1989 and played for an uninterrupted period of 12 years, with 2 to 4 game sessions per week. Then life and priorities changed, and I completely stopped for twenty years. I only started looking into RPGs again during the pandemic, which I think has been a pretty common pattern. I discovered a whole new world of games, creators, software, and habits. It was amazing, and quite overwhelming.

I began writing scenarios again, for my own pleasure, and for a medieval fantasy campaign I started in the first COVID year with my son and a few friends as players (and that is still ongoing).

A couple of years ago, I discovered Justin Alexander’s blog “The Alexandrian” (I’m late to the party on this one, like for a lot of other RPG things). The series of posts on node-based design blew me away. By their own merits, of course, but also because they articulated the way I have always been conceptualizing and structuring the content I wrote for my own games in my brainstorming sessions. I’m sure others felt that way by reading these essays.

My background is in software engineering, and as far as I can remember, I’ve always intuitively viewed RPG module writing with an object-oriented approach. Software development concepts such as reusability, modularity, and inheritance always seemed to fit perfectly. In my early RPG years, I filled tons of handwritten pages with content “building blocks” that I could use and reuse between scenarios and campaigns.

Reading Justin Alexander’s essays and discovering how popular they were, I felt a kind of “approval” in this nerdy way of thinking and writing modules. And I think that’s all I needed to unlock some desire I had for a while to build an application around this concept.

Object-oriented design was the first half of what I wanted to incorporate into the project. Brainstorming and crafting modules is a very enjoyable experience for me, and I suspect for many others. I wanted the application to enable its users to find and emulate those creative gears that made this process fun for them.

Then my son played a crucial role in turning these ideas into a real project cumulating tens of thousands of lines of code over ten months. As a young self-taught software engineer, he was looking for a first solid project to consolidate and practice what he learned. And even though we both code in the project, the most complex parts and the overall architecture were his doing. While I brought my experience and a piece of the product vision, he quickly and naturally became the technical lead and the first code contributor.

As I’m writing this post, we've only started a closed beta with a few users willing to crash-test what is still a very young application. We're excited about the future. We have strong and fun ideas for what could be next on the roadmap, and user feedback and suggestions will heavily influence the process. We've merely built the foundations, and we're eager to see where this path leads, together.