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
#2
04/04/2013 (2:49 pm)
@Daniel - The idea is that developers would create plug-ins that feed into the editor shell. So I could create a plug-in that allows you to edit XML files, whereas you could write a plugin that acts as a level editor. A user could choose what plug-ins to load up while they are editing, customizing their own development environment. 
#3
04/04/2013 (3:44 pm)
I beleive the approach outlined makes a great deal of sense. Having GarageGames support is a blessing so many people don't seem to grasp completely. Based on the familiarity of the products, it does make the most sensible solution to start this path. If other feel up to the challenge of tasking HTML 5 or Engine editors, then all the power to them as well! I just hope more people step up to make this task easier overall.
#4
This sounds great. I can already think of some uses for the editor itself even as a separate 3rd party app. I am thinking of authoring systems for specific industries.
Thanks
04/04/2013 (6:12 pm)
@Michael,This sounds great. I can already think of some uses for the editor itself even as a separate 3rd party app. I am thinking of authoring systems for specific industries.
Thanks
#5
04/04/2013 (7:18 pm)
It looks like the best way to do it (and this is similar to what I've thought of on my own). Plugins would just register with a category and title to display in a menu, for example, and if the editor is purely project-based a tab for each plugin would also make sense.
#6
04/04/2013 (7:49 pm)
Also, it should allow identical instances of each plugin. That way you can run 2 or more instances of a plugin including the game itself. It could make for some excellent game to game debugging/development. 
#7
As far as I understand it, the editor 'shell' will basically be a form of project manager, while the plugins will implement specific editing abilities, right?
I'm thinking about existing plugin systems. I'm not familiar with many - GIMP and Blender come to mind. GIMP plugins seem to be executable files - I've never understood how they can be cross-platform - while Blender plugins are just Python scripts, which makes a lot of sense since Blender is written in Python. In both cases, you simply drop the plugin into a blessed directory. In GIMP's case, that directory may be in user data, whereas I think Blender plugins must be in the program directory.
04/04/2013 (10:43 pm)
Sounds like some way of choosing which plugins handle which filetypes might be useful. Also: what is the smallest possible plugin that can be created? Can users add a single button to a toolbar somewhere? Contrariwise, what's the largest possible plugin? I think you've answered this already - an entire level editor, for example - but I think we need to ask the question.As far as I understand it, the editor 'shell' will basically be a form of project manager, while the plugins will implement specific editing abilities, right?
I'm thinking about existing plugin systems. I'm not familiar with many - GIMP and Blender come to mind. GIMP plugins seem to be executable files - I've never understood how they can be cross-platform - while Blender plugins are just Python scripts, which makes a lot of sense since Blender is written in Python. In both cases, you simply drop the plugin into a blessed directory. In GIMP's case, that directory may be in user data, whereas I think Blender plugins must be in the program directory.
#8
04/04/2013 (11:46 pm)
Something like ECMA script (Javascript) in the editor would be nice. It can compile to machine code so you are not running slow like Python or other languages for complex tools. Then for big stuff a full blown plugin for binaries. 
#9
04/05/2013 (1:01 am)
I think this is the best way to go.Quote:get your coding boots on :-D
I'd honestly like to get started on the editor shell next week.
#10
@Daniel -
For example, should there even be a concept of a "project manager"? Should the editor just load module definitions? If there is a new "project file system", shouldn't that be a plug-in instead of the shell?
My own answers would be, yes I believe a "project manager" would be useful. I think it should be a plug-in, since I could create a project scheme that works well for some, whereas another person can create a better project manager plug-in. Then, a user is free to pick the one they like and load it.
As for what the plug-in should handle, I believe it would be responsible for adding an entry into a file manager, providing the GUI elements, and handling all the logic. The shell really is just that.
@Demolishun - Agree. That could result in having a standard for plug-ins. For example, a plug-in must be able to have multiple instances. A plug-in must always get added to the file-menu. Etc.
04/05/2013 (5:00 am)
Great feedback so far everyone. Keep it coming.@Daniel -
Quote:Also: what is the smallest possible plugin that can be created? Can users add a single button to a toolbar somewhere? Contrariwise, what's the largest possible plugin? I think you've answered this already - an entire level editor, for example - but I think we need to ask the question.The final answer to your question will be based on the design work. You all are going to be reviewing the designs, code, and results. This is your chance to say "I think it should have". That doesn't mean everything can make it in. I'm speaking of the shell and plug-in capabilities.
For example, should there even be a concept of a "project manager"? Should the editor just load module definitions? If there is a new "project file system", shouldn't that be a plug-in instead of the shell?
My own answers would be, yes I believe a "project manager" would be useful. I think it should be a plug-in, since I could create a project scheme that works well for some, whereas another person can create a better project manager plug-in. Then, a user is free to pick the one they like and load it.
As for what the plug-in should handle, I believe it would be responsible for adding an entry into a file manager, providing the GUI elements, and handling all the logic. The shell really is just that.
@Demolishun - Agree. That could result in having a standard for plug-ins. For example, a plug-in must be able to have multiple instances. A plug-in must always get added to the file-menu. Etc.
#11
04/05/2013 (7:27 am)
Great layout! I think the separate-application-approach is a great idea. 
#12
04/05/2013 (12:38 pm)
I think the idea of a separate application is great, but I think it should still have access to most of the internals of the T2D engine, for things like particle editors and physics tools, where it is useful to see them in their own blank window rather than in a live game environment, while still ensuring that what you see is what you get. Otherwise you will either have a situation where the editor functionality starts creeping into the game again, or you end up with a major maintenance headache trying to keep the plugins up to date with any engine changes.
#13
If the edits you are making in the Qt application can be easily shown in a T2D simulation, then it really shouldn't matter where that simulation is running. A separate application would be the same as something embedded in the editor shell. I don't think the shell should care about the guts of T2D at all. All it's doing is loading plugins and presenting them.
And there is NO WAY any editor functionality would be going into the engine itself. There's no reason and there would be no convincing argument for it. The whole point is to get away from having editor functionality in T2D, which is why we aren't using the Torque GUI or TorqueScript.
04/05/2013 (12:44 pm)
@Gerald - I can't say that I fully agree with you on some of those statements. Later down the road, someone can create a plug-in that might run a T2D simulation, which can then provide the experience you are talking about. Honestly, though, the editor is just supposed to create data. That's all it needs to do at the core. The things that are nice to have are visualization and communication with a simulation.If the edits you are making in the Qt application can be easily shown in a T2D simulation, then it really shouldn't matter where that simulation is running. A separate application would be the same as something embedded in the editor shell. I don't think the shell should care about the guts of T2D at all. All it's doing is loading plugins and presenting them.
And there is NO WAY any editor functionality would be going into the engine itself. There's no reason and there would be no convincing argument for it. The whole point is to get away from having editor functionality in T2D, which is why we aren't using the Torque GUI or TorqueScript.
#14
Oh. Personal request: I'd really like to be able to use external editors for text editing where that needs to happen. I've taken to using gVim for pretty much all my text editing needs, and I've even integrated it into Visual Studio so that VS just becomes a file list and a compiler.
04/05/2013 (3:00 pm)
I guess I was sort of trying to figure out what the editor shell would do other than load plugins... what are its responsibilities? Does it provide some sort of API working with T2D-related stuff? If it's just a plugin loader... well, I mean that's cool, but it seems to put a larger burden on a plugin developer.Oh. Personal request: I'd really like to be able to use external editors for text editing where that needs to happen. I've taken to using gVim for pretty much all my text editing needs, and I've even integrated it into Visual Studio so that VS just becomes a file list and a compiler.
#15
Editor Shell: Base Qt application. Responsible for detecting, loading, unloading, and tracking modules. It will update it's interface, such as the file menu, based on messages from a plug-in. A few default widgets, both stock and Torque specific, will be provided. It will likely be responsible for a bridge or messaging system between itself and a running instance of Torque 2D.
Plug-in: Responsible for the majority of the logic. Data editing, main GUI, scripts, and so on. Pretty much everyone will be focused on creating and maintaining the plug-ins. Yes, the majority of the real work is on the plug-in developer, but there will be some help from the shell.
04/05/2013 (5:13 pm)
Without getting into a lot of Qt specific tech talk, here's the general idea:Editor Shell: Base Qt application. Responsible for detecting, loading, unloading, and tracking modules. It will update it's interface, such as the file menu, based on messages from a plug-in. A few default widgets, both stock and Torque specific, will be provided. It will likely be responsible for a bridge or messaging system between itself and a running instance of Torque 2D.
Plug-in: Responsible for the majority of the logic. Data editing, main GUI, scripts, and so on. Pretty much everyone will be focused on creating and maintaining the plug-ins. Yes, the majority of the real work is on the plug-in developer, but there will be some help from the shell.
Quote:I'd really like to be able to use external editors for text editing where that needs to happen.I'm not sure what you are getting at here. You can already do that and nothing about the editors will really change that. You can create an ImageAsset right now, without anything related to this topic. Same with the rest of the data and logic that is fed into a T2D game.
#16
04/05/2013 (6:01 pm)
A setting in the prefs to launch external editors for select datatypes would be a good idea too. First release would probably be all about external tools :)
#17
04/05/2013 (7:29 pm)
Mich: I meant what Ronny said. Being able to associate filetypes with external apps, or even specific plugins. So, for example, if I have a filetree for my project, TAML files open with an asset editor plugin, but TS files open with Notepad++ (or gVim in my case). And then supporting whatever hooks need to happen for the editor to update when those files are change outside the editor, and so on. 
#18
Your point about particle editors is a valid one. Its actually something that we've specifically discussed. For cases like that, we should be able to view specific particles in T2D without loading the whole level/game. In other words, as you edit your particles in the editor you see those changes in the T2D window. Not sure what you mean with respect to physics tools.
04/05/2013 (8:39 pm)
@Gerald:Your point about particle editors is a valid one. Its actually something that we've specifically discussed. For cases like that, we should be able to view specific particles in T2D without loading the whole level/game. In other words, as you edit your particles in the editor you see those changes in the T2D window. Not sure what you mean with respect to physics tools.
#19
1) character assembly folder / behavior folder. took base object(player body) from editor and created arms and legs in torque script, mounted everything together in simulation using behaviors and collisions. Completed this part.
2) orionally planned for level asset GUI interface in separate game to design and export maps.
3) planned for a separate level to handle changing character body types.
I run into a problem if I was to create fields on one level and wanted to load the prefs into another object on another level.
The old editor does not execute any Torque script.
There should be a onOpenLevel command that executes Assembly scripts from a pull down list, that can be toggled.
I would like be able to assemble my characters or load game objects in the new editor that would otherwise be created later in a simulation,, so i can see if they load and mount correctly if I reload the project in the editor. Any new objects should be flagged and not writable to level file.
04/06/2013 (8:11 am)
The way I set up my system of project management in old editor is as follows:1) character assembly folder / behavior folder. took base object(player body) from editor and created arms and legs in torque script, mounted everything together in simulation using behaviors and collisions. Completed this part.
2) orionally planned for level asset GUI interface in separate game to design and export maps.
3) planned for a separate level to handle changing character body types.
I run into a problem if I was to create fields on one level and wanted to load the prefs into another object on another level.
The old editor does not execute any Torque script.
There should be a onOpenLevel command that executes Assembly scripts from a pull down list, that can be toggled.
I would like be able to assemble my characters or load game objects in the new editor that would otherwise be created later in a simulation,, so i can see if they load and mount correctly if I reload the project in the editor. Any new objects should be flagged and not writable to level file.
#20
On a side note, I'm amazed at how fast things are progressing since T2D has gone open source... and loving it!
04/06/2013 (12:05 pm)
I like the plan... live updating (or push button) would be a huge productivity gain! I can't tell you how many times I have to create a new gui profile, then restart T2D just for it to recognize the profile and then restart the application as many times as I make changes to see the changes. Very time consuming.On a side note, I'm amazed at how fast things are progressing since T2D has gone open source... and loving it!
Torque Owner Daniel Buckmaster
T3D Steering Committee
Honestly, having a separate application sounds like a fine way to go. Live updating would be a fantastic way to work with it. Is the intent that the included editor features be plugins like any other third-party editor mode? Or would third-party plugins be plugged into the base editor?