Games

Hurdles in HUD Design

Standard

Over the last few weeks I’ve been putting a lot of effort into making a HUD for my game. I think I’ve played enough games to know a good HUD when I see one, but designing a good HUD has been a completely different experience. 

I went into this knowing very little about how to design a HUD, so the first thing I did was define HUD. The basic definition of a HUD is an overlay that communicates vital information to the player. Turns out, there are 4 classes of HUD components that can exist. For a great breakdown on types HUD check out this article. For my game I decided to use a combination of non-diegetic and spatial properties – most of the HUD exist outside of the game story (bars and meters) but a few things exist in the game space (auras).

4 Classes of HUD components. Image from Micah Bowers – https://www.toptal.com/designers/gui/game-ui#:~:text=What%20is%20a%20game%20user,Diegetic%2C%20Meta%2C%20and%20Spatial.

I also found that I had a lot of assumptions about HUDs that needed to be re-evaluated. I assumed less is always more when it comes to HUD. I thought any method that replaced bars or numbers on the screen with more abstract forms of communication would be more visually appealing.  This is only half true. I think good HUD design minimizes unnecessary clutter in the overlay, but just because some information can be communicated abstractly, doesn’t mean it should be. 

In some games knowing the exact amount of health a player has completely alters gameplay. In a FPS communicating health by an on screen indicator (like red around the screen) works perfectly because the player never needs to know exactly how much health they have. When the screen gets too red they know to dip out and recover. However, in a fighting game knowing the exact amount of health each player has can change strategy drastically. A standard health bar is 100% vital for communicating health because of its accuracy and legibility.

Call of Duty Modern Warfare Damage indicator. Image from Kotaku UK (https://www.kotaku.co.uk/2019/04/12/i-had-my-birthday-party-in-modern-warfare-2)

Another assumption I had was that the HUD display should be visually immaculate. This is pretty far from the truth. One key purpose of a HUD is to be easily readable when needed and totally ignorable at all other times. Having an immaculate design is only necessary when the player is going to spend a ton of time looking at it. I think Persona 5 is a great example of this. 

Persona 5 Battle Scene – Image from Jiaxin Wen (https://jiaxinwen.wordpress.com/2017/04/27/the-ui-design-of-persona-5/)

The unique design of the HUD makes it a pleasure to look at while planning strategies and picking next moves. However, in most fast paced games HUD is only briefly glanced at. The HUD just needs to be styled to match the theme of the game and minimally designed to reduce distraction.

A good HUD is there when the player needs it and completely ignorable when it’s not. They are extremely easy to read and are not bloated with too much information. Glancing at the HUD should not distract the player from the gameplay at hand. It is the responsibility of the devs to understand what information is crucial to the player and deliver it in the most legible way.

Rough Draft of my current HUD

For my game, the most important information is the player’s health and stamina. This will be communicated non-diegetically through bars. The player also has a special move that builds up as aura is collected. This will be communicated spatially in the game’s space. I still have a lot to learn about designing HUD, but I am satisfied with my early drafts and am excited to see where this goes.

Thanks for reading!

-BlackShinobi956

Learning to Pivot

Standard

Generally it’s always good to have a backup plan, right? If things go wrong, it gives you a safety net to fall into. For most of my life I’ve relied on backup plans, and it has helped me a lot, but I think it’s time for me to change my perspective.

I set out to make my first game a while ago. It was a cool concept, but the design pillars I decided to build on were a bit too ambitious for a solo game dev. That resulted in a scope that was too large, gameplay mechanics that were unrealistic, and feeling like my initial goal was too lofty to be accomplished. 

Normally I would chalk the project up as something to come back to later and transition to another project (a.k.a. My backup plan). I have been able to learn a lot about the process of game development by doing this, but ultimately all this has given me is some experience, about a dozen partially complete projects, and 0 released games. =( 

The strategy is a living ever-evolving pivoting mechanism.

Pearl Zhu

Instead of accepting things as being out of reach, I decided to try pivoting instead of transitioning to a backup plan. In this context, that meant every time a core element of my game wasn’t working the way I expected, I took a step back, re-analyzed design pillars, made some adjustments, and kept pushing through. Instead of walking away and starting a less ambitious, equally cool idea; I tinkered, tweaked, and modified enough to maintain design pillars and continued to work on the project. 

Even though the project has been scaled down quite a bit, and the gameplay loop is completely different from anything I’ve shown, I’m still very proud of the game that I have now. It is still ambitious for a solo dev’s first release, so I may have to continue to pivot but overall, the game is coming along well. Can’t wait to show you all!

Thank you for your support!

-BlackShinobi   

Spyro – Ebb and Flow

Video

A brief analysis on why Spyro is a great remaster that has been well received.

 

Music – Morning Routine by Ghostrifter Official | https://soundcloud.com/ghostrifter-of… Music promoted by https://www.free-stock-music.com Creative Commons Attribution-ShareAlike 3.0 Unported https://creativecommons.org/licenses/…