Lets talk GUI design

[MasteR]

I’m interested in hearing some peer opinions on GUI design (implementation not graphic).

 

I have my opinions, but know that they won’t be shared by all. I’ll pose this as a list of questions that could easily be answered. I don’t think there are any strict answers to any of these questions but I value peer opinions.

 

If popular this thread could become an interesting read for Leadwerks developers, before they begin their GUI implementations or before they choose a 3rd party library.

 

• What do people feel are the “core” widgets necessary in a GUI system?

• What widgets do people feel are unnecessary (for games development in particular)?

• What should a GUI system implement? Image loading, audio playback, widget rendering, GUI load/save from/to file? Where do you draw the line? What functionality is outside the scope of a GUI and should be implemented separately?

• How tied down to you engine of choice should a GUI system be?

• What options do you think are needed when rendering widgets? Should they be simple coloured quads? Loaded from images? Have visible borders?

• What widgets should have adjustable opacity?

• Should a GUI system have native font loading functionality?

 

These are just a small handful of questions I can think of, any answers? Opinions? Other important questions?

[Raul]

That's pretty complicate but we have A LOT of examples near us. Depends for what game do you create the GUI.

 

In my opinion: The GUI = Menu system + HUD (for all the types of games)

 

In a FP(S) game, as you can see these days, the HUD is almost gone. Amnesia has no HUD just a few elements for inventory and diary. Old fashion in my opinion. Crysis has a 'futuristic' interface the game menu is almost integrate in the HUD. Now you can make a simple shooter (like half life 2) or a more complex game where you have a map, an inventory system, a skill tree, etc. If you will have a lot of windows like these that you must design your GUI very careful. A bad example is Arcania. I played the demo and the GUI is like sh$t.

 

Just a quick note: Doom 3 has a very interesting interface. It is very much to talk about it so it's better to play it a little.

 

• What options do you think are needed when rendering widgets? Should they be simple coloured quads? Loaded from images? Have visible borders?

Depends of the game type.

 

• What widgets should have adjustable opacity?

I remember in Unreal Tournament that you were able to color the hud in whatever you wanted and also to modify the Alpha of ALL the elements. That was easy and helpful.

[Rick]

All I'd really care to much about is that it's event driven and not polling.

[L B]

All I'd really care to much about is that it's event driven and not polling.

Are you coding in C#? If so, that's very easy.

[Rick]

It's "easy" in C++ also, but yeah it's easier in C# as most of the stuff is done already for you. I was just saying any GUI should be event driven and not polled.

[MasteR]

I agree with event driven GUIs, an OO implementation makes this easy

 

I remember in Unreal Tournament that you were able to color the hud in whatever you wanted and also to modify the Alpha of ALL the elements. That was easy and helpful.

This was achieved and determined by the player at runtime?

 

My opinion is that a GUI's design should be art driven. Trial and error based GUIs implemented by a programmer at design time really limits the idea of a GUI. So I think the ability to load an artists predesigned GUI from file is important.

 

How much control over widget design should be available to a programmer at design time? And what should be achieved behind the scenes?

[Josh]

If you come across any programmers that would be good for writing the GUI, let me know. It's not a mind-bending task, but it needs to be done by someone who has written a GUI before. It has to be written in C++ so that everything can access it.

 

In fact, this is one of those things where I can just write out the complete command set and documentation first, and then let another programmer write the actual code.

[Rick]

You would have to define HOW you want it done though (not just the commands). Would you do just 1 image per control, would you draw it with drawing commands, would you combine 9 image to make the controls (3 rows of 3), etc etc. It has to be fully skinable so I would think the 3x3 images would be ideal, but I thought you said you liked the drawing version (like steam). That sounds like it would require coding to customize vs art to customize.

[Rekindled Phoenix]

In fact, this is one of those things where I can just write out the complete command set and documentation first, and then let another programmer write the actual code.

 

This post caught my eye because I've written a GUI that handles 3x3 textures, click, and hover events for my projects.

 

