Torque 2: Hopes and Dreams
by Chad Kilgore · in General Discussion · 10/22/2007 (10:17 pm) · 29 replies
With the plan for Torque 2 to be a "ground up re-factor of the entire architecture," this thread is aims to be a central set of features Torque hobbyists and developers hope to see in Torque 2. Hopefully, GarageGames will respond kindly to these hopes for Torque 2.
...I know I'm excited.
...I know I'm excited.
#2
10/23/2007 (6:22 am)
That sounds like a primary candidate for a resource management component. 
#3
10/23/2007 (7:49 am)
As long as they keep TorqueScript and don't enforce source modification for making gameplay element, I'll be happy.
#4
10/23/2007 (8:57 am)
As David mentions, Chad's requests are not engine architecture, but application (game) specific. There are no plans by us to work on either of those features as part of the core engine for Torque 2. 
#5
I think it's important for people to realise (as has been said many times before) that Torque isn't a game-in-a-box solution... It's merely an engine on which to build your game. It's a starting point, an uncooked chicken breast, an unopened box of lego, the foundations of a house, a fully clothed member of the opposite sex... You know where you want to go with it and you need to work at getting to that point.
That said, keep the ideas rolling into this thread - I love a good ol' speculation thread :-D
10/23/2007 (9:22 am)
Fair point Stephen.I think it's important for people to realise (as has been said many times before) that Torque isn't a game-in-a-box solution... It's merely an engine on which to build your game. It's a starting point, an uncooked chicken breast, an unopened box of lego, the foundations of a house, a fully clothed member of the opposite sex... You know where you want to go with it and you need to work at getting to that point.
That said, keep the ideas rolling into this thread - I love a good ol' speculation thread :-D
#6
Like I said before, I can finesse Torque, with no source modification, to play videos while a mission is being loaded in the background. I don't know if while designing Torque they asked themselves "How would I play videos while a mission is loading" but again, I think it would be wise for GarageGames to consider it for Torque 2.
10/23/2007 (9:27 am)
I understand that GarageGames may/will not implement these features. But I think it would be wise of GarageGames to consider commonly found features in games while designing Torque 2. In doing so, it allows for the community to more quickly implement their games. My hope is that while designing Torque 2, its designers will ask "If I were a developing a game and I wanted to do X, I would need to do Y to implement it." In keeping design more abstract, Torque 2 development can still be about creating a solid engine, but the engine won't get in the way of its future users.Like I said before, I can finesse Torque, with no source modification, to play videos while a mission is being loaded in the background. I don't know if while designing Torque they asked themselves "How would I play videos while a mission is loading" but again, I think it would be wise for GarageGames to consider it for Torque 2.
#7
I personally think it is the good way to avoid cloned games all over the place.
Torque help you by getting out of the way the tedious technical hassle of making an engine and editors from scratch, but to make your own game you'll still need to make your own art and gameplay element (and, your own style of loading screen), etc. ^^'
10/23/2007 (5:08 pm)
TGB doesn't have any gameplay feature out of the box, and yet it is the most easy to learn of the bunch (well, there's some stock behaviors for 1.5, but the statement is true for 1.1.3 which is still widely used). I personally think it is the good way to avoid cloned games all over the place.
Torque help you by getting out of the way the tedious technical hassle of making an engine and editors from scratch, but to make your own game you'll still need to make your own art and gameplay element (and, your own style of loading screen), etc. ^^'
#8
1. Multiple Terrain Support (with ability to edit in real time to make seamless tiling easier) or incorporation of Atlas in to TGE with ability to modify terrain in editor (real time).
2. Texture Sizes up to 1024 x 1024 ... oh what the heck, 4096 x 4096
3. Full GLSL support (or the like)
4. FULL Q3 style BSP map support (i.e. curved mesh walls and bevels). I've only created about a hundred levels for Quake 3 and other games of that type. Probably a licensing issue.
5. Improvement on existing physics engine, or all new physics engine.
What I've managed to h4x0r:
1. Just made TGE support a terrain block size of 16/32 with correct rendering of water.
2. Settled for spec TGE texture size, just got creative, added support for 15 terrain textures, used detail mapping from TLK, so on...
3. Implemented CG Shader Language support. Normal Mapping, Bump Mapping, Dot 3 Bumpmapping on all DIF, DTS, and terrain objects.
4. Added Q3 style mesh support, works semi-well, has some problems with arches and certain end-caps of high detail.
5. Tried ODE, even got the PhysX SDK and added full physics support with my BFG PhysX card. ODE is nice, but just adds to your licensing headache. PhysX is freaking awesome, but requires people to have the hardware.
10/23/2007 (6:13 pm)
What I want to see in Torque 2:1. Multiple Terrain Support (with ability to edit in real time to make seamless tiling easier) or incorporation of Atlas in to TGE with ability to modify terrain in editor (real time).
2. Texture Sizes up to 1024 x 1024 ... oh what the heck, 4096 x 4096
3. Full GLSL support (or the like)
4. FULL Q3 style BSP map support (i.e. curved mesh walls and bevels). I've only created about a hundred levels for Quake 3 and other games of that type. Probably a licensing issue.
5. Improvement on existing physics engine, or all new physics engine.
What I've managed to h4x0r:
1. Just made TGE support a terrain block size of 16/32 with correct rendering of water.
2. Settled for spec TGE texture size, just got creative, added support for 15 terrain textures, used detail mapping from TLK, so on...
3. Implemented CG Shader Language support. Normal Mapping, Bump Mapping, Dot 3 Bumpmapping on all DIF, DTS, and terrain objects.
4. Added Q3 style mesh support, works semi-well, has some problems with arches and certain end-caps of high detail.
5. Tried ODE, even got the PhysX SDK and added full physics support with my BFG PhysX card. ODE is nice, but just adds to your licensing headache. PhysX is freaking awesome, but requires people to have the hardware.
#9
How does ODE's BSD license add to licensing headache ?
PhysX does not require the hardware.
10/23/2007 (6:25 pm)
@TrentonHow does ODE's BSD license add to licensing headache ?
PhysX does not require the hardware.
#10
@Benjamin L. Grauer
Very good points on the style of TGB. For a nice example of component prototypes, take a look at Behaviors in TGB and the engine design of TorqueX. While TGB Behaviors are gameplay components by design, the component architecture in TorqueX (and in Torque 2, most likely) is much more far reaching, including an abstraction of a number of core modules. Right now what is still hazy about Torque 2 is just what the core engine encompasses and what components will encompass.
Often times, depending on the intricacy of your game, you will often need to create a large portion of C++ functionality. Currently in Torque, depending on what you are changing, this can be a nightmare of interwoven dependencies. Component-based architecture allows developers to plug the pieces they need and build the interfaces between modules rather than digging deep into the core engine source.
Some things will, of course, require engine source changes as people come up with entirely new ideas that tear into the core and change it significantly. But with the transparency planned, teams can understand where they will need to change the core interfaces, or the core itself, and how to best work with components that they need in their games.
@Trenton
Terrain should be a component so that you can add your own, either through a licensed provider of terrain tech or rolling your own.
I'm more for supporting arbitrarily sized textures (no limits) with a heafty note to the art team that they need to test video cards extensively to make sure that the cards can perform with the textures that they are generating. I, however, do not know the engine implications of arbitrarily sized textures. But if there are no internal limits (but good practice suggestions to give to professional artists), then as the hardware grows, it can grow with it. I'm a programmer, but I'm not a graphics programmer so I do not know how this would affect the current generation and the next generation of hardware.
Which would be a rendering component, I believe. Like adding in the OGRE renderer or DX10.
Unless you created it from scratch without looking at the Quake 3 or Radiant Source (and there are a ton of sites with the algorithms behind it), you would have to purchase a $10k single-title license for the Q3 engine to comply with the license since Q3's source is under the GPL but available for alternate closed-source licensing.
Physics is another prime area for a component architecture. Havok, Tokamak, PhysX or ODE...all of them would be prime component candidates. And the BSD license is a very nice license. I'm not sure how it would add to the headache. I guess it could make the credits or license file somewhat longer since you need to include the BSD notice...but you do not have to include the source unless you choose...and then you have to abide by the first clause. The GPL wouldn't be a headache...it just doesn't work in a closed-source environment. And as ArmedGeek noted, PhysX doesn't require a hardware card. It just performs better with one (of course!).
10/23/2007 (7:00 pm)
It might be helpful if everyone reads Stephen Zepp's blog about Torque 2 and transparent development before we begin discussing it in terms of a simple refactor of the current engine instead of a massive componentized overhaul.@Benjamin L. Grauer
Quote:Torque help you by getting out of the way the tedious technical hassle of making an engine and editors from scratch, but to make your own game you'll still need to make your own art and gameplay element (and, your own style of loading screen), etc. ^^'
Very good points on the style of TGB. For a nice example of component prototypes, take a look at Behaviors in TGB and the engine design of TorqueX. While TGB Behaviors are gameplay components by design, the component architecture in TorqueX (and in Torque 2, most likely) is much more far reaching, including an abstraction of a number of core modules. Right now what is still hazy about Torque 2 is just what the core engine encompasses and what components will encompass.
Often times, depending on the intricacy of your game, you will often need to create a large portion of C++ functionality. Currently in Torque, depending on what you are changing, this can be a nightmare of interwoven dependencies. Component-based architecture allows developers to plug the pieces they need and build the interfaces between modules rather than digging deep into the core engine source.
Some things will, of course, require engine source changes as people come up with entirely new ideas that tear into the core and change it significantly. But with the transparency planned, teams can understand where they will need to change the core interfaces, or the core itself, and how to best work with components that they need in their games.
@Trenton
Quote:1. Multiple Terrain Support (with ability to edit in real time to make seamless tiling easier) or incorporation of Atlas in to TGE with ability to modify terrain in editor (real time).
Terrain should be a component so that you can add your own, either through a licensed provider of terrain tech or rolling your own.
Quote:2. Texture Sizes up to 1024 x 1024 ... oh what the heck, 4096 x 4096
I'm more for supporting arbitrarily sized textures (no limits) with a heafty note to the art team that they need to test video cards extensively to make sure that the cards can perform with the textures that they are generating. I, however, do not know the engine implications of arbitrarily sized textures. But if there are no internal limits (but good practice suggestions to give to professional artists), then as the hardware grows, it can grow with it. I'm a programmer, but I'm not a graphics programmer so I do not know how this would affect the current generation and the next generation of hardware.
Quote:3. Full GLSL support (or the like)
Which would be a rendering component, I believe. Like adding in the OGRE renderer or DX10.
Quote:4. FULL Q3 style BSP map support (i.e. curved mesh walls and bevels). I've only created about a hundred levels for Quake 3 and other games of that type. Probably a licensing issue.
Unless you created it from scratch without looking at the Quake 3 or Radiant Source (and there are a ton of sites with the algorithms behind it), you would have to purchase a $10k single-title license for the Q3 engine to comply with the license since Q3's source is under the GPL but available for alternate closed-source licensing.
Quote:5. Improvement on existing physics engine, or all new physics engine.
Physics is another prime area for a component architecture. Havok, Tokamak, PhysX or ODE...all of them would be prime component candidates. And the BSD license is a very nice license. I'm not sure how it would add to the headache. I guess it could make the credits or license file somewhat longer since you need to include the BSD notice...but you do not have to include the source unless you choose...and then you have to abide by the first clause. The GPL wouldn't be a headache...it just doesn't work in a closed-source environment. And as ArmedGeek noted, PhysX doesn't require a hardware card. It just performs better with one (of course!).
#11
I just feel the physics portion of Torque has been ignored far too long and someone with good programming credentials and titles under their belt would be able to cough up a physics engine worthy of being called its own physics engine (i.e. ODE, HAVOK, PhysX). Hmm... TPE maybe. I've tried but failed at making any "drastic" improvements to the existing physics in TGE. Like I said, adding libraries is great, but I want my INDIE title to stay as INDIE as possible.
@David Blake
I appreciate all of the detailed replies, thanks again. :)
10/23/2007 (7:00 pm)
@ArmedGeek Quote:PhysX does not require the hardware.True, PhysX does not require the hardware to run half-lame (IMHO) compared to what it runs like with the PhysX hardware installed. It is still definitly a very viable and highly recommended option for any game developer.
Quote:How does ODE's BSD license add to licensing headache?Let me clarify. ODE's BSD license gets in the way of my EGO. ;) So that pretty much rules out PhysX or any other licensed software I have to credit in my own "INDIE" creation. That is of course with the exception of the GarageGames founders/co-founders/employees/associates/members/contributers/janitors so on and so forth. We have a great engine to work with and a great community that has brought us many improvements and additions to the engine and content.
I just feel the physics portion of Torque has been ignored far too long and someone with good programming credentials and titles under their belt would be able to cough up a physics engine worthy of being called its own physics engine (i.e. ODE, HAVOK, PhysX). Hmm... TPE maybe. I've tried but failed at making any "drastic" improvements to the existing physics in TGE. Like I said, adding libraries is great, but I want my INDIE title to stay as INDIE as possible.
@David Blake
Quote:It might be helpful if everyone reads Stephen Zepp's blog.Oh wow ... maybe I'll shut my big mouth, lol. That's pretty funny, can't believe I missed this. Thanks for pointing us in that direction.
Quote:Terrain should be a component so that you can add your own, either through a licensed provider of terrain tech or rolling your own.Rolled.
Quote:I'm more for supporting arbitrarily sized textures (no limits) with a heafty note to the art team that they need to test video cards extensively to make sure that the cards can perform with the textures that they are generating.::nods:: Good Call.
Quote:Which would be a rendering component, I believe. Like adding in the OGRE renderer or DX10.Roger that, very much needed and due to the current nature of video cards and the gaming/graphics industry you can't live without 'em.
Quote:... you would have to purchase a $10k single-title license for the Q3 engine to comply with the license since Q3's source is under the GPL but available for alternate closed-source licensing.Cool, thanks for the info. That's not too bad of a price if you have a decent title to release, or a decent credit card. LOL.
I appreciate all of the detailed replies, thanks again. :)
#12
I know it was tongue-in-cheek, but if licensing gets in the way of Indie ego, I'm somewhat amazed that you aren't building your engine from scratch. One of the things that Torque 2 development is getting away from is the "only built here" attitude. Experts have put a lot of time and money into PhysX and Havok and Tokamak and ODE. Sure, GG could hire experts and commission them for years to design an implement a competitor to other, more mature products like those listed...but wouldn't it be wiser to create an engine that allows developer to leverage experts of their choice and experience? This has been a large criticism of Torque in the past among the community, and with the availability of excellent third-party solutions this criticism has gotten louder. Physics is the loudest cry, but terrain and sky systems and water have been popular in the past as well.
Of course, with component-based design, you can add your own components to the core and keep all the eggs in your basket, as it were. So it's a win on a number of levels!
10/24/2007 (6:53 am)
@TrentonI know it was tongue-in-cheek, but if licensing gets in the way of Indie ego, I'm somewhat amazed that you aren't building your engine from scratch. One of the things that Torque 2 development is getting away from is the "only built here" attitude. Experts have put a lot of time and money into PhysX and Havok and Tokamak and ODE. Sure, GG could hire experts and commission them for years to design an implement a competitor to other, more mature products like those listed...but wouldn't it be wiser to create an engine that allows developer to leverage experts of their choice and experience? This has been a large criticism of Torque in the past among the community, and with the availability of excellent third-party solutions this criticism has gotten louder. Physics is the loudest cry, but terrain and sky systems and water have been popular in the past as well.
Of course, with component-based design, you can add your own components to the core and keep all the eggs in your basket, as it were. So it's a win on a number of levels!
#13
The funny thing about physics is that if you want to do anything useful with them, you pretty much need to roll your own. In my experience, PhysX, Havok, and their kin are fantastic for doing simulations of barrels falling, bouncing, and sometimes rolling.
10/24/2007 (9:36 am)
Shouldn't be any problems with 4096x4096 now. The frame allocator may need to get it's allocation size increased, since it is used for texture loading.The funny thing about physics is that if you want to do anything useful with them, you pretty much need to roll your own. In my experience, PhysX, Havok, and their kin are fantastic for doing simulations of barrels falling, bouncing, and sometimes rolling.
#14
@David Blake
I agree with everything you are saying. Of course I think it is key to give developers the freedom to choose what they want to use. I choose to use the existing physics engine in Torque becuase it works just fine with some tweaking. And if a more advanced programmer than myself gave it 1 more go around I think it could be much, much better. If not, I still think it rocks. There is absolutely nothing wrong with the current Torque Game Engine.
I don't want to create everything from scratch. Been there done that. I have bought a license for almost everything here in the GG store and have been a proud member since July 2003. I have recompiled TGE at least a thousand times since then and have added all kinds of home brew stuff. I absolutely love it.
As far as licensing being an issue, I didn't really explain myself well. I'm just saying the least amount of third party library additions the better for my indie game designs. I don't mind paying and displaying my license for the Torque Engine and Garage Games. I also wouldn't mind displaying them for other parties. But if I can get away without doing that, then I am ALL for it.
@Pat Wilson
Sweet, thanks for the texture size tip.
I agree about rolling your own physics engine. It's not very hard to fake decent physics. I'm not trying to downlplay PhysX, Havok or the like. I absolutely love them. Half-life rocks with Havok and Cellfactor is loads of fun with maxed out PhysX settings! PhysX in Torque is also absolutely amazing! Especially with some tweaking to Arcane FX!
I in no way want to take away from the goal/mission that we are referring to as Torque 2. I want the latest and greatest. I hope that GG pushes Torque 2 development to the max and takes advantage of PhysX, etc. I hope when I use it that it chews up my computer and video card and spits them out so I have to convince my wife that I need to upgrade. :)
I look forward to Torque 2 and absolutely love all of my purchases from GarageGames.
10/24/2007 (9:32 pm)
I think I should clarify something at this point. When I noticed this forum posting on the What's new section of the GG site, I assumed the creator of the post was referring to what future additions to the currently existing Torque engine. I was not under the impression he was referring to the all new, completely reworked Torque 2 engine as originally pointed out in this thread by David Blake.@David Blake
I agree with everything you are saying. Of course I think it is key to give developers the freedom to choose what they want to use. I choose to use the existing physics engine in Torque becuase it works just fine with some tweaking. And if a more advanced programmer than myself gave it 1 more go around I think it could be much, much better. If not, I still think it rocks. There is absolutely nothing wrong with the current Torque Game Engine.
I don't want to create everything from scratch. Been there done that. I have bought a license for almost everything here in the GG store and have been a proud member since July 2003. I have recompiled TGE at least a thousand times since then and have added all kinds of home brew stuff. I absolutely love it.
As far as licensing being an issue, I didn't really explain myself well. I'm just saying the least amount of third party library additions the better for my indie game designs. I don't mind paying and displaying my license for the Torque Engine and Garage Games. I also wouldn't mind displaying them for other parties. But if I can get away without doing that, then I am ALL for it.
@Pat Wilson
Sweet, thanks for the texture size tip.
I agree about rolling your own physics engine. It's not very hard to fake decent physics. I'm not trying to downlplay PhysX, Havok or the like. I absolutely love them. Half-life rocks with Havok and Cellfactor is loads of fun with maxed out PhysX settings! PhysX in Torque is also absolutely amazing! Especially with some tweaking to Arcane FX!
I in no way want to take away from the goal/mission that we are referring to as Torque 2. I want the latest and greatest. I hope that GG pushes Torque 2 development to the max and takes advantage of PhysX, etc. I hope when I use it that it chews up my computer and video card and spits them out so I have to convince my wife that I need to upgrade. :)
I look forward to Torque 2 and absolutely love all of my purchases from GarageGames.
#15
10/25/2007 (10:45 pm)
I was hoping that the nextgen Torque engine would outdo its predecessors and include full support for both Linux and Mac development in addition to end product compatibility. But it looks like support for Linux is not on firm ground at this point. I plan to migrate as much of my work as possible to Ubuntu Linux in the near future, keeping Windows around only for absolute necessities... hope Linux gets supported!Quote:Quoted by Stephen Zepp's Transparent Development, Torque 2, and You! Plan
"Built in ability to be linux compatible is also an implementation goal, but build to build linux testing is not on the current task list of any of the developers working actively with the engine. It's possible that we may outsource linux compatibility implementation, perform it internally from time to time, or allow the Transparent Development Community or a limited set of developers within that community to support various versions of linux compatibility during a (hypothetical at this point) closed beta period, but none of these options are set in stone, and any/all are subject to change."
#16
10/26/2007 (10:29 am)
I would like to see a replacement of actual Torque rendering system to Ogre and very excited to see the new Component System and Modules architecture to an easier integration of third part tools (i.e. Physics Engine).
#17
If I learned anything [that I didn't already know] from watching the development of TSE, it's that giving linux lip service but then completely ignoring it during development is basically ensuring a product will never run on linux.
Honestly, if Torque2 runs on linux, I'll be delighted. But unlike TSE, I won't speculatively burn money on it onbased on cross-platform promises, before it's actually cross-platform.
Gary (-;
10/26/2007 (10:31 am)
Quote:I was hoping that the nextgen Torque engine would outdo its predecessors and include full support for both Linux and Mac development in addition to end product compatibility. But it looks like support for Linux is not on firm ground at this point. I plan to migrate as much of my work as possible to Ubuntu Linux in the near future, keeping Windows around only for absolute necessities... hope Linux gets supported!
If I learned anything [that I didn't already know] from watching the development of TSE, it's that giving linux lip service but then completely ignoring it during development is basically ensuring a product will never run on linux.
Honestly, if Torque2 runs on linux, I'll be delighted. But unlike TSE, I won't speculatively burn money on it onbased on cross-platform promises, before it's actually cross-platform.
Gary (-;
#18
I don't want to escalate this in to a flame war, but this is highly misleading. There is nothing whatsoever in TSE/TGE-A that causes "ensuring a product will never run on linux".
10/26/2007 (10:42 am)
Quote:
it's that giving linux lip service but then completely ignoring it during development is basically ensuring a product will never run on linux.
I don't want to escalate this in to a flame war, but this is highly misleading. There is nothing whatsoever in TSE/TGE-A that causes "ensuring a product will never run on linux".
#19
Torque2 may be designed with linux in mind, but until it runs on linux... it isn't running on linux.
Gary (-;
10/26/2007 (10:55 am)
Well, sure. I mean, TSE might in theory run on linux if someone invests enough time in it, but as of right now, TSE does not run on linux. That's the long and the short of it.Torque2 may be designed with linux in mind, but until it runs on linux... it isn't running on linux.
Gary (-;
#20
10/26/2007 (5:05 pm)
Agreed. Supporting Linux with dedicated staff (in house or outsourced) from the very beginning is the best way to ensure its actual support. Targeting Mac and Windows and later looking into Linux after completion would be very inefficient at the very least. I hope GG takes serious action on behalf of Linux support from day one. I wish I were more than a beginner at Linux programming, I'd offer my services... oh well. :)
Torque 3D Owner Chad Kilgore