Everytime I talk to someone about game programming they always say "just do it". So "just doing it I am". However, I was wondering if I could get a slight bit of feedback on my current idea. I'm going to keep pursuing it until I hit a brick wall for educational purposes but I was curious how common this kind of structure in a game is.

I was recently reading a book that brought up the concept of a 'system'. Systems have inputs, outputs, feedback mechanisms, etc. It occured to me that all game engines are just a series of systems (and the award for over-simplification of the year goes to...!).

My current structure simply involves all game parts (input manager, rendering engine, networking) inheriting from an interface ISystem. This makes all systems completely isolated from each other.

Systems can also contain subsystems. If the game itself is a system then it can contain a input manager system, a rendering system, and so on.

The way I've defined the interface means that systems can communicate via a message passing interface. Messages derived from an IMessage interface and carry their type with them so that certain systems can receive specific information. I've previously looked at DOOM-3's source in brief and after reading 'All Signs Point to "No-No"' here (http://www.gamasutra.com/view/feature/132500/dirty_coding_tricks.php?page=2) I figured this was a better idea than enforcing simple packing.

Systems keep an output-restricted deque to allow important messages to skip to the front of the message handling process.

This is my first real project and I was really wondering what someone with actual experience thought of this idea. Have I been paying attention to everything I've been reading in books/online or have I missed the point entire and should probably be shot.

Thank-you for any comments.

The interface route is called the Dependency Inversion Principle. It is part of the SOLID development principles.

It does take a little bit more work up front to set up, but if your system grows to any appreciable size the effort will be worthwhile.

When you write a system you program to an interface. You send everything to the black-box interface. The systems do not know and do not care what is behind the interface.

Then when you create objects, you can have them derive from a common base class and let them vary their behavior as needed.

It prevents many code smells, such as a system that is hard-coded to child classes and therefore is brittle and difficult to extend.

I'm a little confuse about what is being suggested. I've done a small amount of Googling (I'm going to do a lot more research on SOLID because it looks like a powerful method of segregation).

My original idea was simply creating system types and have them as data members. From what I've read is it better to simply have a series of pure virtual functions as an interface (say IInputManger, or IRenderer) and contain only pointers to such types? I'm assuming the actual systems derived from these interfaces (RenderingEngine inherits from IRenderer) but have no accessible functions (other than those defined in the interface) because they're only ever accessed through pointers these interfaces?

This makes all interfaces simply adaptors (http://en.wikipedia.org/wiki/Adapter_pattern)? Isn't this the same kind of thing COM attempts to do?

If you plan to roll with a component based system, be sure to read up the chapter of Game Programming Gems on the subject. It presents a really simple way to handle components and some great guidelines to use when developing your own component system.

However in terms of message type systems. I found the Observer-Subject implementation in Intel's Smoke demo to be really interesting. In short subjects can publish changes, observers recieve notification of the changes. A change manager sits between them queueing up changes until a function call is made to begin distributing changes. The change manager also manages the associations between observer and subject based on bitmask of interest they have in common. It's an effective system that forces you to keep your code bundled up nicely and easily seperable.

Yeah I would be wary of shoehorning 3 patterns into one thing. Especially the observer pattern seems to me like creating an entangled mess with looping back and forth messaging with at least the squared complexity of a traditional procedural spaghetti code, if any single thing in your program observes something and is observed itself by anything.

I would just try to follow the SOLID principles, never create any dependency cycles and just maybe use a single pattern if you are 100% sure it is truely helpful for the one problem at hand.