Game Development Community

dev|Pro Game Development Curriculum

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
Page «Previous 1 2 3 Last »
#1
06/18/2013 (3:44 pm)
Just particly stuff missing now, right?
#2
06/18/2013 (3:48 pm)
Good to hear Android support is being pushed forward into actual development. :)
#3
06/18/2013 (3:53 pm)
@Ronny - Essentially. I wish ParticleDesigner was cross-platform. It would only take a day or two to get that loading, but it's been the lowest on the totem pole for potential 3.0 features. However, the 3.0 roadmap is not set in stone. If you have some suggestions on particles, please let us know here.

@Nathan - Indeed. Are you an Android developer?
#4
06/18/2013 (4:52 pm)
sounds great

regarding android
i could at least function as a tester - if its needed?
got 3 android devices

a tegra2 tablet
sgs2 like play device
and a crappy mobile phone
i do kinda cover low/med/high specs with those 3 devices

anyways great to here that t2d is shaping up
and a special thx to MaxGaming and ofc GG
#5
06/18/2013 (4:55 pm)
@J0linar - A wide spectrum of testing devices and users is exactly what we will need. Thank for chiming in. As the developers get closer to a public test, we will let everyone know. Thanks in advance!
#6
06/18/2013 (6:22 pm)
Hi Mich, I love the idea of having Android support. I'm hoping the web plugin will be ported from T3D as well. Also, and maybe more importantly what is the fate of the main level editor? Does it already exist in T2D MIT? Is the GUI editor staying as is? Are each of the editors mentioned in this blog just going to be a set of separate tools with nothing tying them together? I saw some earlier blogs talking about editor direction, but was expecting to see some mention of it on the roadmap. I've just moved to 1.8 and I'm dreading the thought of moving to MIT without having the editors.
#7
06/18/2013 (9:51 pm)
Hi Mich ...

good news from you ...

I think the best news are Android and Leap motion control ..

don't forget to fix some bugs as iOSMoviePlayer that don't work in MIT .....;-)

Bye

I wait for new updates ;-)

#8
06/19/2013 (2:55 am)
Roadmap: I think this is a solid list of new features and updates. One thing that I believe is important, we should launch new features with documentation wherever possible. Once 3.0 is released and we start promoting it outside of the Torque community - say someone gets excited for Spine support, as an example, but gets immediately stuck trying to get an animated model into the engine because there was no step by step guide or tutorial for this process available. Excitement-killer there. It is great that T2D is open source and free to use, but it is that much easier for a new user to lose interest and stop using the engine since there was no monetary investment to help push their motivation if they get stuck with something. I'll certainly help with doc writing where I can.

Particles: I downloaded a trial version of ParticleDesigner a while back, but my first impression wasn't all that positive.

