When Debug UI Ruins Game Design (and what to do about it)

Player Research
7 min readJul 21, 2020

One of the quintessential hallmarks of a ‘work in progress’ game is debug text. Floating gibberish flickering in the foreground of gameplay, occasionally catching your eye with an <ERROR> or a ‘Missing_Texture’.

Thinking about the design of debug UI seems like misspent time. It is, by its nature, only to be used by our development team, and never to be seen by our eventual players.

Why spend more than a single moment considering practicality, or utility, or legibility of UI destined for the trash?

And so, when in a recent UI design workshop I proposed a re-thinking of a prototype’s debug text, it raised a lot of eyebrows.

The studio’s creative team are sprinting on a fast-paced PC multiplayer game, with a range of arcade-y game modes. The internal dev play-sessions were finding loads of fun; the game was starting to shine and the team were in great spirits. But, in my visit on-site and peering over devteam shoulders to watch them play their prototype, it was clear that something was awry.

Multiplayer prototypes are almost always fun. Performing nearly any competitive activity with friends is fun; it makes player research on multiplayer games really tough. But it was clear in watching these sessions that the game the creative team had just described to me in the meeting room, and the game I was watching unfold in these play-sessions, weren’t one-and-the-same. Both were fun. But they weren’t the same game.

After a little thinking I find an unusual culprit: the debug text.

The devteam were so used to the verbose debug output scrolling past on-screen that no one gave thought to turning it off during the play-sessions. It was part of the fabric of the prototype: that green floating text belonged there.

But, with a keen eye, it would reveal information that was designed to be unknowable or obfuscated: the exact status of the enemy team’s win condition, your units’ exact health remaining, the exact damage done in an exchange of fire, and undoubtedly several other variables from ‘behind the curtain’.

And of course that data was being used by the devteam to find an advantage and beat their colleagues. It was being used to win.

Consciously or unconsciously, the devteam were playing a game within their game. A nerdier, more tactical, more complex version of their designed…

Player Research

The premier games user research partner. Where gaming instinct meets scientific insight. PlayerResearch.com