Welcome to Quick Dev Insights. A series of bite-sized interviews with people who work in and around the games industry, from indie to AAA. A full list of these interviews can be found here and you can follow my Twitter to find out when new ones are released!
Creating UI For Games with Ben Humphreys
Hi, my name is Ben, I'm a UI programmer. I do some UX and UI design work too, but I'm originally a computer science major so I'm more into the implementation of things. I've worked using Unreal Engine for 5-6 years and I've been in the games industry for around 10 years. I currently work at Brace Yourself Games as a UI programmer. We're a small company of around 40 people and our teams are even smaller, with around 5 core team members (design, art and programming) and other roles jumping between projects.
Is there a workflow that you like to use when developing a UI for a game?
My workflow isn't really set in stone but recently these kinds of stages have helped me a lot.
I'm very text-based at first. I'll talk to the game designers and talk about the game's features, their order of importance and ask as many questions as I can. From gameplay-specific things like "Can the player be poisoned *and* have other status effects at the same time?", "How many different building types will there be?" to more production-related questions "What platforms are we aiming at?", "What languages will the game be translated into?".
With all this information written down somewhere, I'll start sketching out widgets on paper. This can be health bars, build menus, inventories, whatever the game needs. I'll try to start with the one that seems "hardest", maybe it's a piece of UI that needs to explain a gameplay mechanic that I've never seen in a game before, or it's the UI needed for the core of the game. Other things that might be more by-the-numbers I leave until later (e.g. health bars, a grid-based inventory).
After this I'll try to get these trickier UI elements in-game as soon as possible, with as rough art as possible. I usually make it as plain as possible, just black and white to try to avoid people confusing it with finalized art. The aim at this stage is to *use* the widgets as much as possible. Do the interactions make sense? Is the information conveyed to new players correctly? The answer is almost always *no* but that's what the point of this stage is; to get as much iteration time as possible on the more difficult-to-design parts of the UI.
In parallel with this functional testing I will work with the art team on the look of the UI. We will throw around ideas of typography that would fit, textures, button styles and try to create a very early style guide for the game. This might include examples of a few types of buttons, various decorated headings, panels with backgrounds. From these more standardized widgets it's then easier for the art team to create more custom things for the tricker UI elements mentioned above.
Are there any key conventions that you think help make a good UI?
I'm not a UI expert by trade, but I've always found that consistency can often make the difference between a UI feeling great or feeling kind of weird. Coming to this from a programming aspect, you can help yourself to create a consistent UI by making tools to support that - making it easier to be consistent than to be inconsistent. If every time you create a new text widget, you have to choose the size from an infinite range, it's much more likely that your UI will end up with a huge number of text sizes. However if you only have 3 sizes to choose from, for example Title, Subtitle and Body, then your UI will be extremely consistent. The same applies for colours, panels and other widget types.
UI can be involved in a lot of game systems. Who with and how do you tend to collaborate, when developing a UI as part of a larger team?
At Brace Yourself Games, we work in very small teams so there often isn't a dedicated UX Designer or UI Designer. Myself and the art director will fill the role of UX/UI Designer. I will talk to the lead game designer about a particular feature, what kind of systems there might be under the hood and we will discuss what parts of them need to be communicated to the player. To give a concrete example, in Industries of Titan we have a pollution mechanic. Squares within the city can become polluted, that pollution can spread and have a negative impact on citizens. The simplest and most transparent way to communicate this to players would be to just show them the exact pollution value at every square, updated in real-time. But that kind of information is very overwhelming and doesn't help the player make decisions. Talking to the game designer further it became clear that the mechanic is there to give players interesting decisions about where to place their residential and where to place their industry. The exact numbers at each square don't help with that decision making process. Instead focusing on sources and communicating levels with "low", "medium" and "high" with colour made the system way easier to understand.
When building UI in Unreal Engine, what do you like to use c++ for and what do you use blueprints for? Do people always need to use c++?
I have tried a few different approaches to the C++/Blueprint split within UI over my years as a programmer. I tried making my entire UI in Blueprints in my first job, but I found it very difficult to use the Blueprint debugger to diagnose some of the more complex bugs. The logic became harder to maintain as the Blueprint "spaghetti" grew.
Now I keep as much as possible in C++. As a computer scientist I find C++ way easier to understand than Blueprint logic and the game logic being in text files simplifies collaboration and viewing version history. That being said I think it's up to each developer to do what feels best to them and their team. I've seen really incredible UI work done just using Blueprints, and thankfully in Unreal you're free to choose what suits you.
Are there any resources that you think would be helpful for people looking to learn more about developing UIs for games?
The best thing I can recommend is to start taking notice of the UI in games that you enjoy. Take down notes on what you like, what feels natural, what looks cool? Also what actions in the game are tricky or error-prone because of the UI? Taking down notes should start you thinking about what goes into making a game UI: buttons, text, images, windows, grids of widgets etc.
With that under your belt you can try to implement some of the UIs you have seen in other games. Creating a settings menu or shop menu, with all the edge cases can be a really great exercise; showing when something is not possible, warning the player before leaving the menu, showing confirmation on making a change etc.
Where to find more about you / things you're working on?