I understand what you mean.
Basically, the design of the Murl Engine is rather straight-forward when it comes to (game) logic. You can have multiple Logic::IProcessor objects that can be enabled or disabled individually depending on certain conditions (via SetEnabled()), and you can use various helper classes such as Logic::StateMachine or Logic::IStepableObserver etc. to facilitate organizing your program flow.
If you want something like a signal/slot scheme you will have to implement this on your own, or integrate a 3rd party solution like the ones you mentioned earlier.
Regarding the Util::MessageThread (based on System::Thread, Util::MessageQueue and Util::MessageDispatch) solution: These are mainly designed for being used with asynchronous time-consuming (but not necessarily time-critical) tasks, which you do not expect to be completed within the current tick or frame. Any other task that's supposed to repeatedly update your UI or game objects should remain within the thread context of the OnProcessTick()/OnProcessFrame() calls in order to maintain smooth animation & updates.
Hope that helps!
dizzy
PS: There's no such thing as a summer break. GDC & Gamescom are near, so there's only work, work and more work
Basically, the design of the Murl Engine is rather straight-forward when it comes to (game) logic. You can have multiple Logic::IProcessor objects that can be enabled or disabled individually depending on certain conditions (via SetEnabled()), and you can use various helper classes such as Logic::StateMachine or Logic::IStepableObserver etc. to facilitate organizing your program flow.
If you want something like a signal/slot scheme you will have to implement this on your own, or integrate a 3rd party solution like the ones you mentioned earlier.
Regarding the Util::MessageThread (based on System::Thread, Util::MessageQueue and Util::MessageDispatch) solution: These are mainly designed for being used with asynchronous time-consuming (but not necessarily time-critical) tasks, which you do not expect to be completed within the current tick or frame. Any other task that's supposed to repeatedly update your UI or game objects should remain within the thread context of the OnProcessTick()/OnProcessFrame() calls in order to maintain smooth animation & updates.
Hope that helps!
dizzy
PS: There's no such thing as a summer break. GDC & Gamescom are near, so there's only work, work and more work