Original Post
Hey everyone I've been working on and off designing an engine (well, framework at the moment). My original idea for the engine was to have a modular setup, where one overseeing 'Engine' object would tick individual subsystems, like graphics, animation, input, etc. The main (only?) link was going to be the scenegraph that they all share. This modularity worked quite well until I tried to implement a state manager. Since the state manager needed to translate incoming input and control who receives the translated messages generated by this input, it needed to know about all the modules and all the modules needed to 'register' somehow with the state manager. Unfortunately, this approach seemed to break the modularity of the design I had laid out previously. As I tinkered around with the "Translating", "Controlling" and "Registering" parts of the state manager, I noticed that the system I was designing was remarkably similar to the concept of "Message Passing". After doing some research on Gamedev (here, here, and here) it seemed like message passing was the way to go for my state manager. Inheritance would be able to take care of a lot of the common routines, and smart pointers would be a good way to keep the "new Message()" calls in check without leaking (see Stoic's post in the first link). However, I can easily see myself getting carried away and making every single object in my entire engine a MessageClient - scene graph nodes, camera, etc - since there is so much flexibility with message passing systems, leading to thousands of inherited types of messages. Should I limit the message passing to the modules? Are there any warning signs that I'm getting carried away with the message-passing architecture? Are there any good papers, presentations or books anyone can recommend?