1. As Mich mentioned, it is not cross platform and very iOS-centric.
2. It would not have support for all the fields that T2D has (which isn't that surprising, honestly).
3. It looked like the graph fields only had support for a start key and end key based on particle lifetime? Key framing in general seemed very limited.

Granted, I only had the program installed for at most 10 mins before I deleted it off my hard drive. Perhaps I didn't give it a fair shake. But I do find the workflow of simply having a text/xml editor and a running copy of T2D with the ParticleViewer open side by side meets my needs. Tweak the ParticleAsset values directly in TAML, save, reload the asset in the viewer.

On a related note, the docs for the ParticleAsset Guide and the ParticlePlayer Guide are almost done but I've run into an issue in the API section exporting a Torquescript effect to TAML. The issue is described here: Issue #71. If anyone has some free time to look into this either to confirm the bug or to point out if I am doing something wrong in TorqueScript, it would be appreciated (and then I can get the guides submitted).
#9
06/19/2013 (5:32 am)
This is really awesome. That's a pretty chunky roadmap for a couple of months - good luck and respect to all the contributors that will be making this happen!
#10
06/19/2013 (5:43 am)
@Bruno - The editor work could have replaced everything listed in this blog, due to the sheer scope of the work. The committee decided that a more feature-rich, stable engine was a better goal for 3.0. To offset that, we decided that supporting several 3rd party tools would make it easier for developers that needed visual creation applications. Now that T2D is more data driven, we can finally create loaders and exporters for things like TexturePacker and Spine.

Do you think the QT editor framework is more important than all the above features?
#11
06/19/2013 (5:43 am)
@Andrea - Got that covered. I mentioned in my blog that several bug fixes and general improvements will come along for the ride. Make sure that specific bug is listed as a GitHub issue, so others can try and fix it.
#12
06/19/2013 (5:45 am)
@Mike - Thanks for the detailed review of the roadmap. Your review of ParticleDesigner is spot on. I used it for a much longer period of time and you are right on each point. If that was voted as the most popular feature, then we would have to change the current particle system to accommodate it.

Documenting any new features or updates to the code is absolutely a requirement. There are other communities that use the tools I listed. If the check out T2D because their tool is supported, we need to make sure they have a smooth transition and can get started immediately.

As always, big thanks again for your documentation efforts. They will help everyone get to a solid 3.0 launch.
#13
06/19/2013 (5:56 am)
@Daniel - Yes, very ambitious. Luckily a lot of the work has already started. I have worked on both the Leap Motion and Spine code already.

I've spent time on Leap Motion because I love cool input devices and it will allow T2D to ride the PR wave when the device is publicly launched. I'd say that code is 95% finished. It's currently hosted in the RND branch.

Because GG contributed the maximum amount to the Spine KickStarter campaign, Esoteric has already worekd on a runtime for Torque 2D. Nate and I implemented the spine-c runtime in his fork of the T2D repository. Once the code got to stable state, I moved the work into a branch in the main T2D GitHub. Depending on the the final requirements, I'd say that work is 70-80% complete.

I'll talk about the rest of the progress in my next blog.
#14
06/19/2013 (8:22 am)
@Mike : I completely agree that the ideal situation would be to have documentation available at feature launch.

I just want to add a note that all features that get pushed into the master repository should (and will!) receive such treatment.

When new branches are created or when new WIP features get added to the development branch, it's kinda hard to document them as we develop them.

That being said, expect all 3.0 features to have full documentation at launch.
#15
06/19/2013 (8:44 am)
@Mich, I agree that the editor is not more important than all of the above features. I guess I'm just having trouble picturing how the current workflow looks. My biggest fear is that I convert my existing TGB project over and it doesn't work because there is functionality missing. Currently I make heavy use of the GUI system. Is this supported in the MIT build? If it is and I start using it, is it going to drastically change? I also use TileLayers, the AStar code and the particle system. To what extent do these work in MIT?

I'd really like to start using the new engine, especially since it will now support Android, but what is the best way to figure out what functionality is supported now, what will be coming in the future, and what will be going away or changing drastically? Is there a way to show a 'feature comparison' grid between TGB and T2D MIT so that I can gauge whether or not it makes sense to port over?

Also, how much effort is adding the T3D Web Plugin to T2D? Would this be a small enough item to add to the 3.0 roadmap? I think it would open up the deployment opportunities for T2D-made games.
#16
06/19/2013 (8:57 am)
Quote:Currently I make heavy use of the GUI system. Is this supported in the MIT build?
Yes.

Quote:If it is and I start using it, is it going to drastically change?
There's nothing on the roadmap that shows a GUI overhaul. Someone would have to suggest it and then get community approval. Until then, the GUI system is the same as it was in TGB.

Quote:I also use TileLayers, the AStar code and the particle system. To what extent do these work in MIT?
The old tilemap and A* system is gone. You would have to rebuild your tilemaps using the new CompositeSprite class. Currently, that can only be done by hand through script or TAML. However, having Tiled (tmx) support will provide a visual editor again.

The particle system runtime is basically the same, though it has received some minor changes to accommodate the new asset system. Again, there is no editor. However, another T2D user has written code to convert TGB particles to T2D MIT format. You will likely need to use that or write your particles from scratch.

Quote: but what is the best way to figure out what functionality is supported now, what will be coming in the future, and what will be going away or changing drastically
THIS BLOG!!!! =)

Quote:Is there a way to show a 'feature comparison' grid between TGB and T2D MIT so that I can gauge whether or not it makes sense to port over?
Certainly, but someone will have to create that. Perhaps that could be part of the documentation effort.

Quote:Also, how much effort is adding the T3D Web Plugin to T2D? Would this be a small enough item to add to the 3.0 roadmap? I think it would open up the deployment opportunities for T2D-made games.
It would be difficult. The difference between the T2D and T3D codebases are massive. Someone would have to volunteer their own time to do that. If not, we would have to drop features from the proposed roadmap and free up some of my time.
#17
06/19/2013 (9:04 am)
I really hope everyone paid special attention to the timeline. That date will not be hit unless people volunteer their time to help with adding/finishing features, writing docs, and testing. If volunteers do not come forward, this release would likely be pushed back to November or December. Food for thought.
#18
06/19/2013 (9:06 am)
Hi @Bruno. I remember you from Invadazoids, and I'm still waiting on a port for iPad. :P

Regarding the GUI, it sounds like you know a bit about it!? There is a discussion on the forums about the GUI and what should be done to improve it but there doesn't seem to be too much experience with it. (hint, hint).

#19
06/19/2013 (9:35 am)
@Bruno : I would like to add a small note on the compatibility of the Gui system.

The GUI system is exactly the same (except for the asset system modifications) but some Gui components of TGB were not ported over to T2D MIT.

For example, the guiGraphCtrl.cc (which was used in TGB to edit the curves of the particle effects) is not included in T2D MIT.

I did port it for personal use and it did not require any major changes; you just need to make sure that all the 'includes' point to the new directory structure (dgl/GTexManager doesn't exist in the new architecture, etc.)

All non-editor GuiControls are available in T2D MIT and work exactly as they did in TGB.
#20
06/19/2013 (12:06 pm)
@Simon: yes, that was my assumption as well. Doesn't make sense to document stuff that is still in a feature branch. Most of the things that land in development are pretty stable though, I guess a case by case basis for features would be needed to determine when is the right time to start writing docs. Don't want to leave it all for the week before the push to master.

@Steering Committee: it might be good to have some forum sticky threads that detail what work still needs to be done for certain features. Similar to how Simon approached fixing the CompositeSprite bugs. It could get some people to more easily volunteer if they have a better idea of what the tasks are and the time it will roughly take to finish them.
Page «Previous 1 2 3 Last »