And Then Time Passed

I'm really bad at communicating progress at the same time as making progress. It's been a hot couple of days, and the 7DRL is now done. How did we do? Let's see!

The game we made this year is called Beneath the Throne of the Goblin Queen. And it's a complete game! It's fairly small - the starting screen, an intro level, three or four levels with (hopefully) different themes , and an two-level ending section that I won't spoil! You've seen the design when we were starting off, and we executed around 30% of that design. It seems like a lot, but when you consider that we had 24 projected glyphs, that still means we got 8 good ones in! Here's what that looks like in practice:

As bare-bones as it seems, I'm quite happy with the result! Last year, when I was doing HELLTH, the design I had fundamentally collapsed into a mush of barely coherent names with low internal connectivity. The magic system collapsed into noise. The functional distinctiveness of the enemies cascaded as a result of that fall. The way projects scale is something that I'm taking a serious interest in with these designs. I think that this year's game, shorthand BtT(otGQ), has withstood collapse because we chose pillars which aren't directly in the mechanics and design that can be cut.

The three design pillars of BtT are:

1. Magic can reach anything (no number is safe, no thing unchangeable)
2. Magic is spatial (there's a want to consider steps carefully because of this)
3. Spaces tell stories (narratively involving the player but not mandating attention)

The only way we could think of for making #1 and #2 work out in a way that wasn't just the grid-based, turn-based version of Magicka, or an Excel sheet, is to try and make magic be very soft. You get Words of Power, but you don't control it. It activates when it feels you need it. It was important to make this clear: you will be healed, you will be in light, you will endure. I wanted the tension between the free mind of the player and the constrained cage of the Power to be palpable. The best way, it seemed, was to make it into a resource. You feel tense seeing Tension fill up. You also can't stop it, so it was important to make it something that the player doesn't just dread: there needed to be a reason you'd want to work with it, instead of simply running away. We need you to understand that tension, I guess. The transcription of tension-in-design to tension-in-play to tension-in-strategy has been a very interesting part of this project, and one that I think I'd like to continue playing with. With the pillars being so removed that we don't actively perceive them, we couldn't cut them out even if we wanted to. Implementing the glyph of [LUCK], for example, not as a system, but a bunch of loose modifiers on other things definitely helps to make it feel magical, as if it's setting the mood. Doing the same with [LIGHT] made it feel like the Words of Power had a will of their own that didn't always match yours: walking by a furnace suddenly becomes very dangerous if you're a LIGHT user – the first two pillars are interacting here all on their own.

As for the third pillar, I loved putting bits and pieces of it in. If I were to make a larger game, I'd dedicate a week of time to each bit, honestly, it felt so amazing.

Of course, designing the game was only half of the #7DRL25 experiment. The other half was looking at the SVAROG engine from the outside in, seeing it as a tool and taking notes on what can and should be better. The part that didn't surprise me is that there's a lot of work to do still. The part that did surprise me is that the tools I wanted aren't the tools we made! It seems that there's a discrepancy between what tools I imagine I'd love and the tools I've had us build up over the previous couple of months. From the get-go, I've had a simple statement of intent:

I want to have a tool for quickly prototyping roguelike mechanics.

Along the way, we built a tool for building roguelikes, and it works. How well does it perform when it comes to quickly prototyping roguelike mechanics, though? Not well at all. There's no separation of design concerns, there's no testability of design ideas, and there's no framework for quickly gauging the feasibility of a concept. We, I now understand, don't know how to design design. Designing design, esp. with regards to tools, is a hand-wavy discipline that loves to push for results because it has huge imposter syndrome problems. Underpinning it is a fractal question of "how deep do we need to go with tooling to go deep enough", being that, as tools designers, we're designing not a layer in the architecture, but the whole of it. I've met this question head-on while working on GRASP, and I can tell you that my answer was and remains "deeper". Why I'm not there now comes down to "money", sadly, but even just discussing it helps.

Fractal Unicorn Tools

I've learned of the MarkovJunior library during this week. It uses linear pattern-matching transforms to cover all of one's procedural generation needs. It's a lovely idea and a powerful tool that is close to what would be my ideal approach to procedural generation: a unified language for it. What kills it is that the thing you're designing looks like this in a presentation:

And like this in development and testing:

<sequence values="BWRUGE">
  <one in="B" out="W" steps="1"/>
  <one in="B" out="R" steps="1"/>
  <one>
    <rule in="RB" out="RR"/>
    <rule in="WB" out="WW"/>
  </one>
  <all in="RW" out="UU"/>
  <all>
    <rule in="W" out="B"/>
    <rule in="R" out="B"/>
  </all>
  <all in="UB" out="UU" steps="1"/>
  <all in="BU/UB" out="U*/**"/>
  <all in="UB" out="*G"/>
  <one in="B" out="E" steps="13"/>
  <one>
    <rule in="EB" out="*E"/>
    <rule in="GB" out="*G"/>
  </one>
</sequence>

Even as someone with a very limited visual imagination, I have zero intuition for the latter, but a lot of it for the former! I think I'd dare change the picture above and play around with it. I wouldn't touch the XML file with a stick. We need better tooling. The design philosophy of MarkovJunior is right and I want to go for it within the tools design as well: we need one tool to work for many use-cases and cover them in such a way that allows for its extensions are the tools we need. We need a fractal unicorn tool.

We're not there yet

Where did the time go this time around? We've spent the last three days on implementation, but even then (as we didn't have full days on this) only a small fraction of that was in prototyping actual dynamic situations and fun mechanics. Most of it was (in order of least to most annoyance) spent thinking about and entering data, messages, descriptions, hooking dependencies for different elements in the game (that might fly out if we see time is short), figuring out cryptic Lua errors and finding places where execution should have been terminated but wasn't due to how liberal Lua is. If the variable entityy doesn't exist, surely you just wanted it to always be nil and definitely didn't mean entity. To check whether a component is present in the ECS looks like it can be done with an expression like if entity[Comp] then, but this actually doesn't work and returns... something else to the expression you want to be using, which is instead if entity[Comp] ~= nil then...

For a project any larger, it would have been a death by a million cuts. Even for one this size, it was overwhelming. I also had the repetitive strain injury that is ECS discipline: do we define components close to systems or not? Do we have separation by system or by feature group? How do we handle component cross-contamination? How much reuse do we want in component space, and should we have component aliasing? Should components have uniform interfaces, and how do we enforce this? I want tooling to cover these problems in a transparent way. I want it to be as every-day as it is to get a squiggly red line underline words to tell me I'm wrong. My fear is, however, that we've reached a plateau of tools design in general, and are working with very low floor and ceiling technologies that can't allow us to move up, and it's just getting worse because we're encoding that this is normal. It most definitely shouldn't be. In fact, as for what I wish to do with the tech stack we currently have, here's a sneak peak behind the curtain of BbT's development:

I have a lot to talk about in the coming weeks and months, so stay tuned.