A 'real' ShapeBase?

#1 What most people do is to "mimic" shapeBase--derive from GameBase, and bring code over from other classes that you find useful.

You point out one of the fundamental issues with a hierarchical inheritance system--shapeBase is in fact exactly what you describe: the class where functionality was re-factored to so that the most game objects could have that functionality available. It absolutely makes for a bloated class, and can be hard to manage.

Anecdotal story: in the game Deer Hunter (which was made by Dynamix from the Tribes engine, which of course is now Torque), for about 2 weeks during development deer had jet packs--because they both inherited from shapeBase, and would auto-equip them if they ran into any lying around in (old, transitory) missions.

I've also heard stories of the butterflys from BraveTree's Nature pack auto-wielding crossbows, for the same reason.

#2 8)

I love working with Torque sometimes. Well, you know, it's sort of a love-hate relationship...

Anyway, I just found out about fxRenderObject. That has gone a long way to helping me understand what's going on. I had thought of just copy/pasting from ShapeBase, but the code is too, as you say, bloated for me to get my head around. Seeing it in simplest-possible form in fxRenderObject helped a lot.

So I'm just going to create my own class. I'll use fxRenderObject as a base, take elements from TSStatic to get the shape, shadow and collision, and then see what I can do from there. Animations and sound will be needed, so I guess that'll warrant a foray into ShapeBase land...

Thank you for the response. :)

#3 @Stephen: Not only made me laugh, but will most likely be someone's next great game idea. Non-intelligent, incidental NPCs moving around the scene that auto-wield weapons they pass over and fire at random in random directions. I'd play it just for the grins.

Imagine going into stealth mode to sneak up on an enemy when you suddenly take a crossbow bolt to the ass from a passing butterfly or squirrel who doesn't know, doesn't care. Or look up in time to see a beaver cut loose an 203 round into a flock of pigeons, giving away your position.

"In a world gone mad, brainless little creatures with bad-ass tendencies."

#4 I'm calling it 'BasicShape' :P. 'BaseShape' would have been evil.
Wonder if there's be any interest in this as a resource? I'd reckon it'd be useful for those people who don't want their dragons to spew shell cartriges....

#5 What would be a most excellent resource in my opinion would be extending the fxRenderObject with various other capabilities that ShapeBase (or below) provide, incrementally.

Instead of aiming at one big, large re-production of ShapeBase, the resource would show small things, like "hey, if I want the 3 animation threads that Player allows, and the ability to blend those animations, what would I have to do" style--ok, so that's not a particularly small thing I admit, but approaching it from the knowledge required to glue small bits and pieces into your BasicShape one at a time would be great.

#6 Yeah, that'd be the best approach from a learning standpoint. Hey, here's a deal, if I ever understand anything that goes on in Torque's guts, I'll write a tutorial about it ;P.

But that's what I'm currently aiming for with BasicShape - it's basically a TSStatic with datablock support, as far as I can tell. From there, anything can (and will) be added to it. For a custom class my game will need, I'll be doing animations, sounds, and particles (plus explosions) at least. So there's a good few 'how-to' resources right there.

EDIT: First compile... only 11 errors! I bet they're all doozies...

EDIT: ...and they were all because I forgot to include the header. That done, I now have 77 real errors. Oh, joy...

EDIT: ...knocked down to 27 by adding a semicolon...

EDIT: ...and we're back to 11!...

EDIT: ...and back up again, me having forgotten to add castRay, buildPolyList and buildConvex...

EDIT: Got rid of those errors, but now had to introduce all the BasicShapeConvex methods. Back up to 7...

#7 Yes! First successful build, after exactly one hour's work this morning. I'll test it later on, and if it works, test it some more. Then I'll start writing up a resource. It probably won't be a full 'how to breed puppies between fxRenderObject and TSStatic' thing, just the code, how to use it, and an example. I wouldn't go as far as commenting - a lot of the time I don't understand what's going on myself!

EDIT: Well, I can add it to a single player mission with no problems. Datablock works as expected. Collides with the player and projectiles. Looking good so far!
There seems to be no shadow appearing; I don't know whether this is a mission editor thing. I'll try saving one in a mission and reloading it.

EDIT: Adding a BasicShape to the mission, saving and reloading, the BasicShape disappeared. I assume this is something to do with the way the Mission Editor saves objects. I'm going to write the shape directly into the .mis file.

EDIT: Hmm. Even then, the BasicShape doesn't appear in the mission. Really odd...

EDIT: I reckon the problem is in the networking of the object, though I don't know what I'm doing wrong. Looks all right when compared to TSStatic and ShapeBase.

#8 Daniel,

Try heading to the world center (0, 0, 0) and see if your BasicShape is over there.
I went down the same path as you a while ago, and it wasn't enough just to copy ShapeBase over to another class and expect it to work.

I can't remember the details, but I think you need to manually add the object to the SceneGraph container. Why would you need that when it's not done in ShapeBase? Most likely that functionality is set somewhere else outside of the two ShapeBase source files, but that's a guess.

#9 Thanks for the tip! Stupid of me not to look in the MissionGroup tree, butyeah, the shape was created, just in the wrong spot. Odd - I used coordinates I'd read from the mission editor, but they put the object somewhere different. Meh. At least it's working!
I'll start writing this up as a resource. Probably be submitted tonight or tomorrow.

#10 I think a resource of this would be cool.

#11 Uploaded it, though I don't know if people can see it until it's approved. It's called BasicShape.

#12 You can paste the url here until it is approved.

#13 http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=13361

#14 Quoted for truth. Though as it's only the post above I didn't actually quote it...

#15 I had been messing with this a long time ago. I really got frustrated with trying to figure what does what. Reading this has helped a bit.

One suggestion that may make for some really useful objects is creating sets of classes that inherit from gamebase and add specific features. If the features are documented in each object then it would help in understanding each piece in its own context. Then you don't actually use these objects. You create objects that inherit from multiple parent objects.

For instance:
AnimBase - animation object
CollisionBase - collision object

class NewObject : AnimBase, CollisionBase

I don't know if the syntax is correct, but you get the idea. Both parent objects would just provide the changes from gamebase. One detail that may be a pain is calling functions that both parent objects may modify. I think one is tick() or ontick() or something like that. Maybe that can be handled by explicit calls:

AnimBase::ontick();
CollsionBase::ontick();

Rather than:

Parent::ontick();

Anyway, thanks for working with this.

#16 No worries. About different object types (animation, collision, etc.), I was intending to just add that functionality to BasicShape gradually and turn it into a new ShapeBase - all the features you need for a shape, but less overhead. But yeah, some features should definately go into subclasses, that's a good idea. I don't know if it's posible to inherit from multiple classes, though (my C++ is no good).