• Advertisement
Sign in to follow this  

User interface design (code-wise)

This topic is 2998 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello all, I want to get your insight on how to you get the user interface to 'connect' with the game engine smoothly. My approach is to have a user interface class which holds a pointer to the game engine, then each part of the ui can alter the game engine's data using it's public methods. The problem is that this has got very limiting and cumbersome. So, any suggestions?

Share this post


Link to post
Share on other sites
Advertisement
This one interests me too.

The way I did it (bad way, but pretty straightforward):

I have an aberration that I love to reinvent the wheel (with no help, if possible).
So:

My GUI has:
one window (can easily enhance to have more)
titlebar
tab
pushbutton
toggle
radiobutton
slider
listbox

The actions are usually executed when the left button of the mouse is released (like in windows).

The elements have size, position, label(string), some data (this part is a bit clumsy at this time), state flags (clicked/active/visible/enabled/highlighted/etc),
parent tab, parent GUI element (used rarely, for example toggle disabling other elements), custom click function. Tabs have a parent window.

There is a main GUI function that is called every frame (or can be called only on events, doesn't matter).
There are 4 kind of mouse events in the menu at this time:
1. left button click
2. left button release
3. mouse roll
4. mouse move while clicked.
The main function does some stuff according to the event type.

Left button click: loops through elements and check which one is clicked.
If the type of the item is list-box: selects the listbox's element. (assigns a value to the listbox data).
If the item type is 'tab', then makes that tab active, and the others (with same ID's) inactive
Otherwise it marks the element as 'active'. (because the execution of action is called when mouse-up)

Mouse move while clicked: moves window when the type of the active element is 'titlebar'; moves slider when type is 'slider', and rolls listbox when type is 'listbox'.

Left button release: check the element which has the mouse pointer over it. If it's the same as the active element, executes the action according to the type:
default actions:
the data of the elements are manipulated: toggles toggle, radios radio (if the IDs of the radio elements are the same, turns on the selected one and turns off the others)
Then executes the custom function (if there's any). For example this function disables the current element's child elements. Push buttons usually have to have some kind of action to perform for example 'OK'/'Cancel'/'Apply'

mouse roll: checks if the mouse is over a listbox, if so, rolls it.

Associating game/engine data:
There is an initialization function: setting sizes, positions, default strings etc.
If the GUI would be scriptable, it would load the script. Called once.

There is a data load function: here is the hard coded stuff to assign the items data with the game data. It's simply a list of '=' assignments. Called when the menu is invoked.

Data save function: Assigns the game variables with the element data: A list of assignments, and other stuff (switchig resolution, resetting game, loading maps etc.). This is an nasty abomination.

With this method it's easy to handle 'OK'/'Cancel'/'Apply' because the data and the corresponding game variable is separated:
'OK': save data, close menu (game variables are updated)
'Cancel' close menu (game variables aren't updated)
'Apply' save data

Adding a new menu item means: Adding initialization data to init function and adding the assignment stuff in save/load.

Every type of element has a drawing routine. There are static elements too (separators, strings).


I don't like the two hard coded (save/load data) things, otherwise it works good, and quite flexible (for the needs of a game GUI), and can be improved to a multi-windowed (child/parent windows, dialogs etc).

This isn't a good way I think, but I posted it, because I'd like to hear some critique.


BTW check it out in my signature.

Share this post


Link to post
Share on other sites
Look up on MVC - model, view, controller. The model is your game data and logic, the view consists of your GUI, and the controller is the 'glue code' between them, e.g. the code that reacts to user interaction and that operates on the game data and logic.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement