A game's interface has a difficult job: giving players all the information they need without distracting them from what is happening on screen. An unreadable health bar, a menu that cannot be navigated with a gamepad or a HUD that spills off the edges of an ultra-wide screen are frequent problems, and almost always avoidable with a little planning.
HUD: only what is needed, when it is needed
The HUD (heads-up display) is the set of elements overlaid on the game: health, ammunition, minimap, score, current objective. The first step is to ask, for each element, how often the player needs it.
| Frequency of use | Examples | Treatment |
|---|---|---|
| Constant | Health in an action game, crosshair | Always visible, in a stable position |
| Occasional | Reserve ammo, currency | Visible when it changes or on request |
| Rare | Detailed stats, full map | In a menu or a dedicated screen |
Many games hide elements when they are not needed: the health bar appears when damage is taken and fades after a few seconds at full health. Fewer permanent elements means a cleaner screen and more attention on the ones that remain.
Information in the game world
An alternative to the traditional HUD is to bring information into the scene: health bars above enemies, damage numbers floating up from the point of impact, markers on the ground for dangerous areas. These elements must still remain readable, with guaranteed minimum sizes even when the object is far away.
Anchors and resolutions
A game has to work on screens with different aspect ratios: 16:9, 16:10, 21:9, the 4:3 of some tablets, the elongated formats of phones. Placing elements with absolute pixel coordinates does not work: on a wider screen they would stay bunched up on the left.
The solution is anchors. Each element is attached to a point on the screen, such as the top-left corner, the bottom centre or the right edge, and positioned with a margin relative to that point. Health anchored at the top left stays at the top left on any screen.
Scaling
For sizes, a reference resolution is usually used, for example 1920 × 1080, with a scale factor computed from the actual screen height. Basing the scale on height prevents the interface from becoming huge on ultra-wide screens.
With pixel art it is best to restrict scaling to integer factors, 2×, 3×, 4×, to avoid unevenly sized pixels. Excess space is left as margins or filled with background.
Safe areas
On televisions part of the picture's edge may be cropped, and phones have camera cut-outs and rounded corners. Important elements should be kept inside a safe area, derived from information provided by the system or configurable in the game's options.
Menus and navigation
A menu designed only for the mouse becomes an obstacle for anyone playing with a gamepad or keyboard. Some essential rules:
- one element always selected, clearly highlighted, not just with a slight colour change;
- predictable navigation: pressing down goes to the element below, and edges behave consistently, for example wrapping to the start of the list;
- a consistent back button on every screen;
- confirmation for destructive actions, such as deleting a save or quitting without saving;
- remembered position: when returning to a menu, the selection stays where it was left.
Engines provide systems to define each element's neighbours automatically or by hand. It is worth checking every screen using only the gamepad, then only the keyboard.
Readability
Text and symbols must be readable in real conditions: on a television seen from the sofa, on a phone outdoors, on a laptop's small screen.
- text size appropriate to viewing distance, with an option to increase it;
- sufficient contrast against the background, helped by outlines or semi-transparent panels when the background changes;
- do not rely on colour alone: a rare item can have a differently coloured border, but also an icon or name that sets it apart, for the benefit of people who have difficulty distinguishing colours;
- icons consistent with the device: if a gamepad is in use, prompts show gamepad buttons, not keyboard keys.
Separating logic and interface
From a code standpoint, the interface should not contain game logic. The health bar displays the health value; it does not calculate it. A clean approach has the game expose its data, such as health, ammo and objectives, and emit events when they change; the interface listens and updates the display. That way the HUD can be completely redesigned without touching the logic, and the logic can be tested without an interface.
Interface animations matter too: a bar that drops gradually, with a segment showing the damage just taken, communicates far better than a number that changes abruptly.
In short
- The HUD permanently shows only information that is used constantly.
- Anchors, height-based scaling and safe areas adapt the interface to every screen.
- Menus must work with gamepad and keyboard, with clear selection and predictable navigation.
- Text size, contrast and symbols that do not rely on colour alone ensure readability.
- The interface displays the game's data without containing its logic.