If the documentation / business requirements stated what you wanted Josh, I'm sure a few programmers (including myself) would be up to the task. Though, would this be using LE Source or a plugin DLL / library?

[MasteR]

If you come across any programmers that would be good for writing the GUI, let me know. It's not a mind-bending task, but it needs to be done by someone who has written a GUI before. It has to be written in C++ so that everything can access it.

 

In fact, this is one of those things where I can just write out the complete command set and documentation first, and then let another programmer write the actual code.

 

Clearly I'm drumming up a little design discussion to capture peers GUI requirements as I’m currently developing one. I finalised the design and prototype for AGUI (Artists GUI) for a University assessment 2 weeks ago. The final version is planned for completion by the end of October 2010. The implementation is cross platform and LE independent, I'd be happy to PM the design specification.

 

On a more thread specific note: I'm very interested in the community’s opinions on what functionality a GUI should contain, and the way widgets should be implemented.

The thread has not quite gotten there yet. I have a GUI design spec but I'm just 1 programmer, its hard to think outside the box, as robust as I may think my design and implementation is, I’m sure its limited by my own GUI needs.

 

Lets keep the discussion cracking. If Josh is after a GUI then let’s (as a community) brainstorm its design and specification, it will help us all out.

[Rick]

My thoughts on design from a technical aspect since that's mostly what I think about.

 

1. Should be OO

Button* cmdExit = new PushButton();

 

2. Should be event drive and handle either normal C functions AND class member functions (non static) as event callbacks. Should also be able to chain events to multiple callback functions.

class MyScreen
{
private:
     Button* cmdExit;

     void cmdExit_onClick(EventArgs& e) {}
public:
     MyScreen()
     {
           cmdExit = new PushButton();
           cmdExit->onClick.Bind(this, &MyScreen::cmdExit_onClick);
     }
};

 

3. Should just be one update method to run the main GUI loop.

 

4. The definition should be able to be stored in XML files so an editor can be created.

[MasteR]

What are some Pros/Cons/Opinions on using: Cursor coordinates and picking Vs. Cursor coordinates comparison (testing) to widget screen coordinates.

 

Lets justify our answers.

 

For me I'm unsure hence the question, both have merits, one is significantly easier to program (option 2, IMO) but using this method always leaves me feeling a little...something.

[Rekindled Phoenix]

What do you mean coordinate picking vs. coordinate comparison? Do you mean engine ray-casting picks?

 

I have found that keeping a collection of clickable regions / textures per pixel is the simplest way to handle UI. Application Callbacks and .Net Events have overhead with additional threads, this is just simple math with no heavy lifting.

 

ButtonMinX < MouseX < ButtonMaxX

 

Resizing elements: ?

I've been working on resizing objects for different resolutions to avoid restraints. I start by creating a base size for an object, as a example we can imagine a loading bar with 200x50 pixels. As the resolution changes compared to your base minimum resolution, your buttons and clickable space may alter with simple math. Do you guys think that it's better to enlarge UI elements based off resolution or keep them a particular size and just let those who own HD screens squint?

 

 

I just wish that the engine came with this naively as an option. It's nice to be able to customize, but if you just want a "placeholder GUI" for demos, you have to code the entire thing yourself. FACEPALM

Josh, can this be a priority in LE 3.0?

[MasteR]

I have found that keeping a collection of clickable regions / textures per pixel is the simplest way to handle UI. Application Callbacks and .Net Events have overhead with additional threads, this is just simple math with no heavy lifting.

 

That is a solid point, anyone else?

 

Do you guys think that it's better to enlarge UI elements based off resolution or keep them a particular size and just let those who own HD screens squint

 

For me I like the UI to display consistency regardless of resolution.

 

I found (for my implementation) setting a base scale of 1.0f and rendering all UI elements at this scale handled the best of both worlds as it was easy to add functionality which calculated an alternate scale based on window resolution. That way if you like squinting you'll ignore the scale function and if not, you could set a base resolution via the function and properly scale UI elements.

