What's wrong with T2D's GUI?
by Charlie Patterson · in Torque 2D Professional · 05/19/2013 (3:36 pm) · 27 replies
No literally, I'm sure T2D's GUI needs help.
Let's compile a list of issues and suggestions for fixing them.
Them maybe we can fix them.
Let's compile a list of issues and suggestions for fixing them.
Them maybe we can fix them.
#2
At a high-level I'm not sure there ever was an overal document for GUIs. I've never taken the time to understand the hierarchy. Is it GUIControl at the top? And how it all fits together. Should they all resize if they take on children?
05/19/2013 (7:09 pm)
Thanks @practicing.At a high-level I'm not sure there ever was an overal document for GUIs. I've never taken the time to understand the hierarchy. Is it GUIControl at the top? And how it all fits together. Should they all resize if they take on children?
#3
GuiControl is the base class from which all Guis are derived.
Trying to think more along the lines of 'What would I want the Gui system to do?' instead of what's broken with it.
05/19/2013 (7:37 pm)
Good initiative, Charlie!GuiControl is the base class from which all Guis are derived.
Trying to think more along the lines of 'What would I want the Gui system to do?' instead of what's broken with it.
#4
HTML is a bad example of this - if I want to have a site footer similar to the one on this site, I'd have to copy the HTML code, any applicable CSS rules, and possibly some JavaScript, all from separate files - and that's before you even consider that the entire look of the footer and its position on the page might depend on its parent elements, their CSS rules and JavaScript relating to them, etc.
Processing is a bad example of this because of all the global state that makes the order of your code super important.
I think Torque's GUI doesn't do too bad at this stuff as it is, but it's just a bit clunky. I think one of the biggest issues I deal with is scaling to multiple resolutions - it's just completely unclear how it works. Like, PlayGui (in T3D) seems to always be defined as size 800x600, but it's somehow scaled to the entire screen all the time.
05/19/2013 (8:58 pm)
Important thing to keep in mind, IMO: what Bret calls recomposition. The ability to take tiny chunks of other people's stuff and put them in your own stuff.HTML is a bad example of this - if I want to have a site footer similar to the one on this site, I'd have to copy the HTML code, any applicable CSS rules, and possibly some JavaScript, all from separate files - and that's before you even consider that the entire look of the footer and its position on the page might depend on its parent elements, their CSS rules and JavaScript relating to them, etc.
Processing is a bad example of this because of all the global state that makes the order of your code super important.
I think Torque's GUI doesn't do too bad at this stuff as it is, but it's just a bit clunky. I think one of the biggest issues I deal with is scaling to multiple resolutions - it's just completely unclear how it works. Like, PlayGui (in T3D) seems to always be defined as size 800x600, but it's somehow scaled to the entire screen all the time.
#5
Isn't the GUI system originally taken from TGE, a 3D engine that needed a way to display 2D GUI elements? Daniel touched upon some good points and you mentioned something important too Charlie, there was never any good documentation or tutorials for the GUI. I struggled mightily trying to learn the GUI system and eventually gave up and just started using sprites with GUI-based behavior scripts. For simple stuff this was fine and I avoided trying to make complex GUI elements.
Now that I know a bit of HTML/CSS, the whole GuiControl is like a div concept is now not so foreign, but I still hate it. We have an awesome SceneObject/Sprite system to display game content and the GUI system plays by a totally different set of rules. And then you have to bring new users up to speed on two totally different systems of displaying 2D content with tutorials and guides. I personally would want to see the current GUI system nuked and replace it with a SceneObject based system. The SceneWindow would need to become its own entity and not a child of a GuiControl, etc. I know this option has probably the most work involved since we are not just fixing bugs in the current GUI system, but I think it would be the best course for the future of the engine.
05/19/2013 (10:40 pm)
Perhaps the answer to this question is another question: if you were to design a 2D game engine from scratch, would your GUI system be like what we have today in T2D?Isn't the GUI system originally taken from TGE, a 3D engine that needed a way to display 2D GUI elements? Daniel touched upon some good points and you mentioned something important too Charlie, there was never any good documentation or tutorials for the GUI. I struggled mightily trying to learn the GUI system and eventually gave up and just started using sprites with GUI-based behavior scripts. For simple stuff this was fine and I avoided trying to make complex GUI elements.
Now that I know a bit of HTML/CSS, the whole GuiControl is like a div concept is now not so foreign, but I still hate it. We have an awesome SceneObject/Sprite system to display game content and the GUI system plays by a totally different set of rules. And then you have to bring new users up to speed on two totally different systems of displaying 2D content with tutorials and guides. I personally would want to see the current GUI system nuked and replace it with a SceneObject based system. The SceneWindow would need to become its own entity and not a child of a GuiControl, etc. I know this option has probably the most work involved since we are not just fixing bugs in the current GUI system, but I think it would be the best course for the future of the engine.
#6
I agree with Daniel in that the thing works well enough but lacks consistency and fails a bit in the "Rule of Least Surprise" area.
For the record, you can make pretty much any sort of GUI from SceneObjects anyway - so rather than wipe out the existing GUI system it would be better to have more accessible tutorials on doing that, too.
05/20/2013 (4:50 pm)
Actually, TGE needed not only to display HUD elements, but to display lobby information, scoreboards, map screens, character selection screens, menus, etc - for what they were doing they really needed a lot of GUI horsepower. I just don't think they had much experience building a GUI system (and 15 years ago, who did?).I agree with Daniel in that the thing works well enough but lacks consistency and fails a bit in the "Rule of Least Surprise" area.
For the record, you can make pretty much any sort of GUI from SceneObjects anyway - so rather than wipe out the existing GUI system it would be better to have more accessible tutorials on doing that, too.
#7
Then I know a friend working on a pro indie project and his developer assured him he could build "quick editors" in Marmalade along with writing the code. And this was very important. (Having editors for your game and each game having some unique things to edit.)
So I guess having a feature-rich editor isn't so crazy.
05/20/2013 (8:19 pm)
Kind of a side point, I used to think T2D didn't need a GUI and that the editor written in T2D was crazy! Then I thought of some games, like Richard pointed out, that need lobbies, or RPGs that have lots of spinners and scrollable panes to keep all the stats and inventory, etc.Then I know a friend working on a pro indie project and his developer assured him he could build "quick editors" in Marmalade along with writing the code. And this was very important. (Having editors for your game and each game having some unique things to edit.)
So I guess having a feature-rich editor isn't so crazy.
#8
1. Spine UI
If you've looked at Spine, specifically the Spinosaurus Demo that ships with the trial, you can easily imagine an entirely Spine-based User Interface system.
2. Vector-based approach
[url=http://feathersui.com/examples/]Feathers[url] is an awesome UI add-on to the Starling As3 engine and I'd love to get something like that for T2D. I think most of what Feathers does can be done in TorqueScript as well but in a much more complicated manner.
05/20/2013 (8:36 pm)
Two directions I'd like to explore : 1. Spine UI
If you've looked at Spine, specifically the Spinosaurus Demo that ships with the trial, you can easily imagine an entirely Spine-based User Interface system.
2. Vector-based approach
[url=http://feathersui.com/examples/]Feathers[url] is an awesome UI add-on to the Starling As3 engine and I'd love to get something like that for T2D. I think most of what Feathers does can be done in TorqueScript as well but in a much more complicated manner.
#9
However, there are some issues that need resolving:
1). Lack of a centralized, all-in-one source for documentation. Like so much of the engine, documentation for the GUI system is often spread out over 12 years of forum threads, blog posts, TDN articles, etc. Anyone unfamiliar with the GUI system will find it difficult to really get the most out of it because there's so much 'must-know' info that's scattered around the website.
A perfect example of this is the horizSizing/vertSizing settings. These are extremely important to the GUI engine but finding out how they work and what they do takes more effort than necessary.
I'd personally like to see a sort of 'Torque GUI Bible'. Some centralized location with extensive documentation for every control, best practices, examples, etc.
2). Inconsistent usage of the GuiProfile system and other bugs. Several controls don't make full usage of their GuiProfile. Various controls ignore certain color fields (like the fontColor or selColor, etc.). Other controls have bugs (e.g. the resize with the the GuiDynamicArrayCtrl) or don't actually work at all (GuiBubbleTextCtrl?). A thorough pass through the code would need to be done to resolve these.
3). Weird interface within the context of T2D. T2D's concept of scenes, levels, scene objects, etc. don't really play well (or at all) with GUI controls. GUI controls exist in their own, entirely self-contained 'layer' and so doing things like attaching a UI control to a sprite or placing a control at an exact point in a level involves some ugly bits of code.
This feels odd and is likely the root of everyone wanting to build their UIs out of SceneObjects. Interestingly enough, SceneWindow, which is the class responsible for loading and rendering scenes, is itself nothing more than a GUI control. It has all of the features of the GuiControl class, receives input events from the GuiCanvas, etc. but everything it actually 'does' exists outside of the UI system.
With all of that said, I agree with Richard. I think the best approach would actually be to leave the existing GUI system alone (other than bug fixes, obviously) and instead work toward getting a library of ready-made, SceneObject-based UI controls up and running.
05/21/2013 (9:24 pm)
Torque's GUI system is actually really nice. It's neatly integrated into the engine, interfaces well with TScript, has a huge selection of skinnable, resolution-independent UI controls and has support for Unicode and text localization. You have to look at things like ScaleForm or application-level UI libs (Qt, wxWidgets, etc.) to find something better. However, there are some issues that need resolving:
1). Lack of a centralized, all-in-one source for documentation. Like so much of the engine, documentation for the GUI system is often spread out over 12 years of forum threads, blog posts, TDN articles, etc. Anyone unfamiliar with the GUI system will find it difficult to really get the most out of it because there's so much 'must-know' info that's scattered around the website.
A perfect example of this is the horizSizing/vertSizing settings. These are extremely important to the GUI engine but finding out how they work and what they do takes more effort than necessary.
I'd personally like to see a sort of 'Torque GUI Bible'. Some centralized location with extensive documentation for every control, best practices, examples, etc.
2). Inconsistent usage of the GuiProfile system and other bugs. Several controls don't make full usage of their GuiProfile. Various controls ignore certain color fields (like the fontColor or selColor, etc.). Other controls have bugs (e.g. the resize with the the GuiDynamicArrayCtrl) or don't actually work at all (GuiBubbleTextCtrl?). A thorough pass through the code would need to be done to resolve these.
3). Weird interface within the context of T2D. T2D's concept of scenes, levels, scene objects, etc. don't really play well (or at all) with GUI controls. GUI controls exist in their own, entirely self-contained 'layer' and so doing things like attaching a UI control to a sprite or placing a control at an exact point in a level involves some ugly bits of code.
This feels odd and is likely the root of everyone wanting to build their UIs out of SceneObjects. Interestingly enough, SceneWindow, which is the class responsible for loading and rendering scenes, is itself nothing more than a GUI control. It has all of the features of the GuiControl class, receives input events from the GuiCanvas, etc. but everything it actually 'does' exists outside of the UI system.
With all of that said, I agree with Richard. I think the best approach would actually be to leave the existing GUI system alone (other than bug fixes, obviously) and instead work toward getting a library of ready-made, SceneObject-based UI controls up and running.
#10
2) In the past I've heard outright dislike for GUIProfiles as well.
3) Finally, I wonder how hard it would be to pull the GUI visual base class (GUIControl perhaps) to be a subclass of scene object. It sounds like it would be more limiting (sit atop the scene, behave a little differently with mice and whatnot) but also add more features. For instance, you could animate buttons and... other stuff. Plus it would feel more natural for a 2D game and a 2D game coder. I guess in 3D, it's more awkward to make a gui within your game object scheme.
05/22/2013 (10:06 am)
Thanks @Chris. It's sounding like the lightest change would be some docs and bug fixes. I wonder if people would actually use it more then?2) In the past I've heard outright dislike for GUIProfiles as well.
3) Finally, I wonder how hard it would be to pull the GUI visual base class (GUIControl perhaps) to be a subclass of scene object. It sounds like it would be more limiting (sit atop the scene, behave a little differently with mice and whatnot) but also add more features. For instance, you could animate buttons and... other stuff. Plus it would feel more natural for a 2D game and a 2D game coder. I guess in 3D, it's more awkward to make a gui within your game object scheme.
#11
05/22/2013 (4:24 pm)
GuiControl is a child of SimGroup, which is a child of SimObject, so it's already sort of a cousin to SceneObject....
#12
Short of doing that, it might be nice perfectly fine for a lot of games just to have a library of basic UI controls built entirely out of TScript, behaviors and sprites. The TGB section on TDN has something similar to this but most of them are outdated now.
05/23/2013 (11:06 am)
Ideally you'd want an entirely new, SceneObject-based UI system so that the only difference between a sprite and a UI control would how they react to input. The UI controls would be able to leverage TAML, the asset system, batched rendering, animation, etc. which would be an upgrade over the current system.Short of doing that, it might be nice perfectly fine for a lot of games just to have a library of basic UI controls built entirely out of TScript, behaviors and sprites. The TGB section on TDN has something similar to this but most of them are outdated now.
#13
Some people have dealt with this by creating a second scene and scenewindow and placing it on top. I've never liked this since it blocks interactions with the main scene, and causes you to have to juggle 2 scenes.
The approach I'd like to do would be to expand layering to increase control over cameras so that it would become able to make a "gui layer" where the rendering camera is static while other layers are free to move around. This would also require changes to how we handle mouse/touch events. Each mouse event would need to be converted into whatever cameraspace that layer is using.
The "gui layer" system would also have other uses: for example, a background layer that remains fixed to the camera. If we were able to scale translation of the camera on a layer-by-layer basis then we could create background parallax such as in traditional animation without resorting to scrollers.
05/23/2013 (3:32 pm)
The first obstacle with making GUI objects of sceneobjects is the objects are part of the scene and are subject to camera movements. Some people have dealt with this by creating a second scene and scenewindow and placing it on top. I've never liked this since it blocks interactions with the main scene, and causes you to have to juggle 2 scenes.
The approach I'd like to do would be to expand layering to increase control over cameras so that it would become able to make a "gui layer" where the rendering camera is static while other layers are free to move around. This would also require changes to how we handle mouse/touch events. Each mouse event would need to be converted into whatever cameraspace that layer is using.
The "gui layer" system would also have other uses: for example, a background layer that remains fixed to the camera. If we were able to scale translation of the camera on a layer-by-layer basis then we could create background parallax such as in traditional animation without resorting to scrollers.
#14
05/24/2013 (1:56 am)
Not to take away from the "GUI layer" idea (sounds interesting), but couldn't you just mount your GUI objects to the camera to keep them static?
#15
My point is, could I safely assume that no one really wants a "full" GUI system in Torque like this?
05/27/2013 (4:58 pm)
No one seems to be defending its value as "the way a GUI just is." That is, a GUI isn't a game object. It tends to require containers of other GUI objects, including other containers. For instance, a dialog box with a scroll area with text in it, and some buttons in the bottom right spaces apart nicely. In this way it organizes itself for varied resolution or resizing. It also tends to be a nice feature to wrap one element in another, say a text area in a scroll bar. Or an image and text in a button.My point is, could I safely assume that no one really wants a "full" GUI system in Torque like this?
#16
Part of it is also market trends and who is using Torque 2D. I think a lot of hobbyists and independent developers are attracted today to the mobile/tablet space. In terms of the GUI, you generally have a limited amount of screen resolutions to support, touch based controls which typically force you to keep things simple, and stuff like leaderboards and achievements, which might require a bit more GUI horsepower, are handled by frameworks like Game Center on Mac and iOS. I have countless games on iOS that just dump me into Game Center to view a leaderboard or achievement list instead of making an in-game based one. (whether that is a good thing or not is perhaps other discussion) So the need for a "full" GUI system is perhaps a bit less in those cases.
The link that Simon posted in this thread to that Feathers framework had a pretty decent list of typical GUI components. If most of those components were built in T2D with C++/TorqueScript and based on SceneObjects/CompositeSprites/etc, then that would serve my needs. I turn sprites into buttons all the time by just adding a behavior script to them, the work just needs to be done now for the other components.
05/28/2013 (5:49 am)
Personally, I'd rather redefine "the way a GUI just is". I like the idea of the GUI system playing by the same rules as the game object system and having access to the same fields/methods/TorqueScript bindings. I want the ability to give my GUI objects linear velocity so they can slide on and off the screen, have them be affected by gravity or buoyancy if desired, etc. Why try to fake that with some sort of animated GUI elements or program special transitions when they can simply be part of the physics simulation?Part of it is also market trends and who is using Torque 2D. I think a lot of hobbyists and independent developers are attracted today to the mobile/tablet space. In terms of the GUI, you generally have a limited amount of screen resolutions to support, touch based controls which typically force you to keep things simple, and stuff like leaderboards and achievements, which might require a bit more GUI horsepower, are handled by frameworks like Game Center on Mac and iOS. I have countless games on iOS that just dump me into Game Center to view a leaderboard or achievement list instead of making an in-game based one. (whether that is a good thing or not is perhaps other discussion) So the need for a "full" GUI system is perhaps a bit less in those cases.
The link that Simon posted in this thread to that Feathers framework had a pretty decent list of typical GUI components. If most of those components were built in T2D with C++/TorqueScript and based on SceneObjects/CompositeSprites/etc, then that would serve my needs. I turn sprites into buttons all the time by just adding a behavior script to them, the work just needs to be done now for the other components.
#17
So, perhaps inherit GuiControl from SceneObject (change the parent class, I mean) and reintroduce the SimGroup functionality at the base level. I'd not inherit from both SceneObject and SimGroup - diamond inheritance still sucks. This gives you a SceneObject that has the base functionality of your GuiControl and the rest of the tree should follow suit.
Someone go out and try that, let us know how it turns out.
05/28/2013 (8:00 am)
I'm going to quote myself:Quote:GuiControl is a child of SimGroup, which is a child of SimObject, so it's already sort of a cousin to SceneObject....
So, perhaps inherit GuiControl from SceneObject (change the parent class, I mean) and reintroduce the SimGroup functionality at the base level. I'd not inherit from both SceneObject and SimGroup - diamond inheritance still sucks. This gives you a SceneObject that has the base functionality of your GuiControl and the rest of the tree should follow suit.
Someone go out and try that, let us know how it turns out.
#18
First let me start out by saying that overall I like the current GUI system. It has a lot of functionality and for my current project I'm using a fair amount of it. With that being said it could certainly use some work so here are some things that continue to annoy me:
1) I don't like that you are forced to use profiles. I would like to be able to set all of the same properties that exist in the profiles on each control directly in the GUI Editor and see those changes take place immediately. There could be an option to use a profile, but not force it. The current system forces me to shut down the GUI editor, create a new profile and then open the GUI editor to add the new profile and doesn't display any updates I make to the profile until I shutdown and startup again which makes for a very time-consuming job.
2) Only a few of the most common GUI controls have documentation and even those are pretty poor. I've even had the experience of using the forums to ask TGB veterans about certain controls and even they had no idea how to use them. I think we can have a survey to see which controls are not used by anyone and discard them. Then beef up the docs on the rest.
3) It occasionally crashes for no apparent reason. I think this has been improved in the last couple minor version releases, but I'm still paranoid with my left had on Ctrl+S at all times.
I'm sure there are more, but I can't think of them on the spot... I'll reply again when I think of some others.
06/19/2013 (2:04 pm)
Charlie pointed me to this thread from another thread for me to provide feedback on the current GUI system, so here goes.First let me start out by saying that overall I like the current GUI system. It has a lot of functionality and for my current project I'm using a fair amount of it. With that being said it could certainly use some work so here are some things that continue to annoy me:
1) I don't like that you are forced to use profiles. I would like to be able to set all of the same properties that exist in the profiles on each control directly in the GUI Editor and see those changes take place immediately. There could be an option to use a profile, but not force it. The current system forces me to shut down the GUI editor, create a new profile and then open the GUI editor to add the new profile and doesn't display any updates I make to the profile until I shutdown and startup again which makes for a very time-consuming job.
2) Only a few of the most common GUI controls have documentation and even those are pretty poor. I've even had the experience of using the forums to ask TGB veterans about certain controls and even they had no idea how to use them. I think we can have a survey to see which controls are not used by anyone and discard them. Then beef up the docs on the rest.
3) It occasionally crashes for no apparent reason. I think this has been improved in the last couple minor version releases, but I'm still paranoid with my left had on Ctrl+S at all times.
I'm sure there are more, but I can't think of them on the spot... I'll reply again when I think of some others.
#19
Perhaps a way to expose the profile fields in the editor, and a way to create new profiles within the editor as well? T3D has some cool functionality in this area that would make a good start for this.
I'd like to see the sizing options altered for clarity. Right now it's tough to tell what the hell they do without going through a bit of trial and error. I'm mucking around with some GUI-related stuff at the moment, maybe I'll experiment a little....
06/19/2013 (2:44 pm)
@Bruno - Still using TGB? For the rest of us there is no GUI editor.... To help out a little in the short run I will point out that you should be able to simply exec() your gui profiles script from the console after editing to get your changes to show without having to restart the whole editor (though you might have to reload the currently-edited gui file as well). Not as nice as an actual fix, but hopefully it will ease the pain a little.Perhaps a way to expose the profile fields in the editor, and a way to create new profiles within the editor as well? T3D has some cool functionality in this area that would make a good start for this.
I'd like to see the sizing options altered for clarity. Right now it's tough to tell what the hell they do without going through a bit of trial and error. I'm mucking around with some GUI-related stuff at the moment, maybe I'll experiment a little....
#20
06/19/2013 (5:46 pm)
@Richard, so just to be clear T2D MIT supports the same GUIs (give or take), but doesn't have an editor for them? 
Torque Owner practicing01
MourningDoveSoft