Transparent Development, Torque 2, and You!
by Stephen Zepp · 10/17/2007 (10:26 pm) · 122 comments
There has been some buzz floating around since IGC this year, and a lot of it has been around InstantAction, but we also announced a couple of additional topics that are starting to sink in, so I wanted to dive in to the deep end of the community pool and make some waves....
Transparent Development
Sounds nifty, but what is it? One analogy I've heard that is a pretty solid description is consider TD a window into the offices of the development staff working on Torque 2--see what's being worked on this week, read discussions about designs as they are being discussed internally, and most importantly be able to discuss the designs and implementations themselves, as they occur.
We're not talking marketing information for a product that has already been developed--we're talking watching, and even being able to discuss and provide feedback on the development of Torque 2 as it occurs. I'll get to Torque 2 in a moment, but I want to reinforce that this is a fundamental shift back to the way GarageGames used to interact with the community--away from keeping completely silent regarding what we're working on and why, and back to giving the community rapid and fully packed pages of information on the development as it occurs--not after the fact, and especially not after it's released. Torque 2 isn't even scheduled for beta until well in to 2008, but we're working as rapidly as we can to get infrastructure in place to set up discussions as the engine team works on development.
We're talking roadmaps, milestone lists, design write ups, expected work flow and implementation standards, the works--all up front, all the time. One of the projects that I am working on right now is designing a new set of forums, wiki, and related web tools to manage extensive and extended data flow between the Transparent Development Community (that's you guys) and the engine development team (that's us!). Once this infrastructure is in place, we're going to open it up for communication purposes to a limited set of users for beta testing for a few weeks, and then we will make the information available to all.
[edit: see below in the comments section for further clarification on content and timing]
It's going to be several weeks yet before this infrastructure is ready, and it will be a few weeks of beta testing of that infrastructure as well before we're ready to turn on the fire hose, so please be patient while we get things set up for this to work in the long term--when it's ready, we'll let everyone know and let the show begin!
I do want to make something fundamentally clear from the beginning (and trust me, I'll keep pressing this point until it sinks in fully!): Torque 2 development will be an iterative process, very similar to the SCRUM, or Agile/Spiral Development models--and one of the key aspects of this style of development is that sometimes you go down a path, and it turns out that the path is not the best solution. When this occurs, the best course of action is simply to cut out the results of that development spiral, and reset your project expectations. Sometimes this means removing features, adjusting the milestone list, or delaying (or in some cases even canceling) entire systems.
It is critical that the entire Transparent Development Community understand that this development process you will be watching and discussing is a fluid one--and it should be fully expected that features and systems being discussed one week may very well end up being cut forever the next. No projects, games, and especially no funds or contracts should ever be committed during this development process--if you need to make commitments or financial decisions regarding your projects, then the Torque 2 Transparent Development Community is absolutely not somewhere you should be.
Torque 2
So what's Torque 2? To put it simply, Torque 2 is a ground up re-factor of the entire architecture of all of our engines into a new engine with some pretty amazing architecture and features. We've learned quite a bit over the last several years of engine development, and the time has come to take those lessons and build a new engine that not only provides the maximum flexibility possible to game developers, but fundamentally change many of the designs of the engine itself--correcting design assumptions and work flows that came about over the years that we ourselves find too restrictive, and along the way providing customization and feature enhancement capabilities that were never available before.
Torque 2's fundamental changes fall under three primary areas:
Modularity of Systems: In the past, it was very difficult to leverage into Torque systems, libraries, and raw code written by 3rd parties, such as ODE/Havoc/PhysX Physics, alternate scripting languages such as Lua, Python, and even .NET languages, and many other cool things that are available to game developers. Torque is extremely integrated, with each of the systems tightly coupled to provide a powerful, but ultimately restrictive engine when it comes to "mashing up" other solutions into a coherent whole--and Torque 2 is designed from scratch to correct those issues by allowing game developers to replace major system modules in a "plug and play" style--as long as the external systems match interfaces that the Torque 2 framework expects, you will be able to use just about any 3rd party (or self-developed) system within the core Torque 2 framework.
Abstraction and Interfaces: One of the key ways we will be able to provide this type of "swap out" modularity is by abstracting most of the core systems via the use of interfaces. Each major system will describe a set of interfaces that other systems and objects will use to communicate with the system, so instead of calling code directly within a system, external modules and objects will interact with the interfaces that system exposes--allowing other systems to replace core modules at the whim of the developer.
Torque 2 has already leveraged the previously developed GFX abstraction layer present in TGE-A, and in addition has had several iterations of abstraction of core systems as well, such as the sound layer (now abstracted through a new SFX system), lighting (fully abstracted into a separate module), collision and physics (currently under iterative refactoring towards a comprehensive interface), and many others. As the iterative development spirals of Torque 2 continue, additional systems will be abstracted and interfaces implemented for even more comprehensive modularity.
Components: The concept of a component based architecture is actually very simple--but it has some far reaching design implications, and in many cases can take some time to adapt towards. In most game engines, including Torque, you have a very deep set of classes that form a pretty static ancestry, and you use inheritance of all of these classes in your game object level classes. Unfortunately, this has several issues that become more apparent the longer you use these classes for development, especially across multiple games: your game object classes start becoming more and more bloated, and less appropriate for specific uses. Anyone that takes a good look at the Torque ShapeBase class will soon see what I mean--there are still left over methods in the ShapeBase class that are part of original Tribes code, and aren't particularly useful for most games.
Here's an example of exactly what I mean: Back when BraveTree was working on their environment pack, one of the neat things they wanted to have was butterflies with random movement about the scene. Pretty nifty stuff--they derived a new class off of ShapeBase, and their butterflies merrily wandered about the stronghold mission randomly--until one of them happened to run in to a crossbow object placed in the scene.
Suddenly, this tiny little butterfly picks up this huge crossbow, and starts swinging it back and forth madly as it continues to wander about--merrily meandering about the scene with a totally unexpected weapon of mass destruction dangling from its cute little mandibles.
It was immediately obvious what was going on, and as soon as they picked themselves up from off the floor and stopped laughing, they realized that since the butterfly inherited from ShapeBase, it also inherited the ability to collide with Items, and mount weapons--and that's exactly what it did!
So what does this have to do with components? Well, with the idea of components (based on the Object Oriented Programming concept of aggregation, sometimes called composition), instead of inheriting a series of ever more complex functionalities that your particular object may not need, you create very small units of functionality that accomplish simple tasks--and "build" your game objects from these little components. In the case of the butterfly, they might have added a render3D component, a collision3D component, a hoverFlightMovement component, and a AIRandomMove3D component--and thereby had all the functionality they needed for the butterfly, without any of the bloat that inheriting from a full class would have given them.
We'll be covering components in quite a bit more depth once the Transparent Development Community is in place, but if you are interested in learning more about how component based game development works, TorqueX also uses components, and is a great place to learn how the new design concepts can be used.
What this means for You
Well, the very first thing it means is not a lot to be honest--this is an announcement of a new development style (transparency), and a new engine that is just now entering heavy development. Torque 2 is not going to be ready for use in a major (or even minor) game project until sometime in 2008 (more accurate time line will come when we get more iteration cycles finished up). If you are currently working on a game with Torque (or another engine), or are planning on starting a new project in the next 6 to 9 months, Torque 2 is not for you at this time.
If you are someone that is interested in how an engine is developed, and want to participate in discussions of that development process as it occurs, stay tuned for further announcements about the Transparent Development Community. Once it opens to the public stop on by and hang out--at the least it should be educational and informative, and hopefully some of you might even generate ideas, designs, and implementations that may very well be factored in to the future of Torque.
I'm already well over my word count for a .blog, so I'll answer specific questions in the comment area below.
Transparent Development
Sounds nifty, but what is it? One analogy I've heard that is a pretty solid description is consider TD a window into the offices of the development staff working on Torque 2--see what's being worked on this week, read discussions about designs as they are being discussed internally, and most importantly be able to discuss the designs and implementations themselves, as they occur.
We're not talking marketing information for a product that has already been developed--we're talking watching, and even being able to discuss and provide feedback on the development of Torque 2 as it occurs. I'll get to Torque 2 in a moment, but I want to reinforce that this is a fundamental shift back to the way GarageGames used to interact with the community--away from keeping completely silent regarding what we're working on and why, and back to giving the community rapid and fully packed pages of information on the development as it occurs--not after the fact, and especially not after it's released. Torque 2 isn't even scheduled for beta until well in to 2008, but we're working as rapidly as we can to get infrastructure in place to set up discussions as the engine team works on development.
We're talking roadmaps, milestone lists, design write ups, expected work flow and implementation standards, the works--all up front, all the time. One of the projects that I am working on right now is designing a new set of forums, wiki, and related web tools to manage extensive and extended data flow between the Transparent Development Community (that's you guys) and the engine development team (that's us!). Once this infrastructure is in place, we're going to open it up for communication purposes to a limited set of users for beta testing for a few weeks, and then we will make the information available to all.
[edit: see below in the comments section for further clarification on content and timing]
It's going to be several weeks yet before this infrastructure is ready, and it will be a few weeks of beta testing of that infrastructure as well before we're ready to turn on the fire hose, so please be patient while we get things set up for this to work in the long term--when it's ready, we'll let everyone know and let the show begin!
I do want to make something fundamentally clear from the beginning (and trust me, I'll keep pressing this point until it sinks in fully!): Torque 2 development will be an iterative process, very similar to the SCRUM, or Agile/Spiral Development models--and one of the key aspects of this style of development is that sometimes you go down a path, and it turns out that the path is not the best solution. When this occurs, the best course of action is simply to cut out the results of that development spiral, and reset your project expectations. Sometimes this means removing features, adjusting the milestone list, or delaying (or in some cases even canceling) entire systems.It is critical that the entire Transparent Development Community understand that this development process you will be watching and discussing is a fluid one--and it should be fully expected that features and systems being discussed one week may very well end up being cut forever the next. No projects, games, and especially no funds or contracts should ever be committed during this development process--if you need to make commitments or financial decisions regarding your projects, then the Torque 2 Transparent Development Community is absolutely not somewhere you should be.
Torque 2
So what's Torque 2? To put it simply, Torque 2 is a ground up re-factor of the entire architecture of all of our engines into a new engine with some pretty amazing architecture and features. We've learned quite a bit over the last several years of engine development, and the time has come to take those lessons and build a new engine that not only provides the maximum flexibility possible to game developers, but fundamentally change many of the designs of the engine itself--correcting design assumptions and work flows that came about over the years that we ourselves find too restrictive, and along the way providing customization and feature enhancement capabilities that were never available before.
Torque 2's fundamental changes fall under three primary areas:Modularity of Systems: In the past, it was very difficult to leverage into Torque systems, libraries, and raw code written by 3rd parties, such as ODE/Havoc/PhysX Physics, alternate scripting languages such as Lua, Python, and even .NET languages, and many other cool things that are available to game developers. Torque is extremely integrated, with each of the systems tightly coupled to provide a powerful, but ultimately restrictive engine when it comes to "mashing up" other solutions into a coherent whole--and Torque 2 is designed from scratch to correct those issues by allowing game developers to replace major system modules in a "plug and play" style--as long as the external systems match interfaces that the Torque 2 framework expects, you will be able to use just about any 3rd party (or self-developed) system within the core Torque 2 framework.
Abstraction and Interfaces: One of the key ways we will be able to provide this type of "swap out" modularity is by abstracting most of the core systems via the use of interfaces. Each major system will describe a set of interfaces that other systems and objects will use to communicate with the system, so instead of calling code directly within a system, external modules and objects will interact with the interfaces that system exposes--allowing other systems to replace core modules at the whim of the developer.
Torque 2 has already leveraged the previously developed GFX abstraction layer present in TGE-A, and in addition has had several iterations of abstraction of core systems as well, such as the sound layer (now abstracted through a new SFX system), lighting (fully abstracted into a separate module), collision and physics (currently under iterative refactoring towards a comprehensive interface), and many others. As the iterative development spirals of Torque 2 continue, additional systems will be abstracted and interfaces implemented for even more comprehensive modularity.
Components: The concept of a component based architecture is actually very simple--but it has some far reaching design implications, and in many cases can take some time to adapt towards. In most game engines, including Torque, you have a very deep set of classes that form a pretty static ancestry, and you use inheritance of all of these classes in your game object level classes. Unfortunately, this has several issues that become more apparent the longer you use these classes for development, especially across multiple games: your game object classes start becoming more and more bloated, and less appropriate for specific uses. Anyone that takes a good look at the Torque ShapeBase class will soon see what I mean--there are still left over methods in the ShapeBase class that are part of original Tribes code, and aren't particularly useful for most games.Here's an example of exactly what I mean: Back when BraveTree was working on their environment pack, one of the neat things they wanted to have was butterflies with random movement about the scene. Pretty nifty stuff--they derived a new class off of ShapeBase, and their butterflies merrily wandered about the stronghold mission randomly--until one of them happened to run in to a crossbow object placed in the scene.Suddenly, this tiny little butterfly picks up this huge crossbow, and starts swinging it back and forth madly as it continues to wander about--merrily meandering about the scene with a totally unexpected weapon of mass destruction dangling from its cute little mandibles.It was immediately obvious what was going on, and as soon as they picked themselves up from off the floor and stopped laughing, they realized that since the butterfly inherited from ShapeBase, it also inherited the ability to collide with Items, and mount weapons--and that's exactly what it did!
So what does this have to do with components? Well, with the idea of components (based on the Object Oriented Programming concept of aggregation, sometimes called composition), instead of inheriting a series of ever more complex functionalities that your particular object may not need, you create very small units of functionality that accomplish simple tasks--and "build" your game objects from these little components. In the case of the butterfly, they might have added a render3D component, a collision3D component, a hoverFlightMovement component, and a AIRandomMove3D component--and thereby had all the functionality they needed for the butterfly, without any of the bloat that inheriting from a full class would have given them.
We'll be covering components in quite a bit more depth once the Transparent Development Community is in place, but if you are interested in learning more about how component based game development works, TorqueX also uses components, and is a great place to learn how the new design concepts can be used.
What this means for You
Well, the very first thing it means is not a lot to be honest--this is an announcement of a new development style (transparency), and a new engine that is just now entering heavy development. Torque 2 is not going to be ready for use in a major (or even minor) game project until sometime in 2008 (more accurate time line will come when we get more iteration cycles finished up). If you are currently working on a game with Torque (or another engine), or are planning on starting a new project in the next 6 to 9 months, Torque 2 is not for you at this time.
If you are someone that is interested in how an engine is developed, and want to participate in discussions of that development process as it occurs, stay tuned for further announcements about the Transparent Development Community. Once it opens to the public stop on by and hang out--at the least it should be educational and informative, and hopefully some of you might even generate ideas, designs, and implementations that may very well be factored in to the future of Torque.
I'm already well over my word count for a .blog, so I'll answer specific questions in the comment area below.
#62
Please make sure as you develope T2, that you remember that there are alot of us who are not top end developers. Us that don't develope for a living need tools that allow us to enjoy seeing our creations come to life. I am very excited to see how T2 comes out. Just a thought form the little guy.
10/19/2007 (6:59 am)
Stephen,Please make sure as you develope T2, that you remember that there are alot of us who are not top end developers. Us that don't develope for a living need tools that allow us to enjoy seeing our creations come to life. I am very excited to see how T2 comes out. Just a thought form the little guy.
#63
LMAO!!!!
I posted something about TorqueScript being ripped out, but I don't see my post. Odd.
10/19/2007 (7:07 am)
Quote:Save yourself the pain and use OGRE3D as the rendering engine. :)
LMAO!!!!
I posted something about TorqueScript being ripped out, but I don't see my post. Odd.
#64
Anyway, the roadmap sounds nice and all. The end result is what will determine whether or not it was actually worth it.
10/19/2007 (7:08 am)
Speaking of OGRE, there's always Eric's C4 engine as well. Why wait and deal with the uncertainty?Anyway, the roadmap sounds nice and all. The end result is what will determine whether or not it was actually worth it.
#65
10/19/2007 (7:10 am)
Edit : Sorry for the turbulence. My English is not good enough for that anyway ^^'
#66
10/19/2007 (11:00 am)
Mr. Zepp you are the man! Torque 2 sounds exciting and the development process even more so. Not sure what else to say, except I hope I can add something useful to the process along the way.
#67
10/19/2007 (8:40 pm)
Can't wait!!!!!
#68
10/19/2007 (9:36 pm)
Thanks this gives a good amount of info. The roadmap ahead looks good. 
#69
I hope that OpenGL will be in it and not coming at a later date...
As I feel that DirectX 10 and now 10.1 and only under Vista not only takes out the Linux and Mac markets but a lot (currently) of the windows market.
I think we should be able to have top graphics and not worry about the OS too much.
10/20/2007 (12:57 am)
Wow this is pretty amazing stuff!I hope that OpenGL will be in it and not coming at a later date...
As I feel that DirectX 10 and now 10.1 and only under Vista not only takes out the Linux and Mac markets but a lot (currently) of the windows market.
I think we should be able to have top graphics and not worry about the OS too much.
#70
I'm very excited about this, and dreading it at the same time (another license to buy, and another engine to learn the ins and outs of). :)
Keep it up GG!
10/20/2007 (11:56 am)
Given the modularity of the design I'm sure there will be concessions in place for OpenGL3. I'm just speculating that in order to have a license to support XB360, MS wants DX10 only. Making this architecture modular would bypass that exclusivity. Are the content formats (.dts, .dif, etc) going to change at all? The worst part of porting a project over would be re-doing half the artwork.I'm very excited about this, and dreading it at the same time (another license to buy, and another engine to learn the ins and outs of). :)
Keep it up GG!
#71
Interestingly enough, Marc Rein from Epic made a post a few days ago stating that an OpenGL version of UT3 is going to be released for Mac/Linux but they are going to use DX9+10 on Windows exclusively.
http://utforums.epicgames.com/showthread.php?p=25009404#post25009404
"The beta demo is for Windows only. We're working on Mac OS X and Linux native versions but I don't know when the demos for those will be ready. We are not planning to support OpenGL on Windows - just on Mac and Linux."
So it is possible to release on all formats, it just down to whether the Engine Dev's implement it.
With id and Epic both promising Mac/Linux support now and rumours running rampant that Crytek are porting Crysis to the PS3 using OpenGL 3, due to them posting job adverts saying
"
* Development of a Next-Generation GameFramework based on CryEngine 2.0
* Work on various aspects of porting to PS3 and creating solutions to get the utmost out of the PS3"
it seems the major players are seeing a potential market for multi platform gaming.
One can only hope that now GG has serious financial backing they can follow suite without testing their resources too much :)
10/20/2007 (3:11 pm)
@ ShaunInterestingly enough, Marc Rein from Epic made a post a few days ago stating that an OpenGL version of UT3 is going to be released for Mac/Linux but they are going to use DX9+10 on Windows exclusively.
http://utforums.epicgames.com/showthread.php?p=25009404#post25009404
"The beta demo is for Windows only. We're working on Mac OS X and Linux native versions but I don't know when the demos for those will be ready. We are not planning to support OpenGL on Windows - just on Mac and Linux."
So it is possible to release on all formats, it just down to whether the Engine Dev's implement it.
With id and Epic both promising Mac/Linux support now and rumours running rampant that Crytek are porting Crysis to the PS3 using OpenGL 3, due to them posting job adverts saying
"
* Development of a Next-Generation GameFramework based on CryEngine 2.0
* Work on various aspects of porting to PS3 and creating solutions to get the utmost out of the PS3"
it seems the major players are seeing a potential market for multi platform gaming.
One can only hope that now GG has serious financial backing they can follow suite without testing their resources too much :)
#72
10/21/2007 (3:20 pm)
All I want is a Torque engine that includes well reference documentation with open examples to ALL users... demo as well as those who purchased it. It would also be nice if you would just have a SINGLE engine to handle all the different iterations you have now... it is crazy confusing given all the packages you have out there... 
#73
10/21/2007 (5:58 pm)
Any ideas on how much it will cost?
#74
With the same T2 core system, you may pay for either a Torque 2d renderer module or/and a DirectX Torque 3d renderer module or/and an OpenGL Torque 3d renderer module. It would make sense, though I would prefer something like the single-ultimate-engine-pack-to-rule-them-all-with-everything-in-it-for-less-than-200$, but I highly doubt that it'll be like this (or only if GG wants to really pwns the shit out of all competition).
10/22/2007 (6:06 am)
Chance are, since T2 will be modular, that we get separated modules, like the current torque offer but as modules.With the same T2 core system, you may pay for either a Torque 2d renderer module or/and a DirectX Torque 3d renderer module or/and an OpenGL Torque 3d renderer module. It would make sense, though I would prefer something like the single-ultimate-engine-pack-to-rule-them-all-with-everything-in-it-for-less-than-200$, but I highly doubt that it'll be like this (or only if GG wants to really pwns the shit out of all competition).
#75
Take TGB for example.. it has an ok UI that allows the important drag/drop for hobbiests.. but, you need to use another program to create sprites/3D elements. You need to use a Text editor to write/edit/view the code. You need to use a 3rd party tool to get access to a debugger.... too many extras -and this is just TGB... take TGE, TGEA, TGX, TGwii... just too many products, too many extras needed to create something.
If someone could just come up with an all-in-one stop shopping game creation tool, they'd be on to something.
10/22/2007 (6:33 am)
I hear ya Ben.. but really - what is the competition right now for small hobby gamers? The $100-200 price range is about all a hobbiest is going to spend - but for a hobbiest to really get going and produce a game, the tools need to be tailored to them. That's why an all-in-one type package would fit that bill and I think bring in a huge market for GG.Take TGB for example.. it has an ok UI that allows the important drag/drop for hobbiests.. but, you need to use another program to create sprites/3D elements. You need to use a Text editor to write/edit/view the code. You need to use a 3rd party tool to get access to a debugger.... too many extras -and this is just TGB... take TGE, TGEA, TGX, TGwii... just too many products, too many extras needed to create something.
If someone could just come up with an all-in-one stop shopping game creation tool, they'd be on to something.
#77
And let the development of the DirectX layers be second, to the smaller market and less development on the XBOX360. As I think most people are developing for the PC and being able to release on Windows, Mac and Linux is better then Windows and XBOX360.
EDIT: of cause I'm speaking relatively to us, the indie market.
10/23/2007 (2:53 am)
Yeah I think that the graphics layer should be modular like it is in TGEA. But I think that the standard and main focus should be on OpenGL, as this is supported by all platforms, except XBOX360 of cause.And let the development of the DirectX layers be second, to the smaller market and less development on the XBOX360. As I think most people are developing for the PC and being able to release on Windows, Mac and Linux is better then Windows and XBOX360.
EDIT: of cause I'm speaking relatively to us, the indie market.
#78
how do you figure?
you should obviouly do some market research. windows and xbox360 dominate the gaming sector and have for the last year the 360 alone consitanty had more titles in the top 10 sales charct of UK EU and USA that any other single platform followed by the the PS2 and as far as Windows goes well that is just a rediculas argument to make. windows is 90% of the PCs on the planet. As of January 1st 2008 XP will no longer be sold or shipped. So beinging futureminded developer that means if you are targeting the largest portion of the PC market wich is windows that means DirectX if you wyou want to no look like last years product that means you will support both DX9 and 10. OpenGL has serious issues on Vista. and like it or not if you are planning on making a game with Tribes 2 by the time that it is out and matured Vista with be the majority when it comes to windows. Upgrade cycle on average is 2-3 years wich mean by the time your Torque 2 game is comming out most people are going to have just bought either their first or second Vista PC You put it out with OpenGL and well let just say that being independant that is a gamble that most likely you dont have the budget to make.
I suggest you sign up on gamasutra and some of the other site that will email you sales figures regularly so you can get a little better informed.
10/23/2007 (7:37 pm)
@edward:how do you figure?
you should obviouly do some market research. windows and xbox360 dominate the gaming sector and have for the last year the 360 alone consitanty had more titles in the top 10 sales charct of UK EU and USA that any other single platform followed by the the PS2 and as far as Windows goes well that is just a rediculas argument to make. windows is 90% of the PCs on the planet. As of January 1st 2008 XP will no longer be sold or shipped. So beinging futureminded developer that means if you are targeting the largest portion of the PC market wich is windows that means DirectX if you wyou want to no look like last years product that means you will support both DX9 and 10. OpenGL has serious issues on Vista. and like it or not if you are planning on making a game with Tribes 2 by the time that it is out and matured Vista with be the majority when it comes to windows. Upgrade cycle on average is 2-3 years wich mean by the time your Torque 2 game is comming out most people are going to have just bought either their first or second Vista PC You put it out with OpenGL and well let just say that being independant that is a gamble that most likely you dont have the budget to make.
I suggest you sign up on gamasutra and some of the other site that will email you sales figures regularly so you can get a little better informed.
#79
Beside I have a hard time believeing that you are going to be able to build exes for windows on a mac. I mean yeah they have that functionality but really, I mean at a commercial level it sounds like a support nightmare.
there is no way you are building Highly optimized DirectX code on a mac and compiling it on a mac to run a PC I don't care if you do have a Intel chip.
10/23/2007 (7:44 pm)
@martin. it is funny you should mention Unity it does have some cool features but they require you to run all of the tools and building on mac only. and the indie version is Seriously handicapped. I would rather tough it out with TGEA than go that route. It is nice technology. I talked to a guy at the company just yesturday and he said that there are plans to port everything to windows but it is not currently being worked on or even on the to schedule as it stands now. It is only a "yeah we definatly would like to do it one day"Beside I have a hard time believeing that you are going to be able to build exes for windows on a mac. I mean yeah they have that functionality but really, I mean at a commercial level it sounds like a support nightmare.
there is no way you are building Highly optimized DirectX code on a mac and compiling it on a mac to run a PC I don't care if you do have a Intel chip.
#80
10/24/2007 (2:16 am)
@James: Yeah, I know about the mac "restriction" (although for me not a restriction). :-) But hey, beside that, I think Otee created a good solution with their whole suite. That was just the reason I mentioned it - because Pesto asked for a complete solution thing.
Torque 3D Owner Tim Tillotson
Default Studio Name
Although I will likely have very little impact on the development of the engine itself, sometimes even the little impact the community has can make a BIG difference. To use a recent experience I had in my community: Walmart is going to build a store about 5 houses down from me. I'm an astronomer and having such a bright neighbor is not very appealing, especially given the rural community I live in. So I walked down the city building and planning department. They said they were approving the building codes and zones for the Walmart plot that VERY night. I explained my predicament and they modified the wording, while I was standing there, so that the store lights can have 0 candle power visible from adjoining residential community. They then sent the changed wording over their lawyer for a quick preview and I watched it pass in the city council meeting that night. In short, I can't change the fact that Walmart is building a store next to me very easily, but I can make a simple request that has a dramatic impact on my happiness with where I live.
To relate this to Torque 2: I probably won't change X feature from being developed, or get my special Y feature included, but I might be able to slightly alter a simple design decision that will dramatically increase my ability to use the engine in the kinds of games I want to develop in the future.
Even if I don't affect any design decisions, I'm just so happy I'll be able to see 'why' certain decisions were made, and be able to take these into account when I modify the engine for my own games in the future, or I'll know enough up front that I need to pick a different engine or toolset without going through the pain of trying to do it and realizing it would have been easier to do it from scratch.
I'd especially love it if the new engine made it easier to make games like Will Wright's Spore. (You can catch his GDC talk on YouTube or Google video if you missed it at GDC 2006. See http://en.wikipedia.org/wiki/Spore_(video_game) for more info.) Basically it supports order of magnitude world shifts, procedurally generated content and motion, and allows for easily sharing content among players, to name just a few items that would make for some very interesting games.
Good luck Stephen. You've got quite a job ahead of you, albeit I hope a very rewarding and enjoyable one.