The New GUI Editor

#21 I think Wes and Mike's comments are spot-on.

It is my opinion that a torque developer, hobbiest or not, should eventually become familiar with the C++ side of Torque. Making your own custom GuiControl is in fact an excellent way to "wade in". A hobbiest may not have as much time to dedicate to coding, but they usually still aspire to creating games of fairly high complexity. And in most cases, that level of complexity requires some C++ coding.

However, the script side of torque ( regardless of any complaints ) is infinitely more documented that the C++ side. While GG documentation seems to be focused primarily on the newest users, and introducing them to script, eventually those same people will want to make the jump to C++. When that time comes I hope GG is up to the challenge of helping us out.

The number one benefit of knowing your way around the Torque C++ code, is you can see what is really going on behind the curtain. If something doesn't do what you expected, go look at the code, it may not actually be designed to do what you wanted, or it might have a bug somewhere, etc.. The more familiar you become, the more efficient this process is, until you can essentially answer your own questions quicker than you can post on the forums and wait for a response.

Ok sorry for the rant...
but I do enjoy playing the devils advocate and defending the torque gui which everyone likes to rat on '-)

#22 In RPGs and strategy style games you generally spend much time navigating the menus, so it's important to me that they look and act good. The player can tell the difference between application and game GUIs, and generally OS style guis are viewed as unprofessional or substandard quality. Do you think the SIMS would have done as well, if it had implemented Windows widgets instead? I'm not so sure that it would have.

Banks game GUI looks pretty good, especially for that style of game.. but (for ME) it seems like it'd be slightly harder to maintain than if it had been built with a sogui. This is all just personal taste you know, depends on the project and your knowledge. If you have lots of experience with TGE GUIs (or a few team members who do) more power to you.

Here are more reasons why I am going with soguis. The GUI editor has issues. It seems to crash at random, and when it does you lose your work. Never has the level editor crashed while I develop my soguis. I know those are probably bugs, but I don't have time or patience to report every GUI editor bug to GG. The GUI editor is very quirky. I find myself having to add invisible container profiles and other obscure things just to make it show a widget, and when it does it's usually out of position and refuses to move where I need it. It's also a lot of other information to dig through. Why bother with thousands of confusing GUI widget functions when I can stick to the nicely organized TGB reference?

I tried to make a multiline editable text for behaviors, but gave up because it seemed impossible to allow basic features like cut and paste, delete and backspace keys. My pleas for help on the forum yielded no reply. Maybe basic things like this aren't possible?

"how can you ever have a GuiTextEditCtrl"
You can change a textObjects text all you want, I do it often in my soguis. I'm sure it won't be hard to implement a GUITextEditCtrl. In fact I may need to do this eventually to allow naming of characters and/or saved game files. Here's how I tackle the issue. I have GUI "panels", that get "focus". So when the player goes to edit his text, the game will give that part of the GUI focus, and push the keymap for editing text. It's not hard, my behaviors take care of it for me transparently, and I have no "weird issues" so far.

My soguis looks good at any of the resolutions I plan to support. I was using TGE GUIs and they seemed to scale badly or stay the same size when I change res. This is a major reason I went with soguis, they actually look a lot better when you change resolutions and I like not having to screw with per widget sizing settings. Animated bitmaps are just icing on the delicious cake that is soguis. No engine patching required for that.

@Kevin,
The new EULA basically forces everyone to show a splash screen advertising TGB when the game starts. No difference if you own an indie license, but I picked up the commercial license awhile back to avoid this. So now if I ever update I'll be bound by the new EULA. Which I don't plan on doing unless they give us something amazing.

James I don't know where you're going with the C++ stuff, what does that have to do with soguis? I haven't had to edit the C++ to support soguis yet. Is this something you routinely do for your TGE GUIs? Because that's not really an upside you know ;)

#23 I think everyone likes to rant on the GUI system because GarageGames has shown us a "better way to build a mousetrap" so to speak in creating scenes. It's only a small logical leap to want that ease of use for GUIs as well, since every game basically needs one.

Take creating a button for instance, the scene object way all I have to do is drag a static sprite from the create tab into the scene at the location I want, edit its properties like any other sprite and add the generic button behavior to it. I can create a specific function for that button in the generic button behavior and reference that function inside the level editor.

No worrying about 4 different image files with different _h, _d endings (why couldn't it have been a CELL mode ImageMap?), no worrying about yet another coordinate system with horiz and vertSizing options that are extremely confusing, no worrying about the lack of being able to see the current scene layout in the GUI editor, and no worrying about yet another file that needs to be exec. Sure, it's all just a bunch of minor complaints - but they add up and the scene object way is just more intuitive.

Again, all this is for simple GUI aspects like buttons and text - which is probably enough for the hobbyists that only purchase the non Pro version of TGB and don't have access to the C++ side of things.

#24 How a gui is scaled when resized is dependent on its parent and what you set vertSizing and horizSizing to. Understanding which sizing mode you need and when you need a wrapper "container" control is pretty confusing at first, but it gives you a lot of power.

A crashing GUI Editor is definitely annoying, sometimes the workaround is to edit your gui files directly as much as you can. In the future this should not be a barrier to using torque gui's in your game, I know some crash bugs have already been fixed by the guys at GG.

GuiControls were made to be controls in a gui, and sceneObject were made to be objects in a scene. As such guiControls have features that are incredibly useful for objects you want to behave like controls in a gui, that sceneObjects do not. In my mind using a sceneObject as a GuiControl is like using a screwdriver as a hammer.

Ultimately if a sogui is working for you then as you said "more power to you". I just want to spread a work of caution...

For a complex gui, such as an RPG's, many features GUI controls provide are very very useful. Implementing those features in script as a sogui is definitely extra and unnecessary work.

Learning the Torque GUI system is a pain, but if you plan on continuing to use torque project after project its just something you SHOULD know. Once you understand it, its one more tool in your game creation arsenal!

I am particularly excited to see what GUI changes they make in Torque2...

#25 Ah, alright Joe. Your decision makes sense now. Dying to talk about it, but I am not going to hijack this thread, lol. Oh, and good points with the sogui's!

*Hoping this post doesn't multiply when I'm not looking.*

#26 Extra and unnecessary work? I'm not too sure about the unnecessary part, at least I don't feel that way. My work on soguis helped me learn a lot more about how scenes and scenegraphs work, how objects can work together, intricacies of the behavior system, etc. I feel a good amount of what's in the torque GUI system is rather unnecessary for most games.

It does set me back having to develop widgets and basic GUI elements myself, but when I finish a certain widget I can reuse it all I want project to project because I write them as behaviors. I believe the time I'm spending on soguis, would've been equally spent in the more frustrating development of TGE GUIs. The things Mike Lilligreen brought up are spot on. It just feels more streamlined having everything work within the level editor. If I want to change how things look or act, it's so easy. There are many "gotchas" when it comes to the torque GUI system. Let's take something as simple as changing the border on your menu window. Last I checked you had to be sure to use a line of (perfectly) red pixels separating the borders. And make sure it's ONE PIXEL! Or you get errors and it won't work. Little things like that add up to frustrating me a lot. With my sogui, all I do is select a new texture from a dropdown menu.