HUD budget

294. Lesson identity

Module

1.6 — UI, HUD, and UX

Lesson

HUD budget

Academic type

Design / Systems

Schema type

text

Order

Lesson 2 in the module

Estimated time

20–35 minutes, including practice

295. Learning objective

After this lesson, you can list the information a player must see during one game mode, justify each item by its immediate decision value, and remove at least one item that does not earn its screen space.

296. Why this matters

A HUD competes with the game for the player's attention. Every permanent element should help the player decide, act, or recover from an error in the current mode. A kitchen-sink HUD makes important information harder to find and increases the chance that the interface communicates noise instead of state. When directing AI, a short information budget is also a better specification than “add a complete HUD.”

297. Prior knowledge

You should have completed 1.6 — UI, HUD, and UX: Shown is not true. You should be able to distinguish an authoritative game value from the UI element that presents it. Course prerequisites are basic familiarity with a game mode and its player decisions.

298. Core concept

A HUD is an information budget, not a storage shelf. For one mode, show the smallest set of information that supports the player's immediate decisions. An item belongs in the HUD because the player needs it now, not merely because the game tracks it or because it might be useful later.

A useful test for each candidate item is:

1. What decision does this information support in the current mode?
2. How soon does the player need that decision?
3. What happens if the information is hidden, delayed, or moved to a menu?
4. Is another element already communicating the same thing?

If the answers are vague, the item is a removal candidate.

299. Mental model

Use the Now / Soon / Later / Never filter:

Then test the mode using ACT → RESPOND → CHANGE → AGAIN. After the player acts, ask whether the HUD makes the relevant response and resulting change legible before the next action. This is a visibility test, not permission to display every available value.

300. Concrete example

Imagine a short infiltration mode in which the player's immediate decisions are whether to move, hide, or leave after carrying contraband to an exit. Candidate HUD items might include:

• Current health
• Detection state
• Distance or direction to the current objective
• Carried contraband count
• Total lifetime credits
• Unlocked character biography entries
• A minimap showing the entire level

A first pass could classify them as follows:

The budget is not automatically “show everything classified Now and Soon.” It is a decision to protect attention. If the detection state already gives a clear visual response and the objective direction is obvious from the environment, one or both may be reduced or made contextual.

301. Common mistake

The common mistake is treating “tracked by the game” as equivalent to “must be visible in the HUD.” A designer may add currency, inventory, timers, lore, statistics, objectives, maps, status effects, and tutorial reminders because each is individually reasonable. The combined result forces the player to search through competing signals. A second mistake is keeping an item because removing it feels like losing functionality. Moving information to a pause screen or contextual panel is not necessarily a loss; it can be a better match for when the information matters.

302. Guided practice

Design a HUD budget for one mode of your game or for a small invented mode. Do not design the visual layout yet.

1. Name the mode and its three most important player decisions.
2. List 6–8 candidate HUD items.
3. Assign each item a priority: Now, Soon, Later, or Never.
4. Write one sentence explaining the decision supported by every item marked Now or Soon.
5. Choose one item to cut from the permanent HUD. State where it will go instead, if it still needs to exist.
6. Run the list through ACT → RESPOND → CHANGE → AGAIN. For each step, identify whether the remaining HUD tells the player enough to continue without exposing unrelated information.

The mandatory design decision is the cut. If every item survives, your budget has not yet been tested; remove one and explain why the game is better served by its absence.

303. Validation / evidence

Your work is sufficient when you can point to:

• One named game mode.
• Three immediate player decisions.
• A 6–8 item candidate list with a priority for each item.
• A decision-based justification for every permanent or contextual item.
• One explicitly removed item and a reason it does not deserve permanent screen space.
• A statement of what the player can determine after ACT → RESPOND → CHANGE → AGAIN without reading unrelated information.

The standard is not visual polish. The evidence is a defensible information budget tied to player decisions.

304. Key takeaways

• A HUD should communicate what the player needs for the current mode, not everything the game knows.
• “Now” information deserves stronger and more reliable visibility than “Soon,” “Later,” or “Never” information.
• Every permanent HUD item should justify its space with a concrete player decision.
• Cutting one item is a design test, not a failure to provide functionality.
• Use ACT → RESPOND → CHANGE → AGAIN to check whether the remaining information supports continued play.

305. Related resources / next lesson

No approved resource IDs or titles are linked to this lesson.

Continue to 1.6 L3 — UI that the mode cannot use in English, 1.6 L3 — Una UI que el modo no puede usar in Spanish, the next lesson in 1.6 — UI, HUD, and UX. There you will analyze how a mode's input state can make an otherwise visible interface unusable.

306. Knowledge check