The New GUI Editor

#1 The GUI editor is probably the major part of TGB that is lacking the most. I'd really like to see a sceneObject based GUI system, maybe with behaviors or even a new editor. For now I'm building my game GUIs out of TGB sceneObjects. They're more flexible, prettier and easier to edit.

#2 Until you want a text list or a menu bar or a progress bar, which are easier to do with the gui since the controls already exist. Behaviors on a gui control?! Thats insanity! '-) But if you worked with previous TGB versions or TGE you will recognize that the gui editor in TGB 1.5.1 is quite nice.

But heres what would be nice:
1. adding menu items from the editor (like C# forms designer)
2. can see the callbacks (if any are defined) for a selected control, if they arent defined you can click "create" or "add" and it will open the .gui script file with a new empty callback function created for you (like the events tab in C# forms designer)
3. can add items to a text list in the editor

These are things that I am currently handling in "guiscreen::onWake()", but couldn't rows in a guitextlistctrl be defined in its definition, or the editor could add those list to the onwake for you.

#3 The way I see it, a GUI system with behaviors would be simply a set of behaviors that allow you to make sceneObjects act like the standard GUI items. For example, a pop-up menu would be created by adding a sprite and giving it a 'pop up menu' behavior. That behavior would have fields that correspond to all the pop-up menu properties, like:
Max items to display
Space separated list of choices
entry area graphic
list background graphic
blah blah blah

The nice thing about using t2dSceneObjects is that they're resolution independent, which in my eyes is the single biggest limitation of the old Torque GUI system

#4 Spider that's exactly what I was thinking. Just make a set of behaviors that let sceneobjects act like widgets. So you can do all sorts of trickery with them, layers, transparency, add particles, animation, physics etc.. and also not worry about learning the TGE GUI system..which to me always felt a bit more like an OS GUI than a video game, even when you do skin it.

#5 Having a layout manager a'la wxWidgets and the like wouldn't go astray either, though I can see how this would be lower priority for a GUI system targeted at game usage. I am with Joe on this one, we are currently using standard t2dSceneObjects for GUI purposes with behaviors attached. When we need something a little more advanced, we'll use an acual GUI object.

I too think a scene object based GUI system would be preferable, as it would be more consistant and integrated.

#6 I like using SceneObjects for GUIs much better. You can do more effects on them (fading, particles, animation etc), they display correctly at any screen size, and I find them easier to work with than the TGE GUIs.

#7 Interesting thoughts. Can you share a behaviour or a little tutorial about something like a counter? I would imagine using bitmaps for the numbers. Do you have such a resource?

#8 Have you looked at the new Asteroids Tutorial on TDN Michael? A couple of the sections deal with GUI elements done with t2dSceneObject and t2dTextObject, counters, etc.

#9 Not really, I guess I should. :-) Thanks for the info.

#10 Same here. The GUI Editor should really just be another pullout in the scene editor that I can just drop whatever controls I want on the scene and then quickly edit the images, fonts, colors, behaviors, etc. The current GUI Editor is the one thing I don't like about TGB... everything else is fantastic!

#11

Quote:The GUI editor is probably the major part of TGB that is lacking the most. I'd really like to see a sceneObject based GUI system, maybe with behaviors or even a new editor. For now I'm building my game GUIs out of TGB sceneObjects. They're more flexible, prettier and easier to edit.

Amen to that brother!

#12 I personally think anyone that has previously said they like sceneobject based guis better than "real" guis is crazy.

You may think its easier to "just use sceneobjects" when your game has one level, doesn't have a scrolling camera, and your gui consists of only "lifes" and "level". As your game gets more complex, and your GUI does as well, you will see WHY the entire gui system exists and that it makes complete sense the way it is.

You should be very very GLAD that TGB has a gui system that is separate from the scene. You don't absolutely need it for a very simple game, but TGB has the power to make a lot more than just simple games, and a GUI system is one requirement for that.

Do you think you could implement a GUI like Morrowind or Oblivion with sceneObjects? Handle inventory items, list and sort spells, display popup tips when something is selected, etc... Or even make something as ( relatively ) simple like the guitextlistctrl? I know i sure wouldn't want to, plus its already made. Eventually you will want to make a control do something it cant, and you will need to derive a new control class. Well if you try the same thing with a sceneobject you will have all the overhead and all the virtual methods of a sceneobject, most of which you don't even need, because what you need is a gui control.

Why the Gui editor should be separate
When you are editing a level, you want to edit the level and not have your in-game-hud in the way or whatever, and when you are editing your gui you don't want all kinds of crazy stuff going on in the background. Its not like its hard the way it is now to "switch to gui editor" and then back, and it makes a lot of sense.

Fundamental Difference between Sceneobjects and GuiControls
GuiControls do not exist at a "worldPosition" in a scene, because most of the time you want to specify where on the SCREEN you want them. Reverse calculating the world position based on where you want it onscreen is just wasted processing.
You absolutely do not want your GuiControls to exist in the "scene". How is a loading screen even possible in that case? When you load a mission you just threw out the old sceneGraph, there goes your loading screen. if you want to "show" the same gui in multiple places ( eg. different levels / between levels ) how can that ever work? Do you want to copy paste all your control "objects" into every mission file?

Imagine you want a simple "GET READY" message at the start of a level, sure you can just drag a textobject over, and not use a guitextctrl, but now if you make a second level you have to do the same thing for it, and then make sure they are lined up the same, multiplied by how ever many "gui controls" you are representing by scene objects.

Some things you can do with a gui control that you can't with a sceneobject:
push / pop, easy to switch between different guis
parent / child relationships, useful many many things.
autoresizing, very powerful settings like horizResize and vertResize allow things to stay in the proper place with different game resolutions, good luck implementing that for sceneObjects.
handling input: accelerators for buttons and menu items, click callbacks that just have to be overridden in script, ability to override keybinds ( useful for in game popups ).

#13 Well we aren't just saying it for no reason.. some of us actually do know what we're talking about. It sounds to me like you are just speculating on something you haven't actually tested or experienced. Have you ever built a GUI with sceneObjects?

I have a sceneObject based GUI system working pretty well here. I enjoy being able to edit it in the level editor, using behaviors, layers, visibility functions etc. Mine is a bit more than just "lives" and "score". It's an RPG party management menu containing lists of stats, scrollable and clickable spell/item/equipment text lists, character portraits and stats... so to answer your question, yes ;) I also made an Options menu, and Load game menu with basically the same code (I use behaviors).

One major issue I take with the TGE GUIs... they are not video game GUIs. They look too much like application GUIs. Unless they are buttons they'll never look like what most gamers expect a video game GUI to look like. Some of the commercially released TGB games have opted to use sceneObject based GUIs. Why do you think that is?

Don't be such a nay-sayer :P

#14 Ah! I just love a good forum debate, Mr. Ford!

First of all, I must express my deep hurt at your implication that those who use scene object graphical user interfaces, henceforth known as sogui's, have only created simple games. I am quite sure that my fellow developers and I have made much more complex games than one whose camera cannot move and whose only gui elements are "lives" and "level".

Second, I am quite surprised that you are unfamiliar with using sogui's. You seem to think that my comrades and I are referring to building gui's on the actual player scenes. Such an idea is absurd and if it were true, you would be justified in defending the gui builder. No -- I cannot speak for my friends -- but I know that when I build a gui out of scene objects, I always create a separate scene window over top of the action window. That way, the sogui is universal and is not affected by the camera movement. I usually do sogui creation in scripts, but it would be completely possible to create your own gui in a different level and simply load that level into the gui scene window's scenegraph.

As far as creating gui's for games such as the Elder Scrolls series, I cannot see how a standard gui would be more beneficial than a sogui. To my knowledge, there are no guiInventoryCtrl's so that is new ground. A tile layer would serve just as well as any solution found in the gui builder. Now given, there are somethings that the gui system is needed for, such as the guiInputCtrl. Keybinding would be incredibly difficult without that. Luckily you can make it invisible. Even when I do use actual gui controls, I never ever use the gui builder. I am used to the 1.1.3 builder; Is the 1.7.2 gui builder any better?

Lastly, sogui's are the only way to have animated gui's. I know for a fact that it is impossible to animate gui controls in any manner whatsoever. Unless you count changing visibility. So unless you want to play a game that has a gui like a operating system, you are better off using sogui's.

Mr. Ford, you had some really good points with that last list. I'm still working out a parent/child relationship with scene objects. I'm thinking about using sim sets.

Quote:autoresizing, very powerful settings like horizResize and vertResize allow things to stay in the proper place with different game resolutions, good luck implementing that for sceneObjects.

I didn't know that about gui controls. Does that honestly work? As for scene objects, they resize automatically without any developer input.

I am definitely tired of typing the letters: G - U - I. Until next time!

Kevin
syrealgames.com

#15 "I always create a separate scene window over top of the action window"
Same here, this solves that whole scrolling camera issue.

"there are somethings that the gui system is needed for, such as the guiInputCtrl. Keybinding would be incredibly difficult without that"
I use behaviors to assign keys to objects. I haven't made a way to change keys once assigned, but I doubt it'd be very difficult. I stand by my belief that there is nothing the GUI system is "needed" for.. Although I have made a behavior (it's on TDN) that allows you to mount TGE GUI objects onto your sceneObjects, and I do currently use that for some things like checkboxes and scrollers..mostly because I'm too lazy/no time to rewrite those widgets as sceneObjects - but I'd like to.

As for parent/child right now I have behavior fields to allow assignment of parent/child GUIs..crude but effective. The new version of TGB could make that easier with the new functions that allow iterations over all mounted child objects.. I refuse to use 1.7 due to EULA changes.

It is a bit more scripting to get these GUIs to work well, but in the end I'd say it's worth it. If you use behaviors the code can be reused pretty easily.

#16 I do apologize for any assumptions I made previously, especially after seeing the quality of both your replys.
Having a second scenegraph overlayed would solve many of the issues I had imagined. Although I am not convinced in any shape or form of the utility of sogui's '-)

I didn't realize 1.7 was out! I've been busy working with TGEA for while now, so I will definitely have to check it out and look for any changes.

JoeRossi@
It is fairly amazing to me that you have been able to implement a shogi as you have described, and I applaud you for inventive use of script and behaviors. But I have to maintain that doing all of that, without GuiControls, is pure insanity. All the tools for making it already exist... GuiWindowCtrl, ScrollCtrl, FrameSetCtrl, StackCtrl, TextListCtrl, ( maybe even a TabBookCtrl ).

If animated bitmaps is the only thing holding you back,
here are two GuiAnimatedBitmapCtrls available as resources:
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=3673
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=3965

I am using this for showing loading progress ( "Loading . . ." with looping 'dots' ), and a modified version for "stats" meters, which has the ability to interpolate the animation position towards a target percentage of the animation ( eg. 50% health ).

The artistic look of gui controls is NOT set in stone. They probably look the way they do by default because they were made for use in the editor. By the way, there is excellent information on creating new gui artwork in The Game Programmer's Guide to Torque.

At some point or another you will run into the problem of "I can't do X in script". If you are using GuiControls for your guis when this happens the next step is to make a new guicontrol. However, if you are using sogui's when you reach the "script can do X" limit, what are your options? Often the problem isn't that you can't do it in script, its just that it looks like an ugly confusing mess when you do.

I also would be very worried about the performance implications of moving what would be C++ code into script code. Especially any behavior that utilizes the update calback to do anything significant. Most of the time games want to take full advantage of any cpu available, and often that is by moving script code to C++, whereas using a sogui is doing the exact opposite.

Processing Input
If all you have is keybindings to provide gui input, how can you ever have a GuiTextEditCtrl? Do you bind every single key on the keyboard to it? What you want to really do is peek at the low level input coming in and respond to it in C++, which is exactly what the GuiTextEditCtrl does.
What about when you have multiple controls on screen that both take the same input? In a gui it would go to the one that has focus, you could try the same thing by having an action map for each sogui object that takes input and pushing/poping the actionmap as focus changes, but having a ton of actionmaps is generally a bad idea and can give you weird results.

Autoresizing
Lets say you want a radar to stay at the top center of the players screen at all times. If your sceneWindow and camera ( refering to the sogui scene ), are the same size, say 800x600 so you place the radar at 400x0. Im assuming the scenewindow is positioned such that 0x0 is the top left world coordinate. Now that radar will always be at world position 400x0 unless you move it.

Lets say someone decides to run the game in 600x400. If you opt to keep the same sceneWindow size in this scenario everything may look squished and crappy, so the best visual option is to change the size of the sceneWindow to keep the correct aspect ratio. When then happens your radar at world positon 400x0 may be offscreen, or just in a wierd place. If you want to calculate what the correct position for this new resolution is to remain "top center" you can do so.

Or you can make a GuiControl with horizSizing = center, vertSizing = bottom. Done.

#17 Hi guys. interesting read here :) I just wanted to add something about

Quote:So unless you want to play a game that has a gui like a operating system, you are better off using sogui's.

Does the following looks like Operating System?
I found that building GUI as GUI is much more easier comparing to the SO-based. (this is TGE, but T2D core is integrated, and some components of TGB are used - the avatar in the inventory is t2dShape3D component.
As of animation - there is a guiTweenBitmapCtrl that works quite well (I've made a GuiControl to have all the functionality of guiTween so I can animate any gui control I want - in my game the buttom HUD elements can move for example).

#18 I wouldn't argue against the usefulness of the GUI builder and it's associated controls for a complex GUI system with a large amount of common control styles for a game such as an RPG. I do however find GUIs of small/simple to medium sized games easy and effective to implement using standard scene objects. If I ever need to implement functionality for a more complex scene/game I'd probably use the GUI builder at this point. There are certainly ways around SG destruction as others have mentioned.

Hmm, certainly a case of "right tool, right job". That and whatever you feel most comfortable with.

#19 Yes, in the hands of an experienced developer/team, the standard Torque GUI system is obviously quite powerful and customizable (as bank's screenshot shows).

The problem is that TGB is being partly marketed to beginners and hobbyists. The current workflow that the TGB editor provides in setting up a scene and editing it is fantastic. This is why so many of us prefer to use sceneObjects and textObjects to replace GUI functionality. The GUI editor, although improved from the early TGB days, is still a step backwards to the simple ease of use the level editor and behavior system provides. Compound that with very little GUI documentation/tutorials written for the TGB audience, and this is why there is a vocal group asking that things change.

#20 I'm really learning a lot from this debate, guys! Awesome!

Bank,

That is a really great screenshot! Do you have a release date for the game? I want to play it! I suppose I stand corrected about standard gui's looking like operating systems. Curses! I must stop using all-encompassing statements! A better statement would have been:

"so unless you want to spend a very long time learning the gui system to create a good-looking gui; use sogui's"

Perhaps even that statement is too broad, but as Mike pointed out, I am a hobby developer, and I do not have any programming background whatsoever. Thus, the level builder is a much easier gui building tool to use, especially because I know Torque Script like the back of my eyeballs.

James,

That is a cool resource! I admittedly use the guiBitmapCtrl or whatever for loading screens. This animated gui resource should help a lot, thanks!

Joe,

Your thoughts are definitely sparking ideas in my brain that will make my gui creation more streamlined and easier. I am quite surprised that you found a way to get keybindings functional just using scripts. Kudos! I have yet to make any gui's in 1.7.2, I just switched from 1.1.3. I will most definitely be utilizing some of your suggestions. I am also interested in your objections to the 1.7 EULA. Could you fill me in?

Thanks,
Kevin