Game Development Community

dev|Pro Game Development Curriculum

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
#81
03/22/2013 (11:39 am)
It's been a year since I checked, but isn't there a conflict between our objectives and Awesomium's licensing?
#82
03/22/2013 (11:43 am)
Yeah, we wouldn't be able to include Awesomium easily in the MIT repo, at least as a core component. The licensing for it is Free for Indies up to a certain dollar amount, 100k I think. After that it requires a license.
#83
03/22/2013 (11:48 am)
I am by no means an expert on HTML 5 but out of all the proposed methods for the editor shell, I think it might be one which holds the most promise.

Community development on an HTML5 editor shell should (in theory) open the door for a natural evolution path of T2D towards HTML5 and web publishing.

It also seems to be the most easily approachable solution and could potentially evolve into web-based collaborative game-creation tools.

Of course, we need to determine if this is all realistically feasible but the potential is really exciting.
#84
03/22/2013 (12:11 pm)
Yes, redistribution would be an issue now that I think about it. Great for closed-source projects. WebKit always felt cluttered while awesomium and chromium feel natural. Just specific taste.
#85
03/22/2013 (12:19 pm)
So when considering HTML5 are we talking about a WebKit shell, with editor plugins being written in HTML/JS? Would we support any other languages for plugins?

Does this give editor developers enough power, and flexibility to implement what they want? We came to the QT approach mostly because it was decided that T2D's GUI kit would not be up to the task of a properer editor, while QT more then has the power to handle it.

Does the HTML5 approach still meet up to that requirement?
#86
03/22/2013 (12:27 pm)
Quote:So when considering HTML5 are we talking about a WebKit shell, with editor plugins being written in HTML/JS? Would we support any other languages for plugins?
Allow me to turn the tables. What do you think the answers to those questions should be? How would you approach it?

Quote:Does this give editor developers enough power, and flexibility to implement what they want?
I guess that depends on the type of developer, their knowledge, and how decent the editor shell is implemented.

Quote:We came to the QT approach mostly because it was decided that T2D's GUI kit would not be up to the task of a properer editor, while QT more then has the power to handle it.
True.

Quote:Does the HTML5 approach still meet up to that requirement?
By itself? My opinion is no. We'd still have to either write the editor GUI system or rely on a 3rd party option that provides some of what Qt can do.
#87
03/22/2013 (12:55 pm)
So, if we are still writing the shell in Qt, what is Webkit/HTML5 for? :) Maybe I'm just confused.





#88
03/22/2013 (1:00 pm)
Sorry. The question is still what to write the shell in. Qt has taken the lead, but a couple sources have pointed out some merits of HTML5. I wanted to bring that up as a candidate for the editor shell.
#89
03/22/2013 (1:32 pm)
This is why i suggest taking html 5 intro consideration.

Chris Taylor
"Gas Powered Games"
https://www.youtube.com/watch?v=kuGdQqUhKD4
#90
03/22/2013 (1:46 pm)
@Micheal: Which is where my questions came from :). Does HTML5 provide us the GUI kit that we will need to develop editors? I'm not sure it does myself.
#91
03/22/2013 (1:47 pm)
No, it does not provide you with a robust GUI kit out of the box. You have to create one yourself or import an existing library that provides the functionality.
#92
03/22/2013 (1:58 pm)
Here is the best thing about having the shell in Qt. If someone wants to implement an editor with HTML5, they can write an editor plugin with WebKit and do just that.
#93
03/22/2013 (2:00 pm)
@William - That is an excellent suggestion. Appreciate the back and forth on this. Anything else notable worth mentioning as a pro or con for HTML5?
#94
03/22/2013 (2:02 pm)
To move in the PM direction, it would be completely removing all native code from the Torque codebase for an appification refactor. That seems contrary to advancing the editor suite for Torque 2D MIT. The benefit of Awesomium/Chromium/Webkit is that it allows a strong bridge between apps and native OS code. The benefit of that massive refactor (or starting from scratch, which might be easier) would be a native web engine with all of the warts and growing pains of an emerging platform.
#95
03/22/2013 (2:06 pm)
Enabling QtWebkit would kill some of these birds with the proverbial stone, as long as the developer targets the flavor of HTML5 Webkit supports.
#96
03/22/2013 (2:51 pm)
@David - You just hit on something supremely important. Regardless of the path that is taken, the structure of the editor shell and plugin system will have to be tight and controlled. I'm not saying difficult, just standardized in such a way that garbage doesn't come in and content creators are not restricted.
#97
03/22/2013 (3:17 pm)
@Micheal: I see that being the brunt of the work for developing this editor platform. As Melv has already stated, the UI/Qt side of this is pretty straight forward once T2D can support viewports and embedding.
#98
03/22/2013 (6:38 pm)
What does HTML5 buy us that Qt does not?

I see this on a search for HTML5 desktop applications:
www.tidesdk.org/

Also, what does embedding the game engine in the editor buy us besides maybe shared memory access? (Does windows even support this type of access? I know Linux does.) I was thinking we could launch the engine as a separate app and use a command line switch that is active to debug compiled versions. This would turn on a network port and the editor could communicate that way. So you really only need a web connection to the machine that is running the game engine. Remote developing/debugging. This would allow development/debugging on a phone directly.
#99
03/22/2013 (6:55 pm)
@Frank: T2D already supports remote *debugging* of TorqueScript. That is how Torsion implements its debugger.

The reason to get T2D running inside the editor is to do WYSIWYG editing. Take a particle effects editor: you'd want to be able to tweak params and see the effect in the editor. Or a scene editor: Drag a sprite onto a scene, and watch it interact with the physics setup in that scene.
#100
03/22/2013 (7:06 pm)
@William,
Okay, I can see that. If you recompile the engine can it reload on the fly? I would think that might be important for fast turnaround on game development.