by date
Transparent Development, Torque 2, and You!
Transparent Development, Torque 2, and You!
| Name: | Stephen Zepp |  |
|---|---|---|
| Date Posted: | Oct 18, 2007 | |
| Rating: |  5.0 out of 5 | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Stephen Zepp |
Blog post
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.
Recent Blog Posts
| List: | 05/15/08 - TGB 1.7.3 released for PC and Mac! 04/29/08 - Announcing TGB 1.7.3 Open Beta! 10/18/07 - Transparent Development, Torque 2, and You! 02/16/06 - Torque Boot Camp for Game Builder Announced! 01/12/06 - Torque isn 12/03/05 - I/ITSEC trip--(blog removed due to extreme photo content) 11/23/05 - Torque isn't just for games any more! 10/15/05 - Is that really Mars? |
|---|
Submit your own resources!| Stephen Zepp (Oct 18, 2007 at 06:23 GMT) Resource Rating: 5 |
- *Not intended to be backwards compatible with current Torque Engines.
- *Includes both 2D (from TGB) and 3D (TGE-A) capabilities
- *New directory and system structure that separates engine, application (game), and tools (external apps)
- *Multiple components can provide different implementations for the same task--for example, you may have a dtsLoaderComponent, a colladaLoaderComponent, and a superAwesomeNewFormatLoaderComponent all on different objects in your scene
- *poly soup collision will be the primary collision mechanism
- **BSP is not currently scheduled as a collision/rendering system, but the modular nature of systems and components does not preclude it for the future
- *Torque 2 networking will be modular as well (allowing for replacement modules), and the initial module will be based upon our Torque Networking Library initiative. Other modules (and their related components) may be provided towards the end of the first release phase by GG, community members, or provided by 3rd parties.
- *TorqueX as a product will effectively be unaffected by Torque 2 development and productization.
TGE, TGE-A, and TGB (as well as TorqueX) will continue to receive active support until Torque 2 is well established as a development engine. At that time (well in to 2008), we will begin shifting developers towards using the new engine for future projects.
While TorqueX is an excellent way to get an early glimpse of the component architecture, Torque 2 is written in C++, and TorqueX is in C#, so there is no direct code to code relationship between the two engines.
Edited on Oct 18, 2007 16:39 GMT
| Alienforce (Oct 18, 2007 at 06:38 GMT) Resource Rating: 5 |
Ps. Sign me up on the beta list, send over a NDA asap :)
| asmaloney (Andy) (Oct 18, 2007 at 06:51 GMT) |
[Nice writeup Stephen!]
| Tony Richards (Oct 18, 2007 at 07:01 GMT) Resource Rating: 5 |
I'm going to have to re-think my plans a bit... finally, a real game engine framework.
edit - removed NDA comment :D
Edited on Oct 18, 2007 07:11 GMT
| Stephen Zepp (Oct 18, 2007 at 07:06 GMT) Resource Rating: 5 |
Edited on Oct 18, 2007 07:19 GMT
| Nicolas Buquet (Oct 18, 2007 at 07:45 GMT) Resource Rating: 4 |
Doing cross-platform development, I know it is harder to develop, but it helps to track bug (some bugs that don't show on one platform suddenly appear on another platform because of little/big endian coding for instance) and make the code cleaner.
And secondly, I choose TGE one year and a half ago because of it's cross-platform capabilities (and its network layer of course).
Nicolas Buquet
http://www.buquet-net.com
Edited on Oct 18, 2007 07:45 GMT
| Stephen Zepp (Oct 18, 2007 at 07:59 GMT) Resource Rating: 5 |
Cross platform capability is, as it always has been, important to us, and the underlying architecture is being written with cross platform compatibility built in as it always has.
We realize this is an area of large importance to quite a few developers, and we also realize that our implementation priorities are not always the same as some community members, so I want to be right up front from the beginning:
We plan on testing Mac compatibility all the way through the development process, as much as possible. In fact, we recently hired a second engineer with extensive Mac experience (John Hearn) to work alongside Paul Scott to make sure our builds stay in touch with the Mac OS.
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.
I ask very strenuously that if you have specific reactive comments to the above, that you either post them in a forum thread, or wait until the TD Community is stood up--I'd rather not have this thread become an OS or cross-platform debate. Let's keep it focused on questions and answers, instead of debates about those answers please :)
| Martin Schultz (Oct 18, 2007 at 08:03 GMT) Resource Rating: 5 |
@Nicolas: I'm pretty damn sure it will be multi platform. As it seems to me, T2 will be the new platform for all games and IA in the future and I'm pretty sure that they (GG) don't want to loose the ability to port even their own games to WII / PS2/3 / XBox / Mac and alike, that would require multi platform code. And from what Stephen said, it will be better customizable than any other Torque engine before because the code gets a new leightweighted structure and clearly seperated into single components. Personally I bet that it will be in future easier (!) to get into the code than before.
@Stephen: Awesome blog! (and if you haven't already, go to bed now, it's damn late in Oregon according to the world time map... ;-)
| Kirk Longendyke (Oct 18, 2007 at 08:46 GMT) |
1 - is a masking system similar to the current itterations still going to be embeded, or is that being refactored on out at some point?
2- are you leaning towards oop or aop when it comes to packet-fill? (oop being filling out this object's data then the next, ect ect. till you hit packesize and try again next time, aop being filling out critical data first, like say object transform data for all object, then health, names being a distant non-gamebreaker ect ect)
| Benjamin L. Grauer (Oct 18, 2007 at 08:53 GMT) |
Thanks for the writeup Stephen ^^
PS : Are TGB Behaviors the same thing (or almost the same) as components ?
| Nicolas Buquet (Oct 18, 2007 at 09:21 GMT) Resource Rating: 4 |
| Andy Rollins (Oct 18, 2007 at 10:32 GMT) Resource Rating: 5 |
| Gareth Fouche (Oct 18, 2007 at 11:53 GMT) |
| bank (Oct 18, 2007 at 11:58 GMT) |
One point I'm interesting in...
Do you guys plan to make an engine to be "localization-ready"? Something like adding support for localization for every single part, be that Editors (GUI/World) or the game itself.
And thanks for good response on my Unicode-support question during IGC/Round-Table, but it was not fully covered..
Edited on Oct 18, 2007 13:20 GMT
| Rex (Oct 18, 2007 at 12:17 GMT) |
"...the future is here; Today!".
| Gustavo Boni (Oct 18, 2007 at 13:33 GMT) Resource Rating: 5 |
- There will be a documentation? Cause the current torque documentation is very incomplete.
- There will be changes in the waterblock? I mean, shore and underwater environment.
Thanks
| Jonathon Stevens (Oct 18, 2007 at 13:34 GMT) |
Quote:
TGE, TGE-A, and TGB (as well as TorqueX) will continue to receive active support until Torque 2 is well established as a development engine.
I noticed you included TorqueX in the above statement and am curious as to why? I understand if development stopped on TGE, TGE-A, and TGB, but why would you stop supporting TorqueX? It seems that TorqueX and Torque2 would be both supported with the others going away?
.net and C# in particular becomes more and more usable in the gaming industry every year, so replacing it with yet another C++ engine, no matter how good that engine is, just doesn't seem like a good business decision.
| Martin Schultz (Oct 18, 2007 at 13:49 GMT) Resource Rating: 5 |
| Donald \"Yadot\" Harris (Oct 18, 2007 at 13:55 GMT) |
| John D. Dunlap (Oct 18, 2007 at 13:58 GMT) Resource Rating: 5 |
Also, do you know if GG has any plans to hire/re-task even 1 person to work on the Linux side of T2? It seems, at least to me, that if GG wants to support Linux in the future that it would save GG money in the long run to spend the money early in development rather than trying to port it after the fact.
| Benjamin L. Grauer (Oct 18, 2007 at 14:01 GMT) |
Quote:Managed code is not going to replace anything in the "true" game industry anytime soon (and even not soon). C# and .net is just something Microsoft is pushing for hobbyists wishing to make games for 360, it was never intended to support full blown multi-platform engines like Torque 2, it will never be suited for that.
.net and C# in particular becomes more and more usable in the gaming industry every year, so replacing it with yet another C++ engine, no matter how good that engine is, just doesn't seem like a good business decision.
| Alienforce (Oct 18, 2007 at 14:20 GMT) Resource Rating: 5 |
I think you have to reconsider that statement soon :)
| Martin Schultz (Oct 18, 2007 at 14:21 GMT) Resource Rating: 5 |
| John D. Dunlap (Oct 18, 2007 at 14:23 GMT) Resource Rating: 5 |
Can we please not have a C++ vs. C# war here please?
| Donald \"Yadot\" Harris (Oct 18, 2007 at 14:51 GMT) |
| Mark Dynna (Oct 18, 2007 at 15:21 GMT) |
So, bottom line to everyone "out there:" complaining, ranting, and insulting people when a feature gets cut or a deadline is pushed (because it will happen) does nothing for anyone. So, let's all be good "stewards" of the responsibility GG is giving us (as a community) here.
| Kevin Summers (Oct 18, 2007 at 15:29 GMT) |
| James Thompson (Oct 18, 2007 at 16:10 GMT) Resource Rating: 5 |
What will happen to TGE/TGEA/TX?
| Donald \"Yadot\" Harris (Oct 18, 2007 at 16:10 GMT) |
I support your pleas here. I can only imaging there will be at least one person who will not agree with what is going. I hope that the communities/supporters of GG maintains the higher more mature standard. In other words ignore those who don't have valid comments. If you have something negative to say just make sure you support and document it with good sense. :)
| Stephen Zepp (Oct 18, 2007 at 16:29 GMT) Resource Rating: 5 |
Quote:
Couple related queries on components and the networking model, presuming the questions are not premature:
1 - is a masking system similar to the current itterations still going to be embeded, or is that being refactored on out at some point?
2- are you leaning towards oop or aop when it comes to packet-fill? (oop being filling out this object's data then the next, ect ect. till you hit packesize and try again next time, aop being filling out critical data first, like say object transform data for all object, then health, names being a distant non-gamebreaker ect ect)
First, let me say that networking will be just another module--if you need peer to peer for your networking system, or possibly DIS (military networking protocol), or something unusual--it's just another module.
1) Yes, we will continue to use something similar to our existing masking system. Currently, we will be folding TNL (Torque Network Library, which is effectively a "1.5" version of the core networking within our existing engines) into Torque 2 in some form (componentized and modular based of course)
2) I can't say that it's been addressed. Off the top of my head, I see a lot of pros and cons. Great topic for the TDC once it's up and running!
Quote:
PS : Are TGB Behaviors the same thing (or almost the same) as components ?
TGB Behaviors are close, in use specifically (although not in implementation really). The underlying implementation is quite a bit different since we had to be fully backwards compatible, but in general if you like behaviors, you'll love components.
Quote:
Do you guys plan to make an engine to be "localization-ready"? Something like adding support for localization for every single part, be that Editors (GUI/World) or the game itself.
And thanks for good response on my Unicode-support question during IGC/Round-Table, but it was not fully covered..
UniCode is very much on the list of things to be more successful with in Torque 2, but it's not on the first several levels of iteration tasks lists as far as I am aware. I agree with you very much however that it is both very important, and needs to be treated more holistically. We are planning to move to a String class implementation for a variety of reasons, and it should help to make Unicode support less difficult.
Quote:
Just two questions about Torque 2:
- There will be a documentation? Cause the current torque documentation is very incomplete.
This has been discussed in several places (unrelated to Torque 2 itself), but yes, we will be very much focused on all of the additional aspects besides simply pushing an engine out. I'm going to talk a bit about development versus productization at the bottom of this post, which relates to documentation as well.
Quote:
- There will be changes in the waterblock? I mean, shore and underwater environment.
This is a perfect example of underscoring the differences between engine, application (game), and tools--waterblocks shorelines, underwater environments--all of those functionalities have absolutely nothing to do with the engine--they are all part of the application. In other words, they are game level objects, not engine architecture.
The short answer is "no, at this time, there are no tasks or iterations related to waterblocks, shorelines, underwater development, or any other game level object functionalities--there may be in the future, but we're at the architecture refactoring stage, not the example application stage".
The alternate short answer is "these type of functionalities are suited for game object components, not the engine. At a minimum we will most probably have example components that provide the same level of functionality that exists in, for example TGE-A today. The benefit of the underlying architecture change is that it will be much less difficult to add things like shoreline effects, underwater effects, and other game level systems quickly and easily with components.
Quote:
I noticed you included TorqueX in the above statement and am curious as to why? I understand if development stopped on TGE, TGE-A, and TGB, but why would you stop supporting TorqueX? It seems that TorqueX and Torque2 would be both supported with the others going away?
Was a "catch-22" situation--if I didn't say Torque X, someone would ask about it--if I did, someone would read it differently! Not a big deal at all, I just should have spent some time being more clear from the beginning.
TorqueX and Torque 2 are completely unrelated, and are two completely different engines on different underlying technologies. TGE, TGE-A, and TGB are all in some way affected by the long term evolution of Torque 2, but Torque X is not, at all. Torque X focused users can effectively ignore just about all of the Torque 2 discussions--it won't affect you in any meaningful way.
Quote:
@Jonathan: If I understood Stephen right, then you could easily interface T2 also from C#, like from any other (compatible) language. So the "union" of all engines will be able to be interfaced from nearly everywhere. In theory you could even use JavaScript for it. Stephen, please correct me if I'm wrong.
Close--you could write a new script module that uses C# (or any .NET language--or any other language) as your scripting language. You could theoretically at least treat TorqueX as a module within Torque 2 (I'm reaching here, there might be some technical reason why this would be difficult, but I'm not aware of it at this time if there is one), but there would be no real benefit in this particular case.
Yes, you could certainly use JavaScript as your scripting language, if you (or someone else) write the module for it.
Quote:
Also, do you know if GG has any plans to hire/re-task even 1 person to work on the Linux side of T2? It seems, at least to me, that if GG wants to support Linux in the future that it would save GG money in the long run to spend the money early in development rather than trying to port it after the fact.
I covered this about 7 comments down, but to summarize: It's certainly possible. It's not currently on the actions list for Torque 2 at this time.
Quote:
Will T2 offer anything new platforms such as mobile devices like the DS or PSP?
I can't state any specific platforms at this time, but I think a reasonable conclusion could be made that of course it's in both our, and your, best interests for Torque2 to be as cross-platform as possible, with as many target platforms as feasible. The two specific platforms you bring up have not been discussed to my knowledge, but it's public knowledge that we already have an XBox 360 platform layer, as well as the Torque for Wii code base, and while I'm not saying it flat out, it's reasonable to assume that they could make appearances in some form in Torque 2 well in the future.
Ok, one topic that we haven't covered yet, and one that I can't go into detail too deeply in (moves away from transparent development, and in to competitive business strategy), but it's important to note that the Transparent Development Community will be completely focused on engine development, not product development. It sounds like two names for the same thing, but that's only because in the past, we've never actually done much work on product development--we've just finished an engine to a release-able point, and pushed it out the door with a couple of getting started/how-to docs and called it good.
With the resources we now have available after the IAC partnership, we have stood up an entire team who's sole focus is providing a cohesive product to our customers--tools, documentation, tutorials, examples, demos, and related materials to make working with Torque 2 a well thought out process instead of a "jump in and sink or swim" type of experience.
We won't be going into much detail on this aspect in the short or mid term, but I will say that experiences like the integrated HTML documentation currently provided with Torque X and TGB 1.5.1, the tutorial pack that was recently released for Torque X, and similar efforts are just scratching the surface of what the productization of Torque 2 will be all about.
| Stephen Zepp (Oct 18, 2007 at 16:36 GMT) Resource Rating: 5 |
Quote:
@Mark Dynna
I support your pleas here. I can only imaging there will be at least one person who will not agree with what is going. I hope that the communities/supporters of GG maintains the higher more mature standard. In other words ignore those who don't have valid comments. If you have something negative to say just make sure you support and document it with good sense. :)
I will promise you this: the community participation standards and requirements in the Transparent Development Community will be much higher than they are in our current product community. We absolutely must have bi-directional communication, including strong debate around all sides of any particular issue, but I will be enforcing 100% professionalism and mutual respect at all times.
I wish the infrastructure was in place myself right now so we could get this party started--but I have strict requirements for how that community can be managed, and it requires a lot of changes to how our web infrastructure works, so it will take time for it to be implemented. The current GG.com community is a mixed one, with many purposes and levels of interaction. 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.
The current GG.com community will always exist, and general discussions, questions unrelated to Torque 2 development, soapboxes, rants, product feedback (as opposed to Torque 2 development feedback) and other off topic/unrelated discussion is going to simply not be allowed in the TDC.
| N R Bharathae (Oct 18, 2007 at 16:37 GMT) |
With regard to T2 polysoup will it have lighting similiar to BSP so interiors can built with it?
| Stephen Zepp (Oct 18, 2007 at 16:45 GMT) Resource Rating: 5 |
This particular debate will continue to be held internally only--I'm willing to listen to various ideas (elsewhere please, not in this thread), but we will most likely not publicly respond until we have a solution that not only makes us happy, but will make you happy as well.
Quote:
With regard to T2 polysoup will it have lighting similiar to BSP so interiors can built with it?
Lighting is totally abstracted--if you add a lighting component to your object, it will receive whatever lighting you wish (and have available), including third party solutions. That includes pre-generation of static lightmaps, dynamic lighting, or whichever modules you have included, and component properties you have selected.
| David Dougher (Oct 18, 2007 at 17:33 GMT) |
You can have one big argument at the beginning as to what the settings are for the source formatter and then everybody has to live with the results.
Looking way down the road you might even tell us which formatter you chose and give us your settings so that we can make suggestions for improvements - properly formatted for inclusion.
Just a thought. I have found that it does save a remarkable amount of time when everybody's work looks the same.
| Ray Depew (Oct 18, 2007 at 17:38 GMT) |
<manly>Well, bring it on, I say.</manly>
| Martin Schultz (Oct 18, 2007 at 18:12 GMT) Resource Rating: 5 |
Will the OpenTNL be included or the "older" TNL network layer from TGE? The reason I ask is that afaik OpenTNL has some major advances like firewall punch-through and secured sessions compared to the "older" implementation in TGE.
| Stephen Zepp (Oct 18, 2007 at 18:17 GMT) Resource Rating: 5 |
| Martin Schultz (Oct 18, 2007 at 18:18 GMT) Resource Rating: 5 |
| bank (Oct 18, 2007 at 18:26 GMT) |
The localization / multi-language support is important for us (non-English developers). No, we don't plan to "ship a game within a year", but we are working on MMO, and it's a question of constant development/improvements.
One MMO game is moving from Gamebryo into CryEngine2, so why can't we go from T1 to T2 then? :)
I'll try pay lots of attention on the T2 development, hope it will go nicely. Torque - forever! :)
Cheers!
| Donald \"Yadot\" Harris (Oct 18, 2007 at 18:36 GMT) |
Will Kork be the demo character in T2?
:)
| Gary "ChunkyKs" Briggs (Oct 18, 2007 at 19:07 GMT) |
Quote:
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
I would really like to see this in action, or how it will actually work. To quote icculus:
Quote:
Nothing is portable until it's ported, and all the planning in the world doesn't beat Murphy's Law
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 (-;
Edited on Oct 18, 2007 19:07 GMT
| James Dunlap (Oct 18, 2007 at 19:30 GMT) |
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?
Edited on Oct 18, 2007 19:31 GMT
| Stephen Zepp (Oct 18, 2007 at 19:33 GMT) Resource Rating: 5 |
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:
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?
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.
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.
| Timothy Aste (Oct 18, 2007 at 19:47 GMT) |
| Eric Fritz (Oct 18, 2007 at 20:10 GMT) |
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.
| Stephen Zepp (Oct 18, 2007 at 20:14 GMT) Resource Rating: 5 |
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.
| Bob Berens (Oct 18, 2007 at 20:24 GMT) |
| Stephen Zepp (Oct 18, 2007 at 20:27 GMT) Resource Rating: 5 |
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.
| Donald \"Yadot\" Harris (Oct 18, 2007 at 20:52 GMT) |
| Stephen Zepp (Oct 18, 2007 at 21:01 GMT) Resource Rating: 5 |
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.
| Steven S (Oct 18, 2007 at 21:03 GMT) |
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.
| Novack (Oct 18, 2007 at 21:14 GMT) Resource Rating: 5 |
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?
| Stephen Zepp (Oct 18, 2007 at 21:16 GMT) Resource Rating: 5 |
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.
| Stephen Zepp (Oct 18, 2007 at 21:25 GMT) Resource Rating: 5 |
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.
Edited on Oct 18, 2007 21:27 GMT
| Novack (Oct 18, 2007 at 21:37 GMT) Resource Rating: 5 |
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...
Edited on Oct 18, 2007 21:51 GMT
| Blake Drolson (Oct 18, 2007 at 22:48 GMT) |
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.
| Mike Rowley (Oct 19, 2007 at 00:51 GMT) |
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. :)
| Mike Stoddart (Oct 19, 2007 at 01:04 GMT) |
| Temasek Polytechnic Suite (#0030 (Oct 19, 2007 at 01:08 GMT) |
I'd like to know if T2 will use different art formats, and how assets are imported into the engine.
If it's all polysoup, then I imagine direct support for DIF will disappear, and probably DTS.
I also forsee a major effort in redeveloping our courseware (no big deal, but it's something we need to be aware of).
Has GarageGames ever considered partnering with academic institutions to develop its documentation?
Thanks.
| Joe Rossi (Oct 19, 2007 at 02:09 GMT) |
| Tim Tillotson (Oct 19, 2007 at 04:09 GMT) Resource Rating: 5 |
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.
| William Baker (Oct 19, 2007 at 13:59 GMT) |
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.
| Derek Smart (Oct 19, 2007 at 14:07 GMT) |
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.
| Derek Smart (Oct 19, 2007 at 14:08 GMT) |
Anyway, the roadmap sounds nice and all. The end result is what will determine whether or not it was actually worth it.
Edited on Oct 19, 2007 14:09 GMT
| Benjamin L. Grauer (Oct 19, 2007 at 14:10 GMT) |
Edited on Oct 19, 2007 17:00 GMT
| Jeremy Alessi (Oct 19, 2007 at 18:00 GMT) |
| Broken_Sword (Oct 20, 2007 at 03:40 GMT) |
| Vashner (Oct 20, 2007 at 04:36 GMT) Resource Rating: 5 |
| Edward Smith (Oct 20, 2007 at 07:57 GMT) |
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.
| Shaun Vantuil (Oct 20, 2007 at 18:56 GMT) Resource Rating: 5 |
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!
| metalliandy (Oct 20, 2007 at 22:11 GMT) Resource Rating: 5 |
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 :)
| Pesto126 (Oct 21, 2007 at 22:20 GMT) |
| Dan Keller (Oct 22, 2007 at 00:58 GMT) |
| Benjamin L. Grauer (Oct 22, 2007 at 13:06 GMT) |
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).
| Pesto126 (Oct 22, 2007 at 13:33 GMT) |
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.
| Martin Schultz (Oct 22, 2007 at 13:41 GMT) Resource Rating: 5 |
Quote:
If someone could just come up with an all-in-one stop shopping game creation tool, they'd be on to something.
Unity?
Edited on Oct 22, 2007 13:41 GMT
| Edward Smith (Oct 23, 2007 at 09:53 GMT) |
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.
Edited on Nov 11, 2007 04:53 GMT
| James Brad Barnette (Oct 24, 2007 at 02:37 GMT) Resource Rating: 5 |
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.
Edited on Oct 24, 2007 02:46 GMT
| James Brad Barnette (Oct 24, 2007 at 02:44 GMT) Resource Rating: 5 |
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.
| Martin Schultz (Oct 24, 2007 at 09:16 GMT) Resource Rating: 5 |
| John Spivey (Oct 24, 2007 at 12:39 GMT) |
| James Brad Barnette (Oct 24, 2007 at 14:36 GMT) Resource Rating: 5 |
Nintendo Wii
Xbox 360
Sony PlayStation 2
Sony PSP
Microsoft Xbox
Nintendo GameCube
PC
Sony PlayStation 3
I dont work on the programing side of things on this project but I know that the guys that are seem pretty content with it. I know that it has some kind point an click scripting accoarding to the website that is supposed to amke it easier for not coders to make stuff. The only other engine that I know of that is taking this apporach wher eyou code overything once and then just select a platform and hit compile is id's Tech 5 butthat is going to cost you your first born I'm sure.
It is nice to see that all of this legacy stuff is finally being gotten rid of in the new engines, and here at GG. This is the day that Game artist have dreamed of for a very, very long time.
I hope that GG pays close attention to the new artist tools that they have made for Tech 5 and tries to make some of these systems for Torque 2. "Mega-Texture" is just plain awsome!
If you have not seen the id Tech 5 Tech preivew you can see it here
Basicly the geometry boundries still exist "polycount" but you can have as much texture detail as you want without ever impacting the performance. They show a level that has like 20-60Gb of textures. It is the ultimate artists engine.
Edited on Oct 24, 2007 14:49 GMT
| Pesto126 (Oct 26, 2007 at 12:27 GMT) |
Quote:
Unity?
I'd use Unity in a hearbeat if it worked for the PC... i'm not a mac guy and don't want to buy a new computer just to create a hobby game... would love to use it though - you are right - that's what I'm talking about!
| Martin Schultz (Oct 26, 2007 at 12:37 GMT) Resource Rating: 5 |
| James Brad Barnette (Oct 26, 2007 at 13:00 GMT) Resource Rating: 5 |
I just prefer windows.
| Dragica Kahlina (Oct 30, 2007 at 09:16 GMT) |
Please also think about integration some real nice editors. I am pretty spoiled by the mod stuff that is flying around (FarCry, TitanQuest, NeverwinterNights, ...). Asset pipeline first. How do you get the stuff into the engine is more important than tech candy.
I hope you think of a nice scheme to allow existing users to migrate in an economic way.
Actually I am all for modules etc. But at the moment I am near to categorize my Torque experience as just bad, messy and a waste of time. And announcements like this one are not making it any better.
But by all means count me in. The tech nerd in me likes to play around with new stuff.
| John D. Dunlap (Oct 30, 2007 at 11:45 GMT) Resource Rating: 5 |
Quote:
I am pretty spoiled...
I think that about says it all.
Edited on Oct 30, 2007 11:45 GMT
| James Brad Barnette (Oct 30, 2007 at 13:27 GMT) Resource Rating: 5 |
Yeah this is somthing that id has obviously learned and Epic has know for a long time. all the game play and code in the world doesn't mean squat if you game looks like crap! If it looks like crap people aren't gonna give it time of day.
It is just business. a game may be crap but if it looks awsome people will still buy it it. They may be disapointed but they will still by it and chances are you will make enough to make a better one next time. Hoever if you have a game with good game pplay let say but it looks like crap. Well they are just gonna go look at something else. It is best to have both dont get me wrong. Great games will kepp them there but it is the great artwork that get them there in the first place. In My option the original Far Cry was a perfect example of this the Game looked phenomenal! and the tools for it were so simple and easy to use. so I bought it. Personally I thought the game play was a little on the lame side and pretty repetitive. But I bought it becasue it looked like it was awesome! dont get me wrong I'm not saying that it is ok to release crap that looks pretty just saying that a game that may not have the best game play but has great are will still sell better than one that look like crap and has great game play. Pretty pictures and good marketing can sell just about anything these days.
If any GG product is ever going to succeed in the modern market place it need to have a art pipline on par with Unreal Engine, Tech 5, or CryEngine. These are perfect examples of what an art pipline for an engine should be.
Oh yeah and the documentation for them is simple and very thurough.
It is my belief that GG finally realizes this and that this is where they are headed.
| Stephan (viKKing) Bondier (Oct 30, 2007 at 13:39 GMT) |
Before buying an engine you have to look for a minimum of information on it, and it will only be outdated depending on the use you want to do.
TGE is still a valid engine, with known limitations; and with appropriate graphics and design it can make kick arss games.
Edited on Oct 30, 2007 13:40 GMT
| Dragica Kahlina (Oct 30, 2007 at 15:05 GMT) |
| James Brad Barnette (Oct 31, 2007 at 15:31 GMT) Resource Rating: 5 |
| James Steele (Nov 01, 2007 at 18:07 GMT) |
Surely you guys KNOW that the whole T2 news is only confirming what many of us have known for a long time? The whole TSE development stopped a LONG time ago, and what many of us are left with is a complete mess of an engine that we paid money for, in good faith with the promise of fixed features, addition of missing features and so on. But more fool us for paying for something that we weren't actually getting straight away. Caveat emptor eh?
I'm not expecting miracles for the few hundred dollars I have spent on your products, but I do expect you to stick true to you word. Not give up development when it starts getting a "bit difficult" and then announce a completely new engine, that we'll have to pay for yet again.
And what are the bets that you're going to be selling early adopter versions of this new wonder engine? I got suckered by that the first time around with TSE, and that is not going to happen again!
And to think just at the beginning of this week, before I read about T2, I was reccomending to my boss that we should think about using Torque, given that it gives us similar code bases across pc and console platforms. I said "well...development on the pc engine seems to be slow right now, but I'm sure it'll pick up in the near future and we can share assets and code on pc and console platforms since they seem to have xb360 engine and are moving into Wii dev too"
Boy, do I ever feel dumb now when I go into work tomorrow and say "you know how I was really hyping up the Troque engine. Forget it, I don't know what I'm talking about."
Edited on Nov 01, 2007 18:45 GMT
| John D. Dunlap (Nov 01, 2007 at 18:15 GMT) Resource Rating: 5 |
Quote:
The whole TSE development stopped a LONG time ago, and what many of us are left with is a complete mess of an engine that we paid money for, in good faith with the promise of fixed features, addition of missing features and so on.
You bring up a valid point and for that reason I believe that GG should offer a free upgrade path to T2 from TGEA.
Edited on Nov 01, 2007 18:16 GMT
| James Brad Barnette (Nov 01, 2007 at 20:52 GMT) Resource Rating: 5 |
I do think as most do that there need to be some sort of discount for TGEA owners. I still am going to have to use TGEA for the time being honestly the engine has gotten a lot better in the past 6 months. Though the art pipline still blows. Mainly in the area of atlas and shadows. But even that has made a good bit of progress. At lease we have sahdows on Atlas Blended terrains now.
| John Spivey (Nov 01, 2007 at 21:57 GMT) |
I too bought the early adopters version of TGEA back when it was TSE. Yep, I was suckered in with the shiny water just like the rest of ya.
BUT, I can't help but hope that Torque 2 will be something a whole lot better. By reading the plans it makes good sense. On paper this thing will be huge. In reality, I fear that the 20-30 employees at GG are too spread out and only a few will be doing the Torque 2 thing.
They really should have never said a word and just posted the link for the DL when it was done. I would have bought it.
| James Brad Barnette (Nov 02, 2007 at 00:18 GMT) Resource Rating: 5 |
All of the hating is not going to help except to make the people at GG bitter and go back to no communicating with us.
If you are one of the ones that has decided not to use TGEA for something else then great go use it and stop comming in here bitching. If you have decided that you are gonna wait for T2 to do your game well hey nexgen art takes a while so work on that. If you really want to produce a commercial game you are gonna need to next year and half just for your assets. "this is the route that I have chosen"
The merger has just happend and it is going to take months to see any results from it give them a chance. Before all of thie they did what they could with what they had. we may not agree with how they allocated their resources, "personally I don't agree". But what is done is done. You as a community member need to personally search within and find out wether you can forgive and move on or not. This bitterness needs to end. It is just poisoning the community.
I for one choose to forgive and look toward the future.
Don't get me wrong I have lead a few crusades to GG's gate bitching. But here are they telling you that they are trying to set things right and head in the right direction and some of you are just tearing them a new one over it.
TGEA not live up to expectations? yeah that is not in dispute but come on guys most of us were TGE owner so we paid like what $149 bucks, that is nothing. We totaly got our moneys worth even with the problems. I would buy a Torque 2 EA release in a heartbeat.
Look, all I'm saying is lets give them some time and see how it pans out. But bitching at them here is not going to help anyone. Especially us users!
GG take your time and remember, "Make the art pipeline a top priority!" This is a lesson that id has recently learned. Go to you tube or gametrailers.com and you can watch many a video of him talking about that very thing. If great games are to be made the artist need to be less contrained.
Edited on Nov 02, 2007 14:01 GMT
| Ray Depew (Nov 02, 2007 at 13:36 GMT) |
Look, I have "Notify when new comments are posted" checked on this resource, so I can get the latest news on Torque 2 and Transparent Development (not necessarily in that order). I'm certain that the vast majority of readers of this resource are here for the same reason. However, this resource seems to have been hijacked by a small number of people who want to turn it into a bitch-and moan-session and predict the end of GarageGames.
Would those of you who prefer to tell us all the things that GG is doing wrong, all the ways that this effort is going to fail, and all the ways engine Z is better than Torque, please take your naysaying elsewhere? Start up a new thread in General Discussions or something, but leave this one alone so we can find out what we need to know about T2 without having to sift through all the garbage to get to it.
And would someone at GG consider moderating this discussion to eliminate all the stuff that doesn't matter?
| John Spivey (Nov 02, 2007 at 22:34 GMT) |
Quote:
Would those of you who prefer to tell us all the things that GG is doing wrong, all the ways that this effort is going to fail, and all the ways engine Z is better than Torque, please take your naysaying elsewhere?
OR we are so very hopefull that this is going to be great and want to reiterate the things that we DON'T want to happen with T2. Some of us might be so very optimistic and are relaying our concerns and hope to be put at ease. Some of us MIGHT see this as one of the best options available to us from an expense aspect and really want it to work out for the best. Some of us might really want to ensure that our concerns that the art pipeline is FULLY supported. Think that might be an option?
| Ray Depew (Nov 02, 2007 at 23:18 GMT) |
Quote:
OR we are so very hopefull that this is going to be great and want to reiterate the things that we DON'T want to happen with T2. Some of us might be so very optimistic and are relaying our concerns and hope to be put at ease. Some of us MIGHT see this as one of the best options available to us from an expense aspect and really want it to work out for the best. Some of us might really want to ensure that our concerns that the art pipeline is FULLY supported. Think that might be an option?
Is that really what you're doing when you post to this resource? And are you speaking of your own recent post, or of others' recent posts?
Either way, I don't buy it. Even rereading the recent posts with your "some of us might ..." in mind, they still come across as doom and gloom. Oh, and whining.
| John Spivey (Nov 03, 2007 at 00:37 GMT) |
| Albert Hammel (Nov 10, 2007 at 05:31 GMT) |
"All of the hating is not going to help except to make the people at GG bitter and go back to no communicating with us."
When you are dishonest with your customers, they typically leave. This is something GG needs to start getting right or they will suffer the fate of lots of other companie that treat their customers like feces. Why are you worried about them becoming secretive? It seems they have finally learned their lesson. You need to cater to your market. I'm amazed that they have held on this long.
| Dave (Nov 14, 2007 at 10:37 GMT) |
For anyone used to OOP it is a thousand times quicker to understand good interface docs than to trawl through long-winded explanations on TDN or in books. Of course those long explanations are essential when you don't understand OOP (or art, which I don't) or whatever! But when you are buried deep in code and want to know quickly "Does this interface have a getString method" then tech docs are the quickest way to find out without losing your concentration.
| JoZ (Nov 22, 2007 at 13:02 GMT) |
JoZ
| Stephan (viKKing) Bondier (Nov 22, 2007 at 13:10 GMT) |
There might be a few fixes here and here, but you should consider TGEA as a frozen engine.
Which means Open GL support is dead too. 8-(
I have one question to Stephen: what will happen to TGE and TGEA once TGE2 will be released?
Are they going to be available for free or with very very low amount of money to encourage hobbyists and apprentice programmers to use them?
| Martin Schultz (Nov 22, 2007 at 13:11 GMT) Resource Rating: 5 |
| Benjamin L. Grauer (Nov 22, 2007 at 13:13 GMT) |
| James Brad Barnette (Nov 22, 2007 at 16:43 GMT) Resource Rating: 5 |
| Stephan (viKKing) Bondier (Nov 22, 2007 at 16:49 GMT) |
So currently, GG is not providing anything for that purpose but TGE, and many may switch to different engines, C4, Unity, etc.
| Benjamin L. Grauer (Nov 22, 2007 at 16:56 GMT) |
They said 2008 and they will likely make it in time with their new resources from IAC.
Juggernaut currently already exist, it simply needs to be finished into Torque 2.
| Martin Schultz (Nov 22, 2007 at 18:25 GMT) Resource Rating: 5 |
| JoZ (Nov 22, 2007 at 20:13 GMT) |
| Stephen Zepp (Nov 22, 2007 at 20:35 GMT) Resource Rating: 5 |
--TGE-A (and our other products) is not "frozen". I was just in a meeting yesterday discussing options and possibilities for our various existing engines. As mentioned, Torque 2 is quite a ways out, and we continue to assess and plan for existing engines.
--If it helps you to set up the expectations properly for Torque 2, it should be considered "early research and development"--we're just letting you know about it (and in the future, being able to watch the process) much earlier than you are used to.
--We've discussed this many times in many forums, posts, and other discussion areas, but features that have in the past been described as possibilities (or even goals) sometimes simply don't happen--and this means that there will always be certain people or groups that will say "I bought XXX for feature YYY, and it didn't get developed!". I'm not going to try to convince each and every single person that the value of TGE-A compared to the money they spent is a huge value in just about any economic development model, but as with any game project decision, if you find the path that you've stepped on isn't working for your team's needs, then it's important to correct that decision in whatever way is appropriate.
--We have spent quite a bit of time researching and planning for various transition strategies to Torque 2, and once it m