HUD/UX Philosophies

As a part of our university course, we have been tasked on an employability report in order to research and explore the (hopefully) future career of our choice. This includes things like experience, skills, and where to look for these kinds of jobs. The very first task given was to choose a specialisation.

To begin with, during this course, I was very interested in 3D modelling. Unfortunately, I don’t have a creative nor artistic bone in my body, and this became apparent when I was modelling for the sake of modelling without any kind of submission or guidelines. So I turned to the other side of the course, programming.

We have been taught to use Blueprints as opposed to C++ or C#, something that I am very grateful for as it served as a beginners stepping stone into the wonderful world of coding. Being able to click, drag, and piece together blueprint nodes like a puzzle made learning very easy! And a part of the project I chose for submission also used the Unreal Motion Graphics User Interface. I don’t think I even begun to scratch the surface of what the software was capable of, but I enjoyed it a lot. Therefore, my specialisation will be in the UMG UI, and HUD programming in general. A very big disclaimer for the upcoming blog post: I am not an artist. Not even a little.

Also, I feel like I need to explain, I will be referring to the UI and the HUD together very very frequently. Functionally, the HUD is designed to relay information to the player such as HP bars, or Ammo Counters, whilst the UI are the navigatable menus, spell books and crafting logs. These two things are very different, but the rules for creating a good HUD and a good UI are extremely similar.

UIs have been something I have been interested in since my early days of World of Warcraft. I had enjoyed that game frequently in my younger years, but in particular, piecing together certain addons that would allow me to totally reconfigure the base UI and tailor it to how I wanted it to look, then comparing it to other interfaces people had made, rebuilding it to this time make it look more pretty, or to provide more information, the countless possibilities made for a very fun experience. I feel as though I spent more time modding than I did playing the game. 

World of Warcraft wallpaper created by Reddit user /u/Khrezin

Along side this, I also did basic research on what makes a good HUD, and between reading peoples thoughts, opinions, and my own trial and error, there were a few things I noticed that a games HUD required that are fairly important philosophies to video game user interfaces.

In order to better explain some of the things I will be talking about with regards to World of Warcraft, it's important to note the three roles of Tanking, Healing and Damage. Anyone who is a gamer who has played any kind of RPG will know what these mean. Tanks and Damage dealers need to be able to see their movement and spell effects from enemies to respond accordingly, and healers need to spend a little less awareness on positioning and a little more on ally positions.

One thing all of these roles have in common is they require situational awareness. Whilst the above UI isn't the most tidy or best laid out, the default World of Warcraft UI does a good job of illustrating this point. With a simple glance, the player is capable of searching for their spells, tracking cooldowns, artifact experience, key bindings, and current quests. And even then, a lot of this information is useless during a raid. But it's kept out of the way and clean enough that it's not intrusive, which means a player won't be bogged down with a spreadsheet nightmare of quests and spells which interrupt them from seeing a bosses ability that they are stood in.

Rule number one: Keep information relevant

Default World of Warcraft UI

With this, we introduce our first rule for a good HUD. It must relay relevant information first and foremost. The whole purpose of a heads up display is to provide information, but as I mentioned earlier, some of the information being presented in the base UI; the questing panel- isn't always necessary. During the leveling process and free roaming, then players might want it to be open. During PVP or raiding however, they most likely do not. Which is why it bugs me that by default it is open and minimizing it only lasts for that session.

This rule applies more in favour of HUDs than UIs, although it can apply from a games display to website interface development. As an example don't flood the user with all of the spells information and maths and then also provide a list of monsters who know the spell, it isn't relevant for the player to know unless they ask for it from either a bestiary or advanced tooltips.

Rule number one and a half: Fading and Hiding

This comes quite handily into another point which I'm not sure would be point 2 or point 1.5. An interface can be dynamic, the HUD can be dynamic, the information it presents doesn't always have to be visible. Having parts you can minimise or hide, or parts that you can enable and show makes the UI more easily tailorable and usable by a wider variety of people as well as looking nicer. Taking the quest bar as an example, when the player enters a raid and engages in a boss fight, the quest log is still clickable and interactable which can lead to issues. So being able to hide this is very useful.

Further apart from the World of Warcraft ideas, think of some other types of games. As an example, Fallout 4. After a while, HP AP and Ammo will fade out from the HUD because whilst the player does need to know these important stats, when they are roaming around enjoying the sights, it no longer becomes relevant until they once again enter combat.

