Better to write your own code and actually learn something in the process.

As I mentioned, Torque is not just an engine. It comes with integrated content creation tools and this is very important in getting a game up and running quickly. Ogre doesn’t really have any, apart from some community attempts. It doesn’t even have an official run-time binary scene file format (closest is the dotScene plugin) or scene editor.

For most cases, it will be slower (R&D, development, integration, testing, refactoring, bug fixing), more difficult (skills, management), and costlier (manpower * skills * time), to develop your own engine, at least in the short term (1 to 2 years). That’s why we chose to develop a framework that wraps each middleware in a plugin component, instead of an entire game engine. We are using Ogre, PhysX, Squirrel, and RakNet at the moment.

We made this decision based on our requirements (more net-centric in terms of delivery and content loading than traditional engines) and what complete middleware solutions were available at the time that we could afford. Today, we would probably have chosen Unity.

In the end, it came down to expectations for us. Torque’s features promise (as far as a marketing bullet list does) a lot of things, but the reality didn’t live up to our expectations, mainly in terms of quality of code and ease of working with it. So, our recommendation is that if you want to use Torque,

- your game design shouldn’t be too far away from what you see in the Torque games showcase
- make sure you have good programming capabilities in your team because it is not just for artists
- be prepared to deal with a bunch of proprietary stuff that doesn’t have a lot of good documentation (frustration)
- be willing to pay for real support

IMO, the best professional showcase for Torque (don’t know if it is TGE or TGEA) is the Penny Arcade game series by Hothead. Other more polished Torque games are mostly by GG themselves who know the engine thoroughly. Hopefully, Hothead will share details (not just a postmortem) of their experience and tips with other Torque users.

Once we made the decision to build our framework, we started to look for dedicated middleware that only did what they needed to do – lighter weight solutions, not full game engines. In this respect, Ogre delivered more than we expected in terms of capabilities and extensibility, so it was a good first rendering engine for us. However, this also meant that we needed more technical development skills, time, and money to get to the same level of capabilities as Torque. We’ve spent the last year building this foundation for our company’s future and a prototype, more or less according to plan (some setbacks and slow periods, of course), so this year we can start building on the game. Therefore, this route certainly isn’t suitable for everyone.

In general, the adage of “use middleware” is a wise one these days, but evaluate your middleware carefully and thoroughly, and don’t forget the content development tools!

W.R.T. to Jason Maskell’s comments on Torque (TGE),

1. There are lots of Tribes-specific code, like weapons, etc. even in the engine. This defeats the purpose of a heavily script-driven engine design.

2. I really dislike TorqueScript as well but I think this issues shows how old TGE really is. At the time, there were not many options for embedded scripting languages, and there definitely was a culture of roll-your-own/not-invented-here back then when middleware wasn’t widely available or mature.

3. Script-driven architectures are popular now for game engines, so TGE was probably a bit ahead of the times then for how extensively it relied on scripting. However, this also meant that it had a very complex scripting framework on top of the C++ engine itself. To use TGE effectively, you’d have to learn how both these systems work.

The 2 books Jason mentioned are 3D Game Programming All in One and Advanced 3D Game Programming All in One, both by Kenneth Finney. They deal mostly with TorqueScript but I didn’t find them useful in overcoming TGE’s complexity.

4. TGE is outdated, IMO. The complexity required to learn TGE and deal with its problems is too high.

On the other hand, TGE network is quite well-designed. The problem is that you have to learn about the scripting framework and engine in order to use it properly.

TGE and TGEA are game engines with content creation tools, not just frameworks or APIs, so they do provide more complete solutions. However, some of these tools are a little cumbersome to use and are tightly integrated. This is not an artist-only engine. Scripting will be required.

The community is quite active but for serious support with detailed and authoritative responses (not just guesses), you’ll have to pony up extremely non-indie-friendly fees.

Other issues I’ve had:

* We got TGE early and like many TGE and GG supporters, paid up for TGEA as early adopters, thinking that the money would help GarageGames develop TGEA to get it to market earlier. Imagine our disappointment when GG released Torque2D, then Torque Game Builder for XNA after a year or two, while TGEA didn’t see much progress. Documentation and support efforts reflected GG’s new focus as well. Essentially, we felt like we helped pay for the development of 2 engines for GG that wasn’t useful for us. GG never promised the TGEA early adopter money would be spent on TGEA, but those of us waiting to upgrade to TGEA were pretty much left hanging for years.

* the feature list for TGE sounds great, but many things are either not what they seem or are simply broken in the engine. e.g., player-player collision doesn’t even work http://www.garagegames.com/community/resources/view/12174/1#comment-76503. We don’t feel like we can trust TGEA either.

* console platforms require additional license fees at non-indie-friendly prices. At least 4 figures. And you can’t even do the porting yourself to avoid this fee.

* documentation is outdated, inconsistent, and haphazard. We, and many others in the community, asked for documentation for the custom DTS format to create our own mesh exporter (or maintain abandoned ones) but we never received any help on that other than a “you can look up the source code”.

* a lot of bug fixes and some features get put into the engine through cut-and-paste code from the forums, leading to ad-hoc, highly inconsistent quality code. Try maintaining that.

You can use TGEA instead (with no fixed function rendering support for older machines), or even wait for Torque3D, but frankly, after our experience with TGE and the changes in GG that we’ve seen, it’s left a sour taste.

We are currently developing our own framework that uses Ogre for rendering and other middleware. It’s been quite good so far, but it is a 3D rendering framework (3D API + additional features like an integrated resource system, a plugin architecture that allows extensions, etc), not a full game engine and no real content editing tools. It can be quite complex, but has a good core design.

Performance so far is quite good, even when running in conjunction with other systems like PhysX, Squirrel scripting, etc. On a dev system with Q6600 CPU with 8800GT video card, we are getting up to thousands of frames per second, depending on the complexity of visual effects.

There have been commercial games shipped with it (Pacific Storm, Jack Keane, etc) and some good looking games (http://www.ogre3d.org/gallery/) in progress. It provides both fixed-function and shader pipelines so the visual range is wide.

Also, Global Conflict: Palestine was built using it.

I think you’re overvaluing source code access quite a bit. You really owe it to yourself to try building something with Unity. The model is quite different from the Torque world.

I went from being an experienced coder with no game development experience to speak of, to shipping game in 3 months with Unity. Complexity-wise, my game is probably only a factor of 2-3x less than Venture Africa as well.

-JF