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.
#102
03/22/2013 (7:56 pm)
You could do a lot with web sockets in terms of remote debugging work. Not perfect, but definitely workable (and what's really perfect)?
#103
We are talking about plugins and stuff here. So does that paradigm translate well to the main three architectures (Windows, Mac, Linux)?
03/23/2013 (12:18 am)
Quote:You'd be writing any custom c++ game code to a plugin, recompile, and reload the plugin.I was kind of thinking the game engine is a plugin at that point, but I see what you are saying.
Quote:(and what's really perfect)?Other than you, not much else. :)
We are talking about plugins and stuff here. So does that paradigm translate well to the main three architectures (Windows, Mac, Linux)?
#104
03/23/2013 (7:32 am)
All three of those OSes can load dynamic modules, so yes. Check out the professional T2D forum. There is a post there about getting a plugin system going in T2D.
#105
03/23/2013 (1:31 pm)
Is it possible to make the shell program work with T3D as well?
#106
03/23/2013 (2:52 pm)
Technically, T3D is closer to being ready to run in a shell than T2D. T3D's rendering architecture makes it easier to isolate it and run it in a 3rd party application. T2D has the edge in the persistence and modularity systems, thanks to TAML and our module system. It would be possible, to create something that could work for T2D and T3D, but that would require a bit more time and resources.
#107
That is what I was thinking. T2D needs to be adjusted to work as a DLL (in Windows) and have the functions split out so it can be controlled via an external process. I think the effort to make it a plugin for the shell could also be used to make T2D embeddable in a browser just like T3D. I was going to start working on that for my Python stuff. I just have not gotten around to doing that. This would allow hooks into the interpreter just like T3D has. Hmmm... this could help both (T3D and T2D) projects in more ways than just making a shell. It could have ramifications for web plugin support too.
Does anyone have any pointers on turning T2D into a loadable object file in a cross platform portable way? Is the T3D way of doing this cross platform?
03/23/2013 (4:06 pm)
@Michael,That is what I was thinking. T2D needs to be adjusted to work as a DLL (in Windows) and have the functions split out so it can be controlled via an external process. I think the effort to make it a plugin for the shell could also be used to make T2D embeddable in a browser just like T3D. I was going to start working on that for my Python stuff. I just have not gotten around to doing that. This would allow hooks into the interpreter just like T3D has. Hmmm... this could help both (T3D and T2D) projects in more ways than just making a shell. It could have ramifications for web plugin support too.
Does anyone have any pointers on turning T2D into a loadable object file in a cross platform portable way? Is the T3D way of doing this cross platform?
#108
I'm giving everyone a chance to debate a little further, because I'm coming close to what I think will be the best solution for creating editors for T2D MIT.
03/23/2013 (4:26 pm)
Working as a DLL is not the problem. I compiled it into a library in the past. The main hurdle is the rendering architecture. The engine needs a multi-window system with the capability of rendering to multiple surface, much like T3D. That's the main problem.I'm giving everyone a chance to debate a little further, because I'm coming close to what I think will be the best solution for creating editors for T2D MIT.
#109
You will have to fill in the dots here. I don't understand how that is a problem for an editor plugin. Is this because it hogs the HWIN ref and does not play nice with other event systems? I know the T3D plugin does some stuff for events. I am just not understanding how the rendering pipeline plays into this.
03/24/2013 (5:06 pm)
@Michael,You will have to fill in the dots here. I don't understand how that is a problem for an editor plugin. Is this because it hogs the HWIN ref and does not play nice with other event systems? I know the T3D plugin does some stuff for events. I am just not understanding how the rendering pipeline plays into this.
#110
Also I worked on a Scene Editor. This allows you to import images and data to your game, and place them on screen. Then of course, you would handle when these images would appear and how in the main script window.
And it goes from there... Input and output of script files. Then how you present it to the user is the question. Like if you import an object and set its position to something, just create a script file with a prewritten function including the variables the user set in the Scene Editor or whatever.
Upon compile, I just merge the executable (binary) version of Love2D with it's zip containing the data. This makes it easier for the user to make standalone builds of their game in the editor.
Sorry for long post.
Sincerely,
03/27/2013 (2:01 pm)
The only input I can add to this is when I started working on Lovely Engine. It is a game engine based on libraries from Love2D. What I had was simply put one project window, for settings like game title, resolution, debug logging etc. What I have more is a script editor, which is pretty much the core of the engine. All is based on scripts pretty much.Also I worked on a Scene Editor. This allows you to import images and data to your game, and place them on screen. Then of course, you would handle when these images would appear and how in the main script window.
And it goes from there... Input and output of script files. Then how you present it to the user is the question. Like if you import an object and set its position to something, just create a script file with a prewritten function including the variables the user set in the Scene Editor or whatever.
Upon compile, I just merge the executable (binary) version of Love2D with it's zip containing the data. This makes it easier for the user to make standalone builds of their game in the editor.
Sorry for long post.
Sincerely,
#111
The best way to go about it is to first separate the script engine from the game engine and all other parts to be modular. You cant just go on adding/modifying/improving fused up systems.
If currently T2D and its components are non-malleable then its good to separate them as components. By doing this, it will possible for people to create editors as plug-ins. You will be surprised that various plug-ins will spring if the plug-in interface is well documented with simple down to earth examples. We may even see modeler, image editors and other libraries being developed/ported to work with T2D.
QT or wxWidget or not! All tools will reached there limitations as per what T2D needs to be able to go further from here.
What you may not want is to see various clones of T2D being thrown about over the internet as we have for Linux but T2D is on the git-hub now in the wild so expect that to happen. Editors, Language bindings, SWIG interfaces, FFI and more platforms ports, etc.. will happen as more awareness of the engines are known to people.
Break the T2D engines into its constituents components, documents its plug-in interfaces with simple how-to examples and it will open up ideas since it will be much more easier to tackle.
God blesses!!!
Best regards,
Sanyaade
03/29/2013 (5:16 pm)
@T2D,The best way to go about it is to first separate the script engine from the game engine and all other parts to be modular. You cant just go on adding/modifying/improving fused up systems.
If currently T2D and its components are non-malleable then its good to separate them as components. By doing this, it will possible for people to create editors as plug-ins. You will be surprised that various plug-ins will spring if the plug-in interface is well documented with simple down to earth examples. We may even see modeler, image editors and other libraries being developed/ported to work with T2D.
QT or wxWidget or not! All tools will reached there limitations as per what T2D needs to be able to go further from here.
What you may not want is to see various clones of T2D being thrown about over the internet as we have for Linux but T2D is on the git-hub now in the wild so expect that to happen. Editors, Language bindings, SWIG interfaces, FFI and more platforms ports, etc.. will happen as more awareness of the engines are known to people.
Break the T2D engines into its constituents components, documents its plug-in interfaces with simple how-to examples and it will open up ideas since it will be much more easier to tackle.
God blesses!!!
Best regards,
Sanyaade
#112
04/04/2013 (2:45 pm)
Ok, here's my plan: Editor Proposal. Please weigh in there and let me know what you think.
#113
05/15/2014 (7:23 am)
My work on editors for T2D MIT 3.0 has begun. This is a personal project, not affiliated with Garagegames or the Steering Committee. 
Torque Owner William Hilke
You'd be writing any custom c++ game code to a plugin, recompile, and reload the plugin.