What would you like to see addressed in Torque 3D?
by Matt Fairfax · in Torque Game Engine Advanced · 01/09/2009 (7:10 pm) · 281 replies
Hi all,
We've asked before but I thought I would take the opportunity to build a fresh list of what you would like to see addressed in Torque.
This can be everything from a long-standing bug, to a resource that is so useful you find yourself integrating it over and over, to a complete wish for something. Whatever it is we want to hear it!
Please keep in mind that just because you ask for it doesn't mean that you will get it. I am making no promises but it is always helpful to us to hear what you are interested in or concerned about.
Our community is hugely diverse and something that is absolutely essential and of the highest priority to you and your game may actually be something that other games never use so don't take it personally if we don't address your specific concern.
I am going to make sure that everything specific that you mention gets logged into our task tacker so that it can be prioritized and reviewed even if we don't get to it for Torque 3D. I say "specific" because statements like "vehicles suck" aren't useful to us however if you can narrow it down to "FlyingVehicles crash when they run into the ground too fast" then it is something we can look into.
I am very serious about this...if you ever want a chance at having your concerns addressed then you need to speak up.
We've asked before but I thought I would take the opportunity to build a fresh list of what you would like to see addressed in Torque.
This can be everything from a long-standing bug, to a resource that is so useful you find yourself integrating it over and over, to a complete wish for something. Whatever it is we want to hear it!
Please keep in mind that just because you ask for it doesn't mean that you will get it. I am making no promises but it is always helpful to us to hear what you are interested in or concerned about.
Our community is hugely diverse and something that is absolutely essential and of the highest priority to you and your game may actually be something that other games never use so don't take it personally if we don't address your specific concern.
I am going to make sure that everything specific that you mention gets logged into our task tacker so that it can be prioritized and reviewed even if we don't get to it for Torque 3D. I say "specific" because statements like "vehicles suck" aren't useful to us however if you can narrow it down to "FlyingVehicles crash when they run into the ground too fast" then it is something we can look into.
I am very serious about this...if you ever want a chance at having your concerns addressed then you need to speak up.
About the author
I am a Game Designer at PopCap who has worked on PvZ Adventures, PvZ2, Peggle Blast, and Bejeweled Skies. I am an ex-GarageGames employee who helped ship TGE, TGEA, Torque 3D, and Constructor.
#42
01/11/2009 (3:10 pm)
Broken URL code 
#43
Phil - sounds like it might be something promising indeed, I'm familiar with Paul Tozour's article in the AI Game Programming Wisdom books on nav mesh generation will have to hop over to aigamedev.com and see his posts over there and if there's some useful info.
01/11/2009 (4:39 pm)
Quote:
Andy: I've got a student making an open source library for exactly that. Its not torque specific, but if whatever T3D ends up being uses a polysoup level, this solution will work for it.
Its based on Paul Tozour's specs on aigamedev.com so hopefully it will be the basis of further work at least.
Phil - sounds like it might be something promising indeed, I'm familiar with Paul Tozour's article in the AI Game Programming Wisdom books on nav mesh generation will have to hop over to aigamedev.com and see his posts over there and if there's some useful info.
#44
2) Smaller examples that are the bare minimum code required to implement a small game.
3) Follow all of the rules outlined in Scott Meyers effective C++ books and the Pragmatic Programmer book.
4) Player -> ShapeBase -> GameBase -> SceneObject -> NetObject -> SimObject -> ConsoleObject -> SimComponent is badly designed. You should use composition instead of inheritance for most of these classes. (That's just one example of the many places where the OO design can be improved).
5) Nicely written and fully documented API (see #1)
6) Improve the documentation. Clean house with the doxygen comments. For places where good documentation exists in TDN or elsewhere, provide links in the source code. This makes it so that users can also improve the primary source of documentation.
7) Make it so that places where someone might want to extend or replace functionality are easy to break apart without breaking a lot of code. (new model types, different physics implementations, different DataBlock caching and loading schemes, different mission loaders, different scripting engines, etc).
GG can't implement everything, but making a nicer API so that it's easier for end game devs to interface and extend would go a long way.
For instance, instead of adding Collada support, provide an example that shows how to add Collada support without having to change a single line of engine code.
01/11/2009 (4:39 pm)
1) Abstract interfaces with class factories for all major outward facing components.2) Smaller examples that are the bare minimum code required to implement a small game.
3) Follow all of the rules outlined in Scott Meyers effective C++ books and the Pragmatic Programmer book.
4) Player -> ShapeBase -> GameBase -> SceneObject -> NetObject -> SimObject -> ConsoleObject -> SimComponent is badly designed. You should use composition instead of inheritance for most of these classes. (That's just one example of the many places where the OO design can be improved).
5) Nicely written and fully documented API (see #1)
6) Improve the documentation. Clean house with the doxygen comments. For places where good documentation exists in TDN or elsewhere, provide links in the source code. This makes it so that users can also improve the primary source of documentation.
7) Make it so that places where someone might want to extend or replace functionality are easy to break apart without breaking a lot of code. (new model types, different physics implementations, different DataBlock caching and loading schemes, different mission loaders, different scripting engines, etc).
GG can't implement everything, but making a nicer API so that it's easier for end game devs to interface and extend would go a long way.
For instance, instead of adding Collada support, provide an example that shows how to add Collada support without having to change a single line of engine code.
#45
Could you include a project creator with a barebones project with nothing in it but the player and the flat mission?
That way you know you are using only objects and features that you need into your project and not having to shuffle through pre-added scripts?
01/11/2009 (4:42 pm)
I also wanted to add. Could you include a project creator with a barebones project with nothing in it but the player and the flat mission?
That way you know you are using only objects and features that you need into your project and not having to shuffle through pre-added scripts?
#46
- point 2 : very very important
- point 4
- point 5 & 6 : although some good progress have arrived thanks to Michael Perry's work
Nicolas Buquet
www.buquet-net.com/cv/
01/12/2009 (12:37 am)
I add my voice to Tony Richards - point 2 : very very important
- point 4
- point 5 & 6 : although some good progress have arrived thanks to Michael Perry's work
Nicolas Buquet
www.buquet-net.com/cv/
#47
01/12/2009 (3:49 am)
One very important... Atlas terrain editing capabilities 
#48
01/12/2009 (3:58 am)
One other thing. In 1.7.1 the performance was very good. AtlasDemo for example ran at 450-500 fps on my system (6600 dual core, 2 gigs of ram, nvidia 8800 gts on vista). 1.8 on the same system had a 250% frame rate drop. Others have complained in blogs and posts of similar hits. Mac support was great and all, but a 250% frame rate drop is far too much to give up on the PC. This either needs to be improved upon, or there should be a fallback option with whatever is bottlenecking it. As is, we elected not to upgrade to 1.8 because it offered little in the way of new features, but a massive frame rate drop. If the new TGEA mechanisms are built on top of the new GFX2, then this is something that will definately need looking into. 
#49
01/12/2009 (4:32 am)
Im guessing since your asking us for our input on what we want to see, T3D wont be out for a lonnnnng time?
#50
01/12/2009 (4:34 am)
I think they are looking for something that can wrap up this update nicely for everyone and give them more incite to the future. I already know they are LOLing at half of the things posted here cause they more likely have no time to address all these things. But I'm sure somethings may be addressed or might already be addressed for the next release.
#51
01/12/2009 (4:38 am)
In that case, I would really like to see the lighting system caught up to modern standards. Transparent textures should cast and receive shadowing. Dynamic shadows should work on any shape regardless of tri count. I would also like to see FSAA work with HDRL and bloom. I personally think those are realistic.
#52
Doesn't sound too far off to me.
01/12/2009 (6:27 am)
@Adam: From Brett's blog: Quote:"My ideal outcome is that in mid-2009, everyone who wants to continue working with Torque in the future will be using Torque 3D and sharing resources and knowledge with the rest of the community."
Doesn't sound too far off to me.
#53
It would help to have an example to look at when you you try and create a new renderable object.
TGEA has gone through some changes here lately that leaves me puzzled as to how TGEA expects an object to be setup in order to render it.
One thing the FxRenderobject was good at was giving you a good idea of how to setup a renderable object.
It's documentation is clear and concise for TGE. TGEA not so much.
One problem I had with it was it made reference to being able to be setup as a mirror like object but as far as I can tell no one every documented how to achieve this effect.
My main reason for wanting this to be updated for TGEA is the are a number of TGE resources that don't work for TGEA for no other reason than not knowing how to setup the rendering for TGEA.
The Cloth Physics resource is a good example.
As for other things I like Jaimi McEntire's suggestions.
New Physics for vehicles would be nice.
And as always I think the Atlas system has a lot of potential.
01/12/2009 (9:44 am)
One thing I would like to see is the the FxRenderobject maintained for all future releases of Torque.It would help to have an example to look at when you you try and create a new renderable object.
TGEA has gone through some changes here lately that leaves me puzzled as to how TGEA expects an object to be setup in order to render it.
One thing the FxRenderobject was good at was giving you a good idea of how to setup a renderable object.
It's documentation is clear and concise for TGE. TGEA not so much.
One problem I had with it was it made reference to being able to be setup as a mirror like object but as far as I can tell no one every documented how to achieve this effect.
My main reason for wanting this to be updated for TGEA is the are a number of TGE resources that don't work for TGEA for no other reason than not knowing how to setup the rendering for TGEA.
The Cloth Physics resource is a good example.
As for other things I like Jaimi McEntire's suggestions.
New Physics for vehicles would be nice.
And as always I think the Atlas system has a lot of potential.
#54
01/12/2009 (10:12 am)
The mission editor desperately needs a nudge tool, one that can be toggled on and off by holding down a key. It can be a pain to change the move scale back and forth every time you need finer control. I had one coded at one time and was planning to release it as a resource, I may still do that if I can ever dig it up again, but its definitely something that everyone would get a lot of use out of if it were stock.
#55
I am going to be digging into them bit-by-bit over the course of the next couple of days (you know...in between actually working on Torque 3D =P).
I do want to point out that I am going to have to skirt around some issues a little since we have a marketing plan to announce certain features at certain times to maximize their impact. I know some of you will disagree with me sitting on some things for marketing's sake but, trust me, it is really worth it for GG's business which ultimately makes it worth it for you guys.
01/12/2009 (11:24 am)
Good stuff guys!I am going to be digging into them bit-by-bit over the course of the next couple of days (you know...in between actually working on Torque 3D =P).
I do want to point out that I am going to have to skirt around some issues a little since we have a marketing plan to announce certain features at certain times to maximize their impact. I know some of you will disagree with me sitting on some things for marketing's sake but, trust me, it is really worth it for GG's business which ultimately makes it worth it for you guys.
#56
off the top, my requests:
big ticket items, from most to least feasible:
* implement mission & datablock caching.
this is a tricky hunk of work, but critical for a real-world application, especially if it uses AFX.
* replace torquescript with javascript.
* integrate gecko or another HTML rendering engine, replacing GuiMLTextCtrl.
(this may requite a more robust HTTP object, see below)
* integrate some SWF engine to effectively replace the GuiControl system.
medium ticket items, these are totally feasible, imo:
* replace HTTPObject with a libCurl implementation.
* scrape the resources for bugfixes and improvements to various components. there are *tons* of improvements just waiting to be integrated into trunk.
** this query might be a good place to start. ;)
* a hierarchical scenegraph, where the cup can be a child of the table and if you transform the table, the cup transforms too. i believe there is a resource for this. (by Ramen-Sama ?)
* platforms you can ride on - DTS & DIF. (again, Ramen-Sama pretty much knocked this one)
* provide a system for changing clothes & appearances of characters.
there are numerous resources for this; GG should take the lead and "bless" an approach.
personally i recommend using mesh-hiding and the advanced texture replacement code in combination with a "sku" system which defines clothing items. ie, don't ghost down the names of the meshes and the names of the textures to use, just ghost a list of SKUs.
small items:
* support for alpha in all guiControls, and inherit alpha from parent.
** eg so you can set the alpha of an entire dialog, not just one control at a time.
* improve player-vs-player and player-vs-environment collision.
* provide a default doors system.
true it's not hard to code your own once you've got a few months of torque under your belt, but it's something all noobs want pretty much right away.
* improve the out-of-the-box compilation story.
the last time i went to compile TGE on VS, i was shocked at how much time & effort it took me to get a vanilla engine to compile.
01/12/2009 (11:28 am)
Wow, i pity the fool who has to condense this thread to a digestible list !off the top, my requests:
big ticket items, from most to least feasible:
* implement mission & datablock caching.
this is a tricky hunk of work, but critical for a real-world application, especially if it uses AFX.
* replace torquescript with javascript.
* integrate gecko or another HTML rendering engine, replacing GuiMLTextCtrl.
(this may requite a more robust HTTP object, see below)
* integrate some SWF engine to effectively replace the GuiControl system.
medium ticket items, these are totally feasible, imo:
* replace HTTPObject with a libCurl implementation.
* scrape the resources for bugfixes and improvements to various components. there are *tons* of improvements just waiting to be integrated into trunk.
** this query might be a good place to start. ;)
* a hierarchical scenegraph, where the cup can be a child of the table and if you transform the table, the cup transforms too. i believe there is a resource for this. (by Ramen-Sama ?)
* platforms you can ride on - DTS & DIF. (again, Ramen-Sama pretty much knocked this one)
* provide a system for changing clothes & appearances of characters.
there are numerous resources for this; GG should take the lead and "bless" an approach.
personally i recommend using mesh-hiding and the advanced texture replacement code in combination with a "sku" system which defines clothing items. ie, don't ghost down the names of the meshes and the names of the textures to use, just ghost a list of SKUs.
small items:
* support for alpha in all guiControls, and inherit alpha from parent.
** eg so you can set the alpha of an entire dialog, not just one control at a time.
* improve player-vs-player and player-vs-environment collision.
* provide a default doors system.
true it's not hard to code your own once you've got a few months of torque under your belt, but it's something all noobs want pretty much right away.
* improve the out-of-the-box compilation story.
the last time i went to compile TGE on VS, i was shocked at how much time & effort it took me to get a vanilla engine to compile.
#57
20. Doors & Platforms. Working scripted door/platform system. Standard doors, sliding doors, trigger driven. Platforms that go up and down. Platforms that follow a path. The sort of artist-driven doors & platforms that were in the Quake engines.
21. Generic plugin/DLL loading system, that can register itself with the engine to provide functionality in the DLL to the scripting system. This would be especially good if you end up with a non-source version, so people could still get addons.
For example:
A Database system, self contained in a DLL. Exposes the connection methods to script, as well as methods to load & save data and run stored procedures.
01/12/2009 (11:30 am)
More:20. Doors & Platforms. Working scripted door/platform system. Standard doors, sliding doors, trigger driven. Platforms that go up and down. Platforms that follow a path. The sort of artist-driven doors & platforms that were in the Quake engines.
21. Generic plugin/DLL loading system, that can register itself with the engine to provide functionality in the DLL to the scripting system. This would be especially good if you end up with a non-source version, so people could still get addons.
For example:
A Database system, self contained in a DLL. Exposes the connection methods to script, as well as methods to load & save data and run stored procedures.
#58
Saying that is like shaking the tasty stake at the wolves. So mean and so dangerous... When will everything be announced can you tell us that at least?
01/12/2009 (11:30 am)
@Matt Saying that is like shaking the tasty stake at the wolves. So mean and so dangerous... When will everything be announced can you tell us that at least?
#59
* Bring back video playback
* General improvement of and/or add to the existing in game editor tools. Some of the suggestions for the World and GUI editors are really good. Expand the Particle Editor to include projectile/explosion datablock editing, and improve/fix it's file save. Material editor. Datablock editor.
* Modern real-time lighting/shadowing for everything.
* Take terrain to the next level and beyond. Things like detail map or bump mapping on a per texture basis. True vertical displacement without texture distortion. Curved terrain blocks.
* Create "plug-in ready" sub-sytems sort of like GFX & SFX for things like object loaders, data handling/management, AI, etc. I think this would make it much easier to introduce new custom components without duplicating, breaking, or interfering with something already in place.
* Built in code switches so that every component/feature can be toggled on/off as needed for each project. This way you could still retain a robust feature set yet have the ability to scale the feature set down if certain components are unwanted or seem like too much "bulk" or "fluff" for a particular developer. Kind of ties in with the plug-in sub system idea.
01/12/2009 (11:34 am)
* New model & animation sources for more than the top tier of 3d content creation tools. ie: pre-built rigs for apps such as Blender, MilkShape, Houdini, etc.* Bring back video playback
* General improvement of and/or add to the existing in game editor tools. Some of the suggestions for the World and GUI editors are really good. Expand the Particle Editor to include projectile/explosion datablock editing, and improve/fix it's file save. Material editor. Datablock editor.
* Modern real-time lighting/shadowing for everything.
* Take terrain to the next level and beyond. Things like detail map or bump mapping on a per texture basis. True vertical displacement without texture distortion. Curved terrain blocks.
* Create "plug-in ready" sub-sytems sort of like GFX & SFX for things like object loaders, data handling/management, AI, etc. I think this would make it much easier to introduce new custom components without duplicating, breaking, or interfering with something already in place.
* Built in code switches so that every component/feature can be toggled on/off as needed for each project. This way you could still retain a robust feature set yet have the ability to scale the feature set down if certain components are unwanted or seem like too much "bulk" or "fluff" for a particular developer. Kind of ties in with the plug-in sub system idea.
#60
01/12/2009 (11:37 am)
A call back for on animation playthread finished? to eliminate the scheduling and manual stop of a one time animation? 
Torque Owner Kory Imaginism
innovative imaginations
1. All Gerhard Work LOL
2. Real Time Radiosity Kit and real time global illumination
3. Depth of Field
4. Motion-Blur
5. FX blood splash effect
6. FX water Splash effect
7. Day and Night System
8. parallax mapping
9. parallax mapping terrain
10. realtime volumetric clouds
11. Simul Weather
12. Simul Weather - Lightning
13. Simul Weather - Lightning Night
14. Game Mechanics Kit
15. hair simulation
16. Cloth simulation
17. PhysX Breakable
18. Road and Path Tool
19. (DMM) Digital Molecular Matter
thank you