What would you like to see addressed in Torque 2D?

#41 I'm surprised to see multiple requests for Lua scripting :) I will add my vote for that too, though I'm sure it's not going to happen and also there will be a way to port my Lua code to T2D.

I'd mainly like to see better asset management within the editor. Things like art resources should be able to be built within the editor. There should be a way to load sounds within the editor. It's all about the editors with me really, I'm getting sick of coding lol ;P

#42 I've ranted about this a few times before, but I think the GUI Editor could use some work. Besides making it so that it doesn't crash, my biggest complaint is that you are forced to use profiles. I would like to be able to set all of the same properties that exist in the profiles on each control directly in the GUI Editor. Also, there are a lot of GUI controls that severely lack documentation, so much so that even when asking people in the forums, no one had any idea how to use certain controls. You can read my official TGB review here: bantamcity.com/blog/game_development/torque-game-builder-review/

Also, I'm not going to be too happy if I can't easily convert my TGB project to T2D. Even if it's not easy, but at least possible, I want someone from GG to do a full writeup on how to do it... don't leave that burden to your community.

#43 Bruno, I don't think TBG projects will be able to be converted to T2D. From what I understand, T2D is an entirely new engine. It would be like opening Unreal 2004 maps in Unreal 3, Unless I'm mistaken.

#44 @Bruno - It's safe to say the GUI Editor improvements going into Torque 3D will make it into Torque 2D. A blog is being posted about this today. You'll be happy

As far as compatibility, I really do not think it is going to be possible. The entire scene, camera, and scene objects are completely changed. The old t2dSceneObject system is not what we are using now. Check out Melv's latest blog on the new Model system. The only thing you will still be able to use/port will be your raw assets. I know this might be frustrating for teams in the middle of development, but you will have only 2 choices:

1. Finish your current project in TGB and start a new one in Torque 2D.
2. Use your current project as a prototype and rebuild it completely in Torque 2D.

There's just no way around this. TGB and it's current projects cannot stack up to what Torque 2D will be capable of.

I like your blog by the way. I read it way before this posting and the feedback is extremely useful. Thanks for that

#45 T2D not compatible with TGB? So I'm assuming the genre kits aren't compatible either, even though the real-time networking video featured the PSK?

#46 @Cyrad - The networking video was record quite a while back, before the most major changes started happening. Again we were just using existing assets. To answer your question, though, existing genre kits will not be compatible.

#47 This is true, though you can bet your bottom dollar that the PSK will be maintained and fully compatible with Torque 2D at or near release.

#48 post processing is super important to me, many of the special effects I want to achieve require it.

Dynamic lighting, even it's a pretty simplistic system could be really good also.

The gui editor needs work. It's not intuitive at all, and that's extraordinarily ironic for a gui editor 8)

Also, I know you won't give me a definite answer, but what kind of time frame are we looking at now? Is this something coming out in a year? a month?

#49 Well, something that is really annoying is the fact that I have to import one image at the time into TGB. Tried to do it directly to the folder, but it doesn't recognize them when I open the project.

Also, building the linkage for the animation... the same thing. We should be able to select a bunch of images and then put it in the right order.

And in the animation, it should have a check button to activate the timeline backwards effect so it moves an animation forward and then backwards giving it a continuous effect.

#50 Thank you for this thread, guys!

Here's what I'd like to see:

* Isometric support. Or if you can't do that maybe a sort line rather than a sort point?

* Mount points for DTS objects. 3D support in TGB is already outstanding, but I would love to be able to use DTS models that can carry and animate weapons and other gear.

* Some sort of improvement to the coordinate system for TGB that supports manipulations through more than one axis. Not sure if this would be an absolute or relative system. Specifically: Rotating DTS objects that are at a simulated isometric projection is a real chore. I'd like to be able to set the initial orientation and then rotate around an axis relative to that orientation.

* Improved GUI builder that does less failing silently (so that there are less weird quirks like rollover buttons that fail to activate because the engine expects certain letters appended to your highlight, down and inactive image file names)

* Have the editor allow folders for organizing larger projects (especially for art)

* Echoing Cyrad - The ability to define an object across multiple levels.


AND THE BIGGEST ONE:

Some sort of a transition guide from TGB to T2D. I've spent 6 months using the editor and code to build up levels that heavily rely on t2dSceneObject. Although I'd really like to use T2D I've got no real way of knowing how far down the road that is. To hear that nothing will really be compatible makes me wonder how I should best be using my time.

#51 A couple of things I would like to see addressed are as follows:

Documentation - I know that Michael Perry is/will be working on this but it does not hurt to re-enforce the desire.

Along with normal documentation for those with source code, I would love to see the source better documented - example much of t2dpath, the actual code has little if no comments within the code. Basic programming - comment your code, never can have enough comments. Another example would be in t2dScenegraph.h: maxLayerSupported - comments are ///<Wow; don't even be tempted to change this! - maybe some more comments would be helpful to explain why - also that is the only really helpful comment within that part of the source, which is nothing.

