TGEA - The Good, The Bad, and The Ugly.

#1 TGEA is solid, all around. The materials system is good and easy to work with. Visual quality is pretty good. Performance is good. Torquescript is sufficient. The in-game editors are sufficient, though not superb. Lighting and shadows are probably the weakest part of it right now, compared to an engine like C4. They aren't bad though, main issues are transparency and shadows, and lightmaps not being able to update with the sun if you have a day/night cycle. Physics are simple but fine for most games. The network code is very good. Groundcover is nice. And feature wise there are a lot of cool extras that you get from either community resources, or from the maturity of the engine. Things like precipitation and particle effects. The decals in TGEA are a bit subpar at the moment, though.

I own a pro license for one of the older 3D Game Studio engines (it was a tax write off so I used to license and review them all for my web site), so in comparison to that you can expect a nice graphics boost, and better performance. The editors aren't as easy to use, though.

Torque does have a steep learning curve, so be prepared for that. There are a lot of subtle things to Torque that you won't understand at first. After a while they become like second nature, but when your first learning it may confuse the heck out of you.

#2 Thanks for the great explanation. I've noticed that you are a programmer, so from the programmer's perspective, how would you rate TS on a scale of 1-10? How much access does it actually give you to things like the render buffer, lod coding, etc? How hard is TS to learn in comparison to having previous experience in c-like languages? How fast is TS (seeing as you have experience with 3DGS)?

And one last non-code question, about how much do you think TGEA can take in entities, texture sizes and all before it chokes down (just an estimate like "alot")? Or does it totally depend on your hardware?

#3 LOD is all done automatically in Torque based on the pixel size on screen. If you wanted to rig it up to handle it differently you would have to edit in C++ to make the change. From C++ you can define ConsoleFunctions/Methods which allow you to call them from script. They are already set up for most of the commonly used tasks, but you can extend anything that isn't by modifying the C++ code.

For actual rendering, none of that is done in Torquescript, and for good reason (performance). You can create objects and datablocks to be rendered in Torquescript, create particles, etc, but the nitty gritty is all done in C++.

Torquescript itself is pretty easy to learn. There's some public documentation somewhere on the web site. The performance on it is decent. Most of your game logic would all be handled in Torquescript.

All depends on your hardware. I can give you a real world example, from the project I'm currently working on though. All of our textures are 1024x1024x32 bit (8 bit alpha for specular or transparency) and most textures also have a 24 bit normal map. Our game is an MMORPG, and our zones are 3km x 3km each in size. In the starting zone we have about 300 different NPCs, 150 trees, about 80 cliffs (rocks), a waterblock, a good sized city (interior) with 3 large animated advertisements, about 15 shop signs that turn on and off with glow effects, dense grass throughout the map, lights that turn on and off throughout the city. We have 6 large buildings outside of the city, barbed wire, barriers, a dock, and 3 dungeon entrances. It's relatively well populated. On our low end target system (2ghz+ single core and a 6600 video card) you can get 50 frames per second on average, but it dips to about 24 frames per second in the city. On a higher end system with all of the options turned up (anti-aliasing, HDR) you get over 100 frames per second.

We're not pushing graphical brilliance here by any stretch. Most of our characters are using 3000-4000 polygons, and weapons are much lower (500-1000). So it would vary by what your putting into it. Screenshots can be seen here for examples of those scenes here: www.therepopulation.com/screenshots.html. But none of those character or monster models have LOD on them at all currently, and those numbers are taken playing in single player mode with hundreds of NPCs being tracked on the same system. In general perofrmance is pretty high. It should be noted that we are using Atlas, which renders significantly faster than Legacy or Megaterrains in 1.7/1.8, and we have made a few C++ modifications to allow for better customization and performance on older systems. But that should give you a ballpark idea of what to expect.

For a living example check out some of the games on InstantAction.com which are mostly (if not all) TGEA based. There are also some TGEA based products here at the GG store (with demo most likely) and Steam.

