game user interface

Well, the time has come where it is vital for me to have a user interface in my game project. Just for the sake of fun, let's do a play on words and call it a Game User Interface (or GUI) :D .

Anyways, I was wondering if anyone had any advice about the actual programming aspect of interface design.

I have never really developed a user interface for a game before, and therefore have little experience. I will attach some pictures on how I have gone about thinking about things.

Give me your thoughts and opinions.

don't make things complicated...the way I've always done game interface type stuff is to add buttons and consoles to the engine in the same way as I've done with every other entity. I update the interface stuff at the same time everything else is updated. I render interface stuff the same way I render the rest of the world (in my case, using shaders, which allows to have specific cool stuff when buttons are clicked, 3D buttons, etc etc).

The mistake people always make with interface stuff is that it always ends up being made way too complicated.

I'd go with what vNvNation said, that always turns out well. I always had the ingame interface inherit from what I used for the menu system, which made things pretty clean. A menu would have it's own Proc function which would work with gamestate information in order to shift that around. In the Proc function, it could get kinda hairy if you aren't careful, but to have it run, I would have to write one line of code in my game loop:

Code:

---

meuns[curMenu].update();

---

All that would do is call it's proc function, which I assigned to it during initialization.

This is my general menu structure
// psuedo
class UIMenu;
>bg color;
>call back;
>menu item list;

Pretty simple class that has a bg color (i send it straight to glclear), a function pointer to hold a callback defined outside of the class (usually in menus.cpp or so) and an array of pointers to menu items.

class UIMenuItem;
>top left vector;
>bottom right vector;
>is interactive;
>call back;
>last call back;
virtual f()>recieve(mouse x, mouse y, keyboard int);
virtual f()>render();

The UIMenuItem class is an abstract interface, its very simple and only acts for an interface to render and recieve. Recieve if where I send in user input, I generally dont allow menu items access to the keyboard mouse information, only main menu structures that send that info manualy-- just a personal implimentation choice. Of course recieve and renderr are virtual, so they are defined to be handled in inherited classes. The variables top left and bottom right are the on screen rectacle of where teh item is located - useful for buttons etc. And is interactive is just a boolean to know if a member is static or dynamic. These variables could really be placed in the inherited class, but 7 out of 10 of my ui components use them, so I elimented reptitive member variables. The final variables call back, last call back, are for components that need to call other menus or set game modes etc. Since my gamestructure is one big redirect from my main loop via a function pointer, my menu items set the GameCallBack function pointer to what ever they need to. Last call back is speciffically to make the menus interdependtly linked, so escaping from one menu will return to the menu that called it (or not, if you decide to just set it to the game function instead, it will escape to the game loop). I alwasy set the main menu to escape to the game, no matter what.

From here, you are free to really have fun. I've got an inherited menu item for text, 3d models, art, buttons, check box, and slider.

Hope that helps you out some.