Unite 2010GDC ChinaAsia Game Show 2010GDC 2011
|
The Menu SystemA menu can be a complex thing in a game. Lucky for us it's not. The general idea is to provide some sort of selection process for features of your game. Most of the time, this will consist of drawing a bitmap and having another "selector" bitmap drawn on top, to choose an item or feature for the game. I have chosen to do this a little bit differently. Instead of having a selector, I am simply going to have certain keys correspond to the choices in the menu ... kind of like good old days of DOS, but different. The other important point, is how you setup your system. Do you want the code to go into a "menu loop" and never return until the user makes a selection? Or, do you want to call the menu function over and over again? In the case of Windows, the second choice is 1 million times better since we need to process messages. If we had coded in the first manner, the user could hit alt-tab while we are in the menu code and we would crash. ( NOTE: The game does not have alt-tab support yet ... this will come in a later issue! ). So, we are going to setup the second type of system. The initialization and shutdown routines are nothing that you haven't seen before. All they do is load in our two menu bitmaps. One of them is for the main menu, and one of them is for the file menu. The shutdown code simply frees their associated memory that we allocated. The interesting code is in the Process_XXXX_Menu() functions. We will look in detail at the Process_Main_Menu() function. So, as usual, here is the code for that procedure. An interesting routine, isn't it? Okay ... maybe not. But, if interesting is what you want, then I doubt you will find it in code. Unless you are really weird like I am. Anyway, what does it do? ANSWER: It starts out by locking the back buffer and drawing our menu bitmap onto it. Then, it unlocks the back buffer and flips surfaces so that we can see it. This is boring, not to mention the fact that it is nothing new. But wait ... there, on the next line. See it? Yes, something we haven't covered!!!! We get to call one of our Direct Input routines DI_Read_Keyboard(). If you will recall, this function gets the state of every key on the keyboard. So, when we make this call, everything is set for us to check and see which keys were pressed. We do this by just checking the key values we care about. They can be in any order you want, but be aware that the way it is coded right now, the code will only perform the code for one value ... even if they hit two valid keys. The reason is that the keys are in one huge IF-ELSE statement. So, at the first valid entry the code falls in, executes, and leaves ... forgetting all about the other keys. Thus, if you want/need to support multiple key presses make every "character check" a separate IF statement. Now then ... we check each key that we want information on. If they key has been pressed, we return a value that corresponds to what was pressed. For example, if the user hits the 'N' key for a new game we will return the value MENU_NEW to the caller. These values are known as equates and are defined at the top of the code module in the section entitled "EQUATES." They are the equivalent of #DEFINE in C. They do nothing more than let me, as a programmer, associate a value to a string of characters for readability. Finally, if nothing was pressed that we care about we just return a value reflecting such. The same applies to if an error occurs in the code. This same method has been used for the Process_File_Menu() function. There are many other ways to handle menus and a little creativity will expose them to you. However, this setup is fairly straight forward, and I kind of like it. So, that is what we are using. We have now tied the Direct Input code to our menu system. All that we have left to do is tie the menu and timer code that we just wrote to our main game loop somehow.
|
||||||||||||||||||||
|
||||||||||||||||||||
