Some general advice

[Sachiel7]

Hello again.
So, my current project is (this may sound wierd) an on-rails shooter engine.
I have level creation and camera scripting more or less done. Now I'm focusing on general characters within the scene. I want to ultimately have a scene scripting engine, which triggers events as time passes.
So, I'd like to make things simpler by moving my character meshes with Scene node animators. I'm wondering what the best method would be for this. I want to basically free up the animator when its done with the motion commanded by the scene scripter. Do non-loop animators free themselves when finished? I don't think so...
So I have two methods currently in mind:
1)have a global animator array managed by my game engine that automatically frees animators that aren't running (Not sure how to do this since the Animator class doesnt seem to have any mention of ->isRunning() or anything of the sort)
2)have each enemy/character contain an two animators, one for translation and one for rotation. these will free up as characters are spawned/killed.

Any ideas on which path to pursue?
I'm setting up a character class, that contains Physical properties like HP, Speed, Accuracy, etc, and some functions for animation/movement, AI, attacking, getting hurt, etc etc.
I'd like to post a video of my progress once the project is a little further along...I'm using some semi-unique controls...

[Trefall]

I would think object oriented. If the animator belongs to a certain entity, like the player class, then that's probably where it should be. Also, I'd rather use a singleton than a global since you can control when it'll be instantiated (it won't eat any memory until you call it the first time).

I'd also break your code into manageable pieces. So instead of having one huge class holding all the properties and functionality of a character, consider using the component approach (decorator pattern) or go with a deep hierarchy approach.

If a deep hierarchy, at the bottom, you might only have the scenenode and an unique entity id, you might subclass that by adding one subclass with physics behavior and one subclass with static behavior. Then subclass the physicalEntity class with maybe Actor, which holds properties for an actor, like HP, speed, etc. And subclass the staticEntity with Item, which holds common properties for items in your world, and so on. For each subclass you also add the functions that complement the subclass' variables.

I think deep hierarchies are rather messy though, and very prone to bugs (and difficult to solve some bugs effectively, as you might end up having to rewrite a lot of subclasses due to some error made deep into the hierarchy chain), so personaly I prefer the component approach, though it might take a little longer to get the component approach properly implemented, it's worth it imo. I'd rather spend a little extra dev time there, than on bug-tracking headaches.

Looking forward to see what you come up with