A Task Most Avoided

Let's get this out of the way up front: I don’t like designing UI.

There are some things that come to me naturally, like juggling or sculpting tiny animals out of clay. UI design is not one of them.

Back when I first started building websites many years ago, UI was the thing that always caused the most friction for me. Sure, I understood the general concepts of creating easy navigation and clear paths for the user, but the actual look and feel of it is where it usually fell apart. Most of the time it ended with a bunch of ugly menus and weird buttons.

With practice and experience I got better, but I'd never call myself "good" at it. So when it comes to putting UI into my games, for a very long time it was a step I'd keep pushing further and further down the to-do list.

But again, experience is the best teacher.

Confronting Your Fears

From working on Station Zeta, Camp Keepalive, and then Bleakwatch (as well as some other smaller projects along the way), I learned the longer I kicked the UI can down the road, the worse I was making it for myself in several ways.

First was the obvious issue of having to rebuild a lot of things. Kludging together a lot of placeholder buttons and menus just to make things function “well enough” for the prototyping phase was fine. Keeping things in that state as more and more of the game was built out just meant extra work undoing things later.

Extra effort aside, the key thing I’ve learned about avoiding UI is you miss out uncovering a lot of underlying issues with the game itself you might not have thought about.

I can only speak for myself, but I know I make a fair number of assumptions about how the game works as I’m building it. I know the player can click on an adjacent unit to attack it. I know which spaces on the battlefield a piece can move to. I know why the ranged unit out of position in the front row can’t attack this round.

That’s because I’m the designer: I know what everything is supposed to be doing. But an actual player doesn’t have that benefit - they need all of this information communicated to them in a way that makes sense. Building a UI forces you to think about those questions, and often makes you realize there are questions you hadn’t even thought of that also need to be answered.

Information Society

I started my UI journey on the first part of the game I'd built out: the Battle mode.

One of the first things I decided to tackle - and one of the key things for the player during battles - was how information about units was presented.

Step one was identifying the core things the player would need to know about the state of a unit when scanning the battlefield. A unit’s HP and its Attack value were the immediate needs, but I realized a few other factors were just as important. The player would need to know what kind of attack a unit could make (ranged, melee, or magic) as that would determine a lot about where they might want to position them.

Hand-in-hand with that, the player would need to know whether a unit was out of position. Add to that the need to see whether a unit had moved yet, as well as whether they had Armor or additional status effects and there was a pretty defined bundle of info that needed to be immediately available to the player.

As I mentioned way back in one of my early Station Zeta devlogs, I am a firm believer in scanability. Even if TMF is a turn-based game, with plenty of time to sit and look things over, I think it’s important that the player not have to work hard to understand the information in front of them. Creating a unified visual vocabulary that stays consistent throughout the UI helps make that happen.

With some initial experimentation, I settled on a basic layout for the unit UI:

Here we’ve got a basic Militia unit. The HP is right below, with a numeric readout in addition to the bar. Next to that is a little green “go” light to show it still has movement available. Floating over its shoulder we can see it has an attack value of 1, and it’s a melee attack.

This archer unit has the same layout, but now with a little arrow icon to show it’s a ranged attack. It’s a simple difference, but by carrying those two icons through on other menus and displays, I can hopefully make it easy for the player to quickly parse what’s melee and what’s ranged, regardless of context.

Here’s a battle in progress, with all of the units and their relevant info. Again, I have the advantage of knowing what it all means, but in trying to think like a player I hope I’ve created the skeleton of something that’s easy to understand. In this case, for example, I’m hoping the red X on the leftmost militia jumped out at you as a way to say “hey, I can’t attack right now”.

(And yes, I say skeleton. I know there is plenty of work to be done in the actual look and feel, but getting a unified set of bones in place is the task at the moment)

With that core of information in place, the rest of the battle UI started to fall into place. Indicators for valid movement, a highlight of what phase of the battle was being played out, pointers of who was targeting who - all the things the player needs readily accessible. Then came things that were useful but not vital, like how many units each side has in reserve. This is something the player will probably want to check on, but doesn’t need to be front and center.

Taking Control

Stepping out of the Battle mode and into the Encounter layer, reason number 3 to not avoid UI quickly rose to the forefront: controller compatibility.

I want TMF to be playable with a controller. Given some of the games its taking inspiration from, it’s a natural fit, not to mention that controller compatibility opens up the ability to play it more easily on things like the Steam Deck.

Making things work with a mouse and keyboard is (relatively speaking) pretty easy. You want your unit to move to a different location on the grid? Great, click the unit, click on the new square, and voila. You want to select something in a submenu? Easy, just click open the menu, then click into the section you want.

Doing those things with a controller? Not so easy. Not to utterly bore you with the mechanics of how controller input works in Unity, but there is an awful lot of figuring out what element on screen the player is focused on and making sure that is both clear and functional.

But again, this is also a good exercise in thinking through how the game is structured. Walking step by step through each action the player will take on a turn to figure out both how to visually represent it and how to prompt the correct input from it is a great way to figure out where you are making assumptions as a designer that may not be correct.

In this case, it helped me identify where I needed to build in some more clarity to the turn order process, and a lot of scenarios that were likely to arise that I hadn’t considered initially. It led to some underlying structural changes to how the player’s turns are handled, and then I was able to build the corresponding UI to go along with that.

In the end, I think these are all changes that benefit the game. And if I hadn’t sat down and dealt with them now, I probably would’ve gone down a lot of dead-ends in the future.

Seeing the Tree for the Forest

Not everyone out there shares my feelings on UI, obviously - there are people who absolutely love it. I bet there are even people who are excited to work on it as early as possible (sickos, clearly). But if you are like me and you are leery of UI because you don’t like designing it, or you simply think of it as something that can be slapped on later, I would urge you to try approaching it differently. When I stopped thinking of UI as a chore - just a thing that needed to be there to let the player play the game - and started thinking of it as a fundamental part of the game, it turned me around.

So, the sum total of all this is after a few days of heads-down effort, I’ve got a fully functional (draft) UI in place that’s completely controller-compatible. The other huge benefit to this, beyond everything else I’ve mentioned, is that having a unified UI in place just makes the entire thing feel much more real. This is something I’d be far more comfortable putting in the hands of a playtester than what I had a week earlier.

And that’s actually a great lead-in to what I’ll delve into next time: building a tutorial and a system to handle all of the narrative bits of the game!

P.S. You can always join the conversation at our Porch Weather Games discord!