Managing my actors...

[DtD]

I realised this post was kinda long, so I will summarize up front:
Is using custom scene nodes for my diffrent "actors" (Towers, Enemys, etc) a good idea, or am I gonna cause trouble trying to do that?

Also, for clarification: My game is a Tower Defense game (its like an RTS, but without units for you, and no buildings for them...) however I'd like to reuse as much of my code as possible in the future. However, in particular with an Tower Defense game, there are a nearly infinite number of objects that are constantly being destroyed and created.

BTW> And actor is basically, anything in the scene. Although, certain things (EG: Skybox or the level terrain, and maybe some static elements) won't be considered actors.

--------------------------------------------------------

Ok, I've been spoiled by my long-time use of Game Maker and want some opinions here.

Game Maker has always managed objects for me; running them (like running thier step events every frame), destorying them, etc.

And I haven't done object management sutible for a game for a long long time (Blitz Basic, wooo...) and I want a second opinon (or third, fourth...) on wether my method is a good one.

Basically, I have the following system that I call the actor manager:
I have a base class called act_basic that all actors are based on.
In the actor manager I have a core::array<act_basic*> that is used to keep track of the actors.
The main job of the actor manager is to "run()" the actors.
run() is called in the main game loop and loops through the actor array and tells them all to execute thier run function to interpet thier individual functions.
Here comes the main part I am concerned about: In order to keep the game from slowing down when alot of actors are being destoryed (because this might involve actor_list.erase, which warns that it is slow in the API docs) I instead "drop" them (similar to Irrlicht's IReferenceCounted::drop function, except it simple deletes the class, no grab stuff.) then put NULL in that actor's slot.
Then, in special times I call a function called cleanup() that does two things: A) Destroys all of the old slots. and B) Updates the id variable of all the actors (I have some ideas on how to remove this.)

Then, after that night when I wrote all that code; I thought "Wait...can't I just use a custom scene node for all this?"
But then I remembered from my Game Maker days on how it is a sin to do any major logic code in the Draw Event (like the render() function in the CSNs are far as I know) but then I thought "Well, when does Irrlicht do its animation stuff?" (Ya know, like the Rotation Animator?)

--------------------------------------------------------

So, all these things and more are flying about my brain, so I figure I'll get opinions from a few other people...
Do you think I am overcomplicating it with the Actor Manager?
Do you think that I am going about all this the wrong way?
Do I need to go back to Game Design 101?
Can I use Custom Scene Nodes (or even something better) for my actors.

Sorry for the long post, and sorry if this seems stupid.

~DtD
PS> Also, I wasn't sure if this should go in the beginners forum or the game programming forum.
PS2> Also, I tried searching some things, but I can't seem to find something relavant...

[bitplane]

The best way to do it is to have your own classes and structures that hold actor properties and do the simulation logic, and link these to an existing node with a pointer.
Decoupling the simulation from the visualisation allows things to happen without needing to see them. You could do the simulation on another thread or have the logic loop run many more times than the graphics loop (ie fixed time step), you could have a tiny scene graph containing only the visible things but tens of thousands of actors being simulated in the background.

However, for smaller games I usually just derive my actors from ISceneNode and store their locations and other properties in the scene graph. Why? Because it's easy. It's bad practice because my actors must exist in the scene graph for them to have properties, and of course my code is tied to Irrlicht; changing graphics engines would be a major problem.
I don't use the OnAnimate method of the nodes to do the actor logic though as this would be going too far. You don't want some fancy graphical effect to cause your physics or AI to suffer or vice versa.

I'll move this to the game programming forum, as it will be quickly buried in here.

[DtD]

Ok, so you mean to link the node to the actor, right? Not the other way around? If so, how do I tell the actor to run its "simulation", with something like my actor manager or something else?
--
I don't particularly care about the part about it being hard to change graphics engines, why would I switch from Irrlicht
Also, I'd like to stay away from things that are just "easy" rather than efficient because I'd like to keep the possibility open for a Wii port someday. (Not brew, this will be a commercial game hopefully)
--

I'll move this to the game programming forum, as it will be quickly buried in here.

Ah good point, thanks!

~DtD
BTW> My first C expericnes were on the GBA (Brew), thus I didn't use OOP (I could've used C++ but OOP was a no-no with the GBA) Therefore, I never "properly" learned OOP, I mostly glanced over tutorials. (Even though I learned PHP before C, I didn't understand why OOP is a good thing back then and avoided it like the devil.) I feel fairly certain I know all there is to know about the non-C features of C++, but if I am missing something big here, let me know.

[bitplane]

Ok, so you mean to link the node to the actor, right? Not the other way around? If so, how do I tell the actor to run its "simulation", with something like my actor manager or something else?

No, the other way around. Your actors may or may not have a pointer to a scene node, the scene nodes may sometimes require a pointer back to the actor. The invisible man might be an actor, but he doesn't need to be a scene node.