On the flip side, take Super Mario 64 for example. The game features underwater movement and also an oxygen meter. It should go without saying that on land, the player has absolutely no use whatsoever for their oxygen meter, they're breathing air and running around. However, when the player submerges into the Dire Dire Docks, this information becomes relevant, as they must either surface, find a bubble, or collect coins to regain their air. Therefore, the oxygen meter should now be present, as it is relevant and important. The reason for keeping only relevant information to the screen directly follows onto another golden rule.

Granted they cut some corners and used the same "Power" meter for HP, but it counts. Super Mario 64, 1996

Rule number two: Use as little of the screen as possible

I also feel that perhaps this should be rule number one. Perhaps this is UI rule number one, but HUD rule number two. The UI should not consume the whole screen. The UI should be kept to the edges of the screen for information that isn't important, slowly graduating to the middle of the screen when the information becomes more relevant and important.

This in turn helps in two ways: Firstly, the player can see the game. I know it might sound silly, but the player needs to see the game, be it from a sightseeing perspective driving through USA in The Crew, or to pick up on small telegraphs to boss abilities a la Dark Souls.

But secondly, this can also tie in with game design. If you have important cues pop up towards the top center of the screen, the player will be drawn to them, as it has entered an important space on the screen, typically where enemy combatants would be, or their HP bars. Back to a WoW example, this is where the Deadly Boss Mod would tell you "ABILITY X, RUN/DISPEL NOW/GROUP UP." Yes, it has entered and potentially obstructed the players view, but when a pop up requires instant action, typically this is the right screen space to capture the players attention.

Rule number three: Do not intrude in the center space

And this doesn't mean adjust the players FOV setting. The third and final rule I wish to talk about is kind of contrary to the example I just made, and applies almost exclusively for the HUD, as the player will most likely be in a low danger area if they are going to interface with the UI, although rule 3.5 does also apply to UIs.

Ideally, the HUD shouldn't be obtrusive to the players screen space, and only very rarely should it be allowed to. The above example is one of the few times I feel it is okay to pop up in the players field of view. You should make clever use out of the screen space you are given and know the hotspots for the players gaze as to avoid directly blocking their view because you found a letter on the floor and the game has an urge to update you about a collection. Not a quest item, a collection. If this letter were to self destruct like a secret agent, then fair enough, the player could do with that sort of information.

Kind of reminds me what the internet is like without an adblocker. Far Cry 3, 2012

This rule is a little bit of two points in one again, and I feel it's worth reiterating the requirement of clever space manipulation. Most PC games these days will have 1920x1080 resolutions for the UX designer to work with, and that's quite a lot of room. If 40% of the screen is taken up by an inventory, perhaps you could better utilise some of the space, or perhaps it's been left in a corner where, despite how big it is, it's not overly intrusive. A personal dislike of mine; which I feel is pretty brave to confess, and an example of smart screen space- is Metroid Prime's 'innovative' HUD.

Forced screen space within the players screen space. Metroid Prime, 2002

A lot of people have considered the Metroid Prime HUD to be unique, and whilst I will give credit where it is due, it's function, unique, and kinda cool. After the initial "wow" factor had run out I disliked this layout for one main reason.

The game is on the players screen. From corner to corner. The full screen is used to display the game. So, why then, is the game using this whole space, but creating its own sub space of focus? Perhaps this doesn't seem like such a big deal because the center of the screen is where the player will be looking anyway. But two parts make this HUD very jarring for me to look at: The curved perspective and the outline.

The curved perspective isn't a big deal, it's just strange that the HUD is trying to mimic being information on the visor and put it in the game space without it being interactable, but the world isn't viewed through a fish eye lens and for some reason the overlay is. It seems very strange.

But the outline is what concerns me. If the minimap, energy, radar, and buttons were in their traditional places in the corners and top of the screen without this strange blue outline of the HUD, it would function exactly the same. But it causes a strange disconnect with the edge of the screen. There already isn't much of a reason to use the very edges of a screen in an FPS aside from being able to get a more clearer view of the battleground, but the player will unconditionally not look outside of this border because the immersion will keep them locked in the center of action, and turning the gaze too far away breaks the immersion as you suddenly realise there's a big box of "LOOK HERE PLEASE" and a whole lot of nothing on the sides where the bars could comfortably sit.

Immersion is a fickle tool, but a powerful tool for the game designer. Projecting a HUD into the game space and trying to merge it with the aesthetic of Samus' visor is a wonderful idea, but it should blend seamlessly with the game and not draw attention to itself.