Typography for game UI: the part players read under pressure

Two typefaces, two jobs

Your game needs a display face and an interface face, and they are almost never the same thing.

• The display face carries the identity: the logo, the title screen, chapter cards, key art. It can be heavy, distressed, condensed, strange. It is read once, large, slowly.
• The interface face carries everything else: the HUD, menus, item names, numbers, settings, subtitles. It is read hundreds of times, small, in motion. It has to be boring, and boring is the compliment.
• Using the display face for interface is the most common typographic mistake in indie games. A face designed to look like carved stone at 200px becomes mud at 16px over a gameplay background.
• The relationship is the design. The two faces should feel like they belong to the same game without doing the same job, which is usually a matter of shared proportion rather than shared style.

The logo has its own rules and its own article: game logo design. Everything below is about the second face.

Choosing an interface face

The criteria are unglamorous and they are what separates a face that survives production from one that gets replaced in month four.

• Open apertures. The gaps in a, c, e, s stay open at small sizes. Closed apertures fill in and every letter starts to look like an o.
• Unambiguous characters. Check 1, l and I together, and 0 against O. Players read item codes, server names and seeds, and a face that confuses those creates support tickets.
• Real weights, at least three. Regular, medium and bold. Hierarchy built from weight is cheaper than hierarchy built from size, and it costs no space.
• Good numerals, which is the next section and is more important than it sounds.
• Language coverage for everywhere you ship, including the extended Latin your European languages need.
• No personality at small sizes. Whatever charm the face has should live in the display face. Interface type should disappear.

Numerals: the fix nobody knows about

This one costs nothing and improves every counter in your game. Most fonts default to proportional figures, where a 1 is narrower than a 8. In running text that is correct and invisible. In a HUD it means the number physically changes width as it counts, so your ammo counter, timer and score jitter and shift every frame.

• Use tabular figures for anything that changes: timers, ammo, health values, currency, scores, damage numbers, stats in a list.
• Use them for anything in a column, so prices and stats line up on the decimal rather than drifting.
• Most quality faces include them, either as the default or as a switchable feature. If your chosen face has no tabular set, that is a genuine reason to reject it.
• Lining figures, not old-style. Old-style numerals with descenders belong in body text, not in an interface.
• Fix the alignment too. Right-align anything counting up, so the digits grow leftwards into space rather than pushing the label around.

If your timer wobbles as it counts, that is not a layout bug. That is proportional figures, and it is one checkbox away from fixed.

The type scale

Pick four to six sizes and use only those. Games accumulate sizes the way they accumulate currencies: every screen adds one, and after a year nothing relates to anything.

Then set a floor per platform, because the same design ships to very different reading distances.

Weight, and why thin fails

• Thin and light weights disintegrate over texture, at distance, and through VR lenses. They look elegant in a mockup and vanish in the game.
• Build hierarchy with weight before size. A medium next to a regular reads as a hierarchy without costing a single pixel of space.
• Do not use more than three weights in the interface. Four is where a design starts to look uncertain.
• Beware of faux bold. If the engine synthesises a bold from a regular, the result is muddy at small sizes. Ship the real weight.

Contrast: your type sits on moving art

A book's page does not change. Your background is bright one second and black the next, and any legibility borrowed from the scene will fail in the snow level.

• Give text its own contrast: a low-opacity scrim, a subtle outline, or a soft shadow. Pick one method and use it everywhere.
• Outlines need to be proportional. A heavy outline at 16px eats the letterforms; test rather than guess.
• Test against your brightest level, not the grey box scene. This is the same rule as in seven HUD mistakes, because it is the same failure.
• Do not rely on colour for contrast. Desaturate a screenshot: if the text disappears, it was surviving on hue.
• Check subtitles separately, because they sit over the busiest possible background by definition. The rules are in game UI accessibility.

Blocks of text, and how little of them is read

• Cap line length. Around 45 to 75 characters is comfortable; a paragraph running the full width of a 21:9 monitor is unreadable and looks unconsidered.
• Line spacing carries more than size does. Tight leading is the fastest way to make a readable size feel unreadable.
• Break it up. Two short paragraphs beat one long one, and a list beats both.
• Assume skipping. Whatever the paragraph says, the design has to work for the player who read only the first line. That is a UX writing problem as much as a typographic one.

Case, tracking and the all-caps trap

• All caps works for short labels and destroys long ones. Uppercase removes the word shapes people read by, so a sentence in caps is read letter by letter.
• Add tracking to caps, always. Uppercase set at the same tracking as lowercase looks cramped.
• Do not track small text loosely. Below body size, extra letter-spacing pulls words apart and slows reading.
• Never fake small caps by shrinking uppercase. The weights stop matching and it shows.
• Sentence case for anything explanatory, caps for short buttons and labels if the art direction wants them.

The text that is not English

Even if you never localise, designing as though you will produces a more robust layout. If you do localise, this is where typography turns into a production problem.

• Design against the longest string, not the English one. Many languages run significantly longer, and a label fitted exactly to English will break.
• Non-Latin scripts need coverage or a fallback, and a fallback face that looks nothing like the original undoes your typography in exactly the markets you paid to enter.
• Vertical metrics differ. Scripts with taller ascenders or complex diacritics need more line height than your English mock-up implied.
• Right-to-left is a layout change, not a text change. Plan for it or decide explicitly not to ship those languages.
• In Unity this lands on TextMeshPro fallbacks and atlases, covered in designing game UI for Unity.

Licensing, briefly

A desktop licence usually does not cover embedding a font in a shipped game, and game licences are priced separately. Settle this before a hundred screens are set in a face you cannot legally ship. The detail is in what to send your UI designer.

A type audit

1. Screenshot a busy gameplay frame and a menu. Count the distinct type sizes. More than six is a scale problem.
2. Count the typefaces. More than two in the interface needs a defence.
3. Watch a counter tick up. Does anything shift? If so, switch to tabular figures.
4. Set your smallest text over your brightest background. Still readable?
5. Desaturate the screenshot. Does any text disappear?
6. Stand at real playing distance for your platform and read the settings screen.
7. Find the longest item name in the game and check it in every place it appears.
8. Make one label 40 percent longer and see what breaks.
9. Check whether any bold is synthesised rather than a real weight.
10. Read one full paragraph of in-game text out loud. Would you have read it as a player?