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.
#22
I really didn't mind the fact that the interface was limited to a single window. As Blake Drolson mentioned, editing particles directly in the level editor was a god-send and allowed for insanely quick iteration.
----------
I have two other possible paths which, imho. warrant further discussion
1.
An avenue that wasn't discussed is to switch focus towards supporting a 3rd party pipeline.
Even if we were to integrate all conceivable plugins within a T2D Editor, be it QT-based or directly in-engine, there would still be gaps or preferences that would make most users choose outside editors for certain tasks.
There is already a Tiled (.tmx) importer in the works
www.garagegames.com/community/forums/viewthread/133244
And we will eventually have custom-made Spine runtimes
trello.com/board/spine-runtimes/5131f92a7d6864661c002455
I believe that one valid avenue would be to expose a T2D pipeline so that everyone would be able to start creating in a time-frame that is less than 6 months away.
2.
Even if this definitely falls within the 'toy' category, I have imagined an editor built as a game, similar to Little Big Planet or Halo's Forge.
While most professional game developers might find the idea a tad unproductive, I truly think that this avenue would benefit the community and make the whole technology much more approachable for inexperienced users.
------
What editors do you guys prefer? Do you like UnrealEd's way of handling things (several contexts you can switch between), Unity's (Everything in the same interface), do you prefer Construct's editors?
Be sure to check Notify me of new comments at the top of the post to stay up-to-date on this discussion!
03/15/2013 (5:36 pm)
@Daniel : I see things from a point of view very similar to yours; one of the most attractive things about ye olde' TGB was that it was a one-stop shop.I really didn't mind the fact that the interface was limited to a single window. As Blake Drolson mentioned, editing particles directly in the level editor was a god-send and allowed for insanely quick iteration.
----------
I have two other possible paths which, imho. warrant further discussion
1.
An avenue that wasn't discussed is to switch focus towards supporting a 3rd party pipeline.
Even if we were to integrate all conceivable plugins within a T2D Editor, be it QT-based or directly in-engine, there would still be gaps or preferences that would make most users choose outside editors for certain tasks.
There is already a Tiled (.tmx) importer in the works
www.garagegames.com/community/forums/viewthread/133244
And we will eventually have custom-made Spine runtimes
trello.com/board/spine-runtimes/5131f92a7d6864661c002455
I believe that one valid avenue would be to expose a T2D pipeline so that everyone would be able to start creating in a time-frame that is less than 6 months away.
2.
Even if this definitely falls within the 'toy' category, I have imagined an editor built as a game, similar to Little Big Planet or Halo's Forge.
While most professional game developers might find the idea a tad unproductive, I truly think that this avenue would benefit the community and make the whole technology much more approachable for inexperienced users.
------
What editors do you guys prefer? Do you like UnrealEd's way of handling things (several contexts you can switch between), Unity's (Everything in the same interface), do you prefer Construct's editors?
Be sure to check Notify me of new comments at the top of the post to stay up-to-date on this discussion!
#23
I hope we don't have to rely too much on 3rd party programs for everything. At the moment I feel like a scrooge and don't want to pay anybody anything but I can get over that if I HAVE TOO... I guess... :)
03/15/2013 (6:24 pm)
When I finally found the split view feature in the legacy Torque I thought "That is so cool!". I played with it for 20 seconds then never used it again. Multiple screens are not very high on my list.I hope we don't have to rely too much on 3rd party programs for everything. At the moment I feel like a scrooge and don't want to pay anybody anything but I can get over that if I HAVE TOO... I guess... :)
Quote:What editors do you guys prefer?A took a quick look at the screenshots each program has and I think I like Construct's the best. To be totally honest, I kinda liked the old Torque setup. Although I wanted to edit it badly (like the whole sprite holder thingy) the general set up worked for me. Except the GUI editor, I couldn't figure that sucker out.
#24
The 'Split view' feature you refer to is not the same as multiple windows.
That feature is also present in T2D MIT, if you look at T2D MIT's MultiWindow Toy. This is achieved by having more than one SceneWindow showing the same Scene.
What we are talking about is to have multiple Windows which could be placed anywhere you wish on the desktop.
Also, 3rd party programs can be free! Look at Tiled, Gimp, Blender, Inkscape, GraphicsGale...It is not far-fetched to think of a completely free tool pipeline composed of open-source 3rd party programs.
03/15/2013 (6:53 pm)
@Alpha-Kand The 'Split view' feature you refer to is not the same as multiple windows.
That feature is also present in T2D MIT, if you look at T2D MIT's MultiWindow Toy. This is achieved by having more than one SceneWindow showing the same Scene.
What we are talking about is to have multiple Windows which could be placed anywhere you wish on the desktop.
Also, 3rd party programs can be free! Look at Tiled, Gimp, Blender, Inkscape, GraphicsGale...It is not far-fetched to think of a completely free tool pipeline composed of open-source 3rd party programs.
#25
The general consensus seems to lean toward having a better editor later. However, for that to happen we need people who are ready to commit to contributing their time to make it happen. Have enough talented people stepped up to make this happen?
03/15/2013 (8:00 pm)
I view the editor strategy choice in terms of return on investment. The time I spend writing games is a big investment for me. I want that investment to have good long term rewards. The larger our user community is the better Torque2D will become over time. A good editor will draw users, a poor editor will drive them away. Let's invest in QT. It will pay off.The general consensus seems to lean toward having a better editor later. However, for that to happen we need people who are ready to commit to contributing their time to make it happen. Have enough talented people stepped up to make this happen?
#26
I don't mind having everything in one window like TGB had, are there serious productivity benefits to a multi window setup? Unity's product page for the editor lists the features I am looking for nicely, basically a project browser, inspector, game, scene, and hierarchy view. TGB had all that in one form or another.
Just to make a list of 3rd party tools that T2D has or will possibly support soon:
TexturePacker, Zwoptex (sprite sheets, paid)
Tiled (tile maps, free)
Spine, Spriter (skeletal animation, paid)
PhysicsEditor (collision shapes, paid)
What we need:
Scene/Level Builder
Particle Editor
Project Manager
Collision Shapes Editor (would be nice to have a free tool)
Hmm, I thought the list would be longer, so if I am forgetting something feel free to add.
03/16/2013 (2:12 am)
@Simon - I had a quick look at the editors you posted, at least in terms of screenshots and videos. UnreadEd looked way too busy to me, Unity was ok, Construct I probably liked the most since it reminded me of TGB quite a bit. I also think Spine's UI is really good.I don't mind having everything in one window like TGB had, are there serious productivity benefits to a multi window setup? Unity's product page for the editor lists the features I am looking for nicely, basically a project browser, inspector, game, scene, and hierarchy view. TGB had all that in one form or another.
Just to make a list of 3rd party tools that T2D has or will possibly support soon:
TexturePacker, Zwoptex (sprite sheets, paid)
Tiled (tile maps, free)
Spine, Spriter (skeletal animation, paid)
PhysicsEditor (collision shapes, paid)
What we need:
Scene/Level Builder
Particle Editor
Project Manager
Collision Shapes Editor (would be nice to have a free tool)
Hmm, I thought the list would be longer, so if I am forgetting something feel free to add.
#27
I think the editor GUI/Scripts as before used in iTorque2D is important for prepare level and relative scprited code ... then is not necessary to write manually position or set of objects by taml that need to learn how to set them ...
the editor permit users to set level without handily code to set objects....
this i my opinion ...
Thanks GG ..... your project is growing now !! ;-)
03/16/2013 (2:14 am)
Hei good news ;-)I think the editor GUI/Scripts as before used in iTorque2D is important for prepare level and relative scprited code ... then is not necessary to write manually position or set of objects by taml that need to learn how to set them ...
the editor permit users to set level without handily code to set objects....
this i my opinion ...
Thanks GG ..... your project is growing now !! ;-)
#28
03/16/2013 (3:45 am)
My humble opinion on this topic: The current state of the documentation - both wiki and api - does not give me the impression that it is necessary to look for a new project to start anytime soon.
#29
The documentation is an ongoing process which we are hard at work on but the engine can be used right now to create professional-grade games, as long as you aren't afraid of digging around in the source code a bit.
The sooner we start talking about what we (the community) think would be ideal for editors, the easier it will be to combine our efforts and get the best solution possible in the hands of everyone!
Keep it constructive! :)
03/16/2013 (4:04 am)
@Hans-Joerg : Your opinion is perfectly valid, however bear in mind that Torque 2D is an open-source project which we are building with the community.The documentation is an ongoing process which we are hard at work on but the engine can be used right now to create professional-grade games, as long as you aren't afraid of digging around in the source code a bit.
The sooner we start talking about what we (the community) think would be ideal for editors, the easier it will be to combine our efforts and get the best solution possible in the hands of everyone!
Keep it constructive! :)
#30
.
My plan is to creare a draft game on old 2d that can be broken into multiple toys, have lines like: if old version do this, if new version do something different.
I was waiting a few weeks to see if some basic scene object editor would emerge before I immerse myself in trying to figure out how to Change all my world limit animation into scaling box triggers which hopefully can scale, unlike sprites(from what I have read).
I believe it should be no more a problem to switch the torque script changes from old to new here as it was going from 1.5 to 3d. I was anticipating a separate particle editor as well.
Thanks. So cool.
03/16/2013 (4:10 am)
Edit... It's easier to visualise and switch between scene objects than to go from one level file line number to the next with a big list ofbit()s to remember. It's hard enough as it is..
My plan is to creare a draft game on old 2d that can be broken into multiple toys, have lines like: if old version do this, if new version do something different.
I was waiting a few weeks to see if some basic scene object editor would emerge before I immerse myself in trying to figure out how to Change all my world limit animation into scaling box triggers which hopefully can scale, unlike sprites(from what I have read).
I believe it should be no more a problem to switch the torque script changes from old to new here as it was going from 1.5 to 3d. I was anticipating a separate particle editor as well.
Thanks. So cool.
#31
I am downloading the PySide libraries which is the Qt module for Python written by the developers of Qt. So it does have the widget set that people seem to like. This should not be any different than linking to any other LGPL library in that the source can stay MIT.
The reason I suggest Python is for the coding efficiency gain. I know this is a phenomenon of the language the myself and other developers have experienced. Even experienced C++ developers with 20+ years in the trenches. So please search on the topic if you are interested in this. The phenomenon is you tend to, in short order with little time using the language, spend most of your time solving the problem rather than dealing with the language semantics. I cut my teeth on programming early on with C and then C++. It was not until just 3 or 4 years ago I started using Python more and more. So I have seen how it can cut development time significantly.
So there it is. Ribbon to shreds it!
03/16/2013 (4:24 am)
Okay, I am going to probably step in it on this one. Has anyone thought about developing the editors using Python? I am downloading the PySide libraries which is the Qt module for Python written by the developers of Qt. So it does have the widget set that people seem to like. This should not be any different than linking to any other LGPL library in that the source can stay MIT.
The reason I suggest Python is for the coding efficiency gain. I know this is a phenomenon of the language the myself and other developers have experienced. Even experienced C++ developers with 20+ years in the trenches. So please search on the topic if you are interested in this. The phenomenon is you tend to, in short order with little time using the language, spend most of your time solving the problem rather than dealing with the language semantics. I cut my teeth on programming early on with C and then C++. It was not until just 3 or 4 years ago I started using Python more and more. So I have seen how it can cut development time significantly.
So there it is. Ribbon to shreds it!
#32
Not only can improve and optimize torque2d engine, but also can reflect torque's features.
everybody can study it and expand it. :)
ah~ english...english...english....sad -_-|||
03/16/2013 (6:31 am)
I want to be able to use torque script directly :)Not only can improve and optimize torque2d engine, but also can reflect torque's features.
everybody can study it and expand it. :)
ah~ english...english...english....sad -_-|||
#33
I think a solid visual editor would be helpful but I also believe good tutorials are the key to efficient ramp up. I know a lot of developers are of the opinion that the code should be self-documenting (or that the documentation will always be out of date)... but rather than making excuses for why we don't have documentation we have an opportunity to deliver some tutorials that will be useful to many. /rant
For the next torque visual editor there are two core pieces of functionality that are a must.
1. Scene editing / loading / saving.
2. Asset management.
Let's take a look at each one in more detail.
1. Scene editing / loading / saving.
- I want to load a previously saved scene in the editor.
- I want to edit attributes of each object (such as the name, position, size, dynamic attributes, etc) in the scene.
- I want to save the contents of a scene as represented in the editor.
- I want the ability to undo a series of edits that I have done in the editor.
2. Asset management.
- I want to add sounds and images to my workspace.
- I want to remove sounds or images from my workspace.
- I want to edit the attributes of the images and sounds in my workspace.
- I want the sounds and images added to the scene to use the attributes as defined in the workspace.
In my opinion this is the bare minimum required (and I'm short on details but I'm trying to keep this semi-short). Let's take a quick peek at some of the features that would be considered as next in priority. (These are in no order, just here as an example)
1. (Scene Editing II) I want to edit the collision polygon of any object in the scene.
2. (Assets II) I want to create an animated sprites from a cell-based image in the workspace.
3. (Assets II) I want to add a path to the workspace.
4. (Assets III) I want the assets in my workspace to be organized by their type of asset. The images should be grouped together, the sounds and so on.
5. (Assets IV) I want the assets to sortable/organized by any facet of the asset. This includes dynamic fields.
6. (Editor II) I want the ability to manage (add, remove) plugins to my workspace. The plugins will allow features or workflows not available in the core editor.
7. (Editor II) I want the ability to use a plugin on an object, scene, or asset in my workspace.
As a community we should list out the features we would like to see in the editor. These features should then be prioritized by us, the community, so that milestones can be planned out. The milestones will deliver a minimal bump in features to make the product more useful.
I can see this working in such a way that any feature can be worked on by anyone. Higher priority features will be added to the code base before lower priority ones in the event of any conflicts. An official release won't be made until all the milestone features have been completed and QA'd for that release. Now, this is just the way I see things working in a community developed effort. It's quite possible someone will be more driven to provide a commercial solution and will follow their own path.
Maybe Michael can chime in here and give us some expectations for how he sees this effort proceeding? As I think about this I am having more questions than answers.
03/16/2013 (9:03 am)
I've been thinking about commenting on this thread for awhile now...I think a solid visual editor would be helpful but I also believe good tutorials are the key to efficient ramp up. I know a lot of developers are of the opinion that the code should be self-documenting (or that the documentation will always be out of date)... but rather than making excuses for why we don't have documentation we have an opportunity to deliver some tutorials that will be useful to many. /rant
For the next torque visual editor there are two core pieces of functionality that are a must.
1. Scene editing / loading / saving.
2. Asset management.
Let's take a look at each one in more detail.
1. Scene editing / loading / saving.
- I want to load a previously saved scene in the editor.
- I want to edit attributes of each object (such as the name, position, size, dynamic attributes, etc) in the scene.
- I want to save the contents of a scene as represented in the editor.
- I want the ability to undo a series of edits that I have done in the editor.
2. Asset management.
- I want to add sounds and images to my workspace.
- I want to remove sounds or images from my workspace.
- I want to edit the attributes of the images and sounds in my workspace.
- I want the sounds and images added to the scene to use the attributes as defined in the workspace.
In my opinion this is the bare minimum required (and I'm short on details but I'm trying to keep this semi-short). Let's take a quick peek at some of the features that would be considered as next in priority. (These are in no order, just here as an example)
1. (Scene Editing II) I want to edit the collision polygon of any object in the scene.
2. (Assets II) I want to create an animated sprites from a cell-based image in the workspace.
3. (Assets II) I want to add a path to the workspace.
4. (Assets III) I want the assets in my workspace to be organized by their type of asset. The images should be grouped together, the sounds and so on.
5. (Assets IV) I want the assets to sortable/organized by any facet of the asset. This includes dynamic fields.
6. (Editor II) I want the ability to manage (add, remove) plugins to my workspace. The plugins will allow features or workflows not available in the core editor.
7. (Editor II) I want the ability to use a plugin on an object, scene, or asset in my workspace.
As a community we should list out the features we would like to see in the editor. These features should then be prioritized by us, the community, so that milestones can be planned out. The milestones will deliver a minimal bump in features to make the product more useful.
I can see this working in such a way that any feature can be worked on by anyone. Higher priority features will be added to the code base before lower priority ones in the event of any conflicts. An official release won't be made until all the milestone features have been completed and QA'd for that release. Now, this is just the way I see things working in a community developed effort. It's quite possible someone will be more driven to provide a commercial solution and will follow their own path.
Maybe Michael can chime in here and give us some expectations for how he sees this effort proceeding? As I think about this I am having more questions than answers.
#34
@Simon : Going the asset pipeline approach isn't bad either, but I don't think that's very useful to non developers who want a one stop tool to build their games. For more professional development houses, this is the way to go. I never used the TGB editor, preferring custom tools and Torsion.
We should also consider that even if we have an editor with plugins, we might still be doing some asset generation with outside tools. We'd want to be able to import those (or export into our pipeline) assets into the editor to do any T2D specific work.
For example:
You'll still use Gimp/Photoshop/etc to create your art and import into the editors to setup your animation sets.
You might still use Tiled since it's a fully featured tile editor, and import your TMX maps to add T2D specific info (tile properties, collision polys, etc).
03/16/2013 (9:22 am)
Okay, here's my opinion on the subject. Go with the editors written in T2D, and here's why:- The T2D GUI/font system does need a major overhaul. Doing that for editor support will just strength the feature set that T2D has overall.
- We can still implement multi window support if that is what we want the editor workflow to use.
- We've been talking about editor plugins, which is great, but what if that plugin requires a new feature in T2D? I think having general plugin support within T2D is a great feature for editors and games. Now non-developers don't need to go recompile T2D after merging in 15 Git branches to get the feature set they want.
@Simon : Going the asset pipeline approach isn't bad either, but I don't think that's very useful to non developers who want a one stop tool to build their games. For more professional development houses, this is the way to go. I never used the TGB editor, preferring custom tools and Torsion.
We should also consider that even if we have an editor with plugins, we might still be doing some asset generation with outside tools. We'd want to be able to import those (or export into our pipeline) assets into the editor to do any T2D specific work.
For example:
You'll still use Gimp/Photoshop/etc to create your art and import into the editors to setup your animation sets.
You might still use Tiled since it's a fully featured tile editor, and import your TMX maps to add T2D specific info (tile properties, collision polys, etc).
#35
Then I read this,
Technically, we could achieve what we want with the editors by rebuilding the system to support it, the "overhaul" that's been mentioned. Choosing this route has some repercussions that might come back to haunt us in a few years as Mich stated then again they may hold out for quite some time.
I think it all depends on the feature set we want/need. Personally, I think we should at the absolute least be able to handle all the features the legacy build did and build from there. William's statement (quoted above) got me thinking as well that "if" T2D's GUI system is overhauled in order to support a more epic line of editors then won't everyone using T2D now and in the future benefit from that? Don't get me wrong, I was using QT Creator 3 hours ago, Im a fan. However, seeing T2D expand and become more robust for the developer all while getting new tools seems hard to just throw out the window.
I guess, in my mind I'm seeing this after reading all the comments thus far. Yes, QT can make some snazzy, heavy duty stuff, that's not even a debate. However, implementing the QT perspective does nothing for the engine in and of itself, but will allow us a highly advanced tool-set for many years to come. By that same token, if we go the other route, we get more stable and advanced editors, albeit not QT and the API/Language gets a boost in what it can do and what can be achieved with it. Correct me if I'm wrong in saying that Mich?
This is a toss up for me, I can see benefits of both sides. I love a good tool-set though and so do the folks I work with. Hard decision...
03/16/2013 (1:05 pm)
From Mich, Quote:I'll regret this, but my opinion is "yes", it is possible.
Then I read this,
Quote:The T2D GUI/font system does need a major overhaul. Doing that for editor support will just strength the feature set that T2D has overall.
Technically, we could achieve what we want with the editors by rebuilding the system to support it, the "overhaul" that's been mentioned. Choosing this route has some repercussions that might come back to haunt us in a few years as Mich stated then again they may hold out for quite some time.
I think it all depends on the feature set we want/need. Personally, I think we should at the absolute least be able to handle all the features the legacy build did and build from there. William's statement (quoted above) got me thinking as well that "if" T2D's GUI system is overhauled in order to support a more epic line of editors then won't everyone using T2D now and in the future benefit from that? Don't get me wrong, I was using QT Creator 3 hours ago, Im a fan. However, seeing T2D expand and become more robust for the developer all while getting new tools seems hard to just throw out the window.
I guess, in my mind I'm seeing this after reading all the comments thus far. Yes, QT can make some snazzy, heavy duty stuff, that's not even a debate. However, implementing the QT perspective does nothing for the engine in and of itself, but will allow us a highly advanced tool-set for many years to come. By that same token, if we go the other route, we get more stable and advanced editors, albeit not QT and the API/Language gets a boost in what it can do and what can be achieved with it. Correct me if I'm wrong in saying that Mich?
This is a toss up for me, I can see benefits of both sides. I love a good tool-set though and so do the folks I work with. Hard decision...
#36
1- Create an exporter that generates code from texture packer;
2- Customizing the engine.
Any extensible mechanism should be, in my opinion, maintainable, extendable and easy to publish services through the system. Script languages are good to publish and maintain, but very bad to extend. That's why I am customizing T2D. It's nearly impossible to develop a game with T2D without customizing the engine, unless the game is very simple.
I disagree with an extensible mechanism with an ECMA script since it will be difficult to extend, besides to be simple to develop. Script is a upper layer in a system, not a lower.
The other problem is the component management. In a pluggable system there must be a control to the published services. A layer that manages and controls instability (for this point an ECMA script layer is better) is mandatory. And for this, It must be made an ontology about services. An editor must turn easy the customization for created engine classes and the definition for out files format.
This is the problems I am working now.
It's just a few comments.
03/16/2013 (4:00 pm)
Well, right now I am working in 2 fronts:1- Create an exporter that generates code from texture packer;
2- Customizing the engine.
Any extensible mechanism should be, in my opinion, maintainable, extendable and easy to publish services through the system. Script languages are good to publish and maintain, but very bad to extend. That's why I am customizing T2D. It's nearly impossible to develop a game with T2D without customizing the engine, unless the game is very simple.
I disagree with an extensible mechanism with an ECMA script since it will be difficult to extend, besides to be simple to develop. Script is a upper layer in a system, not a lower.
The other problem is the component management. In a pluggable system there must be a control to the published services. A layer that manages and controls instability (for this point an ECMA script layer is better) is mandatory. And for this, It must be made an ontology about services. An editor must turn easy the customization for created engine classes and the definition for out files format.
This is the problems I am working now.
It's just a few comments.
#37
I've read the other comments and agree with THEM ALL. :) Torque needs docs first. Torque needs a level editor ASAP -- especially for the non-programmer community -- to get rolling. Torque needs a long-plan for an editor also. TGB (the classic editor) is certainly a mess inside. The GUI and fonts need an overhaul for games as well as for any editor. The messy TGB can be brought up to working 3+ times faster than a new editor in Qt.
Here is what I'd like to see...
* Operation Oooey-GUI: A project to clean up the GUI code.
* Operation Phoenix: The TGB editor, not even working now, code-dropped in all its bad, bad, bad glory into its own repo.
* Operation No-Name: A project base started with Qt for the future, including updates to Torque for multi-windows. Python can be supported.
Community members have their preferences and things they like to work on. Scratch your own itch. Start you own working committees or go it alone.
Is this spreading the focus? Obviously. Too thin? Well that depends on community size. Do you have friends to invite to help? Do you have any idea what a present this engine is? Any idea how big this can become? Cocoas? Junk! :) Unity? Watch your back! The GLORY of being one of the first contributors! :P
How to build a HUGE community around Torque2D? That's on my mind the most nowadays. :)
I'd love to see T2D have the level of success of Blender, git, or other open-source *community* driven products. There's some kind of magic that kicks in and I'd like to watch Torque do that first hand. What we have here is a freakin' 6+ year-old, battle tested engine that works cross platform to write games.
So my answer to the posed question is, let's start with them all and see what comes of it? Lose a little control.
03/16/2013 (5:26 pm)
How to build a HUGE community around Torque2D? That's on my mind the most nowadays. :)I've read the other comments and agree with THEM ALL. :) Torque needs docs first. Torque needs a level editor ASAP -- especially for the non-programmer community -- to get rolling. Torque needs a long-plan for an editor also. TGB (the classic editor) is certainly a mess inside. The GUI and fonts need an overhaul for games as well as for any editor. The messy TGB can be brought up to working 3+ times faster than a new editor in Qt.
Here is what I'd like to see...
* Operation Oooey-GUI: A project to clean up the GUI code.
* Operation Phoenix: The TGB editor, not even working now, code-dropped in all its bad, bad, bad glory into its own repo.
* Operation No-Name: A project base started with Qt for the future, including updates to Torque for multi-windows. Python can be supported.
Community members have their preferences and things they like to work on. Scratch your own itch. Start you own working committees or go it alone.
Is this spreading the focus? Obviously. Too thin? Well that depends on community size. Do you have friends to invite to help? Do you have any idea what a present this engine is? Any idea how big this can become? Cocoas? Junk! :) Unity? Watch your back! The GLORY of being one of the first contributors! :P
How to build a HUGE community around Torque2D? That's on my mind the most nowadays. :)
I'd love to see T2D have the level of success of Blender, git, or other open-source *community* driven products. There's some kind of magic that kicks in and I'd like to watch Torque do that first hand. What we have here is a freakin' 6+ year-old, battle tested engine that works cross platform to write games.
So my answer to the posed question is, let's start with them all and see what comes of it? Lose a little control.
#38
When the time comes to have a visual editor, I would want it to be something we can be proud of. Cobbling together temporary tools is something some users may end up doing in TorqueScript on their own anyway, and more than a few of them may share those.
I love the idea of plugins because it gives room for it to grow. Of course, I have to admit, I feel a little scrooge-like myself. I went and purchased both Torque 2D Pro and Torque 3D while they were $99 in Sept. of 2011 because I didn't want to miss out on a good sale, even though money was tight. Then a year later everything started going free and open source.
Don't get me wrong - I love the future these engines have now! - but I still haven't recovered from the sticker shock. :D
~Meredith
03/16/2013 (10:37 pm)
Ultimately, even if it takes a while, for an editor to be solid it needs to be in it for the long haul. I found all the editors I've used, from Torque TGE to Torque 2D/3D to be pretty decent in a pinch. But the GUI editor always gave me the most trouble...When the time comes to have a visual editor, I would want it to be something we can be proud of. Cobbling together temporary tools is something some users may end up doing in TorqueScript on their own anyway, and more than a few of them may share those.
I love the idea of plugins because it gives room for it to grow. Of course, I have to admit, I feel a little scrooge-like myself. I went and purchased both Torque 2D Pro and Torque 3D while they were $99 in Sept. of 2011 because I didn't want to miss out on a good sale, even though money was tight. Then a year later everything started going free and open source.
Don't get me wrong - I love the future these engines have now! - but I still haven't recovered from the sticker shock. :D
~Meredith
#39
Unfortunately there are few resources that are going to be willing to devote any real time to these efforts. They can't try and tackle everything right now.
They are going to have to decide on just one direction to take the tools, and start putting in place what is needed to get the community to kick in.
03/16/2013 (10:47 pm)
@Charlie : Of course anyone can fork the source and go work on whatever they want to do, and release it to anyone they want. However, the steering committee needs to come up with a focused vision to champion, and get the general community behind. Unfortunately there are few resources that are going to be willing to devote any real time to these efforts. They can't try and tackle everything right now.
They are going to have to decide on just one direction to take the tools, and start putting in place what is needed to get the community to kick in.
#40
No one is forced to purchase anything, and there is no reason why someone (even you) couldn't release a free/open source version of a paid feature plugin. Look to android and ios for an ecosystem that supports both.
03/17/2013 (7:06 am)
@Meredith: I'd much rather have a system that can support the possibility of paid plugins, then a system that is forced to always be 100% open source. You end up with many more features.No one is forced to purchase anything, and there is no reason why someone (even you) couldn't release a free/open source version of a paid feature plugin. Look to android and ios for an ecosystem that supports both.
Torque Owner Blake Drolson
Imminent Games
Anyway, in general I lean more towards the "high quality" solution, even if it takes longer, as I can imagine that once the editors are written they will be with us for a long time. Too many factors for me to decide which path is more "high quality" overall though.