I don't know anything about your project and the current state of it, so I have to stay vague in my answers.
It seems you're doing the detail work before you've cut down your project into chewable parts. I usually (haha, so far only two medium to large hobby game projects) start by breaking down the project into sub-systems. Like graphics, physics, ai, user interaction, game logic, etc... Those are layered, meaning the interaction is, save for callbacks, one-directional.
The game-loop does work on these subsystems using a very high-level interface. Usually with a
Facade class.
Getting user input, AI thinking, physics update, graphics update, etc..
Within these subsystem, the same facade class or other helpers have a service interface for smaller specialized classes within the subsystem.
This for the larger picture, now to your problem.
Problematic in your case seems the control-flow. Do those bots really need to get the time, or might it not be better to give them the time. Push instead of pull.
Say, you have an ai subsystem in your project. The game loop calls an advance(float time) function on the ai facade class. Then the facade can determine all active bots, since it manages those and let them do their thinking over a well defined interface. For instance by also calling advance(float time) on those bots.
This way you streamline control-flow and you ensure, that your classes only have access to what they need and thus prevent the interface from getting cluttered and classes calling each other all over your project with you loosing control over what class depends on what other. Trust me here, this happens faster than you think.
Of course time is not the only knowledge your bots need. Determine what is needed and lay out the interface. Decide if you should push it, or if the classes need to pull it. If pulling, from where. Imho only the subsystem facades should have access to irrDevice and grant access over their own interfaces. Not only does it shield your project better from interface changes in irrlicht, since you have now only few places where you need to change your code. But you also minimize dependencies on class level.
The game object class hierarchy for all the entities in your game is difficult to design and thus it is important to give it *really* much thought. I know nothing about your project, as said already, so still vague here.
First of all: Don't even think about making it a SceneNode.
The SceneNode should be either a member of you GO class or be wrapped by a graphics subsystem wrapper class, but not a child class of SceneNode.
My approach is to have a GameObject class with its childs (Creature, < Item < Container, Weapon, Armor). The child classes are only done for fundamentally different concepts that have to be handled differently on a higher level, the rest is data-driven.
A GameObject has some members, a wrapper for the graphical representation, one for physics, one for sound. The game logic only uses this class for interaction, and does not directly control physics or graphics. The GO itself does this, based on the state of it.
HTH
Saturn
