• Advertisement
Sign in to follow this  

Unity Can we discuss GUIs please?

This topic is 4160 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
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
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By GytisDev
      Hello,
      without going into any details I am looking for any articles or blogs or advice about city building and RTS games in general. I tried to search for these on my own, but would like to see your input also. I want to make a very simple version of a game like Banished or Kingdoms and Castles,  where I would be able to place like two types of buildings, make farms and cut trees for resources while controlling a single worker. I have some problem understanding how these games works in the back-end: how various data can be stored about the map and objects, how grids works, implementing work system (like a little cube (human) walks to a tree and cuts it) and so on. I am also pretty confident in my programming capabilities for such a game. Sorry if I make any mistakes, English is not my native language.
      Thank you in advance.
    • By Ovicior
      Hey,
      So I'm currently working on a rogue-like top-down game that features melee combat. Getting basic weapon stats like power, weight, and range is not a problem. I am, however, having a problem with coming up with a flexible and dynamic system to allow me to quickly create unique effects for the weapons. I want to essentially create a sort of API that is called when appropriate and gives whatever information is necessary (For example, I could opt to use methods called OnPlayerHit() or IfPlayerBleeding() to implement behavior for each weapon). The issue is, I've never actually made a system as flexible as this.
      My current idea is to make a base abstract weapon class, and then have calls to all the methods when appropriate in there (OnPlayerHit() would be called whenever the player's health is subtracted from, for example). This would involve creating a sub-class for every weapon type and overriding each method to make sure the behavior works appropriately. This does not feel very efficient or clean at all. I was thinking of using interfaces to allow for the implementation of whatever "event" is needed (such as having an interface for OnPlayerAttack(), which would force the creation of a method that is called whenever the player attacks something).
       
      Here's a couple unique weapon ideas I have:
      Explosion sword: Create explosion in attack direction.
      Cold sword: Chance to freeze enemies when they are hit.
      Electric sword: On attack, electricity chains damage to nearby enemies.
       
      I'm basically trying to create a sort of API that'll allow me to easily inherit from a base weapon class and add additional behaviors somehow. One thing to know is that I'm on Unity, and swapping the weapon object's weapon component whenever the weapon changes is not at all a good idea. I need some way to contain all this varying data in one Unity component that can contain a Weapon field to hold all this data. Any ideas?
       
      I'm currently considering having a WeaponController class that can contain a Weapon class, which calls all the methods I use to create unique effects in the weapon (Such as OnPlayerAttack()) when appropriate.
    • By Vu Chi Thien
      Hi fellow game devs,
      First, I would like to apologize for the wall of text.
      As you may notice I have been digging in vehicle simulation for some times now through my clutch question posts. And thanks to the generous help of you guys, especially @CombatWombat I have finished my clutch model (Really CombatWombat you deserve much more than a post upvote, I would buy you a drink if I could ha ha). 
      Now the final piece in my vehicle physic model is the differential. For now I have an open-differential model working quite well by just outputting torque 50-50 to left and right wheel. Now I would like to implement a Limited Slip Differential. I have very limited knowledge about LSD, and what I know about LSD is through readings on racer.nl documentation, watching Youtube videos, and playing around with games like Assetto Corsa and Project Cars. So this is what I understand so far:
      - The LSD acts like an open-diff when there is no torque from engine applied to the input shaft of the diff. However, in clutch-type LSD there is still an amount of binding between the left and right wheel due to preload spring.
      - When there is torque to the input shaft (on power and off power in 2 ways LSD), in ramp LSD, the ramp will push the clutch patch together, creating binding force. The amount of binding force depends on the amount of clutch patch and ramp angle, so the diff will not completely locked up and there is still difference in wheel speed between left and right wheel, but when the locking force is enough the diff will lock.
      - There also something I'm not sure is the amount of torque ratio based on road resistance torque (rolling resistance I guess)., but since I cannot extract rolling resistance from the tire model I'm using (Unity wheelCollider), I think I would not use this approach. Instead I'm going to use the speed difference in left and right wheel, similar to torsen diff. Below is my rough model with the clutch type LSD:
      speedDiff = leftWheelSpeed - rightWheelSpeed; //torque to differential input shaft. //first treat the diff as an open diff with equal torque to both wheels inputTorque = gearBoxTorque * 0.5f; //then modify torque to each wheel based on wheel speed difference //the difference in torque depends on speed difference, throttleInput (on/off power) //amount of locking force wanted at different amount of speed difference, //and preload force //torque to left wheel leftWheelTorque = inputTorque - (speedDiff * preLoadForce + lockingForce * throttleInput); //torque to right wheel rightWheelTorque = inputTorque + (speedDiff * preLoadForce + lockingForce * throttleInput); I'm putting throttle input in because from what I've read the amount of locking also depends on the amount of throttle input (harder throttle -> higher  torque input -> stronger locking). The model is nowhere near good, so please jump in and correct me.
      Also I have a few questions:
      - In torsen/geared LSD, is it correct that the diff actually never lock but only split torque based on bias ratio, which also based on speed difference between wheels? And does the bias only happen when the speed difference reaches the ratio (say 2:1 or 3:1) and below that it will act like an open diff, which basically like an open diff with an if statement to switch state?
      - Is it correct that the amount of locking force in clutch LSD depends on amount of input torque? If so, what is the threshold of the input torque to "activate" the diff (start splitting torque)? How can I get the amount of torque bias ratio (in wheelTorque = inputTorque * biasRatio) based on the speed difference or rolling resistance at wheel?
      - Is the speed at the input shaft of the diff always equals to the average speed of 2 wheels ie (left + right) / 2?
      Please help me out with this. I haven't found any topic about this yet on gamedev, and this is my final piece of the puzzle. Thank you guys very very much.
    • By Estra
      Memory Trees is a PC game and Life+Farming simulation game. Harvest Moon and Rune Factory , the game will be quite big. I believe that this will take a long time to finish
      Looking for
      Programmer
      1 experience using Unity/C++
      2 have a portfolio of Programmer
      3 like RPG game ( Rune rune factory / zelda series / FF series )
      4 Have responsibility + Time Management
      and friendly easy working with others Programmer willing to use Skype for communication with team please E-mail me if you're interested
      Split %: Revenue share. We can discuss. Fully Funded servers and contents
      and friendly easy working with others willing to use Skype for communication with team please E-mail me if you're interested
      we can talk more detail in Estherfanworld@gmail.com Don't comment here
      Thank you so much for reading
      More about our game
      Memory Trees : forget me not

      Thank you so much for reading
      Ps.Please make sure that you have unity skill and Have responsibility + Time Management,
      because If not it will waste time not one but both of us
       

  • Advertisement