A hopefully constructive engine comparison
by Berserk · in Torque Game Engine · 05/25/2007 (11:49 am) · 24 replies
.
About the author
#4
I believe it should be level editor (ala Constructor) instead of model editor (ala Max). Most every AAA engine makes the assumption that the developer has Max, Maya, XSI, or Lightwave. A very scant few engines have a model editor (3D Game Studio, for example, does...though I hate MED).
EDIT: Fixed my closing quotes.
05/25/2007 (1:43 pm)
Nice start. Just a little clarification.Quote:some editors wich normally, are included in AAA systems (model editor, texture manager, sound editor, just to say some of them).
I believe it should be level editor (ala Constructor) instead of model editor (ala Max). Most every AAA engine makes the assumption that the developer has Max, Maya, XSI, or Lightwave. A very scant few engines have a model editor (3D Game Studio, for example, does...though I hate MED).
Quote:Sorry, I was about to write "can't be without a terrain". I got confused. lolRemove the terrain block from your mission and you're good to go. I rarely ever use terrain.
Quote:Using rigged meshes with collision shapes is painful, exporting anything from a modeling package often produces not-exported collision shapes.I'm not sure since I haven't had a problem using Lightwave. I know others use Blender to good effect with collision boxes.
However, .max files included with the base code always properly export (what's the secret?).
EDIT: Fixed my closing quotes.
#5
though I am sure that there are other experts in this area that will. But as someone who knows the art tools path/pipeline exceptionally well (probably one of only a handful few in the community who can honestly say this) I do want to defend the DTS art pipeline/path.
I don't want to rehash a post I just made on my blog, but to sum things up, the DTS pipeline gets slagged unnecessarily a lot by people who lack the knowledge or experiance to really give it honest critism. I am not saying that it is perfect by any stretch, it has its flaws like any other system or format will have (hard cap limit on number of nodes it can export, limit on the number of details, limit on the polygon count, only 1 uvw channel, support for polygon shapes, trigger values at the wrong location in DSQs that do not start at frame 0, etc.), but I will be honest and say these items are things that most teams will rarely ever encounter and likely never even knew about until I just listed them. IMHO people put way too much blame on it for their project failures when the blame should really be divereted elsewhere.
If I can make some comments on what Berzerk posted:
The blending animation system is incredibly powerful, it was leaps and bounds ahead of anything on the market for years and even still today is up there with what so called "AAA" engines will suppy. I would argue that it would be even beyond anything on the market if the Blend Reference system wasnt broken in the exporters. I will admit I can see where there are problems to the end user, it is a complicated system to understand to wrap your head around, but when you do, you also understand the wealth of possibilities that you can achieve with it as well.
The exporting trick? Well like I said on my blog post there is no trick, it just requires that a) end user is competent in the 3D application that they are using and b) that end user has read the documentation. In all my time here I have rarely seen a real befuddling problem that needed trickery to solve.
edit: Fixed the URL closed tag that I mistyped.
05/25/2007 (1:44 pm)
I really don't know enough about Torques code (C++ and scripting) to fire any comments back at this post, though I am sure that there are other experts in this area that will. But as someone who knows the art tools path/pipeline exceptionally well (probably one of only a handful few in the community who can honestly say this) I do want to defend the DTS art pipeline/path.
I don't want to rehash a post I just made on my blog, but to sum things up, the DTS pipeline gets slagged unnecessarily a lot by people who lack the knowledge or experiance to really give it honest critism. I am not saying that it is perfect by any stretch, it has its flaws like any other system or format will have (hard cap limit on number of nodes it can export, limit on the number of details, limit on the polygon count, only 1 uvw channel, support for polygon shapes, trigger values at the wrong location in DSQs that do not start at frame 0, etc.), but I will be honest and say these items are things that most teams will rarely ever encounter and likely never even knew about until I just listed them. IMHO people put way too much blame on it for their project failures when the blame should really be divereted elsewhere.
If I can make some comments on what Berzerk posted:
The blending animation system is incredibly powerful, it was leaps and bounds ahead of anything on the market for years and even still today is up there with what so called "AAA" engines will suppy. I would argue that it would be even beyond anything on the market if the Blend Reference system wasnt broken in the exporters. I will admit I can see where there are problems to the end user, it is a complicated system to understand to wrap your head around, but when you do, you also understand the wealth of possibilities that you can achieve with it as well.
The exporting trick? Well like I said on my blog post there is no trick, it just requires that a) end user is competent in the 3D application that they are using and b) that end user has read the documentation. In all my time here I have rarely seen a real befuddling problem that needed trickery to solve.
edit: Fixed the URL closed tag that I mistyped.
#6
There are engines that have many editors and even provide an almost complete modeling package editor and such, but most of them really are very strict. As with any engine that gives a broad amount of freedom, complexity is no exception. The more flexible, the more complex, higher learning curve.
Many less then high praises about torque really have to do with implementation verse lack of knowledge, That isn't very unfounded either. Torque documentation is sparse and in many instances out-of-date. They are working on that aspect so I've heard.
Basic facts are that there isn't an engine thats going to build you a game, just as there isn't a modeling package that will build you a model without having knowledge of the software and some ability to understand it. Building a game title is hard work even if you know what your doing, so comparing torque with other game engines (many of which are really not even engines but 3d viewers) just isn't going to work out well.
Spending effort making comparisons like this is sort of a waste of time unless you address some issues that pertain to torques current weaknesses, which is documentation in an organized and up to date manner. TDN is awesome in some instances, but is vapid in others. Once that is cleared up a bit better and the community gets better schooled, this will be the absolute best engine in it's class on the market without contest. This community is already the best in the market, hands down.
Given the base GG has offered here you can fairly easily mod the engine with anything out there, even build editors to your hearts content!
05/25/2007 (7:41 pm)
No one is mentioning the networking out of the box either...build entirely around server client architecture... no other engine i know is that way at all.There are engines that have many editors and even provide an almost complete modeling package editor and such, but most of them really are very strict. As with any engine that gives a broad amount of freedom, complexity is no exception. The more flexible, the more complex, higher learning curve.
Many less then high praises about torque really have to do with implementation verse lack of knowledge, That isn't very unfounded either. Torque documentation is sparse and in many instances out-of-date. They are working on that aspect so I've heard.
Basic facts are that there isn't an engine thats going to build you a game, just as there isn't a modeling package that will build you a model without having knowledge of the software and some ability to understand it. Building a game title is hard work even if you know what your doing, so comparing torque with other game engines (many of which are really not even engines but 3d viewers) just isn't going to work out well.
Spending effort making comparisons like this is sort of a waste of time unless you address some issues that pertain to torques current weaknesses, which is documentation in an organized and up to date manner. TDN is awesome in some instances, but is vapid in others. Once that is cleared up a bit better and the community gets better schooled, this will be the absolute best engine in it's class on the market without contest. This community is already the best in the market, hands down.
Given the base GG has offered here you can fairly easily mod the engine with anything out there, even build editors to your hearts content!
#7
The doc framework used on TGB worked out very well and was also used to quickly create a nice set of docs for Torque X.
not trying to derail the thread, just wanted to do a pre-emptive strike on comments and let everyone know that we know the docs have not been as good as they could be, that we are aware of it, and that we are working on it, and not in a slapdash 'quick fix' way, but in a long term thinking, comprehensive, maintainable, and very usable set of supporting materials.
this task is big. Big with a capital B-I-G. we tackled the small ones first, and now we are working on the big one (TGE).
05/25/2007 (7:54 pm)
Just a note on the documentation. We are working on it. The new documentation format was developed in TGB, as we knew that not only did we need docs, we needed a good way to maintain and extend them. The doc framework used on TGB worked out very well and was also used to quickly create a nice set of docs for Torque X.
not trying to derail the thread, just wanted to do a pre-emptive strike on comments and let everyone know that we know the docs have not been as good as they could be, that we are aware of it, and that we are working on it, and not in a slapdash 'quick fix' way, but in a long term thinking, comprehensive, maintainable, and very usable set of supporting materials.
this task is big. Big with a capital B-I-G. we tackled the small ones first, and now we are working on the big one (TGE).
#8
Now in saying that, I have to mention that we've had our frustrations too, especially on the modeling/artistry end, although things have gotten better. We've also had some frustrations with learning the script, but hopefully with better documentation that will get better too.
05/25/2007 (9:27 pm)
I'm not sure if I'm adding to this conversation positively or not, but here goes. Before our little company bought Torque, we looked at a lot of other game engines and between the freatures and price, we just couldn't beat what Torque has to offer. Some of the engines above cost thousands more than Torque.Now in saying that, I have to mention that we've had our frustrations too, especially on the modeling/artistry end, although things have gotten better. We've also had some frustrations with learning the script, but hopefully with better documentation that will get better too.
#10
As well as rendering, Ogre has a bunch of addons that cover most areas other than Multiplayer. This includes easy to drop in Physics and collision modules, Input, sound, GUI and HUD, paging terrain systems, scripting, scenemanagers of various types, particles, pretty much anything that you could want.
It also has a plethoa of languages that can be used with it through various wrappers. The high level API makes it easier to use than even torquescript in some cases like basic movement, rotation etc.
The material support is more extensive than Torques, especialy if you are using a fixed function pipeline for materials that work on older graphics cards.
If you do happen to have artists using 3dsmax, the art pipeline (Ofusion) is very powerful allowing you to use it as a level editor that actualy renders using ogre within a max viewport.
You can quickly set up your own systems for rigging gameplay objects with mount nodes, rather than being tied down with a long convoluted process that you have in torque.
Ogre has also been used in quite a few commercial games in the last year, one fine example being Alliance, the silent war www.youtube.com/watch?v=Q7USav6WQDU
which uses a very nice volumetric lighting and cloud system developed by ogres lead called Nimble
www.youtube.com/watch?v=pLfHDul5XGw
I'm currently working with a couple of developers on an ogre based engine and .OSM scene tools compatible with the Ofusion max plugin, but allows you to modify and create new levels outside of 3dsmax if you wish.
Having said all this, Ogre3D isn't a game engine out of the box, so you can't make a fair comparrison. But a decent developer can make a very good Game engine using it without much trouble.
Ogre seems to be having a lot of commercial success of late, and you are no longer restricted to LGPL licencing if you dont want it. It's cheaper than torque, but probably costs more if you want to get the most out of it and use something like Ofusion, which costs more than torque alone, but is worth every penny if your serious.
Having said all that, I actually quite liked playing with torque, but the way that so much has already been done for you, but in a simplistic fashion often gets in the way, and makes it difficult to work with. We played with vehicle physics and collisions and soon found it very limiting for the kind of game we wanted to do, even compared to our Blitz3D prototype. It seems great for generic MP fps. but getting much else out of it is a painful experience indeed.
05/26/2007 (12:23 am)
What are you trying to compare Torque too. I use ogre, and the render engine is far superior to Torques. But it isn't a game engine out of the box. However, a competent coder can produce a game engine with it in a relatively short time. Probably quicker than it takes to wade through torque, learn it and start a decent game from scratch.As well as rendering, Ogre has a bunch of addons that cover most areas other than Multiplayer. This includes easy to drop in Physics and collision modules, Input, sound, GUI and HUD, paging terrain systems, scripting, scenemanagers of various types, particles, pretty much anything that you could want.
It also has a plethoa of languages that can be used with it through various wrappers. The high level API makes it easier to use than even torquescript in some cases like basic movement, rotation etc.
The material support is more extensive than Torques, especialy if you are using a fixed function pipeline for materials that work on older graphics cards.
If you do happen to have artists using 3dsmax, the art pipeline (Ofusion) is very powerful allowing you to use it as a level editor that actualy renders using ogre within a max viewport.
You can quickly set up your own systems for rigging gameplay objects with mount nodes, rather than being tied down with a long convoluted process that you have in torque.
Ogre has also been used in quite a few commercial games in the last year, one fine example being Alliance, the silent war www.youtube.com/watch?v=Q7USav6WQDU
which uses a very nice volumetric lighting and cloud system developed by ogres lead called Nimble
www.youtube.com/watch?v=pLfHDul5XGw
I'm currently working with a couple of developers on an ogre based engine and .OSM scene tools compatible with the Ofusion max plugin, but allows you to modify and create new levels outside of 3dsmax if you wish.
Having said all this, Ogre3D isn't a game engine out of the box, so you can't make a fair comparrison. But a decent developer can make a very good Game engine using it without much trouble.
Ogre seems to be having a lot of commercial success of late, and you are no longer restricted to LGPL licencing if you dont want it. It's cheaper than torque, but probably costs more if you want to get the most out of it and use something like Ofusion, which costs more than torque alone, but is worth every penny if your serious.
Having said all that, I actually quite liked playing with torque, but the way that so much has already been done for you, but in a simplistic fashion often gets in the way, and makes it difficult to work with. We played with vehicle physics and collisions and soon found it very limiting for the kind of game we wanted to do, even compared to our Blitz3D prototype. It seems great for generic MP fps. but getting much else out of it is a painful experience indeed.
#12
I'm not sure how you remove terrain, but I remove it from the mission file and make sure that my models are spawned well within the interior. It's been a while since I've done it, but I haven't had any problems unless I forgot to change the spawnpoints. Then I would use meshes and collision boxes to make "terrain" the way I wanted it in Lightwave. Most of my prototyping has been for single-player RPG stuff, so I am not sure what the implications are network wise, etc.
I think Adrian nailed what the thread is about. I was wondering, as he was at the beginning, what Torque was being compared to. If I get time later in the weekend, I'll try to add a comparison to LawMaker and BeyondVirtual; and perhaps Unity. Of course, I will only really be touching on the things I use. It is rather pointless for me to go off on the differences between terrain when I rarely use terrain (though in BV, terrain is a model with mesh collision, while in LM it is closer to TGE's style).
05/26/2007 (7:29 am)
Quote:I'm Berserk and not Berzerk. I'll avoid to interpret this as a provocation, this time.A typo should never be considered a provocation, regardless. Between the Japanese character Berserk and the 1980 videogame Berzerk (which also holds the legacy of first video-game related death), some people just don't know whether it's a 's' or a 'z'. Especially if they rely on phonic spelling. But that's neither here nor there. A typo shouldn't be considered provocation, regardless.
I'm not sure how you remove terrain, but I remove it from the mission file and make sure that my models are spawned well within the interior. It's been a while since I've done it, but I haven't had any problems unless I forgot to change the spawnpoints. Then I would use meshes and collision boxes to make "terrain" the way I wanted it in Lightwave. Most of my prototyping has been for single-player RPG stuff, so I am not sure what the implications are network wise, etc.
I think Adrian nailed what the thread is about. I was wondering, as he was at the beginning, what Torque was being compared to. If I get time later in the weekend, I'll try to add a comparison to LawMaker and BeyondVirtual; and perhaps Unity. Of course, I will only really be touching on the things I use. It is rather pointless for me to go off on the differences between terrain when I rarely use terrain (though in BV, terrain is a model with mesh collision, while in LM it is closer to TGE's style).
#14
- A clean API - for example, C4 is touted as having a clean and easy to work with api. Who knows what clean means, good use of indentataion is no good to me but no dead-code and a consistent naming convention is.
I am a hobbiest, btw. ;) The upmost importance to me is the learning about creating a game. I buy and read the books, I consume products like nobodies business. I spend two weeks learning 3d software ... my big scarey monsters look more like the "big purple dinosaur" so I spend the bucks on a package, until my skills improve.
05/26/2007 (1:21 pm)
I'd like to hear some objective opinions from those who know, about the engine code structure, compared to others. - A clean API - for example, C4 is touted as having a clean and easy to work with api. Who knows what clean means, good use of indentataion is no good to me but no dead-code and a consistent naming convention is.
I am a hobbiest, btw. ;) The upmost importance to me is the learning about creating a game. I buy and read the books, I consume products like nobodies business. I spend two weeks learning 3d software ... my big scarey monsters look more like the "big purple dinosaur" so I spend the bucks on a package, until my skills improve.
#15
C4 Engine Architecture
C4 Engine API Documentation
One thing that C4 has that Torque could benefit from, in my opinion, is a bug tracker. No more digging through the forums or wondering if your bug report/fix has made it into the next build.
C4 Engine Bug Tracker
Lastly, an organized set of release notes, every build without fail.
C4 Engine Release Notes
The source code is clean and well presented. The links above should give you an idea of how organized things are - not important to everyone but it's important to me.
05/26/2007 (6:46 pm)
Quote:
A clean API - for example, C4 is touted as having a clean and easy to work with api.
C4 Engine Architecture
C4 Engine API Documentation
One thing that C4 has that Torque could benefit from, in my opinion, is a bug tracker. No more digging through the forums or wondering if your bug report/fix has made it into the next build.
C4 Engine Bug Tracker
Lastly, an organized set of release notes, every build without fail.
C4 Engine Release Notes
The source code is clean and well presented. The links above should give you an idea of how organized things are - not important to everyone but it's important to me.
#17
You would have to add some serious AI to a Splinter Cell game, but you could do a huge amount of the gameplay using triggers. Same with MGS. You would have to add in the advanced camera resource to get as responsive a camera as MGS.
I'm glad you qualified "spooky" though, because I read it and thought "what kind of freaky haunted house is Berserk driving through in the TGE demo?" Spooky was definitely not a word I would ever use for the demo or limited. So I'm glad you clued me in. Otherwise I would have been lost thinking about Fatal Frame meets TGE's racing starter kit.
For any of the engines, AAA or indie, you would have to do a huge amount of work and engine programming/tweaking/refining to make those games happen. I'm not sure if it is really a good match for the comparison topic. It would make a good new topic, however, to find ways to solve common problems to emulate what is already out there.
06/04/2007 (2:50 pm)
Well, it is a bit hard to gauge on some of the games mentioned. Take fighting games for example, they are often so particular to the control scheme, animation system, etc that the engine is built around the title rather than using any middleware solution. Of course, for most console titles this is often the case. Especially for stand-out titles like Grand Turismo or Tekken. GTA used Powerrender as its base, but was heavily modified to expand the world for Midnight Club before GTA hit 3D. One would have to have a huge amount of C++ experience and architecture knowledge to do those gametypes in TGE or Unreal for that matter.You would have to add some serious AI to a Splinter Cell game, but you could do a huge amount of the gameplay using triggers. Same with MGS. You would have to add in the advanced camera resource to get as responsive a camera as MGS.
I'm glad you qualified "spooky" though, because I read it and thought "what kind of freaky haunted house is Berserk driving through in the TGE demo?" Spooky was definitely not a word I would ever use for the demo or limited. So I'm glad you clued me in. Otherwise I would have been lost thinking about Fatal Frame meets TGE's racing starter kit.
For any of the engines, AAA or indie, you would have to do a huge amount of work and engine programming/tweaking/refining to make those games happen. I'm not sure if it is really a good match for the comparison topic. It would make a good new topic, however, to find ways to solve common problems to emulate what is already out there.
#19
One engine worth comparing Torque to is Delta3D. D3D is an open source engine financed by the US Navy. It is aimed mostly at the serious game crowd and military training simulations in particular. It has some things that Torque is sorely lacking. It has very nicely integrated physics (PhysX and ODE, so you can choose) and very powerful procedural vegetation. It uses Open Scene Graph as its graphics subsystem, for better and worse. It excels at outdoor scenes (OSG can produce top notch renders), but is stuck with meshes, so no interiors. Its world editor is comparable to Torque's, but you need to edit c++ to do things that you can normally do in script in Torque. Add to this the current mess that is their dependency library and it is very difficult to get even a simple test mission running. Also, the networking is not up to par with TNA.
06/05/2007 (12:25 am)
I'll take a stab at how the climbing on ropes is done. Not knowing anything about how they implement these things, I'd hazard a guess that these ropes have a string of dummy nodes that are used as mount points. They are probably evenly spaced to allow the climb animation to transition smoothly from binding one dummy node to the next. One engine worth comparing Torque to is Delta3D. D3D is an open source engine financed by the US Navy. It is aimed mostly at the serious game crowd and military training simulations in particular. It has some things that Torque is sorely lacking. It has very nicely integrated physics (PhysX and ODE, so you can choose) and very powerful procedural vegetation. It uses Open Scene Graph as its graphics subsystem, for better and worse. It excels at outdoor scenes (OSG can produce top notch renders), but is stuck with meshes, so no interiors. Its world editor is comparable to Torque's, but you need to edit c++ to do things that you can normally do in script in Torque. Add to this the current mess that is their dependency library and it is very difficult to get even a simple test mission running. Also, the networking is not up to par with TNA.
Torque Owner Berserk