Menus Must Die
A part of designing a game is, by necessity, designing a means to interact with that game. The basic control scheme is topic for another post. As you can tell by the post title, this is about menus and why they must die.
Every time a menu or text box pops up in a game, it actively works to regress any kind of immersion you’ve created into the game world. There are so few exceptions to this – choices of a new skill when you gain a level, your new technology in Civ Rev or your preferred weapon. These choices are integral to the player’s performance in the game. So, even while parsing through various choices, the player is still actively mentally involved.
Contrast this with things like loading screens or game options. It’s here that unnecessary menu inflation is often found. Typically, a designer will write down every single thing they think needs to be in the menu –
Game Options
- Save game
- Load game
- Music Volume
- Effects Volume
- Dialogue Volume
- Controller Vibration
- Screen Resolution
- Subtitles
- Language
- Credits
That looks like a lot of stuff, so the next typical step is to compress and organize. For some reason, our heads seem to be wired that way. Put everything that seems like X into the folder labeled X. So, the compression goes something like this:
Game Options
- Save game
- Load game
- Sound
- Music Volume
- Effects Volume
- Dialogue Volume
- Language
- Visual Display
- Screen Resolution
- Subtitles
- Controller Vibration
This isn’t good, though, so don’t do it.
What’s happened here is that we’ve created three or more button presses (excluding navigation within the menu) in order for a player to adjust the volume in their game.
Game -> Game Options -> Sound -> Music Volume -> Actual Adjustment
That is a pain in the ass and a very long time to be away from a game world. So, what’s a better solution? Here’s how I do it, which may or may not be better, but it’s worked for me.
- Write everything down you think needs to be in a menu. Do this without reservation and look at other games to see what they include in similar menus.
- Accuse each thing in the menu of lying to you about its need to be there and try to kill it. Just because you can adjust it doesn’t mean it needs to be there.
- Try to limit everything to one button press to get to the appropriate menu or no press at all. Think not in terms of compression and organization but time in to time out.
Limiting everything to one button press if it all possible is the most critical for me. So, as a result, I don’t compress my menus after killing what I perceive to be unnecessary options. What seems to be a long list in a design doc often turns into a vast field of screen once its migrated to a console or a PC screen. So, to adjust the game volume, I might have it look something like this:
Game -> Game Options -> Actual Adjustment
There’s no reason that the various sound sliders can’t be in the main game options screen proper. Another thought – would it be possible to include a volume slider at the bottom of the screen that appears in response to roll over? In that case, there’s not even a button press, but direct interaction.
Such interaction isn’t always possible, but I try to make it a goal nonetheless. I kill every button press I can, I limit a player’s time in menus and try to kill menus wherever I can. One press in -> do what you came to do -> back out you go.
As a note, I don’t always succeed in simplifying things this much, but the effort seldom fails to improve the player interaction in some way or another. Furthermore, every menu takes both programmer and UI artist time, and the less of that I use for stuff like this, the better.
Applied Game Design 
“This isn’t good, though, so don’t do it.”
I think categorization makes sense from a cognitive standpoint, so — even if compression is to be avoided — it may still be a good idea to have a “flattened” version of your categorized menu through the use of group labels on the same level as your menu options.
Having said that, what would you recommend if your “must have” menu options won’t fit into a single screen? Do you favor scrolling through a single menu “page”, or would some kind of menu hierarchy then be acceptable?
Finally, although you haven’t mentioned it explicitly, I’m thinking your advice properly applies to menus shown during a game in progress, and not at all to the title menu? I mention this because I know I wouldn’t want a flattened title screen menu.
Ah, yes, Adrian. All very good points and precisely the reason I’m grateful for comments on this blog.
Yes, categorization and grouping within a single screen does absolutely make sense. You’d want your volume controls together, if only for aesthetic reasons. Players are going to look for things this way anyway, so it’s the clear way to do it.
On title screens, that’s an interesting question. I’m about to jump right in agree there, but then I think about Braid, and how the game has already started when you show up. You just walk off to the right. It was decidedly different, and I really liked it.
One thing that I do find interesting is comparing us to other highly immersive media like film. We take many conventions for granted (HUD, etc) that aren’t used elsewhere. I use this to challenge some base assumptions that I may have in the design process. I find a lot of people start designing a HUD without even questioning whether the game needs one or not.
This makes me think of Granada Espada, which I watched my girlfriend play quite a bit of – every character and enemy has a life bar, energy bar, bars that appear as they’re performing actions, big flashy numbers every time they do anything, etc., and the screen constantly has a message area on the side, stats for each of your 3 characters showing, a series of large menu buttons, and a scrolling marquee with server announcements.
In my opinion, this made the game a visual nightmare, and was especially bizarre considering that the game is meant to be a relatively low time investment, where most of the fun has to do with sitting back and watching your characters fight things on their own.
One more thing – I feel like I’ve read this post, word for word, before – have you posted a version of this before?
I wrote it fresh this morning, but in searching past posts, I have covered it before.
What consists of a button press? Does pressing an arrow on the directional pad count as a button press? What about how the analog stick is pressed/moved?
Moreover, does the player’s familiarity with the interface effect what amounts to a button press?
By button press, I meant something that gets you into a menu. That should have been more clear in the original post. I’ll edit that. Thanks!
I totally agree with this and wonder about your opinion on a related bloating and click problem. On PC games I don’t like the skill icons on the edges of my screen or having to move my hands a lot to press the buttons, like the numbers at the top of the keyboard. I’ve seen icons three deep on two sides of the screen and multiple menus for the number buttons to be used with.