SpaceGirl | Little Game Dev, Little UI

I told you the next one was going to be about game dev, though thats kind of a lie. This is more of an introductory post, so expect more posts on individual features in the future.

So, what in the world are you seeing in that image? There's a lot of garbage going in there, so I wouldn't blame you for being confused. This is a "playground" of sorts to prove (mostly to myself) that creating a game with thousands of mob/projectile interactions is not some crazy hard CS Master's Degree problem that can't be solved. All you need is first principles, non-pessimized code, and (even a minor) understanding of modern CPU architecture (this will probably be a separate future post).

So what is that image?

Honestly, not a whole lot (in terms of amount of code and complexity). Like I said in my last post, making bespoke software really isn't that complicated. That's not to say it's easy, but it's simple, which is an important difference. As of 2024-09-30, there is approximitely only around 1.6k LOC for this entire application (not including deps, of which is only raylib). And that includes a whole UI lib (incomplete mind you, but still very useful), a minimal level editor, simple physics (just AABBs, but hey isn't everything just a box?), and spatially partitioned entities (ironically the current implementation is pessimized tho).

Anyway, the beautifully colored cubes are all entities, while the big pink boxes are level geometry. And all those gray lines everywhere are a wireframe of the (really bad) octree that partitions the entities. The view you see there is when you're in edit mode, the game looks more sane without it.

And here is a little example of using the level editor

And currently the only UI that exists:

The "Game"

I plan for this game to be a minimal clone of Risk of Rain 2, a rogue-like (rogue-lite technically, but only I care about that distinction) with the goal of beating the end boss by collecting a number of items that modify your stats synergistically. The stat modification in particular is what I'm most interested in building. I'm a systems developer, so I'm much more comfortable building the gears inside the pretty box rather than making the box pretty. Which is precisely why this interests me, even without building anything I can just imagine the kinds of problems you'd need to solve with the number of interactions that exist.

As an example, in ROR2, there are items that allow you to heal after you deal damage to an enemy, and items that proc (trigger) after you've healed a certain amount. Just these two items pose questions about how you architect a system like this, because a single interaction (dealing damage) can cascade into multiple other disparate interactions. And when potentially thousands of entities can carry these items you need to think carefully about how you layout and process your data since you're dealing with something even worse than O(n^2) (I mean, imagine items that allow other items to trigger multiple times).

I haven't started work on building this system yet, but I plan to in the near future. These posts are mostly a checkpoint for myself to see how far I've progressed on this. However, there is stuff that I have built that is worth talking about.

The UI

UIs have always been the most annoying thing when making any sort of project, because they were either locked into some framework (QT, WinForms, etc.), or something easy to use (Dear ImGui and others) but where I didn't understand how they worked. It's only the past few years or so that I've been trying to understand how the pillars of modern software actually work. And what do you know, they're simple (not easy, simple).

Last year I had read a series of articles from Ryan Fleury about UI here. It was a real eye-opener about approaching everything (not just UI) from first principles and asking the question "What are you really trying to solve?" I don't want to essentially re-write what he did (you should read it yourself, it's good), so I'll explain how this set the course for how I built my own UI library for myself (the "for myself" part is important).

You have to completely change your perspective on what UI even is. It's not the hamburger menu, it's not a checkbox, and its definitely not the intrusive-fullscreen-GDPR-compliant "we're storing your data" box. No, all UI is, is a region that can (or can't) be interacted with. I know that sounds obvious, but if you don't actively think about UI as purely a region of (non)interactivity, you can paint yourself into a corner implementation-wise and be solving a problem different than the one you actually wanted solved. For example, and Fleury makes a similar argument, if you go about designing UI "components" like buttons, labels, and checkboxes as first-class objects, then you've setup your toolbox at too high a level of abstraction so that now all you can do is build UI with buttons, labels and checkboxes. What if you want to build a cool and fancy button that has an embeded checkbox (or a custom Game of Life simulation with user input). You now have to either build an entirely new component with duplicate logic for handling button presses and rendering a checkbox state, or frankenstein your way to conditionally rendering a button around your checkbox component. Instead of solving the problem of building your cool and fancy new button, you're solving a problem that the rigidness ¹ of your current architecture has burdened you with.

So, thinking in first principles, what is a button and what is a checkbox? You can click both of them. They both have labels on them. They change color if you hover over them. Forgetting about rendering for a minute here. These seem like the exact same "component". The only difference being one of them modifies some state (note I didn't say "contains some state"). Why not just make them be the same? Now in practice, it's a little more complicated than that. Thats why I said to forget about rendering, since a button and a checkbox look very different and you have to accomplish that somehow.

But...How?

I'm glad you asked, non-existant audience!

Just make everything the same object with flags that control what kind of behavior that object supports. Now obviously there aren't enough flags in the world to define every kind of UI element you'd want to create. That's why you'd define UI elements as a hierarchy. You want to make a UI object look like a button? Just add the Text and Border flag. Want the button to be clickable? Add the Clickable flag. Want a checkbox? Do the same as the button, but add a child element that has a BackgroundImage flag linked to an image of a checkmark (maybe I'll make a future post about UI themeing). And finally, you want to make that checkbox button hybrid? It's as simple as changing a couple flags.

It's a fully composable system. It has just enough built-in tools to be able to create more abstract tools (such as a checkbox), but doesn't hinder you when you want to make some bespoke change to a single UI element. And this is precisely the problem you actually wanted to solve. A way to build UIs.

The future?

I know this was a lot about UI and less about game dev, but thats mostly because I got carried away building the UI so there isn't much "game" to speak of. Once I have what I think is a good base for the Stats/Item system in the game I'll write my thoughts on the subject.