Game Development Reference
In-Depth Information
operation to allow the stack to be cleared and have a new element pushed on top.
This is necessary when going from the main menu into gameplay, because you
typically don't want the main menu to still be visible while in gameplay.
Buttons
Almost every menu system has buttons that the user can interact with. For a PC
or console game, there needs to be two visual states for a button: unselected and
selected. This way, the currently selected button is clear to the user. The simplest
way to signify a button is selected is by changing its color, but sometimes the tex-
ture might change orthe size ofthe button increases. Some PC/console menus also
use a third state to denote when a button is being pressed, but this third state is
not required by any means. However, on a touch device a common approach is to
have only the default (unselected) state and a pressed state. This way, when the
user taps on the button, it will change to a different visual state.
If the menu can only be navigated with a keyboard or controller, supporting but-
tons is fairly straightforward. A particular menu screen could have a doubly linked
list of buttons, and when the user presses the appropriate keys (such as up and
down), the system can unselect the current button and select the next one. Because
the buttons are in a doubly linked list, it's easy to go back or forward, and also
wrap around if the user goes past the first or last element in the list.
Usually when a button is pressed, the user expects something to happen. One way
to abstractly support this is to have a member variable in the button class that's a
function. This will vary based on the language, but it could be an action (as in C#),
a function pointer (as in C), or a lambda expression (as in C++). This way, when
a new button is created, you can simply associate it with the correct function and
that function will execute when the button is pressed.
If the game also supports menu navigation via the mouse, a little bit of complexity
has to be added to the system. Each button needs to have a
hot zone
, or 2D bound-
ing box that represents where the mouse can select a particular button. So as the
user moves the mouse around the menu, the code needs to check whether the new
position of the mouse intersects with the hot zone of any buttons. This approach is
used for menu navigation in
Chapter 14
'
s game, and is illustrated in
Figure 10.2
.
