Torque 2D: Editor Collaboration
by Michael Perry · 03/15/2013 (9:28 am) · 113 comments
Torque 2D Editor Collaboration
Greetings everyone! It's time to talk about the 800 lbs gorilla in the room. It's no secret that Torque 2D is an awesome engine with a slick API, lots of examples, growing feature set, and amazing community. However, one of the main drawbacks is lack of visual editors. While we have been helping out with 3rd party tool support, like TexturePacker, nothing beats a full editor suite. Before we get into it, here's a little backstory...
The Road So Far
For a while, I've been avoiding getting into a detailed, public discussion about future Torque 2D editors. The reason is because the T2D team needed to discuss a few things internally:1. What would be our role in the effort?
2. What are potential paths we can lead folks down?
3. What initial research needs to be done to kick off the discussion?
Well, we have finally answered those three questions and have determined now is the perfect time to open it up to all users. Melv and I have had several discussions behind the scenes, so this isn't a whimsical blog. We've gone back and forth on different options, but now we need everyone's feedback.
Editor Shell
Feel free to correct us on this, but we came to the rough conclusion that it is not feasible for GarageGames to make all the editors. Nor is it likely that the entire community can organize and spearhead the effort without our help. This is based on history, our own experience, and the current size/knowledge of the existing T2D users.What we discussed is the concept of an editor shell. The gist is that we would develop a barebones program that would support plugins. The plugins could be developed by anyone, then easily integrated by an end-user. The hope is that multiple plugins would make up an editor suite, without relying on GarageGames or any other sole entity. Our plan was to release the shell for free, under the MIT license, and allow anyone to do what they want with it. People could submit free plugins or sell them, without restriction. A plugin could be as simple as a sprite viewer or as complex as a level builder.
Unfortunately, that idea was not the tough problem to fix. The real issue is deciding on which technology should be used to create the shell. We discussed three potential options:
1. Torque GUI/Script
2. Qt
3. wxWidgets
We quickly eliminated wxWidgets. That left either Qt or the existing Torque 2D GUI/Script system. Either tech offers some major hurdles. Qt is our preferred framework for generating an editor without question. It would enable some very nice features, not least of which would be consistent cross-platform experience, window docking, plug-ins and the use of ECMA-JavaScript for extensions. We could even integrate things like Scintilla for script editing and debugging right inside the editor itself.
The major hurdle we're facing right now is modifying T2D to work in a multi-viewport environment as would be required for an editor. T2D is setup to be a single-window framework. It needs to be more like T3D with a multi-window, texture->device setup, but work without problems on all existing platforms. Without that, the only option is to generate an editor using Torque itself and TorqueScript, something that we'd do but with great, great reluctance. After all, TorqueScript was designed to control games and not larger-scale applications like editor suites. Small tools yes, scalable editors, not so much.
One major failing of that approach is the GUI system which is inconsistent and just plain bad. Additionally, the font system is pretty old. A complete overhaul of the GUI system to include powerful layout for multi-resolution devices and the use of a font library like FreeType2 would be one possible solution to use T2D itself.
Now
Well, you have all been asking about them. Here is our reply. Now it's time to discuss! We obviously would like to hear preference, but we are really hoping we can get some back and forth going on the technical details. What would be amazing is if we could even get some folks to speak up on possible collaboration, because even the editor shell is no small effort. So what say you, community?Regards,
Mich
About the author
Programmer.
#62
03/19/2013 (11:31 am)
I think TS is good the way it is, personally. I think that changing the language would be problematic and a huge hassle. It would be as if Garagegames changed their forum's language to spanish. Some people here already speak it our could pick it up fast by knowing a similar language, but I'm not sure that's what the engine needs right now. 
#63
... or to be clear, we're not saying that. ;)
03/19/2013 (11:32 am)
Nobody is saying anything about changing the language. This is about how the EDITOR is developed not how you write your game.... or to be clear, we're not saying that. ;)
#64
It's really going to be up to the community to then develop plugins for the editor so that it can actually be useful. Basic scene editor, asset management/pipeline, whatever else you can dream up.
03/19/2013 (1:18 pm)
Michael and Melv can correct me if I'm wrong, but the idea is that GG will help get the QT editor shell up and running. Modify T2D to run embedded in QT (or anything), get the QT framework shell up and running, etc.It's really going to be up to the community to then develop plugins for the editor so that it can actually be useful. Basic scene editor, asset management/pipeline, whatever else you can dream up.
#65
I mean, I can grab the Qt creator app and generate a toolbar and some simple splash screens to create my XML GUI file. Then I can throw in like 100 lines of Python boiler plate code to create this "shell program". The effort would take an hour or less. Is that what we are talking about here? Please define what is meant by "shell program".
Edit:
Just so you know I am not blowing smoke: Qt Creator with Python
I also think a plugin architecture with Python would be dead simple as Python is pretty much a plugin system by design.
03/19/2013 (2:07 pm)
Okay, maybe I am daft, but what does "shell" mean in this context?I mean, I can grab the Qt creator app and generate a toolbar and some simple splash screens to create my XML GUI file. Then I can throw in like 100 lines of Python boiler plate code to create this "shell program". The effort would take an hour or less. Is that what we are talking about here? Please define what is meant by "shell program".
Edit:
Just so you know I am not blowing smoke: Qt Creator with Python
I also think a plugin architecture with Python would be dead simple as Python is pretty much a plugin system by design.
#66
@Frank - Think of it like Eclipse. You have a very barebones shell that takes several plugins to make up an editor suite. The important part is embedding Torque 2D into the Qt application, so that it would have access to the module system, TAML system, T2D sprite rendering, and so on. This is important if we want WYSIWYG editing. An empty Qt application with the ability to load plug-ins that can show T2D capabilities.
03/19/2013 (2:40 pm)
@William - You pretty much have it right. The editor shell will be the hardest part of creating an editor suite. It could require the most amount of changes to Torque 2D and initial development with the 3rd party app (be it Qt or whatever). The goal is that we (GG) would contribute to developing that, but additional help with that task is going to be necessary.@Frank - Think of it like Eclipse. You have a very barebones shell that takes several plugins to make up an editor suite. The important part is embedding Torque 2D into the Qt application, so that it would have access to the module system, TAML system, T2D sprite rendering, and so on. This is important if we want WYSIWYG editing. An empty Qt application with the ability to load plug-ins that can show T2D capabilities.
#67
Does that mean we will convert the T2D architecture to a DLL? Sort of like T3D is now? The issue there is event processing like when you embed T3D in a browser.
03/19/2013 (3:42 pm)
@Michael,Does that mean we will convert the T2D architecture to a DLL? Sort of like T3D is now? The issue there is event processing like when you embed T3D in a browser.
#68
What are the long-term difference on use Qt instead of torque GUI?
03/19/2013 (4:32 pm)
I guess that this would be the road map for Torque GUI.- Add guiControl signals to program the logic in c++. (Done)
- Save GUIs in TAML (Done)
- A plugin manager
- Improve guiControls. This does not block the start creating the editor
What are the long-term difference on use Qt instead of torque GUI?
#69
QT is the current UI framework approach because one, it's cross platform and two, GG already has some experience with it.
I still hope someone takes up the torch of overhauling the UI subsystem in T2D, since it does need some work, but that should be geared toward game development.
03/19/2013 (4:40 pm)
@Luis: Gerald pegged it, and I completely agree. the T2D GUI system will never be on par with what is needed for a proper editor suite. No game GUI system is. They are for two different uses, and trying to squeeze an editor suite into a limited GUI subsystem is a bad idea.QT is the current UI framework approach because one, it's cross platform and two, GG already has some experience with it.
I still hope someone takes up the torch of overhauling the UI subsystem in T2D, since it does need some work, but that should be geared toward game development.
#71
At this point quite a few people have expressed dissatisfaction with the current GUI system, nothing more. Since T2D is now open source, an individual or group of people will need to step up and either:
1. Work with the community on making a new GUI system that will appeal to the largest group of users - and then release that system for free or with payment.
2. Create a GUI system that meets their needs first and then offer it to the community for free or with payment.
03/20/2013 (1:41 am)
@Kevin - I don't think anyone can really answer that as there is no new GUI system. I would imagine that being able to manipulate GUI objects in Torquescript will be necessary, otherwise you would be making the GUI system very user unfriendly.At this point quite a few people have expressed dissatisfaction with the current GUI system, nothing more. Since T2D is now open source, an individual or group of people will need to step up and either:
1. Work with the community on making a new GUI system that will appeal to the largest group of users - and then release that system for free or with payment.
2. Create a GUI system that meets their needs first and then offer it to the community for free or with payment.
#72
Obviously they are written against different graphics layers.
03/20/2013 (2:28 am)
I am not very familiar with T2D. How does the GUI system in T3D compare with the current GUI system in T2D? If they are not the same could they cross pollinate? Obviously they are written against different graphics layers.
#73
The biggest problems with the GUI system are that it has poor/confusing layout features, has a strict and silly profile set-up, is comprised of many controls written by lots of different folks leading to many inconsistencies, is fragile and easy to crash when skinning (oh so easy), is mostly used by uniquely naming controls leading to singleton GUIs... blah blah blah.
The time-scales I've seen thrown around here are way off in my opinion. The biggest hurdle is changing T2D so that it can render to multiple view-ports so we can have tool-windows that show things like a Scene, Animations, Images etc. The Qt shell isn't a massive project, it's really just an application shell that provides the T2D/Qt integration and a bunch of editor/plug-in interfaces to adhere to i.e. the code contracts from which the community can gather around to develop code. Basically the shell would act like the campfire for T2D. The extent and complexity of the shell/interfaces would need to be determined and preferably organically grow so versioning would be a critical element in that.
A new GUI could be done in one/two man months in my opinion. This wouldn't include creating every control known to man, just the basics but more importantly a solid foundation for layout, styling, integration of GUI as assets, input/eventing etc.
The shell however would be a few weeks after a design had been finalized but that is a long-term project and expected to organically grow. There are several ways to approach this however.
03/20/2013 (2:42 am)
They are the same (T3D has had more love in that area though) and as you say, just different rendering layers.The biggest problems with the GUI system are that it has poor/confusing layout features, has a strict and silly profile set-up, is comprised of many controls written by lots of different folks leading to many inconsistencies, is fragile and easy to crash when skinning (oh so easy), is mostly used by uniquely naming controls leading to singleton GUIs... blah blah blah.
The time-scales I've seen thrown around here are way off in my opinion. The biggest hurdle is changing T2D so that it can render to multiple view-ports so we can have tool-windows that show things like a Scene, Animations, Images etc. The Qt shell isn't a massive project, it's really just an application shell that provides the T2D/Qt integration and a bunch of editor/plug-in interfaces to adhere to i.e. the code contracts from which the community can gather around to develop code. Basically the shell would act like the campfire for T2D. The extent and complexity of the shell/interfaces would need to be determined and preferably organically grow so versioning would be a critical element in that.
A new GUI could be done in one/two man months in my opinion. This wouldn't include creating every control known to man, just the basics but more importantly a solid foundation for layout, styling, integration of GUI as assets, input/eventing etc.
The shell however would be a few weeks after a design had been finalized but that is a long-term project and expected to organically grow. There are several ways to approach this however.
#74
We all must be responsible for creating our own level editor. This is the grim reality.
Level Editor->Manage - new GUI pop up that I create for my game. Maybe it will work for yours if its a platformer.
03/20/2013 (12:59 pm)
This GUI editor build should have large holes that people can fill in for their own project core game functions, use it like a console to change multiple fields with many objects with one command. An editor style list should be available, so anyone here can create their own version with different priorities to manage unique components. Faster development, clean up the workspace.We all must be responsible for creating our own level editor. This is the grim reality.
Level Editor->Manage - new GUI pop up that I create for my game. Maybe it will work for yours if its a platformer.
#75
TGB's editor was generic enough to allow you to build out most any game. It's not a one stop shop, and you might still need to get your hands dirty with the scripts/engine.
03/20/2013 (1:20 pm)
@Nathan: Most casual T2D users won't be creating any custom editor tools. Eventually we'll have several generic tools for helping developers build games.TGB's editor was generic enough to allow you to build out most any game. It's not a one stop shop, and you might still need to get your hands dirty with the scripts/engine.
#76
03/21/2013 (10:17 am)
What I've always liked about Torque was how easy it is to use. I mean, it allowed first-time designers to jump right in and learn. The problem with having the MIT without editors and completely removing the last version is that element of pain-free-ness is removed as well. I'm really excited to see what you guys come up with, though! :)
#77
03/21/2013 (10:22 am)
And on the flip side, all of the horrible pain points of the older tech has been rectified. The editors were good, but the underlying issues were almost unforgivable. Once there are editors, this will be a juggernaut of a product.
#78
If you have anything else to contribute to the debate of which framework or path to go down, please continue posting to this blog. Early next week I will post another blog, which will talk about recent changes to Torque 2D, new docs, and moving forward with creating an editor shell using Qt.
03/21/2013 (2:20 pm)
Alright everyone, it seems the popular consensus is to move forward with using Qt for the editor shell. As stated previously, this is the route the Torque 2D committee believes is best. For those who disagree, remember that nothing stops you from forging your own path and developing editors using another system.If you have anything else to contribute to the debate of which framework or path to go down, please continue posting to this blog. Early next week I will post another blog, which will talk about recent changes to Torque 2D, new docs, and moving forward with creating an editor shell using Qt.
#79
Would anyone like to weigh on the merit of HTML5? Specifically, what are the pros and cons of using it over something like Qt? I'm performing my own independent analysis, but your voice is very important.
03/22/2013 (10:52 am)
Greetings again. Before I work on my next blog that will hep detail a plan of action, I've been accessed to also consider HTML5 as a possible solution for the editor shell/framework. Would anyone like to weigh on the merit of HTML5? Specifically, what are the pros and cons of using it over something like Qt? I'm performing my own independent analysis, but your voice is very important.
#80
I haven't researched attaching to an in-web canvas object for rendering from a third-party process in either one, though (in-editor game preview).
03/22/2013 (11:31 am)
If you are looking at that route, I'd use Awesomium over QtWebkit. But that's just a matter of personal preference. Both would allow you to do your editor features in HTML5 but allow for invoking native processes, etc outside of the web sandbox. I haven't researched attaching to an in-web canvas object for rendering from a third-party process in either one, though (in-editor game preview).
Torque Owner Travis Evans
WNC Studio
Qt seems to be a popular choice with quite a few cross platform developers, correct me if I'm wrong. The down side to using Qt over Torque Script is a near vertical learning curve for those with no programming experience. Perhaps the editor could take Qt written modules and TS written modules.
Just my two cents.