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.
#2
Change script callbacks with something like GUI_Signal. When a GUI_Signal is triggered, a c++ signal and a script_callback is executed.
We can design GUI in TAML and their relationships/logic in c++.
03/15/2013 (9:59 am)
It is easy to remove TorqueScript from the equation, and write all the logic in c++.Change script callbacks with something like GUI_Signal. When a GUI_Signal is triggered, a c++ signal and a script_callback is executed.
We can design GUI in TAML and their relationships/logic in c++.
#3
03/15/2013 (10:05 am)
@Luis - That's certainly one path to go down, but I did state in my blog that the current GUI system is also a problem. It's not just TorqueScript. The other problem is that the engine does not support a C++ plugin loader. We have modules that use TorqueScript, but that's it. The plugin system would need to be dynamic. I don't think it's a smooth experience for someone to have to recompile every time they acquire a new plugin. 
#4
We already know that T2D itself is capable of handling the editing tasks itself. Some basic asset importers and editors would not be too difficult to get up and running, nor would it be too difficult to build a simple level editor. Now, I'm saying it shouldn't be difficult but I'm not saying it would be quick; there is still a lot of ground to cover.
For older T2D owners you already have examples to work from. While the tools will require a bit of work to refactor to the new system there are plenty of examples of how the editors worked before to give insight into building your own tools.
And Mich brings up a subject near to my heart - a plug-in manager for T2D. Guess I should get back to my research on that one....
03/15/2013 (10:15 am)
Torque's GUI system could use a solid overhaul, but that's a lot of work.We already know that T2D itself is capable of handling the editing tasks itself. Some basic asset importers and editors would not be too difficult to get up and running, nor would it be too difficult to build a simple level editor. Now, I'm saying it shouldn't be difficult but I'm not saying it would be quick; there is still a lot of ground to cover.
For older T2D owners you already have examples to work from. While the tools will require a bit of work to refactor to the new system there are plenty of examples of how the editors worked before to give insight into building your own tools.
And Mich brings up a subject near to my heart - a plug-in manager for T2D. Guess I should get back to my research on that one....
#5
That said, if you got a script-level plugin system implemented, like Richard pointed out, I'm fairly sure people with the older T2D licenses could just peel out the basic editors from there and port them to the plugin interface and make up a LOT of ground rather quickly.
I know that was one advantage I came across(though it's still a little bit of work to integrate) with T3D's largely script interface for editor tools. When a new version came out, I could nab the folder, the 1 or 2 connective script files and if needed, the engine files, dump them into the directory and boom, editor is in the new version, no muss or fuss.
Something similar would be a pretty good idea here as well, I think, if even easier.
03/15/2013 (11:59 am)
I've clearly been steeped in Torque for too long to really notice(though maybe I have inklings?) but I've seen it oft complained about how bad the GUI system is, but I'm not entirely sure WHAT makes it apparently so horrible.That said, if you got a script-level plugin system implemented, like Richard pointed out, I'm fairly sure people with the older T2D licenses could just peel out the basic editors from there and port them to the plugin interface and make up a LOT of ground rather quickly.
I know that was one advantage I came across(though it's still a little bit of work to integrate) with T3D's largely script interface for editor tools. When a new version came out, I could nab the folder, the 1 or 2 connective script files and if needed, the engine files, dump them into the directory and boom, editor is in the new version, no muss or fuss.
Something similar would be a pretty good idea here as well, I think, if even easier.
#6
03/15/2013 (12:11 pm)
I think Qt will be an better option! As Doc308 said, what T2D needs is a general 'LEVEL EDITOR'. Shell and Plugin thing is a better idea! so that someone can write an extension for example a particle editor, or even a asset manager for T2D!.. 
#7
I highly recommend looking at Adobe Flex for the editor framework. We use it internally and I have been very impressed at how powerful and flexible it is. It reminds me a lot WPF but with full cross platform support. It also has the advantage of being editable with the very reasonably priced IntelliJ ($99 for most people) for people who want to extend the editor (warning...using IntelliJ will make you want to switch to AppCode for iOS coding =P). Using Flex also opens up some interesting possibilities with importing/exporting assets and animations from Flash.
03/15/2013 (1:00 pm)
Reposted from here:I highly recommend looking at Adobe Flex for the editor framework. We use it internally and I have been very impressed at how powerful and flexible it is. It reminds me a lot WPF but with full cross platform support. It also has the advantage of being editable with the very reasonably priced IntelliJ ($99 for most people) for people who want to extend the editor (warning...using IntelliJ will make you want to switch to AppCode for iOS coding =P). Using Flex also opens up some interesting possibilities with importing/exporting assets and animations from Flash.
#8
03/15/2013 (1:18 pm)
@Matt - Thanks. Is it safe to say we'd face the same problems with Adobe Flex as we would with Qt? Mainly speaking of the way T2D is currently set up to render and run.
#9
Again, this choice is not up to us alone. Everyone needs to weigh in. If the vast majority of community says they want to use Torque GUI/Script to get something sooner, rather than later, then I can fight that. If everyone wants a more ideal, long term solution, then it's going to take quite a bit more effort and a much longer time.
03/15/2013 (1:23 pm)
Quote:I've seen it oft complained about how bad the GUI system is, but I'm not entirely sure WHAT makes it apparently so horrible.Don't get us wrong, it's great for games. It's just very difficult to use to make a full editor suite. It can certainly be done, as shown with the T3D and TGB editors. Speaking from personal experience, it can be very difficult to scale and maintain without constant maintenance and supervision. It is possible with the current setup, but it would be painful. The main benefit of going with current Torque GUI/Script is that we could get something up and running relatively quickly. Long term, though...
Quote:I'm fairly sure people with the older T2D licenses could just peel out the basic editors from there and port them to the plugin interface and make up a LOT of ground rather quickly.Bad, bad, bad, bad idea. Trust me when I say no one should port the old TGB tools. They just do not fit and were abused over the years. It will be much faster and less painful to code from scratch, trust me.
Again, this choice is not up to us alone. Everyone needs to weigh in. If the vast majority of community says they want to use Torque GUI/Script to get something sooner, rather than later, then I can fight that. If everyone wants a more ideal, long term solution, then it's going to take quite a bit more effort and a much longer time.
#10
I'm not sure how Qt works. Would Qt make a program that we would use to edit things or would Qt itself edit things for our games?
Whether or not we decide to use a Torque powered editor, we need a new gui system. It works but it could definitely be better.
Adobe Flex looks nice but Adobe is terrible at trying to sell me on it. This page throws a bunch of big, usual words at me that I've seen everywhere (productive, framework, consistent, common design patterns) and says "Trust me, we're special".
I would try downloading it or looking at their showcase but my internet is very slow this time of day.
03/15/2013 (1:29 pm)
Ugh, the last thing I want to do is pay a dozen times so I can get enough plug-ins for a proper editor setup.I'm not sure how Qt works. Would Qt make a program that we would use to edit things or would Qt itself edit things for our games?
Whether or not we decide to use a Torque powered editor, we need a new gui system. It works but it could definitely be better.
Adobe Flex looks nice but Adobe is terrible at trying to sell me on it. This page throws a bunch of big, usual words at me that I've seen everywhere (productive, framework, consistent, common design patterns) and says "Trust me, we're special".
I would try downloading it or looking at their showcase but my internet is very slow this time of day.
#11
More than likely, the shell would be developed using the Qt framework and Qt designer. Plugins can be created using that and Javascript, I believe. It's all free, last I checked.
03/15/2013 (1:32 pm)
@Alpha-Kand - That's a valid concern. Though, I don't think everyone will charge for plugins. I'm sure there will be free level editor plugins, paid versions, hell, even a subscription based one.More than likely, the shell would be developed using the Qt framework and Qt designer. Plugins can be created using that and Javascript, I believe. It's all free, last I checked.
#12
If the answer to that question is yes, then obviously I'd say we have no choice, that for the sake of our beloved engine we let QT prevail and bring forth a modular system we can adapt rather easily two and built upon in the future. JavaScript is a good language, easy to use and abuse, so I got no quarrels there for sure. However Mich, if you think TorqueScript is capable barring a GUI overhaul then I think it would boil down to time. In other words, can we have higher quality editors than we were use to made with TS in 6 months or will we have a truly off the chain system built in QT in 1.5 years....I don't know the answer to that, but obviously time I think will have some effect.
03/15/2013 (2:09 pm)
Well this is just my 2cents, but honestly the old editors were not that bad in practical use(actual game development)as far as I'm concerned (although the particle editors were hell) . However, I believe Mich when he says, behind the scenes they are a mess; so with that, I have to believe it would be a mistake to go on using such a structure. Which leads me to this question; could they be scratch built in such a fashion to provide even better practical use and solidified structure using TorqueScript.... or is the reason they are in the mess they are due to the limitations of TorqueScript itself?If the answer to that question is yes, then obviously I'd say we have no choice, that for the sake of our beloved engine we let QT prevail and bring forth a modular system we can adapt rather easily two and built upon in the future. JavaScript is a good language, easy to use and abuse, so I got no quarrels there for sure. However Mich, if you think TorqueScript is capable barring a GUI overhaul then I think it would boil down to time. In other words, can we have higher quality editors than we were use to made with TS in 6 months or will we have a truly off the chain system built in QT in 1.5 years....I don't know the answer to that, but obviously time I think will have some effect.
#13
There are obvious limitations with the current setup:
1. All controls must be in a single window
2. Stuck with the resizing/positioning issues that are inherent
3. Rewriting the editors in another language/framework will be starting from scratch, again
As for the timing, you are kind of close. The ideal solution of going with Qt, changing the architecture of Torque, and the learning curve to get it all up and running is definitely further than 6 months out. This changes if enough people step up and help with the work. The TorqueScript/GUI solution would result in us having something in less six months. Dramatically less, in fact.
You are completely right. This is a tradeoff of time and backwards compatibility breakage. Want something sooner that doesn't break backwards compatibility, but has a chance of falling apart 3 or so years from now? Let's go with Torque's system. Want something next year that is way more stable and can stand up for a long time, but breaks some backwards compatibility? Then Qt is the way to go. Pros and cons my friends.
03/15/2013 (2:21 pm)
Quote:could they be scratch built in such a fashion to provide even better practical use and solidified structure using TorqueScript....I'll regret this, but my opinion is "yes", it is possible. The initial shell will have to be rock solid and a few example plugins need to set a standard. The problem with Torque GUI and script is that it allows anyone to shoot themselves in the foot. I have seen some of the worst code ever when reviewing editors created in Torque. It's just too easy to make crap.
There are obvious limitations with the current setup:
1. All controls must be in a single window
2. Stuck with the resizing/positioning issues that are inherent
3. Rewriting the editors in another language/framework will be starting from scratch, again
As for the timing, you are kind of close. The ideal solution of going with Qt, changing the architecture of Torque, and the learning curve to get it all up and running is definitely further than 6 months out. This changes if enough people step up and help with the work. The TorqueScript/GUI solution would result in us having something in less six months. Dramatically less, in fact.
You are completely right. This is a tradeoff of time and backwards compatibility breakage. Want something sooner that doesn't break backwards compatibility, but has a chance of falling apart 3 or so years from now? Let's go with Torque's system. Want something next year that is way more stable and can stand up for a long time, but breaks some backwards compatibility? Then Qt is the way to go. Pros and cons my friends.
#14
03/15/2013 (2:40 pm)
Its like that moment when you were a kid and walked in Toys-R-Us for the first time with $50 in birthday money.....what to do, where to go, how can I have it all....the possibilities. (facepalm) 
#15
03/15/2013 (3:13 pm)
Well knowing zero about Qt and a bit about TorqueScript makes me want to say go the TS way, but I DO want this to be a viable product in 3+ years, I don't really want to wait 6+ months, but I would rather wait 6+ months for a silk purse than get a sows ear in a couple of months so my vote is Qt..
#16
I'm sure it's great and powerful and clean, but I HATE working blindly.
I say the "quick solution" is a trap - the people like me who need the editor will come back when there's a good editor (free means I can come back when I want to). The people who don't need the editor can work without it for the time it takes to implement.
My vote is to take the "correct road", even if it means we don't see an editor for a year. Focus on mission-critical issues like bug fixes and usability standards.
03/15/2013 (3:58 pm)
As an artist and a weak developer, I can honestly say I'm no longer interested in T2D without an Editor, even if it's free. I simply don't want to spend the time to get ramped up to working mostly in a text editor. I'm still using TGB, so I'm not upset with GG or anything -I just wish to stay with the version that has the visual development component.I'm sure it's great and powerful and clean, but I HATE working blindly.
I say the "quick solution" is a trap - the people like me who need the editor will come back when there's a good editor (free means I can come back when I want to). The people who don't need the editor can work without it for the time it takes to implement.
My vote is to take the "correct road", even if it means we don't see an editor for a year. Focus on mission-critical issues like bug fixes and usability standards.
#17
you can use something like:
Berkelium
http://berkelium.org/
Chromium Embedded
https://code.google.com/p/chromiumembedded/
03/15/2013 (4:18 pm)
I am in no position to give any advice/tips couse I don't know that much about QT or TorqueScripts but have you taken htlml 5 into consideration?you can use something like:
Berkelium
http://berkelium.org/
Chromium Embedded
https://code.google.com/p/chromiumembedded/
#18
Awe man, what is the problem with wxWidgets? I use it all the time for other projects. Am I missing something?
One question about the editor: Why would it need to be part of the same program anymore? You seem to have the live update feature working just fine. So the editor could be an entirely separate process developed using just about anything. So the external program might just need to signal the game engine that something has changed. Perhaps through network message? Debugger could be integrated like Torsion debugger too.
Edit:
Another thought, if the editor were able to connect remotely it could help with debugging and such. I know, I know, a debugger is feature creep. I will shut up now...
03/15/2013 (4:29 pm)
@Michael,Awe man, what is the problem with wxWidgets? I use it all the time for other projects. Am I missing something?
One question about the editor: Why would it need to be part of the same program anymore? You seem to have the live update feature working just fine. So the editor could be an entirely separate process developed using just about anything. So the external program might just need to signal the game engine that something has changed. Perhaps through network message? Debugger could be integrated like Torsion debugger too.
Edit:
Another thought, if the editor were able to connect remotely it could help with debugging and such. I know, I know, a debugger is feature creep. I will shut up now...
#19
For example, the Torque GUI/script route could bring an overhaul to the GUI and font systems, which would no doubt be very beneficial for our games on top of the productivity benefits from a visual editor.
What about all the work you did on 3SS? Is there something from that project that could be modified to use as a general editor, even as an interim solution if the Qt route means nothing substantial editor wise for over a year? Note I am not implying that you just release that code to the community - if you felt the effort to rejig 3SS into a paid product was worth it, that is fine.
03/15/2013 (4:31 pm)
I don't mind going down the Qt route if that is the best long term solution. Would that work bring any improvements that can be used within games or is it mostly to get the best external editor solution?For example, the Torque GUI/script route could bring an overhaul to the GUI and font systems, which would no doubt be very beneficial for our games on top of the productivity benefits from a visual editor.
What about all the work you did on 3SS? Is there something from that project that could be modified to use as a general editor, even as an interim solution if the Qt route means nothing substantial editor wise for over a year? Note I am not implying that you just release that code to the community - if you felt the effort to rejig 3SS into a paid product was worth it, that is fine.
#20
@Bolohan - You certainly are not the first person to suggest HTML5. I'm working on another project right now that exports solely to HTML5 and I'm loving it.
@Frank - It was mainly our own preference to eliminate wxWidgets from the list. It just does not stack up to Qt in our opinion. We also have more in house knowledge of Qt.
@Mike - Using an external application like Qt will force us to refactor some of the T2D architecture, but in a beneficial way. Like it was stated in the blog, we would need to change T2D's rendering to be more like GFX (in T3D). Aside from getting support for external applications, this would better prime the engine to move to other platforms like Android or Linux.
As for 3SS, I would consider all that work "lost." The tools were written specifically for a target audience, which unfortunately killed any reusability for a professional user group. In other words, I would not pull any of the 3SS editors over to a T2D project.
03/15/2013 (5:09 pm)
@All - By the way, I will be responding as much as I can. However, feel free to engage each other in the discussion. Talk to each other about the comments to try and dig up a solution. That's the point of this blog. We are trying to find a solution and it's everyone's job to help with that.@Bolohan - You certainly are not the first person to suggest HTML5. I'm working on another project right now that exports solely to HTML5 and I'm loving it.
@Frank - It was mainly our own preference to eliminate wxWidgets from the list. It just does not stack up to Qt in our opinion. We also have more in house knowledge of Qt.
Quote:Why would it need to be part of the same program anymore?It doesn't have to be. That would be the point of going with Qt or another 3rd party option. The editor shell would simply load plugins that could do whatever the user wanted. It would not run a full T2D simulation, like the previous TGB and T3D editors.
@Mike - Using an external application like Qt will force us to refactor some of the T2D architecture, but in a beneficial way. Like it was stated in the blog, we would need to change T2D's rendering to be more like GFX (in T3D). Aside from getting support for external applications, this would better prime the engine to move to other platforms like Android or Linux.
As for 3SS, I would consider all that work "lost." The tools were written specifically for a target audience, which unfortunately killed any reusability for a professional user group. In other words, I would not pull any of the 3SS editors over to a T2D project.
Torque Owner Doc308
I like the idea of a shell, but what about a separate program entirely. After all, the bulk of what is needed would be general level creation (importing images, etc.. etc..) and then exporting that data to .taml
Of course there's a lot more to it than that, and maybe it does need more of a backbone that T2D supplies.
Just tossing out an idea, maybe others with better knowledge of editors could contribute moreso, either way, it's great to have GG lending a hand, but not doing everything, because.. well, you've got other commitments, and it truly is a community project, just needs a helping hand for guidance is all.