Sign in to follow this  
dave

Unity Can we discuss GUIs please?

Recommended Posts

Graphical User Interfaces, yes that's right. Overview Those (3) people that follow my journal will know that i am writing a GUI library for a university project. I have nearly all of the ground work in place and now i am looking to build a feature list and also prod people for their likes and dislikes about existing GUI librarys that they have worked with or played with in games. Done: First Revision - Most POD structs are written. - Error handling subsystem. - Error reporting subsystem. - Everything unit tested ofcourse. Control List These are the controls i aim to have in the first release, all the basic ones. - Clear Frame - Image - Button - Checkbox - Radio Button - Label - Text Box - Drop-down menu Most simple things can be done with them and in time i will add the more complex controls. If there are any controls you think should instead be considered a basic control and should be added to the list above, please say. Your Compiled Contributions - Investigate the GUI in Neverwinter Nights. - Existing GUIs. - What hplus0603 said. - Timer class for consideration later. Conclusion If you could comment on any of the following points, 'twould be great: - Other libraries available and their reputation. - Other libraries and your experiences with integrating them into your own applications. - Any major talking points regarding your own developement of a GUI. - Opinions on likes and dislikes about the usability of any of the GUIs in commercial games. I'd be really greatful for your input as i will add your comments to my project documentation and they will be considered throughout the implementation of my GUI. Thanks in advance, Dave Ma Journal [Edited by - Dave on September 30, 2006 11:41:12 AM]

Share this post


Link to post
Share on other sites
Holy crap! I too am working on one for uni, although mine was just meant to be very lightweight, so I didn't have to worry about my Real-Time Rendering course when it came from going from Windows to Linux. I've got a very flexible event-handling system up and running, windows and basic controls buttons working. I wanted to make it a pretty interface, like OSX, but cross-platform.

I'm going to go read your journal now.


However, I'll say this: If you design it like Java, I'll come to your house, strangle you in your sleep, and then urinate in each of your eyeballs. It will not be pretty.

Edit: I see you meant for DX/OGL - mine's for OSes. Still, we can talk about design, right?

Share this post


Link to post
Share on other sites
Quote:
Original post by Dave
Control List
These are the controls i aim to have in the first release, all the basic ones.
- Clear Frame
- Image
- Button
- Checkbox
- Radio Button
- Label
- Text Box

Most simple things can be done with them and in time i will add the more complex controls. If there are any controls you think should instead be considered a basic control and should be added to the list above, please say.


Hmmm... How about a pull-down menu?


Quote:
Your Compiled Contributions
[Here i will list brief summarys of the main points noted from your replies.]

Conclusion
If you could comment on any of the following points, 'twould be great:

- Other libraries available and their reputation.
- Other libraries and your experiences with integrating them into your own applications.
- Any major talking points regarding your own developement of a GUI.
- Opinions on likes and dislikes about the usability of any of the GUIs in commercial games.


All I've really used is Windows Forms, which I have to say is quite good and easy to use. I had a bunch of problems switching between code and the 'design view'. I just gave up with the design view in the end and used pure-code. I didn't exactly 'integrate it into my own application', though, I used it for a stand-alone level editor.

I'm presonally a fan of Half-Life 2's and Steam's GUI. I love their simplicity and atractiveness. Though Steam has lately been going the route of iTunes and everything else with the flashy gradients and what-not, though is improving in usability.

Neverwinter Nights also had a pretty good GUI. Oblivion's was good looking, but I found it considerably more cumbersome than Morrowind's.

HTH

Share this post


Link to post
Share on other sites
Thanks guys.

@ _goat: It's all about design, design and design. The rendering is only a small part of this GUI really. What is good about your event handling system?

@ Ezbez: Ok i will add a pull down menu to the list. I also like Steams GUI, that is kinda my inspiration. I will also look into Neverwinter Nights.

Thanks.

Dave

Share this post


Link to post
Share on other sites
I did a GUI system a few months ago. They're quite interesting as they basics are pretty much well known, but it's still really hard to get a good overall system. Some screenshots of my GUI system in my journal.

IMHO the most important thing initially is to decide on what you're actually going to use it for, and in particular whether it needs to be an 'arcade-y' GUI or a 'windows' GUI. In other words, do you want it for a game like Quake (where you only really need buttons, images and some stuff for an options screen) or for a game like WoW where you have lots of draggable windows, and complicated controls.

