3D Action Game architecture

[3DModelerMan]

I'm working on a 3D adventure game, I have some code already written, but I'm planning on refactoring it in a little while. How should I have everything structured? Right now I have it like this:

A main game manager class contains all subsystems:
Irrlicht, physics manager, input receiver, actor/entity system, event manager,
and sound system.
The physics manager encapsulates creation of rigid bodies, soft bodies, and collision shapes.
The sound systems encapsulates sounds, and whatever other classes I make for it.
The input receiver sends the game event for the key event ("key up" is sent as "player move forward"). It uses the event manager to do this, which is just a simple event system.
And finally the actor manager, contains game actors/entities and updates them each frame. The actors/entities themselves encapsulate their own scene nodes, and sometimes have pointers to a rigid body. They also have a character controller, which is a seperate object that can be attached or detached to, for example: switch from player control to AI.

Does anyone have any suggestions for a better architecture? Or does this sound good enough?

[CuteAlien]

Sounds not too bad. I usually add a few more major classes. One important distinction I make is usually separating the application from the game logic. So I have an application class and a game class.
And very helpful - one class per gui-screens. Where a gui-screen is usually a dialog, but can also be a collection of hud-elements.

[3DModelerMan]

I'll do both those, I'll seperate the GameManager into Application, and GameLogic. And I like the idea of a different class for each screen.

[jerrelDulay]

Sounds good. How solid do you think it is? I organize my structure a bit differently, but part of that is because I'm crap with C++ at the moment, and I can't structure things exactly how I want! If you were thinking of building a more reusable game engine that you can use to adapt other games, wouldn't it make more sense to have a myGameEngine class that encapsulates and pretty much performs anything that isn't Irrlicht specific/crucial?

I'd like to hear how your actors encapsulating their own management is working out. I've always given actors their own "automatonity" in the past, but with the latest project I'm working on, I've actually given much more control to "myGameEngine," which literally acts as a director... It tells the actors, props, and events what to do (or rather, when to do what they're supposed to). It's working like a charm, but mostly I did it to avoid awful encapsulation issues.

Best of luck with your projects!

[3DModelerMan]

The actors themselves have an update function that any game logic can run in. But for my character actors, I needed something a bit more flexible, because I didn't want a giant switch statement in my character actors when they switch from player controlled to AI controlled. So I made the're logic seperate.