Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
Should you consider practicality, utility, or legibility of UI that's destined for the trash?
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 experience.
And in highlighting this at the design consultation workshop, I saw the flash of realisation behind a few eyes at the table. Uncertainty crept into the room.
Which game was fun? The game design they’d imagined, or the stat-heavy game living inside it?
It’s clear that debug and placeholder UI doesn’t deserve too much thought. Certainly this devteam could have saved a lot of heartache and reviewing of their decision-making if they’d just thought to turn off everyone’s debug readout. Trust me when I say it’s one of those ‘obvious in retrospect’ moments.
But there’s no denying that placeholder UI will inform a player’s opinion and experience of gameplay. During internal play-sessions and user testing those placeholders and readouts will inform how players play and the strategies they use. As the devteam above found out: just because there’s no final UI doesn’t mean that the placeholder UI isn’t affecting the player experience.
So teams have the impossible task of quickly throwing together a UI that is somehow analogous to the final UI in various ways, is quick to implement, versatile to change, suitable for internal play-sessions and showcases, but also supports the team’s various technical needs for development.
Here are a few ideas and practices to help make early placeholder UI as effective as possible — particularly when you’re running early playtests and internal play-sessions — and avoid game design being accidentally undermined.
Variable readouts provide an ever-present and exact readout of some game variable that’s otherwise unknowable. It’s typical that placeholder UI is therefore numeric, specific, and persistent:
99 HEALTH
In contrast, final game UI often trades-off high specificity for rapid legibility: e.g. health bars instead of health numbers. It’ll use approximations of distance, time, or cool-down. And show information only while relevant to decision-making.
Like so many things in gamedev: The designs that are quick-to-implement are in contention with the designs that better orchestrate the player experience.
Before any internal play-sessions, discuss and set some boundaries for what information should be designed as accurate and slow to read versus information that is approximate and fast to utilise by players. Perhaps you’ll find some justification to reduce the displayed accuracy of gamestate variables in your prototype, or change the way they’re presented to use symbols or simple visualisations instead of text.
One of the easiest ways to get information out from ‘behind the curtain’ is to print text to screen. This really biases teams toward visual and alphanumeric presentation of information. Video games are primarily a visual media; a fair amount of the ‘experience of play’ can be defined by what the player looks at on the screen. So it’s important to control which attention-grabbing activities are permitted to be shown.
Consider how simple sounds or haptics could be used instead of a visual readout, and if they might be less interruptive, or more reflective of the final experience.
Using auditory, haptic or otherwise non-textual communication allows teams time to find the ‘game language’, and get it in front of players earlier. For an example of the value here, check out this thread on the iterative process that forged an all-auditory whistle-language used by The Last of Us Part 2’s Scars (mild spoilers).
I propose that it is a greater risk associated with presenting too much information than presenting too little with your early prototype. Especially if most of that information is in text.
Anecdotally, it’s easier to persuade folks on the value of an addition of information than removal; playing the game day-in-day-out quickly leads to reliance on the information we’re presented. Moreover, understanding the impact of an interface design addition is a lot easier if you’ve got historical playtest data from before you added it.
That said, this exists as a serious approach: “The Scream Test” of taking features away, and waiting to see if-and-why you get an earful from your colleagues or players, therein a metric for how much a feature is really used.
Like Neo in The Matrix, there are going to be some folks in-studio who can ‘see the code’ as they’re playing, to their benefit during play-sessions. Hopefully your internal play-sessions are including a wide variety of devteam members, including those that are not technically involved with the ins-and-outs of the project.
If placeholder UI is needed, make sure it’s labeled and clear, and not using in-game jargon. If one person is using that information for an advantage, that’s not OK. If everyone is using or abusing some information in-game, that’s at least consistent, and should be reflected in the feedback you capture.
As noted above, debug is meant to be accurate; by definition then it’s also meant to be true. But certainly there is a place for lies and half-truths in displayed information.
The Apex Legends team recently shared how their internal play-sessions used fake player names and disabled voice chat to focus improvement on their in-game ping system: you can imagine that having colleagues’ names in their internal play-sessions undermined their ability to emulate random players squadding-up online.
Consider if adding a layer of fakery or obfuscation - designed to emulate real play, or gameplay depth that doesn’t yet exist— could somehow improve the feedback you’re getting.
Ensure you’ve got the ability to quickly turn off any technical readouts once you’re seeking feedback on ‘fun’.
Our research teams are constantly putting real players in front of prototypes. It’s not uncommon for the playtest built to have retained some backend-only readout like a framerate counter. Even if part of the playtester’s briefing is to ignore that element (“it’s not part of the test!”), it will nonetheless grab player’s visual attention, and risks dragging them out of the experience.
The ability to see where players are affixing their eyes in real-time is transformative for understanding how players use UI-heavy games. Eye-tracking has even been used to train eSports professionals to manage their attention and minimise ‘poor’ gaze behaviour.
Researching UIs with eye-tracking can show how players are using (or not using) UI. It’s best used for assessing individual UI elements and gameplay scenarios, and can be utilised for player research on placeholder UI.
Thinking back to the playsessions I’d seen affected by debug text, the team were left with a stark question: Which game was fun? The game design they had imagined, or the stat-heavy game living inside it?
The answer, of course, was: both versions. Their eventual design will end up learning from each extreme. To move forward, the team needed to separate the player-facing from the dev-facing HUD, and see what gameplay emerged, using playtesters from the public and not the devteam.
And of course now they’re a now a little more careful to design their placeholder & debug UI…
Read more about:
Featured BlogsYou May Also Like