The 'arcade' GUI doesn't need lots of the fancier features - no layout managers, no draggable windows and a much simpler set of widgets. On the other hand it must be highly visually customisable, as every menu tends to be skinned differently. You also tend to want lots of feedback - button highlight, press and click animations/sound, etc.

The 'windows' GUI is more spartan in looks but needs to be much more flexible in terms of widgets. Plus you need to deal with draggable windows, resizing windows, multiple popups and modal popups. And possible make it resolution independant too rather than fixed res. On the plus side skinning is easier, as it's usually more restricted to "set background colour", "draw border style", in an attempt to keep the whole thing looking consistant.

Personally I'd say pick one and stick with it. Trying to do both tends to mean you end up doing a windows-y GUI, which can be totally the wrong feel for a game that needs simpler menus.

In my case I went for arcade-y; which means I'm aiming for menus that are really quick and easy to create, easy to layout, and easy to add in custom widgets and visual styles for each control. The core does little more than collecting input, generating events and dispatching them to the controls. Theres a method for user created controls to be added, and user created 'styles' which register which widgets they're capable of drawing so they can be used.

One neat touch is the in-game layout editor. I can actually position, resize and reskin the controls while the game is running so I get WYSIWYG. During development this layout is saved and loaded everytime a menu is closed/opened, for the final game it'll just load the layout and the editing will be disabled.

Share this post


Link to post
Share on other sites
I'd recommend you download some existing GUI libaries to give you some ideas and allow you to spot some pitfalls that you should avoid.

Visual C# Express edition( for windows forms) and the free version of Qt are a good place to start.

Share this post


Link to post
Share on other sites
Our GUI system (at work) is based on a lazy invalidation method.

Every property (and I mean EVERY property) of the GUI components is observable, and can be set to subscribe to other observable properties.

The entire GUI is described using XML, and in the end, property values come from static XML values. However, the XML data that the GUI derives from is also observable, so when the XML file changes, the GUI re-layouts itself (adding/removing components as appropriate).

The data flow does allow for simple formulas, so the "width" of a text control might be set as the "width" of its parent container minus 10, and the "left" of that control might be set to 5, to get some borders. There are also layout controls that take width/height as input, and publish various sub-control properties as output; children will then bind to these to get the appropriate layout behavior.

It is really powerful to have a fully data driven, fully reactive data flow graph for your entire GUI system (this includes the values within the controls, too, like the actual "text" and actual "value" of a control). However, writing the system so that everything is actually reactive, observable, and bindable, is quite a large task. We've spent many man-years on it.

I would recommend thinking in this direction, though. It's quite nice.

Share this post


Link to post
Share on other sites
I too have a (marginally unimpressive) UI system in place, also in my journal (link at bottom of post). I do something akin to hplus' description for layout, and some data binding spots. As he says, it is quite nice once done, and done well.

Some other major controls that I have and have found useful to a certain degree.

1. Timer. Some people's orginization would have this be more appropriate elsewhere, but I've found it useful to be able to tie an arbitrary timed trigger as a child control to another. Makes FPS displays, certain animations, blinking things much easier.

2. Sound. I hate when stuff isn't consistant. Ever see when you close a window playing a sound and the sound continues? Annoying. It's also fairly hackish to fix depending on how you have things designed. I have a UI control that wraps a sound resource and maps open/visible:close/invisible to play:stop. Makes things easier and consistant, and allows for easy expansion into other GUI sound interfaces; often overlooked in games outside of Options.

Non-Basic:

3. Containers (lists). In data heavy games, it's really nice to have a container that can do auto-arrangement/formatting for you. These are really hard to do right, but when they are... a godsend.

4. Canvas. Essentially a RenderToSurface which is constrained to a rectangle. It's not useful at first glance, but having a common class which does it makes things like screenshots, display caching, and thumbnailing consistant, repeatable, and flexible.


And as I touched upon earlier, I find inconsistantcy annoying in GUIs. Usually that includes things that look identical but have different behaviors (usually due to mouse input differences), or obvious keyboard control of the UI not existing. Wether that's a UI failing or the programmer's fault is debatable though...

Share this post


Link to post
Share on other sites
You're GUI library should have a way of representing multiple document interfaces. The traditional MDI system seems to have been replaced with tabs - make such a control.

