We design game interfaces at full size on good monitors, then ship them to someone playing four-player split screen on a television across the room. The HUD that was legible at arm's length becomes a row of coloured smudges.
The test is embarrassingly simple. Export the screen, scale it to 40%, and look at it from normal viewing distance. Everything that still reads, works. Everything that does not, fails — and you have found it in a morning rather than after the animation pass.
Why 40%
It approximates the worst realistic case. A quarter of a 1080p screen in four-player split is roughly half the linear dimensions, viewed from two or three metres instead of sixty centimetres. The exact number matters less than the discipline of applying the same one every time.
We run it on three things: the HUD during combat, the inventory screen, and the end-of-match summary. Those are the screens read under pressure.
What fails, in order of frequency
Colour-only distinctions. Four players in red, blue, green and yellow is the classic. At 40%, red and green are the same grey to roughly one man in twelve, and at distance they are similar to everyone. Shape has to carry the difference — a triangle, a square, a circle — with colour as reinforcement, never as the only signal.
Thin strokes. A 2px outline at full size disappears entirely at 40%. Either go to 4px or drop the outline and use a filled shape.
Numbers that matter. Ammunition count, health value, timer. If the player has to read a number while something is shooting at them, it needs to be bigger than looks right in the mockup. Considerably bigger.
Icon detail. Icons drawn at 64px carry detail that turns to mud at 26px. Redraw them at the smallest size they will appear and scale up, not the reverse.
Low-contrast overlays. White text at 70% opacity over a bright scene is readable in a screenshot and invisible in motion. The background moves; the opacity does not.
The second test: freeze a real frame
The scaled mockup assumes a tidy background. Real gameplay has explosions behind the health bar.
Take three screenshots from actual play — the brightest scene, the darkest, and the busiest — and composite the HUD over each. Anything that depended on the background being calm will announce itself immediately.
This is where the designer's instinct to be subtle usually dies, and it should. Interface over gameplay needs its own ground: a scrim, a shadow, a solid plate. Something that does not negotiate with whatever is happening behind it.
What this bought on Kraken Arena
We ran both tests before any animation on a four-player brawler. Three things changed: player colours gained distinct shapes, the cooldown ring went from 2px to 5px, and the health numerals grew by about 40%.
In playtesting afterwards, players identified their own character on first play 96% of the time, against 61% before. That is not a subtle polish improvement. That is the difference between a game people can follow and one they cannot.
And the cost was one morning, spent before the expensive work started. Every one of those three changes would have meant re-animating if it had been found later.
Make it a step, not an instinct
Put it in the process between layout and animation. Export, scale, look, fix. It takes an hour and it removes the category of bug that is most expensive to find late and most obvious to players immediately.
Working on something like this? We do this kind of work for a living — software, design, delivery and the accounting behind it.
Start a conversation