2008년 10월 16일
Menu Construction
I was talking with a fellow designer recently about menu functionality in games. He asked my process for creating them, and I decided to post that here.
1. Assume the menu is lying to you about its need.
Whenever a menu, text box or other pop up occurs in a game world, it has the potential to break the sense of immersion that you’ve worked so hard to create. Fight against its need to be, and ask yourself if there is another way to provide the player the information or get the information you need from the player. There often is.
2. If you feel the menu really needs to be, list every single thing that needs to be in that menu.
Usually, the game options menu is allowed to live. That menu typically contains everything from music/fx/voice control to subtitles to vibration toggles for console titles. Load and save game menus are sometimes nested inside of the options menu.
Generally, I list every single thing I think needs to be in the menu in no particular order.
Brightness
Volume - music
Volume - effects
Volume - dialogue
Subtitles - on/off
Vibration - on/off
Difficultly level (if it can be adjusted during play)
Now try to kill each thing you’ve listed. Do you really need it? One of the biggest problems with designers is their natural need tendency toward game sprawl as epitomized in Master of Orion 3 with its 54 (or more) separate menus. During the alpha of that game, it had many, many more. So, again, assume that these options are lying and ask yourself if you really, really need to have them there. Some are mandated by the TRC/TCR/LotCheck (first party publishing requirements).
3. Don’t nest.
With the options listed and vetted, I decide what’s going to be in the menu. One of the things I frequently see from junior designers is the neat but annoying decision to nest menus one under the other. As a general rule of thumb, I go for the fewest button presses/clicks for the player to get to what they want to get to. Nesting obviously works against that.
For instance:
Options -> Music Menu -> Music Volume
Options -> Music Volume
In the above scenario, there’s no need for a specific Music Menu if there can be a section of the main options screen that allows the player to adjust that.
4. Give things priority.
I also list options in order of likely use. For instance, you’re more likely to save your game than you are to adjust the music volume, so more frequently used things get menu priority.
5. If you can’t select it, don’t show it (or make it greyed out)
If you can’t use it - like “Load Game” at the beginning of the game - don’t show it.
6. Decide the default selection
Whenever you select a menu in a game, something should be the default selection. This is often missing in design docs and left to the programmers to select, though they have way better things to do.
7. Document it / Prototype it
Many designers today prototype menus in flash or other tools to give an idea of how the menu should function in a game and to test out the menu flow. Documentation should specify precisely how the menu works. I’ll post more on that tomorrow.
1. Assume the menu is lying to you about its need.
Whenever a menu, text box or other pop up occurs in a game world, it has the potential to break the sense of immersion that you’ve worked so hard to create. Fight against its need to be, and ask yourself if there is another way to provide the player the information or get the information you need from the player. There often is.
2. If you feel the menu really needs to be, list every single thing that needs to be in that menu.
Usually, the game options menu is allowed to live. That menu typically contains everything from music/fx/voice control to subtitles to vibration toggles for console titles. Load and save game menus are sometimes nested inside of the options menu.
Generally, I list every single thing I think needs to be in the menu in no particular order.
Brightness
Volume - music
Volume - effects
Volume - dialogue
Subtitles - on/off
Vibration - on/off
Difficultly level (if it can be adjusted during play)
Now try to kill each thing you’ve listed. Do you really need it? One of the biggest problems with designers is their natural need tendency toward game sprawl as epitomized in Master of Orion 3 with its 54 (or more) separate menus. During the alpha of that game, it had many, many more. So, again, assume that these options are lying and ask yourself if you really, really need to have them there. Some are mandated by the TRC/TCR/LotCheck (first party publishing requirements).
3. Don’t nest.
With the options listed and vetted, I decide what’s going to be in the menu. One of the things I frequently see from junior designers is the neat but annoying decision to nest menus one under the other. As a general rule of thumb, I go for the fewest button presses/clicks for the player to get to what they want to get to. Nesting obviously works against that.
For instance:
Options -> Music Menu -> Music Volume
Options -> Music Volume
In the above scenario, there’s no need for a specific Music Menu if there can be a section of the main options screen that allows the player to adjust that.
4. Give things priority.
I also list options in order of likely use. For instance, you’re more likely to save your game than you are to adjust the music volume, so more frequently used things get menu priority.
5. If you can’t select it, don’t show it (or make it greyed out)
If you can’t use it - like “Load Game” at the beginning of the game - don’t show it.
6. Decide the default selection
Whenever you select a menu in a game, something should be the default selection. This is often missing in design docs and left to the programmers to select, though they have way better things to do.
7. Document it / Prototype it
Many designers today prototype menus in flash or other tools to give an idea of how the menu should function in a game and to test out the menu flow. Documentation should specify precisely how the menu works. I’ll post more on that tomorrow.
# by | 2008/10/16 10:40 | Game Design | 트랙백 | 덧글(0)





☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]