Transparent Development, Torque 2, and You!
by Stephen Zepp · 10/18/2007 (5:26 am) · 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.
#42
This definitely sounds like good good news! However, I'm slightly curious as to whats GG's intentions for TDN? Is T2 going to be a part of it or are you moving on?
10/18/2007 (7:30 pm)
Once again, many thanks to Stephen Zepp for the time he puts into answering our questions.Quote:
I am working on right now is designing a new set of forums, wiki
This definitely sounds like good good news! However, I'm slightly curious as to whats GG's intentions for TDN? Is T2 going to be a part of it or are you moving on?
#43
I'll take some top level pokes at your major points, but many of the questions deserve long and involved discussions of their own over at TDC, so please don't expect immediate, fully fledged answers!
Your first statement isn't actually true (we currently have 5 or 6 different render devices implemented internally through R&D, although none of them are currently appropriate for public release, nor will they be except as part of Torque 2), but the second is 100% accurate.
Later iterations (once the framework is solid) will most probably (I'm making an educated guess, it's still quite a ways away) focus on providing alternate system modules. A hypothetical example might be the networking system--we've talked publicly already about TNL being a network module, and we've had some internal "might be a good idea to plan for" style conversations for things like peer to peer networking modules, and even far out discussions on things like DIS (military open protocol for networked simulations) modules.
Your question does bring up a totally valid, and important point: "plug and play" is an analogy, not a reality, and I should have stated that more clearly. There will be quite a bit of required work for any particular external system to be able to meet the framework's expected interface expectations. Some systems are by industry standard easier to abstract than others, and theoretically at least some systems will be immediately capable of being brought in to a Torque 2 application, while others will require additional "first time" work to make that happen. Of course, depending on previous iteration successes, some of these abstractions may be implemented specifically by us, and when developing the abstraction interfaces we're paying good attention levels to existing popular systems to make that process easier. Some abstraction interfaces will ultimately need to be performed by people outside the GG engine development team--possibly TDC members, possibly 3rd party providers.
Graceful fall back whenever possible, combined with dependencies where required. If a component needs certain abstracted capabilities for example, and has no method of fallback available within the component, it would (hypothetically again, this is still under development) gracefully fail. To determine these dependencies, it would first enumerate over the interfaces that are available to see if it can find what it needs.
GFX for example already has some of the things I'm describing--CustomMaterials provide for fallback paths to less capable shaders if a specific video card doesn't support what the primary material requests. If the module doesn't support a capability required by a component (or other module), then the module configuration will report as not capable for the requested functionality.
That doesn't negate the value of middleware in any way, because any middleware is designed to aid development in areas that may be unrelated, or at a "higher level" than the implementation of one particular project.
10/18/2007 (7:33 pm)
@Gary: really good questions--and ones that we expect to be very fleshed out over time once the Transparent Development Community is fully up and running.I'll take some top level pokes at your major points, but many of the questions deserve long and involved discussions of their own over at TDC, so please don't expect immediate, fully fledged answers!
Quote:
Going with the example of GFX... no-one's actually written a non-directX renderer for it. All the pluggableness in the world doesn't *actually* make something pluggable, until more than one thing has been plugged into it.
Your first statement isn't actually true (we currently have 5 or 6 different render devices implemented internally through R&D, although none of them are currently appropriate for public release, nor will they be except as part of Torque 2), but the second is 100% accurate.
Later iterations (once the framework is solid) will most probably (I'm making an educated guess, it's still quite a ways away) focus on providing alternate system modules. A hypothetical example might be the networking system--we've talked publicly already about TNL being a network module, and we've had some internal "might be a good idea to plan for" style conversations for things like peer to peer networking modules, and even far out discussions on things like DIS (military open protocol for networked simulations) modules.
Your question does bring up a totally valid, and important point: "plug and play" is an analogy, not a reality, and I should have stated that more clearly. There will be quite a bit of required work for any particular external system to be able to meet the framework's expected interface expectations. Some systems are by industry standard easier to abstract than others, and theoretically at least some systems will be immediately capable of being brought in to a Torque 2 application, while others will require additional "first time" work to make that happen. Of course, depending on previous iteration successes, some of these abstractions may be implemented specifically by us, and when developing the abstraction interfaces we're paying good attention levels to existing popular systems to make that process easier. Some abstraction interfaces will ultimately need to be performed by people outside the GG engine development team--possibly TDC members, possibly 3rd party providers.
Quote:
Another question about your modularity is how do you fit to the lowest common denominator? How would I use OPCODE for collisions in a place where the pluggable code architecture demands support for support convex hulls? Or do you simply not support convex hulls? Will I be able to [heaven knows why] use OpenGL1.0 with the new graphics layer, even though it expects to be able to use shaders?
Graceful fall back whenever possible, combined with dependencies where required. If a component needs certain abstracted capabilities for example, and has no method of fallback available within the component, it would (hypothetically again, this is still under development) gracefully fail. To determine these dependencies, it would first enumerate over the interfaces that are available to see if it can find what it needs.
GFX for example already has some of the things I'm describing--CustomMaterials provide for fallback paths to less capable shaders if a specific video card doesn't support what the primary material requests. If the module doesn't support a capability required by a component (or other module), then the module configuration will report as not capable for the requested functionality.
Quote:Totally subjective question, so I really can't answer it. It's a truism that given any contrived set of project requirements (or even many real world ones), you can argue that using middleware of any sort holds you back, and/or would take more time than a "do it yourself" effort.
Finally, one other question... If I wanted to write a game, using OpenGL for graphics, Bullet & GIMPACT for physics and collisions, and intercal for scripting... at what point would it be easier to write my own game from scratch, rather than trying to implement each of these things into torque's pluggable architecture? What makes juggernaut better than writing it myself, in the case where I don't like a lot of the things that come in the box?
That doesn't negate the value of middleware in any way, because any middleware is designed to aid development in areas that may be unrelated, or at a "higher level" than the implementation of one particular project.
#44
10/18/2007 (7:47 pm)
Awesome stuff
#45
It's important to note that the process that Stephen describes is the ideal that we'll be working toward during Torque 2 development, and is not something that will happen all at once, right away. Similar to the iterative style of development that Stephen described will be integral to Torque 2, transparent development is expected to evolve in much the same manner, and it's continued evolution beyond just providing the most basic of information (like what has already been presented in this post) will depend on its effectiveness both for you and for us. Baby steps.
As Stephen noted, we expect to have improved communication tools (real forums, real wiki, etc.) up very soon, but it will probably be several weeks (read: months) before it is populated with useful information. And the information it is populated with will be what Stephen can glean from dev plans, processes and code commits. We want to keep the devs developing and pumping out useful code, and not spending a bulk of their time putting together information for public consumption. It will be Stephen's job to be the conduit between the devs and the community, but his effectiveness and the type of information available will depend on dev support as well as yours. We're confident that Stephen is the right guy for the job... as many of you have seen, he has a highly technical mind and is an excellent communicator.
As Stephen has noted elsewhere, Torque 2 development is currently in the destructive phase, abstracting functionality away from the core engine so that it can later be built back in in a modular manner. Much of the communication Stephen describes won't be highly detailed (or interesting) until development enters the re-constructive phase which, again, is several weeks (read: months) away.
Finally, thanks all for your support and enthusiasm! We're excited about this and it's fun to see you all excited about it as well. I just want to properly set expectations as we try to build out this communication stream.
10/18/2007 (8:10 pm)
Quote: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.
It's important to note that the process that Stephen describes is the ideal that we'll be working toward during Torque 2 development, and is not something that will happen all at once, right away. Similar to the iterative style of development that Stephen described will be integral to Torque 2, transparent development is expected to evolve in much the same manner, and it's continued evolution beyond just providing the most basic of information (like what has already been presented in this post) will depend on its effectiveness both for you and for us. Baby steps.
As Stephen noted, we expect to have improved communication tools (real forums, real wiki, etc.) up very soon, but it will probably be several weeks (read: months) before it is populated with useful information. And the information it is populated with will be what Stephen can glean from dev plans, processes and code commits. We want to keep the devs developing and pumping out useful code, and not spending a bulk of their time putting together information for public consumption. It will be Stephen's job to be the conduit between the devs and the community, but his effectiveness and the type of information available will depend on dev support as well as yours. We're confident that Stephen is the right guy for the job... as many of you have seen, he has a highly technical mind and is an excellent communicator.
As Stephen has noted elsewhere, Torque 2 development is currently in the destructive phase, abstracting functionality away from the core engine so that it can later be built back in in a modular manner. Much of the communication Stephen describes won't be highly detailed (or interesting) until development enters the re-constructive phase which, again, is several weeks (read: months) away.
Finally, thanks all for your support and enthusiasm! We're excited about this and it's fun to see you all excited about it as well. I just want to properly set expectations as we try to build out this communication stream.
#46
Things will shift, things will change, some things might happen quicker and some things might happen later than discussed. As I mention in the original blog and others have commented on as well, for this to be successful for all of us, everyone will need to be well aware of the completely fluid and unstable nature of things, and not make any personal or financial commitments until Torque 2 is released as a product.
10/18/2007 (8:14 pm)
Good clarifications Fritz, thanks :) Lots of data out there in a very short period of time, and I want to stress once again that this announcement comes very early in the entire process, both Torque 2 and Transparent Development.Things will shift, things will change, some things might happen quicker and some things might happen later than discussed. As I mention in the original blog and others have commented on as well, for this to be successful for all of us, everyone will need to be well aware of the completely fluid and unstable nature of things, and not make any personal or financial commitments until Torque 2 is released as a product.
#47
10/18/2007 (8:24 pm)
Will access to TDC forums/wikis be fully moderated so that obvious flamebate will never see the light of day? [ I can hope, can't I? :-) ]
#48
10/18/2007 (8:27 pm)
Quote:
The Transparent Development Community will have one purpose: provide a community focused on the development of Torque 2, and I will be actively moderating at all times to make sure it stays on focus.
#49
10/18/2007 (8:52 pm)
During the dvelopment process will there be any additional features that maybe targeted toward Serious Game developers such as the government like data encryption or something of that nature that may benefit them?
#50
Doubtful, except as to how systems of that nature might guide the general framework itself. Those types of capabilities fit into the realm of new/additional system modules and components, instead of core engine framework and baseline systems.
10/18/2007 (9:01 pm)
Quote:
During the dvelopment process will there be any additional features that maybe targeted toward Serious Game developers such as the government like data encryption or something of that nature that may benefit them?
Doubtful, except as to how systems of that nature might guide the general framework itself. Those types of capabilities fit into the realm of new/additional system modules and components, instead of core engine framework and baseline systems.
#51
The butterfly description was pretty funny. :-) The use of components will be nice. I like the whole OO approach that seems to be shaping.
> Not intended to be backwards compatible with current Torque Engines
Can you explain this a bit more? At first glance, it may mean absolutely no current part will be compatible with T2. On the other hand, are there certain aspects or ideas which are translatable or may require little in the way of changes? More specifically, what about TorqueScript? Will the script we use today still be usable in T2? With the whole component idea, it sounds like the structures of the current script classes will also be going away.
10/18/2007 (9:03 pm)
Thanks for the nice blog and further comments. Stephen, you do a good job of representing and describing the technology and upcoming process. Thanks for your effort in these boards.The butterfly description was pretty funny. :-) The use of components will be nice. I like the whole OO approach that seems to be shaping.
> Not intended to be backwards compatible with current Torque Engines
Can you explain this a bit more? At first glance, it may mean absolutely no current part will be compatible with T2. On the other hand, are there certain aspects or ideas which are translatable or may require little in the way of changes? More specifically, what about TorqueScript? Will the script we use today still be usable in T2? With the whole component idea, it sounds like the structures of the current script classes will also be going away.
#52
what versions of OpenGL and/or DirectX are been considered? This is just been taken from the current renderer or are plans to develop extensions?
And: Torque as indie focused as it is, is also nown (and part of his magic came from) for have serious/pro/AAA capabilities. In this sense T2 will change philosophy and became more indie or it is planned to be a fully competitive engine?
10/18/2007 (9:14 pm)
Here I have two questions Stephen:what versions of OpenGL and/or DirectX are been considered? This is just been taken from the current renderer or are plans to develop extensions?
And: Torque as indie focused as it is, is also nown (and part of his magic came from) for have serious/pro/AAA capabilities. In this sense T2 will change philosophy and became more indie or it is planned to be a fully competitive engine?
#53
TorqueScript in and of itself will still be used, and in very similar ways--but as you note the design of the underlying "large, bloated" objects will change significantly. Instead of getting tons of callbacks on a single object, you'll be getting smaller callbacks on components of an object, for example.
Nothing will stop you from sludging through line by line of your implementation and porting it to Torque 2 from an existing Torque project, but in the long run it might very well be more effective to start over with the design and re-implement if you must move to the new engine.
As I've stated several times above however, the question of porting a game that exists today over to Torque 2 should be the farthest one in your mind, if it exists at all. Unless you are on a 3-5 year development cycle, there will not be any benefit to your project at all in even thinking about moving over--it's not going to be ready any time in the near future at all.
If you're working on a game right now, plan on finishing that game in the engine you selected. If you are even planning to start a new project in the next 6-9 months, plan on starting thatproject in an existing engine, and expect to finish it there as well.
10/18/2007 (9:16 pm)
Designing for inheritance and designing for aggregation are two pretty fundamentally different things--and the resulting implementations you get from one are going to require extensive re-working to fit into the other.TorqueScript in and of itself will still be used, and in very similar ways--but as you note the design of the underlying "large, bloated" objects will change significantly. Instead of getting tons of callbacks on a single object, you'll be getting smaller callbacks on components of an object, for example.
Nothing will stop you from sludging through line by line of your implementation and porting it to Torque 2 from an existing Torque project, but in the long run it might very well be more effective to start over with the design and re-implement if you must move to the new engine.
As I've stated several times above however, the question of porting a game that exists today over to Torque 2 should be the farthest one in your mind, if it exists at all. Unless you are on a 3-5 year development cycle, there will not be any benefit to your project at all in even thinking about moving over--it's not going to be ready any time in the near future at all.
If you're working on a game right now, plan on finishing that game in the engine you selected. If you are even planning to start a new project in the next 6-9 months, plan on starting thatproject in an existing engine, and expect to finish it there as well.
#54
I'm going to have to get back to you on that one--I'm not sure what device drivers we have currently are for R&D purposes, and which are expected to be part of Torque 2.
I do know that we have the DX9 device that TGE-A has, as well as the Xenon (XB360 render device) that is part of our 360 platform license, and that DX10 has been discussed but not guaranteed.
Tricky question the way you phrased it, kind of backs me in to a corner!
We want Torque 2 to be appropriate for, and focused on, the needs of indy developers--powerful systems and capabilities that allow an independently minded development team to have successful, appealing games. We also want to be able to use the engine ourselves for our own games, and of course lay a framework that is both flexible enough and powerful enough to attract the largest scale of customers, all the way up to the commercial/AAA markets into the future--but indies (and ourselves, after all, throughout our history we've been indie developers ourselves), including the spectrum of beginners and hobbyists as well, will be very important to us as a market for Torque 2.
To summarize: we're focusing on the indy side of the spectrum, but aiming at providing a powerful game development engine and tool set that is attractive to anyone making games.
10/18/2007 (9:25 pm)
Quote:
Here I have two questions Stephen:
what versions of OpenGL and/or DirectX are been considered? This is just been taken from the current renderer or are plans to develop extensions?
I'm going to have to get back to you on that one--I'm not sure what device drivers we have currently are for R&D purposes, and which are expected to be part of Torque 2.
I do know that we have the DX9 device that TGE-A has, as well as the Xenon (XB360 render device) that is part of our 360 platform license, and that DX10 has been discussed but not guaranteed.
Quote:
And: Torque as indie focused as it is, is also nown (and part of his magic came from) for have serious/pro/AAA capabilities. In this sense T2 will change philosophy and became more indie or it is planned to be a fully competitive engine?
Tricky question the way you phrased it, kind of backs me in to a corner!
We want Torque 2 to be appropriate for, and focused on, the needs of indy developers--powerful systems and capabilities that allow an independently minded development team to have successful, appealing games. We also want to be able to use the engine ourselves for our own games, and of course lay a framework that is both flexible enough and powerful enough to attract the largest scale of customers, all the way up to the commercial/AAA markets into the future--but indies (and ourselves, after all, throughout our history we've been indie developers ourselves), including the spectrum of beginners and hobbyists as well, will be very important to us as a market for Torque 2.
To summarize: we're focusing on the indy side of the spectrum, but aiming at providing a powerful game development engine and tool set that is attractive to anyone making games.
#55
Nevertheless your answer, as usually, was perflectly clarifying.
Edit: I see now the problem is because my tacit assumption that an engine is "Indie oriented" OR AAA, when in fact that assumption is not entirely correct. I think your explanation is quite adecuate anyway.
Edit2: Grammar and typo, oh lordy...
10/18/2007 (9:37 pm)
LOL Stephen, no harm intended, is maybe my still limited english... :$Nevertheless your answer, as usually, was perflectly clarifying.
Edit: I see now the problem is because my tacit assumption that an engine is "Indie oriented" OR AAA, when in fact that assumption is not entirely correct. I think your explanation is quite adecuate anyway.
Edit2: Grammar and typo, oh lordy...
#56
If I can make one request regarding the documentation the new team is preparing for the new engine, please have a full game example. I don't care if its a book I need to buy or a series of tutorials, but I would like to see a real game development example, one that requires making changes to the C++ code and involves networking. The fact that there is still not a full game development example for TGE/TGEA (GPGT was single player, and only covered script code) makes the engine hard to digest and learn. One solid fully detailed example game would go a long way into making torque2 the success it deserves to be.
Anyway, great news, cant wait to see how the new engine turns out and to be able follow and help guide its development is very cool.
10/18/2007 (10:48 pm)
Wow, huge news. I like it! To me it finally means we just might get the indy game engine we are all dreaming of. Thank you Stephen for your post and further informative responses.If I can make one request regarding the documentation the new team is preparing for the new engine, please have a full game example. I don't care if its a book I need to buy or a series of tutorials, but I would like to see a real game development example, one that requires making changes to the C++ code and involves networking. The fact that there is still not a full game development example for TGE/TGEA (GPGT was single player, and only covered script code) makes the engine hard to digest and learn. One solid fully detailed example game would go a long way into making torque2 the success it deserves to be.
Anyway, great news, cant wait to see how the new engine turns out and to be able follow and help guide its development is very cool.
#57
As with everyone elses comments, this is fantastic news. I'm as excited as everyone else. :)
10/19/2007 (12:51 am)
Quote:One solid fully detailed example game would go a long way into making torque2 the success it deserves to be.I agree.
As with everyone elses comments, this is fantastic news. I'm as excited as everyone else. :)
#58
10/19/2007 (1:04 am)
Save yourself the pain and use OGRE3D as the rendering engine. :) 
Torque Owner Gary "ChunkyKs" Briggs
I would really like to see this in action, or how it will actually work. To quote icculus:
Going with the example of GFX... no-one's actually written a non-directX renderer for it. All the pluggableness in the world doesn't *actually* make something pluggable, until more than one thing has been plugged into it.
Using physics as an example [a topic about which I'm fairly familiar], all the armwaving in the world about collisions and physics doesn't make Bullet *and* ODE work with something, until there's visible working Bullet *and* ODE implementations.
I guess the way to look at this is, how are you implementing these things? In theory, Modularity and stuff is all well and good, but there's a level somewhere between "Writing your own from scratch" and "Three magical function calls", and I'd like to know how ODE is supposed to fit into a project that also works with Havok.
Another question about your modularity is how do you fit to the lowest common denominator? How would I use OPCODE for collisions in a place where the pluggable code architecture demands support for support convex hulls? Or do you simply not support convex hulls? Will I be able to [heaven knows why] use OpenGL1.0 with the new graphics layer, even though it expects to be able to use shaders?
Finally, one other question... If I wanted to write a game, using OpenGL for graphics, Bullet & GIMPACT for physics and collisions, and intercal for scripting... at what point would it be easier to write my own game from scratch, rather than trying to implement each of these things into torque's pluggable architecture? What makes juggernaut better than writing it myself, in the case where I don't like a lot of the things that come in the box?
Gary (-;