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.
#22
Sort of. What I mean is that some animations don't work for different skeletons, because the models have different reference poses and/or scales/rotations etc on the bones. This would take a DSQ, and basically retarget that DSQ for a different skeleton. It could do this by determining at load time the differences from the two skeletons based on the initial poses of both reference skeletons.
You betcha.
01/10/2009 (7:52 am)
Quote:I'm not sure I follow you on this one...do you mean something like in the current T3D demo where it shares one set of DSQs with all of the different Players (except for the Elf who has animations built-in)?
Sort of. What I mean is that some animations don't work for different skeletons, because the models have different reference poses and/or scales/rotations etc on the bones. This would take a DSQ, and basically retarget that DSQ for a different skeleton. It could do this by determining at load time the differences from the two skeletons based on the initial poses of both reference skeletons.
Quote:
Would you guys be interested in hearing my thoughts on your suggestions? Even if I say that something isn't likely to happen or if I disagree with you on something?
You betcha.
#23
19. Blockers.
Blockers that don't cast shadows. Blockers that can block any (or all) of the following:
a) Missiles.
b) Players
c) AI Players
d) Vehicles (by kind)
e) Players that are not in vehicles.
f) Blockers that have a generic script callback that let you check specifically whether to include it in collision detection or not.
How does this differ from a trigger? It acts like a solid piece of the world. If you are blocked, then you can walk up against the blocker and skate along the edge like it were a wall.
Here's an example: You have a somewhat complicated DTS that's eye candy. You turn on polysoup, so your missiles have pixel-perfect collisions. Then, you put a blocker around it, so your player and ai players can't jump up inside the geometry. But firing around and through it still work like expected. You can also use this to keep players out of unsafe areas, or from driving cars into buildings, etc.
@Steve:
I debated whether to put them in. But the truth is, with the way the character animation is defined, this requires internal engine changes that I keep needing to do each upgrade. They seemed mostly appropriate for the majority of game types that involve actual players (fps, rpg, action adventure, etc), and then again don't need to be used if not needed.
01/10/2009 (8:09 am)
Some more for my list:19. Blockers.
Blockers that don't cast shadows. Blockers that can block any (or all) of the following:
a) Missiles.
b) Players
c) AI Players
d) Vehicles (by kind)
e) Players that are not in vehicles.
f) Blockers that have a generic script callback that let you check specifically whether to include it in collision detection or not.
How does this differ from a trigger? It acts like a solid piece of the world. If you are blocked, then you can walk up against the blocker and skate along the edge like it were a wall.
Here's an example: You have a somewhat complicated DTS that's eye candy. You turn on polysoup, so your missiles have pixel-perfect collisions. Then, you put a blocker around it, so your player and ai players can't jump up inside the geometry. But firing around and through it still work like expected. You can also use this to keep players out of unsafe areas, or from driving cars into buildings, etc.
@Steve:
Quote:I do kinda feel 4-7 and 10 are more "mods" than "base engine" -- not that I'd turn them down, I have to say
I debated whether to put them in. But the truth is, with the way the character animation is defined, this requires internal engine changes that I keep needing to do each upgrade. They seemed mostly appropriate for the majority of game types that involve actual players (fps, rpg, action adventure, etc), and then again don't need to be used if not needed.
#24
01/10/2009 (8:10 am)
Lots of built in post processing effects. 
#25
I for one welcome a true communication with a company employee on their thoughts on what should be in their product and what should not and why they think it should not. There will be some who will give you a hard time, but I for one appreciate hearing your thoughts.
My concerns.... Project creep.. Some of these are good ideas, but if it takes away from the delivery of T3D which we can start using and learning while some of the other things are being implemented later - as GG has always done in the past.
So.. I for one say fire away! You can always lock the thread if it gets out of hand:)
01/10/2009 (8:23 am)
@MattI for one welcome a true communication with a company employee on their thoughts on what should be in their product and what should not and why they think it should not. There will be some who will give you a hard time, but I for one appreciate hearing your thoughts.
My concerns.... Project creep.. Some of these are good ideas, but if it takes away from the delivery of T3D which we can start using and learning while some of the other things are being implemented later - as GG has always done in the past.
So.. I for one say fire away! You can always lock the thread if it gets out of hand:)
#26
Please! comment on the requests!
My wish list: Tools!! tools, tools!
After all the work you guys have done on the engine, it feels more obvious the lack of better editors; from the most basic thing of a better visual appeal, to the need of a high number of new RAD tools for rutinary actions (datablocks manipulation, general tweaking, effects creation, materials experimentation...).
Much of those are out there, just need a whole merge, huge revamp, and its insertion into a more flexible and more easily programable editor.
The Engine productivity would escalate enormously.
01/10/2009 (8:46 am)
@Matt, really cool post.Please! comment on the requests!
My wish list: Tools!! tools, tools!
After all the work you guys have done on the engine, it feels more obvious the lack of better editors; from the most basic thing of a better visual appeal, to the need of a high number of new RAD tools for rutinary actions (datablocks manipulation, general tweaking, effects creation, materials experimentation...).
Much of those are out there, just need a whole merge, huge revamp, and its insertion into a more flexible and more easily programable editor.
The Engine productivity would escalate enormously.
#27
For example; you want to create a racing game, you drag and drop the vehicle code into the repository code base. Drop in your cars within the game world, drop in the track that is based on the code, with track sequence numbers so you know if the car is going the wrong way, and it will display an on screen notification. If you want to change the cars you have the documentation to back it up and what is required to mod the new cars to the codebase for it to work. Drop in a speedometre, visual map, start and finish points and away you go.
Same for RTS, MMORPG, Space/Flying Simulator, FPS
Add in just the core components that are 100% bug free tried and tested.
Yes, you'll get quite a few clone games out there, but then it's down to the developer/artists and what experience they may have to make it different. I've seen many people give up, because they cant get anywhere with game development, and this will be a sure way of accomodating even the Indie/Hobbiest developer who is just starting out, with the path to making their own games or modify existing starter code bases. It will certainly be backed up by the documentation then, which should be flawless.
For the more advanced developer, more tools, deployment options.
Physics is a must, or even up to date physics integration instructions (not enough support or knowledge in this area)
More real-time development within the game world.
01/10/2009 (9:01 am)
Rapid Game Development, drag and drop in code components that can be modified, but quickly prototype your game. You get everything you need to create a basic game, then it's down to the developer to expand on this. Documentation for each drag and drop component.For example; you want to create a racing game, you drag and drop the vehicle code into the repository code base. Drop in your cars within the game world, drop in the track that is based on the code, with track sequence numbers so you know if the car is going the wrong way, and it will display an on screen notification. If you want to change the cars you have the documentation to back it up and what is required to mod the new cars to the codebase for it to work. Drop in a speedometre, visual map, start and finish points and away you go.
Same for RTS, MMORPG, Space/Flying Simulator, FPS
Add in just the core components that are 100% bug free tried and tested.
Yes, you'll get quite a few clone games out there, but then it's down to the developer/artists and what experience they may have to make it different. I've seen many people give up, because they cant get anywhere with game development, and this will be a sure way of accomodating even the Indie/Hobbiest developer who is just starting out, with the path to making their own games or modify existing starter code bases. It will certainly be backed up by the documentation then, which should be flawless.
For the more advanced developer, more tools, deployment options.
Physics is a must, or even up to date physics integration instructions (not enough support or knowledge in this area)
More real-time development within the game world.
#28
* Running dedicated servers on cheap Linux servers would save developers money.
* The more platforms you port code to, the less bugs you have in a codebase.
* If there is a new platform that you want to port a game to (PS4, Wii2, iPhone2) it would make porting WAY easier since the code is much more generic, and most newer platforms are more Linux like than Mac OS or Windows like.
* You might not get support from the GPL zealot Slashdot crowd, but you will get a lot more of the users that use Ogre3D and other open source engines by having all the bullet points they have.
* Since the engine is already ported to Mac OS, porting the engine to Linux, even though it will be a pain, is still not nearly as bad as porting the Windows only TGEA to Linux.
The only other thing I would request other than the normal "enhanced performance" or "better stability" is fullscreen support for Mac OS. And by the way, thanks a lot guys for getting Torque3D to work on Mac OS. I really appreciate all the effort you put into it. It really means a lot to the community.
01/10/2009 (9:08 am)
I know that no one wants to hear this, but I second ChunkyKs on Linux support. The reason for implementing this would be as follows:* Running dedicated servers on cheap Linux servers would save developers money.
* The more platforms you port code to, the less bugs you have in a codebase.
* If there is a new platform that you want to port a game to (PS4, Wii2, iPhone2) it would make porting WAY easier since the code is much more generic, and most newer platforms are more Linux like than Mac OS or Windows like.
* You might not get support from the GPL zealot Slashdot crowd, but you will get a lot more of the users that use Ogre3D and other open source engines by having all the bullet points they have.
* Since the engine is already ported to Mac OS, porting the engine to Linux, even though it will be a pain, is still not nearly as bad as porting the Windows only TGEA to Linux.
The only other thing I would request other than the normal "enhanced performance" or "better stability" is fullscreen support for Mac OS. And by the way, thanks a lot guys for getting Torque3D to work on Mac OS. I really appreciate all the effort you put into it. It really means a lot to the community.
#29
.Portals! exported in polysoup models or added in mission editor
.Atlas exporters for /maya/3dmax/ and others.
.Working examples of Cars,players,with animations to go along with the updated Docs for all supported 3d tools.
.Incorporated show tool/model viewer that has T3D shader support.
.ability to Bumpmap terrains <--i can dream cant I lol.
.full screen ambient occlusion, Dynamic lighting, stencil shadows,<----YES please.
01/10/2009 (9:31 am)
As a artist i wood like to see .Portals! exported in polysoup models or added in mission editor
.Atlas exporters for /maya/3dmax/ and others.
.Working examples of Cars,players,with animations to go along with the updated Docs for all supported 3d tools.
.Incorporated show tool/model viewer that has T3D shader support.
.ability to Bumpmap terrains <--i can dream cant I lol.
.full screen ambient occlusion, Dynamic lighting, stencil shadows,<----YES please.
#30
2. PhysX. Even though I never used it, I heard it was good.
3. Linux support would be nice
4. Built in melee system could help
5. Built in minimap
6. In-game particle editor system,
7. Conversation system may be nice
8. DTS shapes may use polys, not just triangles.
9. Night-Day system (a way to seamlessly change skyboxes at will)
10. Fix bugs for Mac (it is still buggy with the terrain system and other small parts).
11. Ingame xyz editors and scaling (I don't want to type numbers everytime I want to rotate or scale an object)
01/10/2009 (9:38 am)
1. A behavior system, similar to the one in TGB.2. PhysX. Even though I never used it, I heard it was good.
3. Linux support would be nice
4. Built in melee system could help
5. Built in minimap
6. In-game particle editor system,
7. Conversation system may be nice
8. DTS shapes may use polys, not just triangles.
9. Night-Day system (a way to seamlessly change skyboxes at will)
10. Fix bugs for Mac (it is still buggy with the terrain system and other small parts).
11. Ingame xyz editors and scaling (I don't want to type numbers everytime I want to rotate or scale an object)
#31
01/10/2009 (9:59 am)
Yeah, ability to enable stencil shadows on the players instead of shadowmaps, I agree. 
#32
Then optimize and modularize the existing code, adding in any of the suggestions already mentioned here. I like Jaimi's suggestions most of all. Other than that I most of all think the sgLighting kit should be scrapped (it was a great improvement for TGE but less than satisfying for TGEa) and a modern equivalent done for T3D, this should include real time lighting and shadowing for everything. I would be more than willing to pay for this.
01/10/2009 (11:40 am)
First fix all outstanding bugs (some of which have a several year history) and fill in missing and broken (stubbed/commented) features and provide that for existing customers. We shouldn't have to pay for this.Then optimize and modularize the existing code, adding in any of the suggestions already mentioned here. I like Jaimi's suggestions most of all. Other than that I most of all think the sgLighting kit should be scrapped (it was a great improvement for TGE but less than satisfying for TGEa) and a modern equivalent done for T3D, this should include real time lighting and shadowing for everything. I would be more than willing to pay for this.
#33
To me it seems Torque3D will be more than an engine, so I've added remarks to the website that is going to support the new engine as well. My list is the following:
Engine:
- Modular physics layer - do not add a physics implementation that can not be taken out by flipping a switch
- Modular AI layer with the option to connect several algorithms for path finding, learning, etc...
- Uniform shader based lighting and shadowing system (with transparent png support)
- Atlas is a great magnet to TGEA - until you find out that it's not exactly finished still. Add more blendable texture layers, 3d rotation for textures, and scalability, but even more importantly - add functions that help people use Atlas for what it promises to acomplish. Object stream on demand!
- Polysoup fixed (I strongly believe that there's a bug with rotated statics - still testing)
- Complete Mac version
- Linux support at least for dedicated server mode - we're indies, this is very important to us!
- AutoLOD generator for objects that don't have lods and polysoup meshes for objects that don't need detailed collision / shadowing - to optimize system resources.
- More and more useful general shaders like SSAO, DOF, Motionblur, etc...
- Make anything that's too game specific be switchable on / off in a modular way - and don't put the radar in - so I don't have to start stripping these out before I start making a physics simulation or a massively multiplayer 3d puzzle game. These things work for one game, but they bloat the engine for scenarios when such features are not needed.
- Very detailed and versatile camera system
- Better audio manageability
- A uniform replicator system that uses script callbacks for defining replication rules
Editors:
- Editor should not assert (ever) when an inverse range is given - just clamp the last value instead - I usually develop in debug mode, and I've lost a tremendous amount of data due to reversed random values and such...
- Tools to optimize game art for speed and bandwidth
- Mission editor: Drag/drop, wyswyg texture and model selector / loaders, customizable interface (ie. if I want the tree on the left and the properties on the right - which I really do)
- .obj, .x and .3ds static shape import. For simple objects like furniture and orher props, it would speed up the work of the artist and the developer by skipping dts conversion alltogether.
- Datablock editor, yes, though datablock storage and use would probably have to be reworked
Scripting:
- Add NULL, please, even if it just means ""
- Add %this and %datablock automatically
- Bring Torsion in-house, ship with engine, finish / include Elixir. Add engine source parsing to be able to better highlight script syntax. Online docs / comments on functions from within the editor - add community news to the editor itself, include any external editors, converters, viewers as a part of Torsion to make it the ultimate tool for Torque (through plugins). Include docs for plugin development.
Factory demos:
- A human starter model with correct proportions - Kork has got all artists creating 2.5-3m tall humans
- Terrainless demo mission, with Atlas for planets that can be zoomed onto, and generally more examples of what Atlas could really do.
Docs and website:
- Start a new resource system or update the current one to better be able to manage resources for a specific version.
- Include a very detailed change log and patch with newer versions. There's lots of time to be lost deciphering what those new changes mean. Mention functions, methods, flags, etc...
- Weekly patches - however small they would be - in between major versions
- Pay-for-view resources (instead of content packs), where it's easier for artists to sell their models. It would still be moderated, but would work more like a vendor system where GG acts as a shop and as a moderator while artists and developers would have access to updating their products. This is almost the same as content packs now, still it would trigger a _huge_ number of new resources.
- Host files images and video, so no external providers are required.
- Let users control who has access to a resource they have submitted.
And finally, I think it should actually perform better than its predecessors. :)
Thanks for reading through this.
-- Konrad
@Jaimi: That blocker is a great idea! You could do it with special (as in visible only when editing) terrain textures too, and it would be easier to edit (at least in legacy and megaterrain) the regions traversable to a certain group of objects. This would not work where there's no terrain though.
01/10/2009 (12:27 pm)
I think Torque3D should stay / become more of an engine and not a game demo. My opinion is the same when it comes to a conversation system, or a day-night system - they would make the engine bloated.. It's easier to develop on an engine that you can understand because it's clean. Anything that's considered to be a feature of a specific game genre should be a (better-than-now organized) resource instead, and should not have a place in the engine by default. Certain features that are widely used could be resources that come with the engine though.To me it seems Torque3D will be more than an engine, so I've added remarks to the website that is going to support the new engine as well. My list is the following:
Engine:
- Modular physics layer - do not add a physics implementation that can not be taken out by flipping a switch
- Modular AI layer with the option to connect several algorithms for path finding, learning, etc...
- Uniform shader based lighting and shadowing system (with transparent png support)
- Atlas is a great magnet to TGEA - until you find out that it's not exactly finished still. Add more blendable texture layers, 3d rotation for textures, and scalability, but even more importantly - add functions that help people use Atlas for what it promises to acomplish. Object stream on demand!
- Polysoup fixed (I strongly believe that there's a bug with rotated statics - still testing)
- Complete Mac version
- Linux support at least for dedicated server mode - we're indies, this is very important to us!
- AutoLOD generator for objects that don't have lods and polysoup meshes for objects that don't need detailed collision / shadowing - to optimize system resources.
- More and more useful general shaders like SSAO, DOF, Motionblur, etc...
- Make anything that's too game specific be switchable on / off in a modular way - and don't put the radar in - so I don't have to start stripping these out before I start making a physics simulation or a massively multiplayer 3d puzzle game. These things work for one game, but they bloat the engine for scenarios when such features are not needed.
- Very detailed and versatile camera system
- Better audio manageability
- A uniform replicator system that uses script callbacks for defining replication rules
Editors:
- Editor should not assert (ever) when an inverse range is given - just clamp the last value instead - I usually develop in debug mode, and I've lost a tremendous amount of data due to reversed random values and such...
- Tools to optimize game art for speed and bandwidth
- Mission editor: Drag/drop, wyswyg texture and model selector / loaders, customizable interface (ie. if I want the tree on the left and the properties on the right - which I really do)
- .obj, .x and .3ds static shape import. For simple objects like furniture and orher props, it would speed up the work of the artist and the developer by skipping dts conversion alltogether.
- Datablock editor, yes, though datablock storage and use would probably have to be reworked
Scripting:
- Add NULL, please, even if it just means ""
- Add %this and %datablock automatically
- Bring Torsion in-house, ship with engine, finish / include Elixir. Add engine source parsing to be able to better highlight script syntax. Online docs / comments on functions from within the editor - add community news to the editor itself, include any external editors, converters, viewers as a part of Torsion to make it the ultimate tool for Torque (through plugins). Include docs for plugin development.
Factory demos:
- A human starter model with correct proportions - Kork has got all artists creating 2.5-3m tall humans
- Terrainless demo mission, with Atlas for planets that can be zoomed onto, and generally more examples of what Atlas could really do.
Docs and website:
- Start a new resource system or update the current one to better be able to manage resources for a specific version.
- Include a very detailed change log and patch with newer versions. There's lots of time to be lost deciphering what those new changes mean. Mention functions, methods, flags, etc...
- Weekly patches - however small they would be - in between major versions
- Pay-for-view resources (instead of content packs), where it's easier for artists to sell their models. It would still be moderated, but would work more like a vendor system where GG acts as a shop and as a moderator while artists and developers would have access to updating their products. This is almost the same as content packs now, still it would trigger a _huge_ number of new resources.
- Host files images and video, so no external providers are required.
- Let users control who has access to a resource they have submitted.
And finally, I think it should actually perform better than its predecessors. :)
Thanks for reading through this.
-- Konrad
@Jaimi: That blocker is a great idea! You could do it with special (as in visible only when editing) terrain textures too, and it would be easier to edit (at least in legacy and megaterrain) the regions traversable to a certain group of objects. This would not work where there's no terrain though.
#34
Lets face it, torque as it is, is still tribes 2. For all people have hacked at it enough to make something else, its still tribes 2.
Torque's main issues are definitely in the area of either pipeline (creating usable assets) or usability (often just knowing the flow of code to get something useful done).
I'd suggest a root rewrite of the object core. As others have pointed out, make it so that you dont HAVE to have a networked game. Dump datablocks (always hated those), remove all of the extraneous cruft from the heirarchy and start again.
Features wise, having a nice modular set of the following:
Mesh drawing, both animated and static
Proper scene graph api
Deferred loading as a core feature (so you can do streaming, or net loading)
Physics integration, but in a way that you can change the implementation
A unified material system, along with material browsing and in-game placement
wxWidgets based editor
Half decent shadow map support, preferably PSSM or some variant thereof. Also allow transparency in shadows
Open file format (collada)
a standard shader format, read directly from a well known toolset (collada fx? or maybe the fx from Fx Composer)
AI (behavior tree, editing toolsets etc)
User selectable scripting languages
A half decent polysoup level format
Seriously, I think most of this is pretty obvious. If not, just look at Unity's feature set and do that :)
The problem I have, is that there is always this urge to add features, but the features are just adding to that internal cruft. Often they are next to useless (atlas for instance). Now I know it sounds like I'm bashing, but I think we all know the state of the codebase enough to admit that it currently whiffs a bit.
What I'm saying is that you need to think about making this a codebase of the future not of the past.
01/10/2009 (3:12 pm)
I think the main thing would be a refactoring of the codebase to bring it up to modern development standards. Things like unit tests in place, using composition rather than inheritance etc.Lets face it, torque as it is, is still tribes 2. For all people have hacked at it enough to make something else, its still tribes 2.
Torque's main issues are definitely in the area of either pipeline (creating usable assets) or usability (often just knowing the flow of code to get something useful done).
I'd suggest a root rewrite of the object core. As others have pointed out, make it so that you dont HAVE to have a networked game. Dump datablocks (always hated those), remove all of the extraneous cruft from the heirarchy and start again.
Features wise, having a nice modular set of the following:
Mesh drawing, both animated and static
Proper scene graph api
Deferred loading as a core feature (so you can do streaming, or net loading)
Physics integration, but in a way that you can change the implementation
A unified material system, along with material browsing and in-game placement
wxWidgets based editor
Half decent shadow map support, preferably PSSM or some variant thereof. Also allow transparency in shadows
Open file format (collada)
a standard shader format, read directly from a well known toolset (collada fx? or maybe the fx from Fx Composer)
AI (behavior tree, editing toolsets etc)
User selectable scripting languages
A half decent polysoup level format
Seriously, I think most of this is pretty obvious. If not, just look at Unity's feature set and do that :)
The problem I have, is that there is always this urge to add features, but the features are just adding to that internal cruft. Often they are next to useless (atlas for instance). Now I know it sounds like I'm bashing, but I think we all know the state of the codebase enough to admit that it currently whiffs a bit.
What I'm saying is that you need to think about making this a codebase of the future not of the past.
#35
I'd also like to see consistency in coding practices throughout the engine.
GUI updates. Many of the GUI controls have just been thrown into the engine will little regard for efficiency or tidy coding. It would be nice if they had an update.
I'd say a lot more, but I'd be repeating what is above.
01/10/2009 (3:26 pm)
At some point, I would like to see GG focus on reducing Torque 3D's footprint. Make it an engine that is far more friendly for lower powered devices.I'd also like to see consistency in coding practices throughout the engine.
GUI updates. Many of the GUI controls have just been thrown into the engine will little regard for efficiency or tidy coding. It would be nice if they had an update.
I'd say a lot more, but I'd be repeating what is above.
#36
Make it more like a 3D TGB, where you don't have to remove bloated features hardcoded into the source to get yours working. More power to scripting, you shouldn't have to do any source modification to make any type of game.
01/10/2009 (4:07 pm)
I agree with everything that Konrad Kiss said.Quote:I think Torque3D should stay / become more of an engine and not a game demo. My opinion is the same when it comes to a conversation system, or a day-night system - they would make the engine bloated.. It's easier to develop on an engine that you can understand because it's clean. Anything that's considered to be a feature of a specific game genre should be a (better-than-now organized) resource instead, and should not have a place in the engine by default. Certain features that are widely used could be resources that come with the engine though.[...]
Make it more like a 3D TGB, where you don't have to remove bloated features hardcoded into the source to get yours working. More power to scripting, you shouldn't have to do any source modification to make any type of game.
#37
- Terrain improvements - I enjoy Atlas. The size, visible range, and performance on it is very good. But it is a royal pain to get good looking terrain in it. It's near impossible to get a rasonable texel count up close. As a result what we wound up doing for The Repopulation was just using atlas to create terrain colors, and we added in a simple system that uses different detail textures based on where you are on the map (usually either grass or dirt/pavement). That helps, but its not perfect. What I'd like to see from Atlas is the ability to use either multiple detail textures out of the box, based on the underlying blend textures. Having the ability to place normal maps or use specular highlighting on terrain would be helpful too. Games like Vanguard and Age of Conan recently showed off some of the cool things that can be done with Specular and Normal mapping on terrains. Really looks breathtaking.
- A better shadow solution. The current solution works fine and performs well under most circumstances. Where it fails though is with transparent objects. Trees in particular, it's impossible to get a good shadow in that criteria. There are also other cases with animated shadows where it's really difficult to get them to display at all.
- A better solution for trees. I love the groundcover class, but what I'd really like to see now is Sickhead/Ben's tree pack make its way into T3D. Sickhead was showing this off in TGEA well over a year ago, and it looked great. But the it disappeared and they haven't responded to its thread since then. With GG contracting Sickhead out recently, I'd like to see this picked up.
- More procedural shaders. I love TGEA's procedural material system. In fact, I love it so much I pretty much refuse to use custom shaders. Rather than do that and having to account for different situations, I've taken to expanding the materials system for things like sunlight, color shifting, etc because you can just do it once and then not have to worry about lighting, glow, or other effects not working in other situations. What I'd like to see is more effects. Parallax mapping would be a nice addition to the materials system, as it provides much improved visuals at reasonable performance cost, and can easily fallback to normal mapping using the same textures.
01/10/2009 (9:10 pm)
The biggest improvements I'd like to see:- Terrain improvements - I enjoy Atlas. The size, visible range, and performance on it is very good. But it is a royal pain to get good looking terrain in it. It's near impossible to get a rasonable texel count up close. As a result what we wound up doing for The Repopulation was just using atlas to create terrain colors, and we added in a simple system that uses different detail textures based on where you are on the map (usually either grass or dirt/pavement). That helps, but its not perfect. What I'd like to see from Atlas is the ability to use either multiple detail textures out of the box, based on the underlying blend textures. Having the ability to place normal maps or use specular highlighting on terrain would be helpful too. Games like Vanguard and Age of Conan recently showed off some of the cool things that can be done with Specular and Normal mapping on terrains. Really looks breathtaking.
- A better shadow solution. The current solution works fine and performs well under most circumstances. Where it fails though is with transparent objects. Trees in particular, it's impossible to get a good shadow in that criteria. There are also other cases with animated shadows where it's really difficult to get them to display at all.
- A better solution for trees. I love the groundcover class, but what I'd really like to see now is Sickhead/Ben's tree pack make its way into T3D. Sickhead was showing this off in TGEA well over a year ago, and it looked great. But the it disappeared and they haven't responded to its thread since then. With GG contracting Sickhead out recently, I'd like to see this picked up.
- More procedural shaders. I love TGEA's procedural material system. In fact, I love it so much I pretty much refuse to use custom shaders. Rather than do that and having to account for different situations, I've taken to expanding the materials system for things like sunlight, color shifting, etc because you can just do it once and then not have to worry about lighting, glow, or other effects not working in other situations. What I'd like to see is more effects. Parallax mapping would be a nice addition to the materials system, as it provides much improved visuals at reasonable performance cost, and can easily fallback to normal mapping using the same textures.
#38
-Kill baked shadows and have Dynamic lighting shadows, so that when moving the sun around the world it updates the shadows?
-Event Script implementation like RPG Maker has for event driven games.
-I think some one said it before but an ability to start a base game thats non server client driven for single player games.
-3DS support
-The ability to make left and right manipulation of the terraform ground so you can make things like caves and underground pathways with out dts objects.
-Implemented active day and night sun movements with fixed shadow renderings
-AVI, MPG, or some other kind of video player for movie scenes and cinematic.
-Already build in common resources like swim, walk, run. climb, advanced camera
-Lastly, a RPG demo example for people that are not trying to make FPS, or Racing Games.
01/11/2009 (8:12 am)
Would you be able to add:-Kill baked shadows and have Dynamic lighting shadows, so that when moving the sun around the world it updates the shadows?
-Event Script implementation like RPG Maker has for event driven games.
-I think some one said it before but an ability to start a base game thats non server client driven for single player games.
-3DS support
-The ability to make left and right manipulation of the terraform ground so you can make things like caves and underground pathways with out dts objects.
-Implemented active day and night sun movements with fixed shadow renderings
-AVI, MPG, or some other kind of video player for movie scenes and cinematic.
-Already build in common resources like swim, walk, run. climb, advanced camera
-Lastly, a RPG demo example for people that are not trying to make FPS, or Racing Games.
#39
The available middleware solutions I've looked at (Kynapse, SpirOps, Pathengine) are really too expensive for an indie developer (Pathengine is 13,000 Euros for the full source version or 8500 euros for a binary only with interface layer).
It's something that I'd like to see have the features like:
- Automatic Navmesh generation given the abilty to tweak certain parameters to affect the generation, start with tessalation of the game world and then using something like Hertel-Mehlhorn to optimise the polygons.
- Navmesh Editor - no matter how good the automatic generation is there is always the need to manually tweak things or add additional information (hide points, places to jump from, areas to crouch, etc).
- Save generated navmesh (as something like mission.mesh) and then ability to load at runtime.
- Some example pathfinding/search routines eg. A* and Dijkstra
It's an area that takes a huge amount of work to get it working but would add a huge amount value to Torque in my opinion.
01/11/2009 (2:18 pm)
The main one for me would be a great pathfinding system, I am thinking one based on a navmesh (convex polygons) rather than waypoints as it gives you a lot of advantages for understanding the game world and where you can and can't go which is useful for more than just pathfinding like finding cover, working with dynamically changing worlds, etc.The available middleware solutions I've looked at (Kynapse, SpirOps, Pathengine) are really too expensive for an indie developer (Pathengine is 13,000 Euros for the full source version or 8500 euros for a binary only with interface layer).
It's something that I'd like to see have the features like:
- Automatic Navmesh generation given the abilty to tweak certain parameters to affect the generation, start with tessalation of the game world and then using something like Hertel-Mehlhorn to optimise the polygons.
- Navmesh Editor - no matter how good the automatic generation is there is always the need to manually tweak things or add additional information (hide points, places to jump from, areas to crouch, etc).
- Save generated navmesh (as something like mission.mesh) and then ability to load at runtime.
- Some example pathfinding/search routines eg. A* and Dijkstra
It's an area that takes a huge amount of work to get it working but would add a huge amount value to Torque in my opinion.
#40
Its based on Paul Tozour's specs on aigamedev.com so hopefully it will be the basis of further work at least.
01/11/2009 (2:45 pm)
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.
Torque Owner Giorgio Zanetti ( JoZ )
Corona Team
Quote: "Would you guys be interested in hearing my thoughts on your suggestions? Even if I say that something isn't likely to happen or if I disagree with you on something?"
Sure, I would! Since the starting "conversation" about pricing is yet started (and yet coming very hot) would be at least nice to see a list of the features you think to include... obviously some can be not released in the end but s also reasonable those cannot be more then a 30% of them ... Also I think as you GG employes are talking about how much work has been done there is a list of improvements yet in T3D and for maybe also list of things not yet done but you may list as "for sure" ... Or not?
I hope to see:
- Really big advancements in the editors
(let's say facilities, on the way of those rolled out by the PlasticGems series but a bit more polished)
- Fix to various lighting problem on interiors
- Include a material editor
- Include better audio managing capabilities (something on the road this is something we yet integrated many times on and on with every release)
- Built in Radar (tired of implement it all the time with often problem with new releases... it seems something pretty 70% of people use...)
- Built in full screen shaders
- Built in datablock editor
- Art pipeline improvements (further then Collada support) [ok I'm not very specific here but GG too when talking about it, so let us know some planned imporvements about that matter...]
The list can go on but I stay with those for the moment... :-D