#4 Yes, I have looked into InstantAction, and by what explanation you've given me, you've really renewed my trust in TGEA.

I was happy to begin with that it was the Tribes 2 engine.

If there is more to explain then I'd love to hear it.

#5 Ok, I do have a couple more questions:

1. How is the shader editor? The engine describes "click together" ones, does it mean that you are actually editing the code to "click them together" or is it like selecting the types of materials that you want ex: normal mapping, toon, etc., or can you do both?

2. What kind of bugs are there, and how bad are they? any show stoppers?

#6 @Glen, there's no material "editor" tool per se, and if what you saw was recent, it may have been something that will be in a later release. In the current version of the engine, you define materials in script. It's pretty simple to add all the standard stuff in a material (normal maps etc).

#7

Quote:
intermediate in c-script (c like language), but I plan on learning TorqueScript as soon as I get my hands on a copy of Torque.

Interesting note: the ".cs" extension we use for TorqueScript is actually short for "C Script". TorqueScript is a C derivative language that has been customized to make it easier to work with Torque and game development in general. You can actually see our flex/bison configurations used to generate it if you buy the engine.

In general I tell people that if the are familiar with C or a C-like scripting language (javascript, actionscript, etc) then they should be able to get fairly comfortable with TorqueScript over the course of a weekend.

#8 @Ross: ok, that's cool.

That is interesting. As before mentioned I am currently using 3DGS and they use a c-like language. The new version has lite-c which is a bit different. Anyway, that means that TS will be a bit easier I think. I just think the actual functions may take a while to learn. Thanks for the info matt.

#9 Could I see some code examples?

Few more questions:

Is it possible to allow for users to "mod" a game that has been built with Torque?

Does the engine automatically scan for sub directories and files in those said directories? if not is it possible to do so?

Does the engine support adding "on-screen entities and gui" in the scripting language? If so, is it possible to apply shaders to said entities and gui?

Assuming that you can add "on-screen entities", do they react properly to lights (I.E. lights that are close to the camera affect the entities correctly)?

What all kinds of camera control do you have in TS (vector positions, movement, p/t/r (pan tilt roll), render passes, etc)?

#10

Quote:Could I see some code examples?

Download the demo and you get access to all the scripts to read and play around with. The only real limits on the demo is no engine source and you can't publish a game.

