If you are familiar with this image and know what it refers to, then you are probably too deep into internet and twitter discourse and I feel sorry for you. But not all hope is lost, and even though you can only watch and you are powerless, things might just get a little bit better!

(you can only watch)

Good thing I don’t have to worry about any of that, I have *my own* game engine! (and kids, that’s how I spend three months trying to get a sequence of characters showing up on the screen without breaking everything)

but anyway, what goes into making a UI?

On the gif above that I posted on X (formerly Twitter) you can see a simple tactics-style movement and combat! And I’m very proud of that. But I absolutely hate the sequence of characters “o to wait i to attack u to move” that you can see on the top left corner of said gif, and, of course, the final video game shouldn’t be like that, that would be absurd. So what is the solution?

The solution, of course, is User Interface. We don’t want “o to wait i to attack u to move” – We want a list of options that you can navigate through, and these options happen to be “Move, Attack, Wait” – But not only that, what if we want to change the option “Attack” to “Act”? What if we want to add more options? We need a flexible User Interface!

So that’s the story of how I started working on the User Interface of my game engine, machinist.

So I started doing some research, and by doing research I mean opening Godot and taking notes on their UI structure, as well as opening the book “User Interface Programming for Games.” and copying their UI structure. With that, I had a few classes on my engine:

  • A Control class – This is the base for all UI elements, a control is basically a *thing* that will exist within the UI.
  • Some specializations in Control, like a Container class (holds a list of controls), a Label class (a control that has text), and a Panel class (renders a beautiful 9-slice panel that can be resized)
  • And of course, a UI Manager, and a broad Menu class.

Things started getting a bit more complicated when I wanted to make a list of elements in the UI. The idea is simple.

Let’s say I have 3 labels. I want to add these three labels into a List class, and I want the list to handle repositioning them and rendering them. That is achieved through having a ListItem and a List class, which basically just holds a gueepo::vector<ListItem>

That’s not exactly where it gets complicated, since a list really just keeps track of a number (its position), and then just adds the width/height of the items into that to reposition the items, just basic math, really. The rendering is passed on to the control itself, so the ListItem/List don’t have to worry about it, so it’s pretty much like not having to do any work at all!

It gets complicated when you ask the following questions: When selecting an option in the list, how do I execute a function? How do I make it so a machinist::Menu talks to machinist::BattleSystem? – Solving this specific case is doable, machinist::BattleSystem can be a Singleton, or we can have static functions. We can add a callback on machinist::ListItem and there we have it, but how do we solve the broader problem? What even *is* the broader problem?

The broader problem is: “How do we separate menu structure/visual and menu logic?” Not only that, but the problem is also “How do we separate engine-side menu and game-side menu?” Things can get a bit cumbersome here if you want to keep a data-oriented approach, what exactly is menu data? Just a description of elements and position? Where do you store the logic? Every menu is its owns .cpp file? Do you want to add a scripting language just for the UI? How would you do that?

Well, I don’t have the answer for any of these.

But my current approach will be to work on creating a better separation between engine and game, not just for UI, but for *everything,* which basically means that I’ll put a pause on the UI work for the moment and work on some restructuring and refactoring. Fun !!

Since we are talking about restructuring and refactoring, maybe it’s time to revisit gueepo2D and do some needed work there as well, it needs some tweaks and a GUID generator system, so we can set up better data-oriented approaches on machinist. Fun !!

If you have followed everything that’s going on here, you will notice that we started up with “How do we make a UI system for an engine?” and ended up with “Welp, I have to refactor and work on the structure/architecture of the engine.” Which is a recurring thing in game engine development !! Fun !!

So that’s what I will be doing for the next few weeks. Maybe I can have a videogame finished by 2027.

banger

Leave a comment