Also, no list controls? [sad]

Share this post


Link to post
Share on other sites
Although i didnt state it, list controls and tabs will be the more advanced controls. I had thought of the timer, sounds like it should be included.

Share this post


Link to post
Share on other sites
I am also unsure about whether to try and make this library cross platform, using OpenGL as the alternative rendering API.

Any thoughts on the ease of this?

Share this post


Link to post
Share on other sites
Quote:
Original post by Dave
I am also unsure about whether to try and make this library cross platform, using OpenGL as the alternative rendering API.

Any thoughts on the ease of this?


I've not actually done it, but if you build everything off of the API dependant parts ("image" and "text" mainly) and keep abstraction in mind, I can't imagine it'll be terribly difficult to drop in replacements for image/text which use differing APIs.

Share this post


Link to post
Share on other sites
See, what's putting me off making it cross platform is that i would have to write image loaders or use another library, since i couldn't use either for loading the textures. I would also have to write a font system for text.

Do i hahve any other solutions to this?

Share this post


Link to post
Share on other sites
IMO, a good way of abstracting out the platform-dependant drawing portions of the GUI would be to follow a sort of device context approach, where the base control class has a drawing context associated with it, and all drawing methods go through the context interface, where the implementation is platform dependant.

I don't know how *nix and X-windows, or Cocoa works, but I know this would make it easier to add support for Win32 and OpenGL (and possibly Direct-X) driven back-ends.

Share this post


Link to post
Share on other sites
I did an OpenGL GUI Library for a university project a couple of semesters ago as well. I didn't get done with what I wanted to and I'm actually still working on it. If you are interested here are a few of the key features of my gui system;

• Every component such as the window and push button are derived off of a cComponent class.
• The cComponent class contains a singleton class to a texture repository that contains textures for the backgrounds, frames, fonts, etc.
• The cComponent class allows the component to be customized by allowing the user to select up to 9 textures: 4 for the frames, 4 for the corners, and one for the background.
• I use a virtual coordinate system and translate everything during rendering. The Screen is 10000x10000 units. The only thing that doesn’t use the virtual coordinates is the component frame set.
• Child controls don’t contain pointers to the parent, but have coordinates relative to the parent. When rendering, a control is called by its parent which sends the coordinate translation information.
• Everything is handled through the cWindowProcessor class which basically has two main functions: CreateMessages(void *data); ExecuteMessages(void *data);
• CreateMessages() basically takes the input information, find out which window is being targeted by the cursor and then find out which component inside window is being targeted by the cursor and then create the appropriate message to put in the message queue.
• ExecuteMessage() basically calls every message that is in the queue. Each window has a function pointer that the user sets to determine what happens when each control is pressed, dragged, etc.

Share this post


Link to post
Share on other sites
Some random thoughts:

- Make the renderer "pluggable". There should be rather few basic rendering functions necessary ("draw colored rectangle", "draw textured rectangle", "draw string of text", etc). Making these functions part of an easily replaceable "Renderer"-class (or similar) should make it fairly easy to implement a renderer for a different platform while keeping the rest of the code the same.

- Composable components. Yeah, ok, not the catchiest of names, but basically making it easy to create a new kind of "gadget"/"widget"/whatever by combining existing components is a near must-have capability.

- In my opinion the single most important part of a gui-library is making it easy to plug gui-component behavior into my own code. Preferrably something like


class Test {
public:
Test() {
fooButton.setText ( "Foo" );
barButton.setText ( "Bar" );
fooButton.onClick ( foo );
barButton.onClick ( bar );
}
void foo();
void bar();
private:
Button fooButton;
Button barButton;
};



Something like Boost.Signal would fit the bill quite nicely.


Personally I'd make the Drop-down menu control a "non-basic" control composed of other components (a Label for the text, an Image for the "drop-down down arrow", both in a Frame. With another Frame with Labels in it shown when clicking, for instance.)

Share this post


Link to post
Share on other sites
How does your GUI interact with the rest of an application? For example, if I wanted to have a window pop up, with a text box that allowed me to, say, input a username and password and click a "login" button, how would the GUI communicate to the application that we are ready to allow the player to attempt to log in, and how would the application find out what username and password the player entered was? This is where I keep getting stuck in my GUI design. I can't seem to think of a non-procedural solution to the problem.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this