We’ve been kicking around what to do with the HUD since at least July. This is a chronicle of our journey. I’ll spare you the awful mockups/prototypes.
Iteration 1, 2 and 3: Standard 4x game HUD
There is a lot of information a player could potentially want to see on the screen as he’s playing Astrobase Command. So kind of the default was to go with a standard 4x game HUD, because there’s a lot of intersection in terms of the kind of information (resources, unit details, module details, etc) a player could be tracking.
This was our starting point. Master of Orion set the gold standard here, and pretty much every 4x game has followed the template.
However…
It was immediately apparent that the art style of a standard 4x HUD (which is generally sleek and compact) completely clashed with our skueomorphic look and feel. We have folders, ID cards, oscilloscopes, monitors. A standard HUD didn’t look right, because it’s a UI element that is obviously a UI element.
Astrobase Command needs a metaphor that gives the HUD context.
Iterations 4 through 10: Standard 4x game HUD — but skinned to look like something
All the other UI elements in Astrobase Command are a “something.” One of our goals was to have GUI that not only the player uses to interact with the game itself, but that the characters in the game use to interact with their world. This is fundamentally immersive.
So one idea was for it to make the player feel like he’s here:
But… this actually came out worse in some ways than more traditional HUD skinning.
Not only are real-world objects horribly unoptimized for space, BUT basically we had a bunch of floaty bits that each individually looked like a “thing” which clashed with the personnel folders and other objects due to the different perspectives and scale.
Incredibly immersion breaking.
So not only did we need a metaphor that gave the HUD context on its own, but it had to make sense within the context of the rest of the GUI — which consists of draggable real-world objects.
Iteration 11: A complete mess
The more I messed with it, the worse it got.
Ultimately the problem was that HUDs are “bounding boxes” for a playable area. They sit at the bottom, creep up the sides, and maybe have a horizontal menu at the top. But having a HUD in Astrobase Command pulled you out of the action. Because instead of building your base, you were playing a game about building your base.
This is a fundamental difference. It’s the difference between a game where you are driving a car, and a game where you feel like you’re playing a car-driving game.
We needed it to feel like the first.
This was becoming a problem!
But wait… why do HUDs even exist?
Let’s go back in time to the dawn of video games. HUDs started off as a static strip across the bottom (or top) of the screen where a score was displayed. Later other details were added. Even later, they were skinned to help give the game a specific look & feel.
Why a static strip?
Because back then, processor cycles (and scanlines, if you’re on a console hooked up to a TV) were at a premium. A static strip was an element you didn’t have to render every frame. Games with larger HUDs had better framerates (and on consoles you could do some cool tricks with scrolling).
If you look at a game like XWing, the HUD was almost half the screen.
Observe:
This is actually really clever. You feel like you’re in a cockpit. The game only has to render about 60% of the screen, which means they can push more polygons into a smaller area and optimize frame-rate.
We don’t have this issue. Graphics cards these days are optimized enough that this isn’t really a technology constraint. Plus in our case (since we’re not making a photo-realistic shooter) it doesn’t matter.
So… do we even need a hud?
Short answer is “no.”
Iteration 12: The Desktop
Note: All art is placeholder! (that goes in general for Astrobase Command). Part of an iterative design process means getting just enough quality to have something playable without being distractingly awful. And then as we start to play-test more and more of the design, we can lock down the art and improve the quality.
So the idea is that all GUI elements for the game, by default, are arranged on the desktop which is pulled in and out (opened/closed) from the side. Or the elements can be accessed via the desktop (such as datapad programs).
Everything is a draggable object. So for example one way to access your characters is via a rolodex of ID cards which pop out. You can move the rolodex wherever you want, or even drag it off the desktop to the left hand corner of the screen. When you close the desk whatever is left on the desk will close with it.
This means the GUI is completely customizable. Because you are simply moving the elements to where you want them on the screen. Elements you don’t use a lot can stay organized however you want on the desktop.
(Note, since this screenshot was taken, we have since added an inbox where your recruit applications and other notices pile up).
We also redid the datapad to fit with the new style.
The datapad is a context-sensitive menu. So it changes depending on whether you are selecting a mission, manufacturing items, or construction a module, and so forth.
The datapad has its own GUI — which is pixel/retro art. And this fits with our overall technology look. Plus we found it pulls the player into the game to have devices that feel independent and have a place in the gameworld.
So now we are in the process of designing and adding elements to the desktop. As we add features to the game, that feature gets a representation somewhere.
So… the question to the community: what sort of actions do you see yourself performing a lot? What kind of knicknacks will your space-desk have?
