Mare Sheppard and Raigan Burns are game designers, developers, artists, and co-founders of Metanet Software. Over the last 12 years they’ve iterated upon N, their first release, and recently released N++ on PS4 and PC. They graciously shared their thoughts on UI design, the importance of graphic design, and a ton of their design process on N++!
For more images of the UI in N++, check it out in the UI Archive.
How did you start working on games?
We both took some computer science classes at U of Toronto; at the same time, we were playing a lot of freeware and abandonware (courtesy of Home of the Underdogs) and being really inspired by games made by 1 or 2 people—it made us think we could do it too. So we just started experimenting and trying to program little prototypes, learning gradually over the course of a few years.
Have you noticed any trends in game UI/UX over the last few years?
Not really! We don’t play as many games as we’d like. This is why your site is so useful—it lets us see what we’ve been missing.
When everyone moved to Scaleform it seemed like there was a marked uptick in games that had horrible latency in their menus—just everything loading very slowly, inputs being dropped or blocked, etc. Awful feeling menus.
It seems like indie UI is often better, but that might just be because indie games tend to be a bit more minimal and simple, so that they maybe don’t have as much work to do.
And there are cool experiments—eg BaraBariBall with your jumps represented as a ring of dots around your character. In general I wish more games tried to make vital info easier to read like this—often stuff gets crammed in a corner and you don’t really have access to it when you need to focus on your character.
What is critical to successful game UI to you?
We think the best UI doesn’t get in the way of players, but also makes sure to support them with information they need.
A good example of a problem is in Dark Souls 3: when changing equipment they show you stat deltas (so you can see the effect that changing weapons/armour will have on your stats), which is useful. But they don’t show stat deltas in the shop UI! Which means when you’re trying to buy stuff, you either have to memorize a couple dozen numbers to compare, or write them down, or go back and forth between store and inventory comparing them one by one. In the end using a wiki is the least-painful way to figure out loadouts, and maybe in the age of Minecraft having the wiki be a vital part of a game is okay, but to us it still feels pretty horrible.
We really don’t know why stuff like this keeps happening in games… Possibly because players are so used to having to wade through terrible UI that they don’t notice or complain; maybe as an industry we’ve normalized bad UI experiences.
Where do you see the greatest room for improvement in game UI today?
The current state of “game feel” in menus is abysmal. We find it incredibly frustrating when there is latency between inputs and audio/visual feedback, and sadly this is the norm.
Responsiveness in menus is something that almost no one seems to care about (or they care, but it’s cheaper to just ignore the problem), and in our opinion it plays a huge role in how “solid” the game feels.
It’s easier to program menus if you take a laissez-faire attitude to when stuff happens; lots of UI libraries sort of guide you towards this attitude, because they’re all callback-based so you don’t really know when or where stuff is actually happening. But this is really important info to keep track of, because otherwise you end up introducing extra frames of latency which feel bad.
And then there’s just dumb stuff like not loading the whole menu system but only the current page, so that every time you change pages, there’s a little loading hiccup/stall. Why?! Again, I think middleware is part of the problem: they provide a generic solution, and load-on-demand is a generic solution, but it sucks. Computers are blazingly fast and have gigabytes of memory these days, it seems weird to not use those resources to provide a better experience to users (eg by keeping the menus always in memory so there’s no loading delay at all when invoking them).
A great test for a game is: can I navigate the game without looking at it or hearing it? i.e can I enter a sequence of inputs and have it respond to each one, without ignoring or blocking any of them? Most games just fail: after making a selection your input will be ignored/blocked while the UI does some stupid fancy transition animation; as a result it feels inconsistent since you can’t just hammer in a sequence of inputs you know should work, you sort of have to navigate the menus in a delicate blind probing because you’re never sure when you’re in control or when you’re blocked.
There’s no good reason why your menus should have any more latency than the game itself: every frame the user should be able to press a button and get a response, without being blocked.
What can games learn from the history of graphic design?
Graphic design is a combination of beauty and clarity, and can display and communicate information to an audience in a really striking and balanced way, and we think those lessons should be pulled into games, which sometimes tend towards the functional side of the spectrum and lose the aesthetic. Good graphic design balances both equally.
With N++ one cool thing for us was seeing how stylish graphics and UI and a solid logo all interrelate, and contribute to the entire presentation of the game, including merch and marketing. The design of the logo, entities and elements and level shapes complimented each other nicely and allowed us to really get creative and abstract with how we thought about the game in general. We were able to make some interesting merch, and we also came up with unusual ideas like printing scarves for an ad campaign.
The process of working with a graphic designer and the inspirations that led to the aesthetic direction of the game definitely influenced the results, and what we were motivated to create beyond the game itself, which we found really interesting.
Also, we think there is a huge untapped potential for games to start using graphic design not just for UI but to inform the entire visual design of the game itself. Metrico is a cool example of this; in general if you look through a good book of graphic design, you’ll find such a huge range of visual styles, it makes you wonder why most 2D games are still retro pixels or cartoon/illustrated style.
What are your favorite game interfaces?
The menus from Wipeout 3 are definitely a favourite, and certainly an inspiration for the UI in N++.
Lately we just played Hyper Light Drifter, which beyond being a terrific game also has an amazingly brave and bold UI design: the use of text has been virtually eliminated. This is incredibly challenging to do well, but they pull it off, and it adds so much to the game: it feels like its own self-contained reality, a little world that has its own visual pictographic language. It was awesome to see Hyper Light Drifter build UI into its world in a totally cohesive way. We would love to see more devs put that much time and effort into their UI.
What are your favorite design books?
We have been collecting design books for over a decade, so this is a hard question to answer! 🙂
Lately we’ve been posting some our our favourites on our blog: http://www.metanetsoftware.com/tag/library
We have so many favourites, it’s hard to choose, but definitely DS101, Idea Mag x TDR, Narita Inspected, TD 63-73 and Buro Destruct‘s series are up there.
What did the UI design process on N++ look like?
It was a very roundabout process, and took a surprising amount of work.
Initially we had the idea that the game itself was 2D and grid-based, so the UI should also be; we wanted to avoid branching yes/no trees because they’re boring and tedious and just seemed so thoughtless. Surely we could do better!
The 3 game modes (Solo/Co-op/Race) and 3 pages of levels (Intro/N++/Legacy) form a 3×3 matrix, so we had the idea of laying everything out in a 2D grid where the X and Y axes would always represent something: menus would present NxM matrices of child menus, levels were arranged on a huge grid with difficulty increasing in a gradient along X and Y, etc.
The other piece of the puzzle was that we were going to lay out all of the menus on a 2D plane, in a sort of visual hierarchy, so that as you press a trigger button the camera gradually “zooms out” of the particular screen you were in to reveal the entirety of the UI (all pages of all menus) in a tiny iconic form (and then you could zoom back in to a different screen).
We stole this idea from the OP-1, a really cool portable synthesizer: it contains a lot of hidden state, so as a sort of cheat, you can press shift+help and get a live diagram of the signal flow through the whole machine, sort of an overview of all the components that normally you only see in fragments, a single screen at a time.
The idea of taking something that is usually implicit to the user—the “site map” of a game’s UI—and explicitly showing them all the pieces and how they relate together in a single zoomed-out screen, seemed like a really cool challenge and a fun idea. Plus we figured it would make navigating faster and easier since players could zoom out to jump between any screen without having to traverse a hierarchy.
Unfortunately (maybe predictably), this didn’t end up working; we spent a lot of time trying to make it work, but in the end it was just a bit too weird, and also had problems in a bunch of edge cases—for example there’s just some info in games that is naturally 1D rather than 2D (eg user-made levels sorted by date), and this sort of just pointed out how awkward our approach was.
After several months of banging our heads against this problem in between making levels, we realized that we had to give up on our dream of developing a new UI paradigm. We had to admit that the reason everyone uses hierarchies of lists + yes/no buttons isn’t that it’s good, but that it’s standard/functional: it may not be optimal, but displays the relevant information and it has the advantage of being something everyone understands how to use it without having to learn a new UI paradigm from scratch just for one game.
It’s a bit frustrating because there are so many potentially better ways of breaking things down or presenting them, but it seems like we’re all stuck in a local optimum.
How did the UI design change over time?
Once we had the basic look of the menus down (thanks to MASA), most of the changes were just in response to development (eg realizing that we needed to add some piece of info or functionality to a given screen).
Additional early mockups of the UI:
How did you collaborate with MASA? How much of his work made it into the final game?
Our initial plan was to hire a graphic designer to design all of the menus (and in-game game graphics), however we ended up spending half of our graphic design budget on a designer that didn’t work out…which was unfortunate.
This meant that as a compromise, we decided to hire someone to develop concepts and reference material which hopefully covered most of the UI problems we would face—then we could flesh out the rest of the UI ourselves using the references made by the designer.
We worked with MASA during spring/summer 2013; he’s located in South America while we’re in Canada, so it was all through skype and email.
Our main goal working with him was to define the look of the game—both in-game and menus—as well as develop a new logo. We think this was a huge success.
We prepared a “design bible” of reference material that we thought might be interesting or useful, mostly taken from our library of design books. (This is something we prepared before we contacted any designers, as a way to hopefully communicate the direction we wanted to explore)
The first week or two was just discussion; we laid out what our goals were (“modern” clean print graphic design look; vector based; lots of info to convey in menus) and talked about various issues, getting us all on the same page. You can see some early stuff if you scroll all the way to the bottom of our tumblr.
MASA then began preparing a lot of mockups and proposals for a direction, starting really broad and then narrowing down as we discovered what we thought worked and what didn’t. Every week we would meet and discuss what he had prepared; we always had the meetings a day or two after being sent new material, so that we had time to reflect on it properly. (This was his idea—we had never really worked with an external consultant before, but this trick is super useful and something we’ve been applying to every decision we can: sleep on it)
The first thing we started with was the logo; this was really tense, as we we knew we needed something dramatically different, yet we were really unsure how to proceed. In the end we’re really happy with how it turned out, but the process was quite stressful since nothing seemed like it was working, right up to the final solution.
The main reference is of course the legendary Wim Crouwel, specifically his poster for Claes Oldenburg (which has recently been developed into a full font, called Architype Catalogue); probably most people in games are familiar with it from Wipeout 3—The Designers Republic referenced it in the team Icaras logotype.
We actually tried a much more literal copy of the font ourselves when trying to brainstorm a logo, but MASA instead did an amazing job of taking a similar idea (at concave corners little bits are cut out) and applying it in his own way that worked much better.
The logo took about half of our time with MASA, which might seem a bit extreme, but it was vital as once it was set the rest of the design crystallized around it.
Wireframe versions of the logo featured slightly rounded, slightly-thicker-than-hairline vector lines, and we used that as the basis for all of the in-game graphics. MASA would prepare grids of many different symbols/shapes, and we would discuss what we found interesting and which could be used to represent what in the game.
These in-game graphics were really hard to get right—they needed to refer to previous iterations of the game, but match N++‘s more modern/clean feel. We took a handful of the symbols MASA developed and used them as the basis for the in-game graphics; in the end we may have been a bit too conservative; certainly we took far more liberties applying MASA’s concepts to the in-game graphics than we did with the UI. We felt that in-game, functionality was key and thus we decided to err on the side of “could be less boring but works well”.
The last thing we worked on with MASA was the menus; at this point we didn’t have that much time left, but the logo and in-game graphics really helped narrow down our focus so we were able to hone in on a good solution without too much iteration.
In the end we were left with a couple screens of finalized UI mockup, which we used as the basis for designing all of the menus (i.e trying to apply the style of the mockups to all screens)—and also, most importantly, a great font. (More on that later)
Then there are the colours. Right from the start we knew we wanted to experiment with colour, but we were thinking relatively conservatively—i.e keep the grey tones but try adding more accents. MASA designed the default colour scheme, “vasquez”, to be very similar to N/N+. (It’s nice, with the series we’ve run the gamut: N was grey-blue, N+ was grey-red and N++ is grey-green!) But he also thought that we were much too attached to grey, and began really pushing back and questioning whether that was really a good idea. We resisted at first, but as soon as he started sending mockups with neon coloured tiles, we realized that this was a really new and exciting direction that could actually work!
We didn’t have time to fully explore colours with MASA, but he got us on the right track with a bunch of colourful mockups that gave us a direction to aim for. We asked a friend of ours who is a visual artist, Lisa Harrison, to make some mockups—we sent her a mocked up scene in illustrator and had her try to find different colour palettes that worked.
Armed with these starting materials, we then began to prototype and implement all the colours in the game, developing each colour scheme. They look simple, but each one requires defining about 200 different colour values!
What were the biggest UI issues you needed to address from N+?
If you’re unfamiliar with N, levels are laid out on a grid; the top row of the grid starts unlocked, and beating a level unlocks the level below it. This helps prevent players from getting stuck, since they can always move to a different column if they can’t progress in their current column.
The main problem in N+ was that, though all the levels were laid out on a grid, we only showed the player one column at a time. This meant that a lot of players didn’t realize that they were free to try different columns without completing the previous one! Not only did this make the game a lot more linear than we intended, there was an accidental difficulty spike about 1/3 of the way through the game. This meant that a lot of players gave up without realizing they could just skip that problem level! Purely because of a UI failure.
This time we vowed to not make the same mistake…but we accidentally made a different one.
We now display the entire grid on screen at the same time, to make it perfectly clear that players have a lot of options. However, because of how we present the info (the top row starts unlocked), and maybe because people tend to read left-to-right, the result has been many players playing row-by-row rather than column-by-column! An unfortunate overcorrection on our part.
This is a problem because the levels were arranged assuming columns, which means that the difficulty curve of playing rows is much more flat and feels a bit boring and undramatic. Some players seem to prefer it that way, but in general we wish we had done a better job of communicating this aspect to players, or that we’d been able to explain better how much choice players have in how they want to play through the levels.
Actually, this highlights what our real main challenge was: we wanted to avoid the typical “annoying paperclip” tooltip help text that many games use to point out and introduce players to each element of the UI. We find this sort of approach annoying, and tried really hard to simply present players with a set of commands and let their natural curiosity guide them to explore the UI and learn for themselves what everything did. This hands-off approach definitely helps the game feel a bit cleaner, BUT the downside is that most users are unaware of a lot of the functionality built into the menus.
What do the Colo(u)r Blindness options in the game affect?
We used a couple free tools to look at each colour scheme and identify those which might be ambiguous or hard to read for players with certain types of colour blindness. The game uses this info to filter/hide colour schemes which are problematic from the list; so, rather than modifying the colour schemes, this simply omits those that are potentially a problem.
What tools did you use to create the game’s UI/graphic assets?
The UI is unfortunately all hard-coded, pure C++ code. This was not a great solution; we figured it would save time vs having to write a lot of importing tools, but in the end it’s debateable since the menus took an egregious amount of time to program.
We would mock up each screen for our programmer, along with all of the functionality to be implemented (which buttons did what, what the animations looked like, etc). We used Illustrator, Flash, and Photoshop to prepare the mockups.
What typeface are you using in the game, and how did you choose it? Were there any licensing challenges?
We’re using Sys 2.0, by Fabrizio Schiavi.
This was actually something MASA found—when developing the menu mockups one of the main challenges was to find a font that worked. It actually took a really long time to find a good font, we were getting pretty worried because absolutely nothing was looking good; it was all either too “rave” looking (futuristic fonts) or too “old” looking (standard print fonts).
Sys is great because its uniform-thickness lines perfectly mirrors the style of the in-game graphics, helping everything to feel even more coherent. It’s simple and geometrical, looking clean and futuristic in a timeless way (rather than the very poorly aging futuristic fonts popular in the early 2000s).
Sys 2.0 also includes a ton of characters (very useful when you need to support all European languages).
Licensing was great—we were really stressed about this, but we simply contacted Fabrizio and he was very helpful.
When designing the UI, did you need to make any changes to accommodate both console and PC versions?
We set 1280×720 as the minimum resolution and used that as the size of all mockups (since scaling up is easy but text can’t necessarily be scaled down without problems).
In terms of UI, we definitely designed for the PS4 specifically—I really love our use of the trigger buttons as amodal menus, something that had always seemed obvious to us but for some reason is rarely done in other games. Try pressing the trigger halfway down for fun. 😉
Unfortunately this approach caused problems on PC. We tried as much as possible to work around them, but in the end I think the UI is probably best enjoyed with a gamepad. This seems like a natural consequence of designing for a specific platform, and while it’s frustrating it’s also hopefully a sign that we did the right thing initially—if there hadn’t been problems, that would suggest that we didn’t really take advantage of the specific affordances of the PS4.
It’s unfortunate that unless you design for a lowest-common-denominator, you always end up running into a few awkward issues. Or maybe we just need more practice. 😉
How did you test the UI throughout the game’s development?
Simply by using it as we performed the usual testing. In general most big problems were caught at the mockup and implementation stages, we don’t remember having to change anything big once it was up and running.
The UI ended up being much more challenging than we had anticipated—we started out by assuming that the reason most games have bad UI is largely because it’s not high priority for either the devs or the audience, but in the end we realized that it’s probably because of how much time and effort (and stress) is required to properly tackle some of the problems. And maybe that most developers are less idealistic and more pragmatic when it comes to allocating resources to UI.
After 12+ years, have you gotten tired of N/N+/N++ yet?
We haven’t gotten tired of playing it, but we’re so satisfied with how N++ has turned out, we don’t feel the need to ever make another one, which in our eyes is a huge success. Especially in terms of level design, we feel pretty exhausted.
Playing N++, and especially watching other people play via Twitch and YouTube, is still amazing 🙂