Better path support and bug fixes fixed - Example see this post www.garagegames.com/community/forums/viewthread/76835 This was fixed by Melv May nearly a year ago and still we don't have the fix. (Please share this fix for those that have been waiting)

Also with paths - while creating them within in the builder we should be able to see and change on the fly their node number/position. Make it similar to your editing collision polygons, nodes are shown, you can add them and subtract them at will within the builder, showing their position number. Also when adding points it should want to join the nearest node, not some random one(usually node 0) causing extra lines within the path. If you don't understand what I mean, create a circular path - just try it, major pain.

And finally in the same post I linked Phillip O'Shea logged the bug into JIRA TGB-100. I understand you have a repository for bugs and a place for the team to work but that comment is meaningless unless we can see it. I do understand that some of the developers live in different parts of the world but access to see and track the bugs on our side would be great. That way when a bug is fixed we can look at the solution and apply the fix to our code. The community is strong here - maybe those hard to fix problems can be solved easily by others. If they could see the problems they could provide you solutions. Also if someone is building a game and having a ton of problems, instead of combing through the forums reading worthless posts by those that have little understanding of programming logic, they could check to see if there is a bug in the code. I spent about 4 hours with the path problem before I began to search the forums. Probably spent another 10 hours weeding through worthless posts - ran into shutts first post about the problem and almost skipped his second and third one. Just to find out that I was doing nothing wrong but there was actually a bug in the code that was fixed about a year ago and has not been released.

Ok done complaining - for now that is all. Overall TGB is a great engine and I look forward to T2D when it becomes available.

#52 I have to disagree with you on the code comments. All of the T2D API code I wrote myself and I am someone who writes a crazy amount of comments in code and always have. I didn't write the core engine, the t2dPath, t2dTextObject code nor the TGB builder and several other collaborative parts of TGB though.

With regards to saying why you shouldn't change that value: if you've ever done any advanced programming you should be aware that there are hundreds of these things in engines, most of which don't even have a warning not to change them. The warning is enough and serves it purpose.

Look through the t2DXXX code. There's a comment almost every other line. What kind of comments do you want? You cannot comment everything in code, nor should it be be the place to teach people how to use it.

I agree that you can never produce enough documentation but I do disagree strongly with "also that is the only really helpful comment within that part of the soucre, which is nothing".

#53 Oh yeah, I've wanted to get the bug reporting online and public for a long time. The biggest hurdle for it though is someone manning it to ensure it doesn't become a junkyard. Been there, done that.

I've used JIRA for many years, even in a multi-customer public facing setup and it's only worked if you can dedicate resources to vet the reports, remove duplicates, post referrals to existing fixes etc.

I'm not saying it's a bad idea (I completely agree with you and I'm looking into the possibilities of this in 2010), it's just that the resourcing is something that'd have to be organised first. Maybe the community managers would take this on, I'm not sure.

#54 I think bug reports should be publicly readable, and a bug report mail address should exist, manned by someone who enters (and vets) them. Avoids pollution and duplicates, but we mere mortals can still look up known issues.

#55 Would an official update from OpenAL 1.0 to OpenaAL 1.1 be out of the question? (Or has that already happened and I just haven't been paying attention?)

#56 I definitely would like to see better support and editor integration for sound effects and music. Things like:

- being able to easily set scene-wide music or ambient sound effects

- ability to drop positional sound objects into the scene and edit their properties in the builder

- properties like volume changes depending on the distance the listener is to the sound object (by defining a max/min sound radius for example), relative volume from each speaker depending on the direction the listener is in relation the object, etc.

In other areas:

- better art asset management, being able to organize things with a custom folder/sub-folder system within the builder

- separation between static sprites and scrollers in the builder. Not everything I import as a full image mode static sprite I want to have show up in the scroller tab too.


I'll leave it at that for now, thanks for listening.

#57 isometric tiles, definitely...that would be the cherry on top...:)

#58

• Audio - pause and resume sounds.
• Joystick support on Mac version - really needed for iPhone prototyping
• Web browser plugin.
• Documentation - complete working games, with carefully commented code and all the source assets, thoroughly tested on all platforms. Dissecting other games is the easiest way to learn an engine I find.
• Rotating camera.
• The current particle editor is really good - just add some more functionality like typing in exact values.
• Lighting effects like in the XNA TGB.
• SceneObject methods like setAutoRotation and setLinearVelocity that can change scale and opacity over time - to save me having to write them.
• Concave shape objects and collision bounds.

#59 Add drawing functions to draw 2D primitives.

Add an option to refresh TGB when the code was edited without having to restart it.

#60 Already been said but ctrl+alt+delete to not crash the app on Windows Vista and Windows 7. (how old is Vista now?)