Q: Why no tutorials / articles / code snippets that are OO?

#1 well, many times you want to just change the base code instead of deriving a new class and making it work in the whole torque engine (ie add it in editor, in managers, etc) its not that easy

#2 subclassing to override methods to alter behavior will not break any editors or anything, that is the whole point of subclassing to alter the behavior without breaking the public interface.

also if the objects are scriptable they will work as is with any of the editors or managers or what ever you are concerned about.

Example I override the Projectile class and create a new Class that inherites called Bullet.

Now Bullets move so fast that they do not need to have visiable model or a bounding box, I can change the collision code and the drawing code and any other behavior by just re-implementing the methods, sometimes by actually calling the super method and then altering its output slightly, sometimes writing completely new code.

That is why you subclass, it is so you can change the behavior of an object without breaking its contract with its interface.

That way you instantate Bullet objects for bullet based weapons and the engine calls the exact same methods and they do something differnt and the engine, since all the tools are engine based, they would not break.

#3 well projectile is easy, but what about ShapeBase or Player objects, to subclass those u would have to do some major coding

#4 your going to have fun with the player class ..
deriving from it. As you get to know it you shall see..
maybe a brief introduction is in order:

First we would have to ask ourselve's .. Why?
what do we need to Override this class for?
what needs to be here that has no relation to the Player class current?

Ok once we have found that ...
in my instance .. I needed a Life object...
one that would have most of the player features in the game, I also dont really want this to be a Player Object.(one that can be used by the end user)
Simple no?

there are some other things ..
but maybe you see where im going with this.
there is some functionality in the player class...
that might not be acceptable for your next class,
and it sometimes cannot be avoided.
My resolution here was to start a New class Not deriving from player class .. and instead copying some of the functionality from it instead of using it.

as for the other's you mention:
Vehicles are made to do it and are already.
Projectiles Same case except they were all removed.
Items .. I think will be different again a little more like player there are some crappy things you would want to avoid in a new class, otherwise you might find your stuff belongs with Item not a new class.

And, Most things Do derive from exhisting game framework .. how the heck else would the good stuff get in?

the PathedInterior I wrote is derived from GameBase :)

Edit:
and of course by now you must have easily noticed the operations of the Parent variable in each class.

you will see when it comes time in your derived class,
to handle the Parent class' needs just what kind of trouble the deriving class brings.
Of coure this is case specific and will only hurt when the parent class is doing things you dont want to do.

im not up on a soapbox saying this cant be done..
im merely stating that it will be fun(the player class)
and the goal of not modifying the current class will make it a real challenge.

#5 not a problem I have already sublcassed Player and created an AttributedPlayer that has all the stats and collections of skills and what not.

Now the mDataBlock is only referenced for default values and there are instance variables for all the ones that should be dynamic.

I over rode the updateMove() operation and completely rewrote it to change the behavior for movement, I have had relatively few problems with it. The ones I have had were MY lack of understanding about TGE idioms, not the OO part.

It was very straight foward, if I don't like what the superclass is doing, don't call it and completely re-implement the behavior.

Next up is a Race class and a Profession class that AttributePlayer will inherit from also and they will offer even more flexibility.

That way I can refactor the ability code to the Race class, and the skill code the Profession class for a cleaner separation of logic and much easier to read code.

These will only need to be regular C++ classes and AttributedPlayer will handle marshalling their persistant attributes back and forth across the wire!

Class based players will be simple to script on the front end and will have practically limitless possibilites. For ORCs you just define them differently in the datablock than a Human or Elf for example.

There is some whacky stuff in there but I am just overridding what I need to and ignoring what I don't need, and if don't want it to work at all I can just override the operation with an empty implementation.

Also if you need non-humaniod Player objects they can be subclassed out to support multiple arms, legs, head and what not without merge maddness or having 10,000 lines of if () code in player.cc and player.h