Programming the UI for Inkbound
Hey Inkbound fans, I’m Muhammad Abdul-Rahim, better known to the community as Marimo. You may have seen me on a few of the weekly streams, filling in when either Cami or Andrew are unavailable. Well, today, I’m here to give you an inside peek into what it’s like to program the UI in this game. I’ll try not to get super technical with these details, but it might lean a bit in that direction!
Let’s start by dissecting a simple screen: the StatHudScreen!
In game, this screen shows up in the bottom-right corner of the HUD. It displays a small subset of important game stats that you can quickly reference without having to open the more detailed Stats screen. So, first things first, let’s look at the layout of the screen:
The cubes represent objects in the hierarchy for this screen. Blue cubes represent prefabs, shared components that I can copy and paste as needed. Changes made internally to a prefab are reflected on all instances of the prefab, which is useful for visual components that are reused throughout the game. Let’s now take a look at an individual StatEntryUI component:
It’s actually quite simple: just an icon and a text label. The icon seen above is just a placeholder visual for the actual icon: the icon of the stat itself. This is where things get a bit complicated, as two invisible forces work to populate this simple UI component:
Luckily, the numeric label is just that: numeric. As such, we can configure it to not support font switching between locales, as our other text labels support. This ensures the numeric display will be identical for this component across all locales. That is useful because the amount of screen space we have on the HUD is limited, so we’d like things to be the same across locales, if possible. We only hit that checkbox for purely numeric labels, and only sometimes, as the need arises.
Looking at the high level of the visual script, we see our references to the 12 UI components that comprise the StatHudScreen, but we also see a different reference above it, one to something called StatCategoryVisualData. Let’s look at what’s going on in there…
Wow, it’s kind of complicated! This visual data object contains a lot of information on all the stats we want to visualize throughout the game, the categories they belong to, rules on when they can show, if they can only show in the HUD or if they can also show in the more detailed view, and beyond. This piece of data is referenced in multiple places in the game!
Scrolling to the bottom of the object, we see our references to the stats we want to display in the HUD. It is this list that the UI visual screen uses to determine which stats to showcase. Any designer can go in and specify the data with the tools provided in the game engine editor. This allows anybody to make changes to the visual HUD display, both here and in the detailed stats view, without having to adjust code further.
This gets to the crux of why we put the effort in to expose functionality in the editor and outside code: we want the game to be easy for designers to maintain, and we don’t want to force the designers to learn how to code just to do something as simple as reordering stats in the HUD. The core of my work is not so much making the game directly, but rather, making the tools that make the game. In other words, creating a wrapper atop the engine, a framework, with which Inkbound can be crafted.
If you made it this far without getting bored, congrats! Thanks for reading this, and thank you for playing Inkbound. I look forward to crafting more and more content for you to enjoy!
Let’s start by dissecting a simple screen: the StatHudScreen!
In game, this screen shows up in the bottom-right corner of the HUD. It displays a small subset of important game stats that you can quickly reference without having to open the more detailed Stats screen. So, first things first, let’s look at the layout of the screen:
The cubes represent objects in the hierarchy for this screen. Blue cubes represent prefabs, shared components that I can copy and paste as needed. Changes made internally to a prefab are reflected on all instances of the prefab, which is useful for visual components that are reused throughout the game. Let’s now take a look at an individual StatEntryUI component:
It’s actually quite simple: just an icon and a text label. The icon seen above is just a placeholder visual for the actual icon: the icon of the stat itself. This is where things get a bit complicated, as two invisible forces work to populate this simple UI component:
- The numeric label is localized, such that it will display properly across all supported locales
- The icon sprite is loaded via the addressable asset system, such that the image for the stat is not put into memory until it is needed, so as to reduce memory consumption and boot time of the overall title
Luckily, the numeric label is just that: numeric. As such, we can configure it to not support font switching between locales, as our other text labels support. This ensures the numeric display will be identical for this component across all locales. That is useful because the amount of screen space we have on the HUD is limited, so we’d like things to be the same across locales, if possible. We only hit that checkbox for purely numeric labels, and only sometimes, as the need arises.
Looking at the high level of the visual script, we see our references to the 12 UI components that comprise the StatHudScreen, but we also see a different reference above it, one to something called StatCategoryVisualData. Let’s look at what’s going on in there…
Wow, it’s kind of complicated! This visual data object contains a lot of information on all the stats we want to visualize throughout the game, the categories they belong to, rules on when they can show, if they can only show in the HUD or if they can also show in the more detailed view, and beyond. This piece of data is referenced in multiple places in the game!
Scrolling to the bottom of the object, we see our references to the stats we want to display in the HUD. It is this list that the UI visual screen uses to determine which stats to showcase. Any designer can go in and specify the data with the tools provided in the game engine editor. This allows anybody to make changes to the visual HUD display, both here and in the detailed stats view, without having to adjust code further.
This gets to the crux of why we put the effort in to expose functionality in the editor and outside code: we want the game to be easy for designers to maintain, and we don’t want to force the designers to learn how to code just to do something as simple as reordering stats in the HUD. The core of my work is not so much making the game directly, but rather, making the tools that make the game. In other words, creating a wrapper atop the engine, a framework, with which Inkbound can be crafted.
If you made it this far without getting bored, congrats! Thanks for reading this, and thank you for playing Inkbound. I look forward to crafting more and more content for you to enjoy!