Jump to content
  • Advertisement
Sign in to follow this  
dave

Unity Can we discuss GUIs please?

This topic is 4371 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

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
Advertisement
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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!