David Sinclair is a UX design leader who's previously worked at Carbine, Bungie, Crytek, and Sony Online Entertainment.
I want to take this moment between jobs in the shit-show games industry to talk about designing interface and information systems for video games in the context of multi-platform development. I first started thinking about this when I was working on Destiny as part of the initial planning team around bringing Destiny 2 to PC. Then later at Carbine Studios, I was working on a now canceled game which we planned to ship simultaneously on multiple platforms.
In this piece I’ll confine "multi-platform" to Console and PC games because that’s where I’ve focused a lot of my attention over the past couple of years. Though I do recognize the beginnings of a trend to bring core PC and Console games to mobile—PUBG and Fortnite are two examples.
This article is aimed at UI minded folks working on AAA/AA games with a view to helping them to avoid creating problems for themselves while still providing a great player experience.
Starting Off on the Right Foot
If you know you are going to make a multi-platform game that spans game consoles and desktop PCs, then it would be wise to take this fact into account from the outset when it comes to interface and information design. This is because designing and building twice is expensive and generally a stupid idea.
Waste is the number one problem that plagues the game industry—I’m not going to qualify it here; I’ll probably write about that in some detail if I remain unemployed long enough to get around to it. While employed, I tend to throw myself into it and not come up for air for months at a time.
Onward…
Two designs, two implementations, and if you really fuck it up—two UI teams. That’s what you’re looking at if you focus entirely on one platform in the development of interface and information systems. At best you will set yourselves up to face the various challenges that come with porting your game to another platform. It can get much worse if you actually decide you want to design and build two completely different systems from the get go (I’ve never heard of that actually happening in the case of PC and Console, but now I’ve put it into the Universe…). That’s how you’ll likely encounter the two UI teams issue.
Furthermore, I’d go so far as to claim that even if the original plan is to release on a single platform, still design for the likelihood that that it will make it to other platforms eventually. I triple down on that statement if you are using a multi-platform engine like Unreal or Unity—they make it so easy. The worst thing that could happen is that your UI is legible at any reasonable distance.
Many games have been designed with the sole focus on a single platform, then gone on to be very successful, warranting a release on another platform that has different user experience needs such as input options, screen viewing distance, device specific settings, etc. Anyone who has had to do a port will attest that it can be a real pain to do the work in general, and it’s much harder to do the new platform justice in terms of UX.
It doesn’t take much more effort to think this stuff through in the beginning in spite of current platform plans are. I believe that regardless, your design will be better off for it for reasons that may become clear later on
if I remember to qualify that statement.
The Central Problem
Designing interface and information systems for multi-platform games requires the team to consider what I believe to be the central problem at hand:
How do we design and build UI and information systems that look and feel appropriate for the platform and input scheme the player is using while being mindful of development resources?
The variables for consideration are numerous but most can be filed under two key differences between PC and Console platforms:
Consoles have limited input options for most players (controllers) while PC players are generally accustomed to a more versatile mouse and keyboard input scheme.
Console players at large tend to play on TV sets while sitting some distance away, while PC players more often than not are right up close to their monitors. The primary concern here is legibility of information—colored text at a font-size of 9 points barely flies when someone with great eyesight is hunched over their keyboard only inches from their monitor, let alone on a 40 inch TV on the other side of the room.
Interestingly, these are now fast becoming outdated generalizations born out of a time before:
the resurgence of 8 and 16bit-influenced indie games, many of which are very compatible with (and arguably best suited to) controller play
HDMI becoming standard for both monitors and televisions
casting technology like Steam Link
increasing awareness of accessibility needs
These factors have facilitated significant change in actual player behavior. More PC players have controllers and expect to have the option to use them when they please. Likewise there is increased support for the mouse/kb scheme on both PlayStation and XBOX consoles in recognition of greater attention needed to making games playable to people with diverse accessibility needs.
The truth for game developers, is that the lines between PC and console have become blurred and that the problems mentioned above are really just variance in input preferences and viewing distance.
The only immutable difference that currently exists between console and PC’s in gaming is the PC player’s need for more settings to best leverage their hardware, e.g. graphics. This something I’m not going to cover today.
In this article (which is already longer than I thought it would be) I’m going to recommend a specific variation of several “console first” approaches. I think this term is easier for people to get their heads around, but in truth I’m recommending an approach which focuses upon the most difficult problems first—larger viewing distances and limited input methods (controllers).
I feel that this distillation of the problem is helpful in focusing our design efforts.
Console First
I feel like for most people reading this, especially those already in games in a UX design role, it might come across as a bit patronizing to have me here saying “You guys should, like, design for console first.” as if it wasn’t already obvious. I can live with that.
For everyone else, this is why I recommend the already quite widespread practice of console-first UI and information design:
If something is legible at the 10ft view, then its legible up close—every time—unless we are talking about a Monet. This isn’t true the other way around.
If you can make your control scheme work on a controller, then you can adapt to PC. It’s harder the other way around when you have dozens of keys to choose from and a mouse. That’s how you get the classic MMO systems involving heavy keyboard use and window management.
In the wild
I think the best way to illustrate the approach that I’m going recommend at the end of this article is to go through some real-world examples of how others tackled multi-platform design. I’m about to get specific in referencing certain games and it’s very important to me that I make it clear that I’m not shitting on any of these games or the people who made them. I don’t do that; it’s a miracle any game gets released at all. Also every one of the games I
No tags.