[MasteR]

... This thread not the hub of input that I had envisioned (apart from you chaps above )

To counter this I'll pose specific design questions which arise.

 

Design Question #1

Is there ever a need to render a cursor or text opaque (see through/semi-transparent)?

 

Design Question #2

Should "gradient" effect widgets be up to the artist to create, or is this rendering style so universal that a GUI should have it "built" in?

 

Design Question #3

Is there ever a need to tint a cursor or image based widget with an overall colour?

[Rick]

... This thread not the hub of input that I had envisioned (apart from you chaps above )

 

This is the one things I'm not a fan of in the LE community. Almost no one wants to talk about design. I think that's because a good number of people are artists and not programmers.

 

I'd keep replying but I assume you would like a variety of people's ideas.

[MasteR]

I'd keep replying but I assume you would like a variety of people's ideas.

 

Reply away Rick, I'd like to keep the discussion going. Two heads are better than one.

Some future questions may spark additional interest.

[Rick]

1. Yeah, I think text for sure. Fading text is pretty common and in games.

 

2. I personally think artists should worry about this. If a 3x3 image system is used they will have complete control of how everything looks.

 

3. Good question. At first thought I'd say no, but it might be handy. Cursors could just be swapped for other cursors with the needed tint, but tinting widgets could help avoid the artist from having to make a bunch of the same images with different colors.

[MasteR]

3. Good question. At first thought I'd say no, but it might be handy. Cursors could just be swapped for other cursors with the needed tint, but tinting widgets could help avoid the artist from having to make a bunch of the same images with different colors.

Agreed.

 

Design Question #4

When I think of sounds "roll over" and "click" come to mind, but nothing else. What other sounds (if any) does a GUI require?

[Ending Credits]

Agreed.

 

Design Question #4

When I think of sounds "roll over" and "click" come to mind, but nothing else. What other sounds (if any) does a GUI require?

 

Ambient Music?

[Rekindled Phoenix]

Design Question #1

Usually that's unnecessary feature for a cursor, but fading text is quite common. As an example, most RPGs have a small number that fades in /out of the screen with each damage done to an entity. Font that is permanently opaque usually is reserved for Web 2.0 menus, and the final steps in the development process for a game when the developers start making everything pretty.

 

Design Question #2

I agree with Rick. If there is a sort of grid system, the artists will have the flexibility to customize the interface. My implementation is a 3x3 system and works well for my project.

 

Design Question #3

Yes. Giving flexibility to the artists would increase the productivity of the GUI pipeline. Tinting is no exception and would allow the developers the ability to tint an entire subset of menus without having to re-render the graphics in a Paint application.

 

Design Question #4

"Shift to Menu [Forward / Back]", "Error / Not Allowed to click", "Scrolling"

[MasteR]

Ambient Music?

For me, I view music as a seperate piece to the meue puzzle. music combined with a GUI will make a menu. I don't personally thing music is part of the GUI itself.

 

Design Question #4

"Shift to Menu [Forward / Back]", "Error / Not Allowed to click", "Scrolling"

This brings up...

 

Design Question #5

Where should sound playback reside? I believe it should be included in a GUI but should sound playback be the widgets responsibility or the GUI's.

 

e.g. When you interact with a widget should the widget play the sound.

 

OR

 

When you interact with a widget should the mouse click (or any other form of user input) call a generic PlaySound() method native to the GUI as a whole?

[MasteR]

Final call...

Anyone else have an opinion on design question #4.

[Rekindled Phoenix]

Design Question #5

Where should sound playback reside?

 

I believe each event, such as "ButtonClicked" or "MouseHover" should have available properties to define a sound if needed. The GUI should be responsible for firing these events, and checking if there is a sound associated with each.

 

Either that, or a callback that a method should listen for. In C# / VB you define an event, and then the class inheriting the code may listen and act accordingly.