Torque 2D Editor Plan
by Michael Perry · 04/04/2013 (1:50 pm) · 41 comments
Editor Plan of Action
Greetings everyone! Welcome back to another Torque 2D blog. I originally had a slew of topics and announcements to cover in this blog, such as our new branches, new tutorials, and R&D work. However, trying to jam that all together with this main topic was just too much.
I'll cover all the new goodies in my next blog. For now, I want to make sure a very important perspective is maintained during your read...
IMPORTANT NOTE: The content in this blog is my own proposal. I believe it is the best route to take, but I do not have the power to make the final decision. Nor do I want that power. This is the plan I believe will have the greatest success, so this is your opportunity to say "Go for it!" or "Please reconsider because of ____".
Editor Tech Choice
In the Editor Collaboration blog, we discussed the following options:- TorqueScript, etc
- Qt with T2D embedded
- Editor as a separate application
- HTML 5
- Python
- And more...
If you disagree with this approach, now is definitely the time to speak up.
Initial Editor Work
It's really simple. Design first, develop after. Excluding experimentation and tutorial work, no actual coding should occur until we have designed the following:1. What is the editor shell?
2. What is a plug-in?
3. What is the plug-in system?
After the designs are ready and planning is complete, the development of the shell and plug-in system will commence. Once the shell is up and running, all of us in the T2D open source community will be able to create our own editor plugins, which can be open source themselves, or sold in our store (or on your own site).
Of course, we on the steering committee and at GarageGames will ensure that the necessary basic set of editing tools are included as part of the open source code base. In the end, the editor should be producing data. For example, an XML editor that uses the Torque 2D schema is the a solid start. That plug-in alone can produce all the data needed to create assets, scenes, and other T2D stuff. From there, it's a matter of vocalizing what plug-ins we will be working on so that others can proceed on their own accord.
However, we anticipate (and will encourage) developers to create specialized editors (for RPGs, RTSs, or other genres). We can’t (and don’t want to) control how community plugins are distributed. So if you want to sell them or give them away for free, it will be up to you. I believe this approach can result in having a solid foundation sooner, rather than later. That opens the door up for everyone to start creating plug-ins, making 2013 the year of editor support for Torque 2D.
I hope you are as excited about that potential as I am. Now, what can be done in the short term?
Parallel Development
Depending on who is working on the editor shell and plug-in system, it's going to be a little while before we have something in a polished state. I'm more than likely going to create an entirely separate repository for this project. This does not mean work is going to stop in the core Torque 2D repositories.While the editor work is happening, we will continue to fix bugs. More importantly, we will be adding support for 3rd party tools that will make development easier for artists, designers, and newcomers. Examples include, TexturePacker, Zwoptex, Tiled, Spine, Spriter, PhysicsEditor, and more. Supporting these tools will dramatically reduce the amount of hand coding required to create assets for T2D.
Until Next Time...
Alright everyone, I don't want to overload you all too much. I'll pause here so you can start asking questions and poking holes in my proposal. I'd honestly like to get started on the editor shell next week. The parallel development for 3rd party tool support has already begun, so the wheels are turning. So let's stop delaying, agree on a plan...hopefully mine :) ... and get to work.Regards,
Mich
About the author
Programmer.
#22
04/07/2013 (6:02 am)
@Demolishun - Thanks for the post. Everyone knows me as Mich, so we can keep that trend going. I'm happy to hear you want to volunteer. Shoot me an e-mail (address is my profile). 
#23
Don't get me wrong I don't think the chosen approach is a bad one, I just think in the long run it could have lead to greater improvements to TorqueGUI/TorqueScript/T2D as a whole.
04/07/2013 (1:50 pm)
If I'm honest I was hoping for the TorqueGUI/TorqueScript route as it would have meant the TorqueGUI would have got some much needed attention and no doubt would have led to many other direct improvements to T2D as a side effect of the work.Don't get me wrong I don't think the chosen approach is a bad one, I just think in the long run it could have lead to greater improvements to TorqueGUI/TorqueScript/T2D as a whole.
#24
04/08/2013 (4:20 am)
Design first, develop after. is really an amazing idea,there're many designers do not have to power to bring their idea to real game,but with the help of TGB,it's getting better,i hope that this editor plan can go on well 
#25
04/08/2013 (4:36 am)
As a plan, sounds fine. Definitely needs a few more details (such as language support [multiple hopefully] for example). Hopefully I can help out (my day job is part graphics developer, part tools developer [strange hybrid I know]), so look forward to seeing plans and further discussion. 
#26
04/08/2013 (9:01 am)
Will there be a "test scene" button like there was before? 
#27
@Mich: Since the idea is to keep T2D in it's own process, should we expand on the socket debugging system in Torque to add a command/control API? With a remote control API we could have the T2D instance load/reload script files, and that alone is powerful enough to let an editor plugin display whatever they want in the rendering process.
A particle effects editor would just write some script glue to a file on disk, and command the rendering process to execute that. That script would just load a basic scene with the particle effect. Any changes would flush to disk, and command the rendering process to reload it (hence seeing changes in real time). Editors could use separate T2D processes, or possibly share a process.
I don't see a reason why we need an explicit *update* button in the editor. Let the plugin's determine when it needs to update the remote process.
Using the TCP socket layer already in T2D would allow the command/control API to stay platform agnostic.
04/08/2013 (9:13 am)
@Martin: It's been said several times already, but the GUI within T2D is never going to be up to par with a real GUI framework like Qt. They are for different goals, and it's better to use a full fledged GUI framework for an application that will probably need that power.@Mich: Since the idea is to keep T2D in it's own process, should we expand on the socket debugging system in Torque to add a command/control API? With a remote control API we could have the T2D instance load/reload script files, and that alone is powerful enough to let an editor plugin display whatever they want in the rendering process.
A particle effects editor would just write some script glue to a file on disk, and command the rendering process to execute that. That script would just load a basic scene with the particle effect. Any changes would flush to disk, and command the rendering process to reload it (hence seeing changes in real time). Editors could use separate T2D processes, or possibly share a process.
I don't see a reason why we need an explicit *update* button in the editor. Let the plugin's determine when it needs to update the remote process.
Using the TCP socket layer already in T2D would allow the command/control API to stay platform agnostic.
#28
04/08/2013 (9:14 am)
@Jackrabbit: That would be up to a specific plugin. The editor framework itself would probably not know what a *scene* is.
#29
@William -
Absolutely. I think that will be very important in the usage case of someone modifying an ImageAsset in the editor, then pushing a button to tell the running instance of T2D to refresh that asset, or all assets.
There's a simpler solution. Simply have T2D running, with a module loaded that simply displays particle effects. When the engine is told to refresh assets, the ParticlePlayer will automatically reload its asset in real time and no further work would be needed. Some kind of script glueing could be useful for other stuff, though.
04/08/2013 (9:24 am)
@Martin - What William said. To add on, this work does not mean the Torque GUI can't be improved. Anyone can take a stab at improving the GUI system. Nathan Sweet, from the Spine team, has suggested we look into integrating scene2d from libgdx as an option for T2D's GUI system. Just an example.@William -
Quote:Since the idea is to keep T2D in it's own process, should we expand on the socket debugging system in Torque to add a command/control API? With a remote control API we could have the T2D instance load/reload script files, and that alone is powerful enough to let an editor plugin display whatever they want in the rendering process.
Absolutely. I think that will be very important in the usage case of someone modifying an ImageAsset in the editor, then pushing a button to tell the running instance of T2D to refresh that asset, or all assets.
Quote:A particle effects editor would just write some script glue to a file on disk, and command the rendering process to execute that. That script would just load a basic scene with the particle effect
There's a simpler solution. Simply have T2D running, with a module loaded that simply displays particle effects. When the engine is told to refresh assets, the ParticlePlayer will automatically reload its asset in real time and no further work would be needed. Some kind of script glueing could be useful for other stuff, though.
Quote:I don't see a reason why we need an explicit *update* button in the editor. Let the plugin's determine when it needs to update the remote process.Agreed. The plug-in will add buttons and file menu options that can signal the running instance of T2D to do something. I want the editor shell to be lean and mean.
Quote:Using the TCP socket layer already in T2D would allow the command/control API to stay platform agnostic.Also agreed, but some work needs to go into testing the system on all currently supported platforms. For example, I think the iOS and OS X platforms need thorough testing and fixes.
#30
04/09/2013 (12:34 pm)
Oh, one other thing. I really like the tilemap system in TGB. If possible, please keep that in perspective? 
#31
04/09/2013 (12:36 pm)
@Michael - so it sounds like if somebody has a particle editor, a physics editor, an animation editor, an effect editor... they will either need to have 4 copies of the T2D engine loaded into the editor at once, 4 instances of T2D running alongside the application at once (and be able to figure out how to communicate with the right one), have to wait for one instance of T2D to shut down and another one to open when switching between plugins, reinvent all of the rendering, animation, physics, effects code and hope it matches up with T2D, or just not be able to visually isolate any of the objects they want to work on and edit everything in the live game environment, with the editor just being a glorified text and property editor?
#32
@Gerald - I think we got our communication streams mixed up. I haven't really talked about multiple instances of Torque 2D or anything. I haven't even gotten to the part about what it would take to modify T2D's architecture to run as a plug-in in the editor shell.
Plug-ins which produce data are editors. I could have a plug-in that creates an AnimationAsset and saves it out to a file. It can pick an ImageAsset, set properties, and assign animation cells. That's an animation editor, since it creates data that can be used by a Sprite. At a minimum, you only need to see the text that drives the data. At any point, you can see more visualization inside of a Torque 2D application running completely separate from the editor.
What you are talking about is advanced visualization inside of the editor, which can be approached from multiple angles. I do not need a running instance of Torque 2D to show what an ImageAsset would look like. I can write that from scratch in Qt. I could even use another library for showing image cells.
But, should someone want to show what the ImageAsset would look like in Torque 2D, without running Torque 2D as a separate application, they would need to create a plug-in that would run an instance of Torque 2D inside of the shell. The current engine architecture would run full instances of Torque 2D, which is a bad thing. That's what you are talking about. If someone wants to write a plug-in that uses actual T2D systems, work need to be put into making T2D more flexible. I talked about that in my last blog.
That's all getting ahead of ourselves, though. I'll be posting some more thorough write-ups on what how the tech for the editor shell and plug-in system will progress.
04/09/2013 (12:56 pm)
@Anonymous - Have you looked at the Composite system in T2D MIT? I think it does a much better job than the old TGB tilemap system.@Gerald - I think we got our communication streams mixed up. I haven't really talked about multiple instances of Torque 2D or anything. I haven't even gotten to the part about what it would take to modify T2D's architecture to run as a plug-in in the editor shell.
Plug-ins which produce data are editors. I could have a plug-in that creates an AnimationAsset and saves it out to a file. It can pick an ImageAsset, set properties, and assign animation cells. That's an animation editor, since it creates data that can be used by a Sprite. At a minimum, you only need to see the text that drives the data. At any point, you can see more visualization inside of a Torque 2D application running completely separate from the editor.
What you are talking about is advanced visualization inside of the editor, which can be approached from multiple angles. I do not need a running instance of Torque 2D to show what an ImageAsset would look like. I can write that from scratch in Qt. I could even use another library for showing image cells.
But, should someone want to show what the ImageAsset would look like in Torque 2D, without running Torque 2D as a separate application, they would need to create a plug-in that would run an instance of Torque 2D inside of the shell. The current engine architecture would run full instances of Torque 2D, which is a bad thing. That's what you are talking about. If someone wants to write a plug-in that uses actual T2D systems, work need to be put into making T2D more flexible. I talked about that in my last blog.
That's all getting ahead of ourselves, though. I'll be posting some more thorough write-ups on what how the tech for the editor shell and plug-in system will progress.
#33
04/09/2013 (7:18 pm)
@Michael - Fair enough. Yes, T2D will need some serious refactoring to be flexible enough to be leveraged by plugins in an editor in any meaningful way, but I think that will really be essential to creating an editor suite that is a valid replacement and enhancement over the old in-game editor systems. If the editor plugin framework does not expose the engine, then refactoring the engine into a DLL with an API that can be accessed by the plugins would be the next best thing I think.
#34
04/10/2013 (5:54 am)
@Gerald - Sounds like we are getting on the same page now =)Quote:If the editor plugin framework does not expose the engine, then refactoring the engine into a DLL with an API that can be accessed by the plugins would be the next best thing I think.This statement is one in the same. It has to be refactored to work in the plug-in system. The editor shell should not have anything to do with Torque 2D or data editing. Again, it needs to be lean and clean. The editor shell will likely be open source, like Torque 2D, which means people will be free to create their own version. I just want to stress how important it is for developers to think of the plug-ins as the driving force of functionality. So if you want to see Torque 2D in the new editor, it will need to be loaded through a plug-in.
#35
The editor needs to expose some type of integration that plug-ins can use without trying to come up with their own system. that integration doesn't have to mean hosting a full T2D instance within the editor, but we need something.
I think the idea of being able to launch a T2D instance, and then connecting/controlling it via the TCP debugging socket is a route that gives the editor plenty of power, but isn't too difficult to get working in the engine. Each plugin can control its own T2D instance, which basically gives every plugin a T2D window external to the editor.
04/10/2013 (12:44 pm)
@Mich, If you want an editor suite to really have any chance, it is going to need some type of T2D integration. Having an editor that is nothing more then just a plug-in host isn't going to be very useful. Leaving T2D integration up to plug-in authors is also going to leave us with a dozen different ways of integrating.The editor needs to expose some type of integration that plug-ins can use without trying to come up with their own system. that integration doesn't have to mean hosting a full T2D instance within the editor, but we need something.
I think the idea of being able to launch a T2D instance, and then connecting/controlling it via the TCP debugging socket is a route that gives the editor plenty of power, but isn't too difficult to get working in the engine. Each plugin can control its own T2D instance, which basically gives every plugin a T2D window external to the editor.
#36
04/13/2013 (4:11 pm)
Looks good. I have no problem with the editor being a separate app.
#37
04/20/2013 (5:44 am)
Hello Micheal, did you post some infomations about editor? it was started or not? :)
#38
04/20/2013 (5:54 am)
@KevinYuen - The bulk of my work has been working through Qt tutorials, reading the Qt API documentation, and writing my down my ideas about the shell and plugin system. When I can collect it all into a cohesive document, I will be posting it online for everyone to collaborate on.
#39
06/17/2013 (6:49 am)
@Michael - I suggest that the editor can give a framework, so that we can develop it together. :). After all, the engine frame current may have some changes. 
Torque Owner Demolishun
DemolishunConsulting Rocks!
I am really liking this. I can see this being generic enough to help T3D as well. In addition I like the idea of multiple instances of T2D (example): one for a game level, one of a particle, and one for a character. You can literally test out the particle in one window, then decide to test with the level, and also see how it might work attached to the character. All without having to restart anything. If the T2D instances are separate processes then it won't take down the editor and other instances. This is very clever!
I am mostly doing T3D stuff right now, but now I want to help out with this editor!