I need to make the game’s primary pipeline, which includes proper timing for when the world is generated and dismantled — when the player is playing or in the menu. From plyer’s perspective, this comes down to having menus, world loading, pause screen, transitions, etc. So that’s basically how I am approaching this — UI with implication that the underlying framework is needed first.

First of all, I need to do some preliminary HUD work. I currently have a HUD systems, but I am going to convert it into a UI system and just have HUD elements be same sort of UI windows that I can open and close as needed with all the callbacks to control them nicely. I really don’t want to keep two systems that basically do the same.

Long story short, here are all my HUD elements — hud panels/windows organized and prefabed (and to see how many there are already for early scope creep prevention):

I need to add main menu, options menu, pause menu, victory and death screen, etc. I won’t go into details, but I already made a simple panel window system for previous prototypes, expanded for River Hex Connect and have been adjusting slightly since. So let’s start with a main menu (I have most of these sprite-less font-less panels left from River Hex Connect):

Before I can wire this in, I also need to make some game state stuff and wire a proper “start world” and “stop world” logic as well as gameplay-only updates for all my gameplay systems (which is most). With that done, I can actually press play to play (that is, only start the world and update the systems then). I can also make the options panel transition and have my (previously-made) sound controls:

I can also add a pause menu panel:

Not that it actually pauses anything. So I need to make a game state for this, and have all the systems wired to receive pause and unpaused events so they can handle anything they need, such as cursor capturing or music changing.

I can also wire options panel to work “in-game” same as via main menu (just return to pause panel instead of main menu when playing):

When the player dies, I can show the death menu (without pausing the game):

There’s no real “restart”, because I have only one level, so it will just restart the same world.

I don’t have a victory condition yet though. I do have the exit prop/hatch and I can (temporarily) have the player press “E” or something when neat it to trigger “victory”. This is a bit tricky as the player gets removed (which is currently how death works) and I need to rewire everything to understand when the player dies vs “teleports away”. And with a little finicking around, I can show the win menu:

I don’t really have any “continue” either, so it will just restart the world.

Now, the world generation takes a second or two. And I really need a loading screen, if not a progress bar. This is a bit tricky since I have to insert a UI panel reacting to world creation in a specific way. Currently, the world is generated on the same unthreaded frame, no matter how long it takes. I can’t convert it all right now, but I can add some rudimentary states to loading stuff for future integration. And that works for now:

I have a bunch of debug stuff for quickly restarting and just starting the game directly into the level, and I really want to keep it all for quick testing needs, so I’m adjusting as needed.

There’s a few items I need to take care of, such as a reusable confirmation window to confirm abandonment or quitting the game:

Except a small problem is that I the background panel is still visible, so I ideally want to optionally automatically fade a panel (even if my actual art will likely include a window background):

And now I have all the UI panels (again, seeing them as a list helps visualize just how many there are already):

Of course, art for all of this is pending. I will also cover exact content of each menu, like options, separately. A lot of this will be towards the end of the project when I know exactly what is needed and I am basically wrapping up.

And this makes my main UI pipeline more or less complete. This isn’t a long entry, but this is an important part. UI is hard. Keeping the game stateful and UI organized is way harder than it sounds unless one makes sure to have a framework ready and establishes a pipeline all systems follow and separates UI from game logic well. Otherwise, bugs and issue will just continuously keep cropping up. At some point, cost to add or change UI will just be unjustifiable.

MicroRogue DevDiary #39 – UI framework
Tagged on:         

Leave a Reply

Your email address will not be published. Required fields are marked *