(At least I'm 99% sure this is/was the case, been a while since I looked at the demo downloads.)

#11

Quote:Is it possible to allow for users to "mod" a game that has been built with Torque?

Yes. Include the creator folder or a subset of it.

Quote:Does the engine support adding "on-screen entities and gui" in the scripting language?

Yes. You push a gui to the screen and pop it from the screen when you are done. This is all done in script.

Quote:is it possible to apply shaders to said entities and gui?

Are you talking about objects? as in 3d objects? If so, the answer would be yes/no. It doesn't out of the box, but there is a mod here for tge that you could port to tgea that could allow it.

Quote:What all kinds of camera control do you have in TS (vector positions, movement, p/t/r (pan tilt roll), render passes, etc)?

Out of the box, it pitches and rolls. (turns) There is a mod here to add advanced camera options, but I don't know if it works in tgea or not.

#12 Sounds good, except for the camera stuff... I figure though that camera is handled through models, there seems to be nodes for them in any dts model exporters. Granted, I would like to have full control of the camera, but that would also be possible through editing source if the mod didn't work for TGEA.

Thanks very much for your answers, judging from what I've seen with alot of the T3D blogs, I think I might wait for it to get the engine, however references for TGEA is a great start. I'll probably have more questions soon, so keep watching the thread. :D

#13 You guys have been really helpful. Thank you all for the help so far. Looking forward to brett's next T3D post for more info on how it's progressing.

Few more questions:

1. Does the engine have any packing tools?

2. Assuming that 1 is true, what all kinds of packing tools can you use? (packing source in exe, Q3-style resource packing, etc)

3. How complex is the source to modify? (on a scale from 1 to 10, 10 being the highest) explain please ^^

4. What all properties can you change on entities? (vector position, pan/tilt/roll, material, etc)

5. Do gui object automatically change depending on the resolution, or does that require extra scripting?

6. How complex is adding new ppe shaders? (as I understand it you have to add them through source editing)

7. Does the documentation have an offline version that installs with TGEA?

#14 1. Not automated but you can package your assets in a .zip file and use them directly.

2. Q3 style resource packing in .zip containers.

3. That depends on what you want to modify. There are some areas of the code that are very easy to modify without breaking anything. Other areas... I'm a 20+ year C++ veteran and I have used Torque since 2001 for several projects and I still experience significant difficulties doing certain types of things. The biggest two problems: Torque was written as a game and was never originally intended to be used as a generic game engine. It still has huge remnants of its origins, which is Tribes 2. As such, it does not have any clear cut API. If you want to do something that isn't documented, you have to wade through hundreds of thousands of lines of code in order to figure out how to do it. Although the documentation is much improved, it still doesn't solve the problem of the software lacking a clear cut API.

4. That really depends on the entity and how you code it. Torque has example entities as part of their FPS and Racing starter kits which you can modify position and orientation, but generally you do so by modifying the physics force and torque parameters, not by directly modifying the position. This allows the collision detection to operate correctly. You can also easily change materials. Since these entities are "examples" then you are expected* to write your own, and therefore you should be able to pretty much modify anything you wish.

*Note: You will get conflicting answers here. This is one "official" answer, whereas other people in the community say that you can make a game by slightly modifying the examples. This really depends on the type of game you are creating as to whether you find this to be true or not. If you're making a game that's similar to Tribes 2 then probably you can get away with it. If not then it's best to go into it assuming you'll have to be writing code... but you do have examples.

The biggest stumbling block here is that nothing identifies what's "example" code vs what is actually part of the engine (as I said, it has no clear cut API).

5. This is automatic.

6. Source editing is required, although you can purchase a SSAO "example" so that you don't have to figure out how to make it work yourself. It's not terribly expensive, plus you get SSAO (but limiting your game to 3.0+ shaders)

7. Yes... I believe this is what's included. It's incomplete but GG has a full-time extremely talented and dedicated person working on it, and he has high aspirations of the documentation being the best game engine documentation available.... Even if he falls short of his goals, it's still a huge step in the right direction.

#15 Thanks. I intend to make most of my content from scratch in code anyway, I prefer it. The style of movement and stuff that I want wouldn't be Tribes 2.

You've been very helpful, as before mentioned I'll probably have more questions and stuff. :)

#16 Just to chime in on the camera - it is actually very easy to modify how the camera behaves in the source. You can adjust the camera's rotation and position on all three axises and you do not have to rely on camera nodes in your models. For example, it only takes 4 lines of code to make a "god view" type camera. It also only takes a few lines of code to make your player move relative to the camera's position/rotation.

It really is very easy to create different styles of player/camera behavior.

p.s. Buy TGEA!

#17

Quote:Just to chime in on the camera - it is actually very easy to modify how the camera behaves in the source. You can adjust the camera's rotation and position on all three axises and you do not have to rely on camera nodes in your models. For example, it only takes 4 lines of code to make a "god view" type camera. It also only takes a few lines of code to make your player move relative to the camera's position/rotation.

It really is very easy to create different styles of player/camera behavior.

That's nice to know. However, with nodes for camera positions, I don't think I'll need to edit exact camera positions, but it is nice to know that it's not that hard.

Quote:p.s. Buy TGEA!

I can't just yet there are some things we will be working on this year to push our company(s) forward, and It won't be until sometime later this year, unless things go really well. I WILL get Torque though, whether it be TGEA or T3D(technically still TGEA), and in the future TGB.

#18 What's the highest and lowest number that variables can handle in TGEA?
Or is it possible to make numbers extremely high?

#19 :D anyone got an answer?