Torque 2D 3.0 Roadmap (includes Android)
by Michael Perry · 06/18/2013 (3:41 pm) · 51 comments
Torque 2D 3.0 Roadmap, Development and You
On February 4th 2013, we launched Torque 2D MIT (2.0) on GitHub. The Steering committee was formed shortly after the launch and helped forge a new, better T2D with the help of an eager community of hobbyists and professional developers.One of the Steering Committee's duties is creating and revising Torque 2D's roadmap. We have a meeting once a week to discuss Torque 2D and try to take the best decisions regarding the future of our beloved engine.
The point of this blog is to show the roadmap we have come up with. More importantly, this blog is where the entire community will ratify the roadmap. The final decision is not up to GarageGames or the T2D steering committee. This is merely our best suggestion, based on our own desires and understanding of the engine. This is our official quote:
Quote: Torque 2D 3.0 will be our first major release since the initial launch and will contain many updates, new features and a lot more documentation. It also represents a more stable starting point for new users and provides a much easier learning curve.
Torque 2D 3.0 Proposal
The following lists make up our ideal Torque 2D 3.0 launch. This is all subject to change, mainly based on your feedback and contributions. These are just suggestions, some of which have already been worked on just to test feasibility.Android
This features needs no verbose introduction. MaxGaming attempted to fund an Android port via KickStarter. Sadly, the campaign failed. Despite that, GarageGames, its owners, and MaxGaming have decided that Android support is too important to ignore. In order to support indie developers and further the greatness of the engine, Torque 2D is coming to Android! What we need from the community are testers, doc writers, and supporters. Spread the word and volunteer your doc writing skills.Leap Motion Controller
This small device can detect your hands and fingers over it and report on their absolute positions and rotations. It is a new way of interacting with applications and has a lot of potential. The Leap Motion won’t be available before July 22nd (they are taking preorders on their web site) but they have been sending out hardware and the SDK to interested developers.Spine Support
Spine is a skeletal animation editor which allows for really dynamic animations that are not possible with traditional spritesheet-based animations. The goal would be a complete integration of Spine functionality into T2D 3.0, which includes the bone system for character animation, skinning, full animation control, mixing, and access to bones.Tiled (.tmx) file support
Tiled is a general purpose tile map editor, built to be flexible and easy to use. In addition to its own map format, Tiled supports read/write plugins for using it with proprietary map formats or formats used by other editors. Physics Editor support
PhysicsEditor allows you to create collision shapes easily and export them for use directly in games that use Box2D. Unlike content creation tools like Spine and TexturePacker, PhysicsEditor generates actual objects for game play and physics simulations. Because Torque 2D has moved toward being data driven via TAML and the asset system, PhysicsEditor support has to be designed before coding start. I have started a thread here, hoping to get suggestions and volunteers for the work.Sandbox Refactor
The Sandbox demo is becoming quite cluttered and clunky with all the toys. Our goal is to cleanup the modules and make the Sandbox a little simpler. This will consist of consolidating several toys and updating the UI to allow for easier to access controls.
Massive Documentation Update
The Steering committee has steadily updated the wiki with guides and tutorials to help you better understand and master the power of T2D, and will continue to do so in the future. However, other Torque 2D users have started contributing lately.
Community member Mike Lilligreen has also contributed documents on par with our highest standards. Take a look at the Blending Guide and Input Guide. In order to have the best documentation possible for 3.0, we are urging others to follow Mike's lead.
In addition to the wiki, Charlie Patterson has been helming a major update to T2D will make full reference documentation a reality. Much of his work consists of updating the engine so support Doxygen style commenting, rather than explicit strings found in ConsoleFunction and ConsoleMethod. This effort will make it easier and safer for anyone to contribute documentation for all functions, objects, variables, and callbacks exposed to TorqueScript.
General Improvements
As with any update, several general improvements will make their way into the codebase. Some will be a result of new features, while others will come from one-off contributions. The following is a simple list that will likely grow before 3.0 launches:
- Image and animation cells can now be referenced by name
- TAML system will be updated to support JSON format for persistence
- TAML visitor updated to support new formats
- CompositeSprite improvements
- iOS platform improvements
- OS X platform improvements
- Performance improvements
- Many bug fixes
Torque 2D 3.0 Timeline
The Steering Committee aims to is aiming to have three or four releases a year, where a release is defined as merging all development branch changes into the master branch. To that end we are hoping for a September 2013 release for T2D 3.0. Ultimately, that is up to everyone. It takes a village to raise an engine. If everyone agrees on the road map proposal, then we will need everyone to start contributing.Now, let your voices be heard! What do you think about this roadmap? What would you change, add, remove, or applaud? Who will help the actual development and documentation? Let's hear it people!
Regards,
Mich
About the author
Programmer.
#42
Stay tuned.
07/03/2013 (9:49 am)
@Mike - Much thanks. That's exactly the kind of attitude we are trying to foster in the Torque 2D community. Volunteers are needed for the rest of the tasks. I'll be posting another blog soon that will better enable everyone to make contributions and track what's being done.Stay tuned.
#43
07/11/2013 (5:43 am)
I'd be really happy to contribute, I'm looking forward to seeing the list of things to be done so I can see what I can bite off.
#44
Or should I review Spine and consider switching over to it?
All the best.
07/11/2013 (6:12 am)
Additionally @Michael given that Spine has such a close relationship with GG and is formally on the roadmap for 3.0, what is the status of the spriter integration? Is it something I could pick up, is it similar to the Spine integration?Or should I review Spine and consider switching over to it?
All the best.
#45
The good news is that the Spine implementation is a good baseline to follow for similar runtimes/tools. The one drawback to Spriter is the lack of an official runtime. Nathan from Spine created runtimes for nearly every platform and language, which made it a simple matter to integrate the spine-c into T2D's codebase.
Here is the state of the Spriter implementation:
1. Base object and asset have been created, but not complete.
2. Spriter file loading is finished.
3. DOM is finished.
4. Connection between the Spriter asset and Spriter object is nearly complete
5. No actual rendering or animation
6. No access to internal data, like slots and bones, exposed to script.
At this point, it's a matter of filling in the blanks. The biggest blank being the animation runtime. The Spine implementation that is available now is a great reference for anyone who wants to continue the work on supporting Spriter.
07/11/2013 (6:27 am)
@David - Much thanks for offering to help. We are updating our Trello board to fully reflect the state of Torque 2D. As for a Spriter implementation, it was put on hold when Melv left and I had to help with the Spine implementation.The good news is that the Spine implementation is a good baseline to follow for similar runtimes/tools. The one drawback to Spriter is the lack of an official runtime. Nathan from Spine created runtimes for nearly every platform and language, which made it a simple matter to integrate the spine-c into T2D's codebase.
Here is the state of the Spriter implementation:
1. Base object and asset have been created, but not complete.
2. Spriter file loading is finished.
3. DOM is finished.
4. Connection between the Spriter asset and Spriter object is nearly complete
5. No actual rendering or animation
6. No access to internal data, like slots and bones, exposed to script.
At this point, it's a matter of filling in the blanks. The biggest blank being the animation runtime. The Spine implementation that is available now is a great reference for anyone who wants to continue the work on supporting Spriter.
#46
What's the planned cutoff ? Gingerbread or ICS ? Anything else means we lose a LOT of potential market share : can't assume people have more than one Android phone, and that they root it and install custom roms ;)
I have two, a low end pos from ZTE (N762) on budget carrier Public Mobile (35 bucks a month, for unlimited calling, SMS AND unlimited, unmetered data. Think I average 8-10 gigs a month on the 3g plan, not counting wifi usage) and a sort of mid/lo range Samsung Galaxy, the ACE-IIx (GT-S7560M on Telus (it's a Canada only model btw, the other ace II is totally a different beast), no data plan, use Wifi at home, at large or use the zte as a portable wifi hotspot ;)).
Both are rooted, neither is running custom roms beyond the recovery ones.
They have the same gpu on the SOC but the samsung is the only of the two that can take advantage of it with slightly more than a half gig of RAM. And even then, I get memory bound quite easily with cached processes hogging always at least half of that, not to mention hiccups from the GC.
The ZTE runs Gingerbread (2.3.5) and is constrained to a 32meg VM per process, while the Ace IIx is running Ice Cream Sandwich (4.0.4) and gets 64 megs per VM. Now, that number might be determined by the amount of RAM available rather than the Android version, ofc. Barely starting to scratch the surface there, I'll be back with more reliable info soon enough...
Haven't researched the topic with any depth yet, but I guess we're looking at encapsulating a bunch of code in native jar libs using C interfaces, not forgetting that it's ARM and we're an order of magnitude slower than x86 at the same clock speeds/RAM configs ?
A lot of java will have to be written anyhow, and torque script might have to go, right ? Or be severely constrained. I'll be looking at Lua as it's a favorite of mine for embedded game scripting as a possible alternative, as we want to avoid GC action during gameplay as much as possible, if not completely (seriously)
Not to forget that we can't count on the external SD being usable for swap or even install space, as most Android handhelds fake an external SD with internal storage as far as code and app data is concerned. Basically, with ICS and beyond, on the dominant manufacturer (Samsung), an external SD card for the normal use case is for photos, videos and music, or just about.
Doesn't mean we can't allow for power users having rooted devices with partitioned external SDs that allow for installation, and even a linux swap partition, but it can't be the common denominator.
It's going to be quite a challenge, and I do have to say it's tickling the fancy of my hacker bones ;)
If there is some contract/result driven financial incentive possibilities, even better (huge cheshire cat grin)
From the cursory reading I've done so far, the community seems a lot smaller but a lot more mature and focused in general, not a bad thing to get things done in an Open Source environment.
Stay tuned for my take on things, and hopefully some concrete results sooner than later.
Cheers !!
07/14/2013 (6:05 pm)
Porting to Android is also going to imply some major rewrites, and some tough decisions unless you only want to run on an infinitesimal part of the installed platform out there. What's the planned cutoff ? Gingerbread or ICS ? Anything else means we lose a LOT of potential market share : can't assume people have more than one Android phone, and that they root it and install custom roms ;)
I have two, a low end pos from ZTE (N762) on budget carrier Public Mobile (35 bucks a month, for unlimited calling, SMS AND unlimited, unmetered data. Think I average 8-10 gigs a month on the 3g plan, not counting wifi usage) and a sort of mid/lo range Samsung Galaxy, the ACE-IIx (GT-S7560M on Telus (it's a Canada only model btw, the other ace II is totally a different beast), no data plan, use Wifi at home, at large or use the zte as a portable wifi hotspot ;)).
Both are rooted, neither is running custom roms beyond the recovery ones.
They have the same gpu on the SOC but the samsung is the only of the two that can take advantage of it with slightly more than a half gig of RAM. And even then, I get memory bound quite easily with cached processes hogging always at least half of that, not to mention hiccups from the GC.
The ZTE runs Gingerbread (2.3.5) and is constrained to a 32meg VM per process, while the Ace IIx is running Ice Cream Sandwich (4.0.4) and gets 64 megs per VM. Now, that number might be determined by the amount of RAM available rather than the Android version, ofc. Barely starting to scratch the surface there, I'll be back with more reliable info soon enough...
Haven't researched the topic with any depth yet, but I guess we're looking at encapsulating a bunch of code in native jar libs using C interfaces, not forgetting that it's ARM and we're an order of magnitude slower than x86 at the same clock speeds/RAM configs ?
A lot of java will have to be written anyhow, and torque script might have to go, right ? Or be severely constrained. I'll be looking at Lua as it's a favorite of mine for embedded game scripting as a possible alternative, as we want to avoid GC action during gameplay as much as possible, if not completely (seriously)
Not to forget that we can't count on the external SD being usable for swap or even install space, as most Android handhelds fake an external SD with internal storage as far as code and app data is concerned. Basically, with ICS and beyond, on the dominant manufacturer (Samsung), an external SD card for the normal use case is for photos, videos and music, or just about.
Doesn't mean we can't allow for power users having rooted devices with partitioned external SDs that allow for installation, and even a linux swap partition, but it can't be the common denominator.
It's going to be quite a challenge, and I do have to say it's tickling the fancy of my hacker bones ;)
If there is some contract/result driven financial incentive possibilities, even better (huge cheshire cat grin)
From the cursory reading I've done so far, the community seems a lot smaller but a lot more mature and focused in general, not a bad thing to get things done in an Open Source environment.
Stay tuned for my take on things, and hopefully some concrete results sooner than later.
Cheers !!
#47
Since this blog post is nearly a month old, I don't know if it sees much traffic anymore. In any case, the best person that can answer your questions on what is happening with the Android port would be Tim from Max Gaming. All I can remember reading from some other blog or forum post would be that it will use the Android NDK - I assume this means that it leaves most of the core engine and TorqueScript alone and most of the work is done through the platform layer. Right now core game logic and scripts are easily ported between Windows/OSX/iOS - it would be odd if Android goes down a totally different path.
If you did want add Lua as a scripting language, I don't think anyone would complain. I know every now and then someone wishes that it would be great if Torque supported Javascript/Lua/C#/whatever. It would be one less hurdle for someone to adopt the engine if it supported a scripting language they already know or prefer. I don't think TorqueScript should be dropped though, the bridge to C++ should simply be written in such a way that multiple scripting languages can coexist like on some other engines. Or sort of like how TAML supports XML/JSON/binary now, and I think I saw work-in-progress on CSV and SQLite from someone in the community. I'd hate to think what that would do for documentation requests though - I can see the forum posts now: "Why aren't there more tutorials for <insert scripting language here>????"
07/15/2013 (4:12 am)
Hi Nicolas,Since this blog post is nearly a month old, I don't know if it sees much traffic anymore. In any case, the best person that can answer your questions on what is happening with the Android port would be Tim from Max Gaming. All I can remember reading from some other blog or forum post would be that it will use the Android NDK - I assume this means that it leaves most of the core engine and TorqueScript alone and most of the work is done through the platform layer. Right now core game logic and scripts are easily ported between Windows/OSX/iOS - it would be odd if Android goes down a totally different path.
If you did want add Lua as a scripting language, I don't think anyone would complain. I know every now and then someone wishes that it would be great if Torque supported Javascript/Lua/C#/whatever. It would be one less hurdle for someone to adopt the engine if it supported a scripting language they already know or prefer. I don't think TorqueScript should be dropped though, the bridge to C++ should simply be written in such a way that multiple scripting languages can coexist like on some other engines. Or sort of like how TAML supports XML/JSON/binary now, and I think I saw work-in-progress on CSV and SQLite from someone in the community. I'd hate to think what that would do for documentation requests though - I can see the forum posts now: "Why aren't there more tutorials for <insert scripting language here>????"
#48
I am a beginner in Torque 2D, but he much looks like engine of my daydream!
Thank you You for your perennial labour!
I like the roadmap!
Offer to add:
1) Support of the mask alpha channel.
2) Theora video player with support of the mask alpha channel for making 2D-3D effects applicable presently in modern casual games with acceptable capacity on all device...
3) Render targets for render to texture.
4) Distortion Mesh.
07/17/2013 (3:44 pm)
Hello! We Ask to forgive me my english(..I am a beginner in Torque 2D, but he much looks like engine of my daydream!
Thank you You for your perennial labour!
I like the roadmap!
Offer to add:
1) Support of the mask alpha channel.
2) Theora video player with support of the mask alpha channel for making 2D-3D effects applicable presently in modern casual games with acceptable capacity on all device...
3) Render targets for render to texture.
4) Distortion Mesh.
#49
Torque 2D MIT Trello
Core Engine Board
Documentation Board
Editor Board
Modules Board
If you have a Trello account, you can leave comments on the boards and individual tasks. Example comments can include:
"What's the current status?"
"Where can I find this branch?"
"Can I volunteer for this?"
"I like this feature. Can we make it higher priority than ___?"
Any GitHub issues that are submitted will be duplicated on the Trello board, so feel free to use either. The purpose of the Trello board is to provide an easier to read solution for tracking the progress of Torque 2D MIT. There have been a lot of complaints about the GitHub interface. We've already filled out a lot of tasks, but everyone should now be able to view and make requests.
07/22/2013 (9:19 am)
The Torque 2D MIT Trello organization is now live:Torque 2D MIT Trello
Core Engine Board
Documentation Board
Editor Board
Modules Board
If you have a Trello account, you can leave comments on the boards and individual tasks. Example comments can include:
"What's the current status?"
"Where can I find this branch?"
"Can I volunteer for this?"
"I like this feature. Can we make it higher priority than ___?"
Any GitHub issues that are submitted will be duplicated on the Trello board, so feel free to use either. The purpose of the Trello board is to provide an easier to read solution for tracking the progress of Torque 2D MIT. There have been a lot of complaints about the GitHub interface. We've already filled out a lot of tasks, but everyone should now be able to view and make requests.
#50
07/23/2013 (4:41 pm)
Very cool Kanban! 
Associate Mike Lilligreen
Retired T2Der
As a general comment for everyone, while posting about feature requests and areas where T2D is lacking is fine - that's not going to get much accomplished. Where are the volunteers to help at least get the proposed feature set for 3.0 out the door in a reasonable time frame?
Since not needing source was always one of the featured points of T2D, the community is split between those that are competent in C++ and those that aren't. Heck, even I fall into that latter group. But there are things that everyone can do to help. I've had a brief look at what would be needed for PhysicsEditor, and that looks like a task a non-c++ coder can do if making an exporter is similar to TexturePacker. So I'm willing to take that work on so those few with C++ knowledge and spare time can work on tmx, spine, etc.