Engine Control

I think you're going to need to better explain what you are looking for. What do you mean by control the engine? Can you explain what you mean by a controller and what does it do?

Sorry.
I mean managing states, adding objects, tell it to load scene, and all that.
Adding objects should probably be a function inside the engine itself, right? But I need something to tell it "Hey, create a box!". Say my character throws a huge ball, then the character has to tell the engine, "Hello? Throwing ball over here!" and the engine has to create the ball, and so on. That's what I'm looking for. Adding a pointer to the engine to the character (so it says like engine->createBall()) seems wrong somehow. Or is it?
What should tell the engine what it should do? I'm a bit lost, as I said...

You mean object management as in creation/destruction then? Think of who has responsibility to create or destroy the objects. What "events" will lead to creation or destruction of something? Who will know about the object? Will any who knows about the object need to be notified if it is deleted - the observer pattern (see wikipedia article with that name) is one way of sending such notifications. Another idea is to make nobody know about an object directly. Instead, give them an id (let ids be of type unsigned long or similar to prevent the engine from running out of ids) to make a lookup in a map data structure to see if the object is still there. If it isn't, assume someone else deleted it and remove all knowledge of it.

You definitely do not want some big "Engine" class that does everything. Instead, split up your "engine" into systems that do specific things. Then those systems, usually you will split them up into separate componenets (for lack of a better word) that do even more specific things.

For a quick example, maybe you want to be able to procedurally generate boxes, balls, and anything else that comes to mind. You would need some sort of system (this is where design comes in) to generate 3d models given sets of parameters. At this point you might have a class for each type of model you can generate. Etc. Etc.

That was a whole lot wrapped up into just a few sentences, and there are books worth of details that were not covered, but anyway try to separate things out, or you will become quickly overwhelmed. Once you have this figured out, "controlling your engine" is simply the interface to each class (barring more advanced techniques like scripting but I have a feeling that's a good ways off!)

Cheers
-Scott

[edit] To illustrate further (although I'm getting repetitive)... you don't want

      Engine -> 1000s of functions to "control it"but rather:     Engine -> Model Generator -> Sphere -> Few functions to control it                               -> Box    -> Few functions to control it            -> World Logic     -> Functions to say "a sphere exists here" etc.

not the greatest example but you get the idea... because you are going to end up with TONS of systems and components to these systems (not to be confused with component-based objects).

I'll keep both posts in mind, but I forgot to mention that I already have physics, rendering, audio, etc. What I meant by engine is something that connects these. I guess what I'm referring (wrongly, I know) to engine, is probably what I want to use as a controller.
Sorry, I really shouldn't be posting when I'm sick and tired.

Still, you don't want to tie it all together with a single class, as it can still potentially have thousands of needs. Anyway there are many ways of tying it all together. That's pretty much why people debate on Inheritance vs. Component Based Systems vs. whatever.

I'd google, and in fact better yet search this site's forums for topics about component based systems. It's all here, but be prepared for a lot of reading.

Cheers
-Scott

Thanks! That surely brought some clarity to me.