Rainboids Dev Diary: HUDs Up! HUD Design Choices

HUDs tend to be one of the most understated aspects of game design: good ones don’t feel like they’re there. It’s easy to overlook how much time and effort goes into making them contextually meaningful without being overstated. Bad HUDs, on the other hand, are blatantly obvious for how in-your-face they are.

HUD Philosophy

A lot of care has been afforded to making the Rainboids HUD functional and useful without being in your face. It delivers meaningful combat information at a glance while reinforcing positive feedback from gameplay.

The Rainboids HUD strives to strike a balance: minimalism on one hand, and on the other, elements that deliver “juice” — that sense of progress and accomplishment that drives player satisfaction. Much of Rainboids’ design aesthetic is rooted in viscerally satisfying feedback, and the HUD is no exception.

Every HUD element is there to do one of two things: surface relevant combat information (like the player’s weapons loadout), or convey stats that fuel the player’s sense of satisfaction (like accumulated gold and the experience bar).

HUD Elements

The HUD timer was a close call. I considered cutting it to reduce visual clutter, but it earned its place because it amplifies the sense of urgency and momentum. Because the timer is always ticking up, the game always feels like it’s “going somewhere.”

The minimap, in contrast, was cut — primarily to reduce HUD elements and clear up the screen. Removing it freed up an entire corner, which is substantial, and enabled a cleaner layout. The decision didn’t come easily: a minimap is unarguably useful, especially since the Rainboids map is larger than a single viewscreen. Without one, I worried there would be more downtime spent hunting for enemies. But in Rainboids, I want the enemies’ locations to be known.

Fortunately, a soft, glowing enemy indicator at the edges of the screen more than compensates. In fact, it arguably makes the minimap redundant — which is what sealed the decision.

The EXP bar was there from early iterations, simply to add a layer of satisfaction for every hit. It was deliberately integrated into the player health bar to minimize screen real estate: it isn’t strictly essential, but it provides nice feedback. Giving it its own bar would have meant additional margins and clutter, so it was fused with health instead.

The weapons loadout wasn’t there originally. In the earliest builds, weapons were purchased and selected through the shop. Later, weapons were made free and unlocked from Wave 1, and selection moved into the main pause menu. Finally, controls were added to cycle through weapons mid-combat — at which point a visual indicator for the currently-equipped primary and power weapons became necessary. By then, the weapons loadout felt obvious, even mandatory.

For positional combat information, instead of a minimap, players are nudged toward enemies by a gentle, warm glow at the edge of the screen. A glow was preferred over more concrete indicators like arrows or triangles; the softer approach lets it feel like part of the environment rather than an overlay. One of the ideals of game design is to make the environment itself “directive” — so the player naturally intuits what to do from visual cues. Integrating those cues into the environment, or into the interface so seamlessly that it reads as environment, is a core prerogative for a designer.

Organization of HUD Elements

I paid close attention to the placement of HUD elements, experimenting a lot and drawing on design choices I’d absorbed over the years.

The top-left of the screen is, to me, the most critical real estate: it’s where many people’s eyes gravitate for a “start” point, especially for left-to-right readers. Most user interfaces put important things there — the File menu in Windows and macOS, the Apple menu, the start of every line of left-to-right text. From the earliest iterations of Rainboids, health has lived in the top-left, because health is arguably the single most important stat.

Initially, the top-left held only the health bar, the bundled EXP bar, and the level readout. Then gold was added. Then the weapons and skill loadout squares. Eventually, the top-left started to feel cluttered. The information was important — but the corner felt like it needed cleaning up.

That’s when the bigger reorganization came in. I first experimented with moving health to the bottom-left and placing the loadouts above it. It worked, technically — but it felt wrong.

Part of it was that the loadouts didn’t sit right above the healthbar. But there was also a more subtle issue: the healthbar’s silhouette has angles that really belong in the top-left. A “/” diagonal (rising from bottom-left to top-right) feels at home in the top-left corner, while a “\” diagonal feels at home in the bottom-left. I wasn’t about to redesign the healthbar, so I kept it where it belonged.

There was also a stylistic mismatch: the distinct-looking loadout squares clumped against the distinctive healthbar wasn’t quite right. They were two different visual languages communicating two different kinds of information, and forcing them together muddled both.

This was the moment I decided to cut the minimap. Freeing up an entire corner meant the loadout squares could have their own dedicated space to convey their unique information — and the HUD as a whole became visibly less cluttered.

Lessons Learned

Stepping back, a few principles crystallized over the course of this work.

Every HUD element has to earn its place. The question isn’t “is this useful?” — almost anything is useful. The real question is whether what it adds outweighs the screen real estate, the visual noise, and the cognitive cost it imposes on the player. The minimap was useful; it still got cut, because a softer mechanic was already doing its job.

Prefer environmental cues over interface cues. The edge-glow that replaced the minimap isn’t just a smaller HUD element — it’s a fundamentally different category of communication. It reads as part of the world rather than an overlay on top of it, and that’s almost always the better trade when you can pull it off. The HUD’s job, ideally, is to do the things the environment can’t.

Juice and information are not opposing forces. The EXP bar fused into the health bar is doing two jobs in one footprint: it’s combat-relevant and it’s a steady drip of positive feedback. The best HUD elements tend to multitask like this, and looking for those overlaps is usually more productive than treating each stat as a separate widget.

Layout is a language, and the screen has grammar. The corners aren’t interchangeable. The top-left carries weight that the bottom-right doesn’t. Even the diagonals inside an element imply a direction of flow. Fighting that grammar — putting health where it doesn’t belong, or stacking mismatched visual styles in the same corner — produces that vague “it feels wrong” sensation that’s hard to articulate but immediate to perceive.

Iteration is the only real method. None of the final layout was obvious from the start. The weapons loadout migrated from shop to pause menu to permanent HUD over multiple passes. Health stayed put through every reorganization attempt because every alternative felt worse. The minimap survived a long time before the edge-glow rendered it redundant. Good HUDs aren’t designed so much as they’re whittled — element by element, corner by corner — until what remains is exactly what the player needs and nothing more.

The goal, in the end, is a HUD the player stops noticing: one that tells them everything they need to know, rewards them for playing well, and otherwise gets out of the way of the game itself.

· · ·

Comments

Leave a Reply

Check also

View Archive [ -> ]

Discover more from afeique.com

Subscribe now to keep reading and get access to the full archive.

Continue reading