Torque and modifications

I purchased Torque back in 2004. At that time, I had no clue it would change my life. This is not a fanboy blog praising all of Torque, but an honest opinion of someone that, 2 years ago, had no programming experience whatsoever. I have always had problems with math and left school with quite bad grades.

Still, it worked out just fine for me. I hear many experienced programmers saying Torque is a mess and hard to learn, and I can not help but wonder how much time they have spent with it until they dismissed it.

Now, I'm going to talk about some of the modifications I have made recently, and to some degree: why I made them.

FMOD

I very recently implemented this into Torque and replaced OpenAL completely. As our game has a very focus on sounds, we felt it was needed. I'm currently playing around with LowPass filters. FMOD has so far been wonderful to code with, and reminds me about Torque alot.

I felt that the OpenAL implementation had a long way to go before it can be considered useful and I did not find its structure easy to understand so I did not bother to rewrite it.

ShapeBaseImage & a new MuzzleFlash class

This one was a tough nut to crack. We have alot of fast fireing machine guns in our game, and ShapeBaseImage does not seem to have been designed with that in mind. It is great for equipment though so we ended up creating a seperate class - we can call it weaponImage for the sake of this plan.

There are too many changes to name them all here, but the key ones are:

[*] Seperate 1st/3rd person images, much like HL2's system with one worldShape and a viewShape (different shape files, not to be confused with LOD).
[*] Multiple threads, so you can play more than one thread at once.
[*] The viewShape is static to the viewer, but moves side-to-side when looking around, and back/forward when looking up/down. There is also a seperate thread for move animations - again very much similiar to HL2's system.
[*] A callback into shapeBase which (in simple terms) creates a hitbox to the shapeBase object (and not to the image since it does not tick) if isCollidable is set to true in the image datablock. This way you can interact with the image.

I also designed a seperate client-only muzzleFlash class, that is built up by one single plane that changes texture depending on the direction of the viewer and the eyeVector. No need for complex shapes there. Big thanks to Melv May's documentation about rendering objects!

A new simple flying vehicle class, based on ShapeBase.

This is the one that took most of my time away during June-August. I had a simple flying vehicle class using clippedPolyList, and simplePolyList from the TankPack (which was VERY useful in understanding how collisions are handled on player-like shapes) but I ended up not using it because the physics were too simple, even for our arcade-like needs.

Martin Schultz and I discussed a little bit about flying vehicle issues by email and this awoke my interest in the subject again. So I redesigned the class and ended up with what I have now: A pretty simple flyer, yet that behaves as you would expect a flyer to. It does not have a rigid body, though - but is even lighter on CPU than the player itself.

Conclusion

I've got a few more major modifications that I have made, but time is running out and I think the above already illustrates my final point: ANYONE can learn this stuff (Torque :P) and go far, given sufficent time and dedication!

Thanks!