How to build an in game menu system?
Author
This is sort of a broad topic but currently im in need to writing a menu system for my game. Config menu, start menu, so forth, and heads up display and such...
So basically im looking into any docs out there or book recommendations that fall on this topic. Anything with explaining why certain ways are better than others or anything with gotchas or reasoning. Dont need code examples really.
I am using DirectX9 under C++.
Thanks much guys!
--Brad
I never read any docs or books on it. I've heard people advocate using a stack to store entries. Right now I just use a menu factory (for a given state/substate) and vaguely linked callbacks.
So just start making crap from scratch and toss what doesn't work. I don't think you'll find tutorials on it, nor should you need them.
So just start making crap from scratch and toss what doesn't work. I don't think you'll find tutorials on it, nor should you need them.
Author
Well I can think through the process straight forward and understand it, but when something has been done as many times as it has within gaming, I thought that there might be a better way that has been written down.
Otherwise u are absolutly correct it should be a a fairly straight forward issue to solve. A Stack wouldnt be a bad idea, but I just dont see a need for it considering that most menus arent but 2-3 deep and alls u have to save is the last state right? I guess with options it might need it for saving issues which a stack would work great in. Now that I think about it, if I might need a stack for one menu option, might as well make it available to all menus regardless of depth...
How does yer way differ?
Thanks,
Brad
Otherwise u are absolutly correct it should be a a fairly straight forward issue to solve. A Stack wouldnt be a bad idea, but I just dont see a need for it considering that most menus arent but 2-3 deep and alls u have to save is the last state right? I guess with options it might need it for saving issues which a stack would work great in. Now that I think about it, if I might need a stack for one menu option, might as well make it available to all menus regardless of depth...
How does yer way differ?
Thanks,
Brad
The thing is, xsirxx, that even the concept of a "menu" is so amazingly abstract that there are no real right or wrong ways. I could tell you how I implemented the menus in my game (medevilenemy.f2o.org/pp.html) but that probably wouldn't help you at all.
All I can suggest is that before you even start writing up code, pick up a pad and a pencil and sketch out visual ideas. Once you have something you like start coding the graphical end of it... then code in option selection and the like (ie: mouse clicks if you are using the mouse, etc.)
All I can suggest is that before you even start writing up code, pick up a pad and a pencil and sketch out visual ideas. Once you have something you like start coding the graphical end of it... then code in option selection and the like (ie: mouse clicks if you are using the mouse, etc.)
Download menu systems that are open source and see how they do it. I don't recall ever seeing tutorials on this. I just use "buttons" windows style. When a mouse is clicked and a menu is up, the engine fires off a game event to the menu system that handles it. If nothing was clicked on and the menu is "taking over" the menu system fires off the mouse event to the game (like the code that handles the initial input would if the menu wasn't up). If something was clicked the message is "eatten".
I know that's more the communications part but it's what I found the most difficult.
I know that's more the communications part but it's what I found the most difficult.
I needed some GUI buttons in my game, nothing deep. So I made a text file format to store them, it was just
Menu Name, Number Of Buttons
Button Name, x,y,width,height,CLICKID (a number, or -1 for a static button)
Menu Name, Number Of Buttons
Button Name, x,y,width,height,CLICKID (a number, or -1 for a static button)
etc...
Every gamestate has it's own menu. I just check for a ClickID from my menu class that does a cursor test against the buttons in the currently active menu on click and returns the ID in my gameupdate() loop.
I only needed a HUD/Menu system that knew when things were clicked. So this may be useless to you.
Menu Name, Number Of Buttons
Button Name, x,y,width,height,CLICKID (a number, or -1 for a static button)
Menu Name, Number Of Buttons
Button Name, x,y,width,height,CLICKID (a number, or -1 for a static button)
etc...
Every gamestate has it's own menu. I just check for a ClickID from my menu class that does a cursor test against the buttons in the currently active menu on click and returns the ID in my gameupdate() loop.
I only needed a HUD/Menu system that knew when things were clicked. So this may be useless to you.
//respond to mouse input else if (Mouse.rgbButtons[0] & 0x80) { //was a gui button clicked? if (Gui.CheckClick(mx, my)) { switch(Gui.GetClickID()) { case 1: GameSetMode(GAME_MODE_GAME); break; case 2: GameSetMode(GAME_MODE_HIGHSCORE); break; case 3: SetDone(); break; default: break; } } }Quote:Original post by Vampyre_Dark
I needed some GUI buttons in my game, nothing deep. So I made a text file format to store them, it was just
Your handler code is about identical to what I'm doing in my current game (using indexed callbacks with a switch and rebuilding each menu layer with a factory keyed to the menu layer ID).
It's a flexible system, though I appreciate that you've taken it to a text file whereas I've hardcoded my menu setups in my factory.
If someone is just starting out on this, might I suggest using xml via TinyXML for the GUI definition file instead of plain text. This will handle all the parsing (plus comments) and is an easy way to define a structure, eg to have a button within a panel.
Also, since writing back to the xml file is simple with TinyXML, if you make your GUI elements alterable you can edit it graphically in the game and just write the updated xml file when you're done. This is good for allowing your end users to set up the GUI to their liking as well.
TinyXML also supports UTF-8 which was a godsend for me, so that's how I made my GUI: pic
Also, since writing back to the xml file is simple with TinyXML, if you make your GUI elements alterable you can edit it graphically in the game and just write the updated xml file when you're done. This is good for allowing your end users to set up the GUI to their liking as well.
TinyXML also supports UTF-8 which was a godsend for me, so that's how I made my GUI: pic
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
