Hello,

first of all, congratulations to the authors for their great work about the parallel
game engine. I really scarfed down the articles and the Smoke Source Code ;-)

Now, I try to extend the architecture and your opinion is very important to me.
I want to link in some form of Game Logic which sits on top of the FrameWork
and is responsible for tasks like Create/Destroy new actor, Release/Load new
level, stream/restore Game State etc. Call it a GameManager. The Systems, upon
their creation, receive an Interface to GameManager. In their Update()-method,
systems can post Messages to a thread-safe Event-Queue of the GameManager,
implemented f.e. with famous the TBB. So the systems can work unaffected by other
systems and post requests for GameManager.

Of course, the Execute()-Method of the Framework has to be changed
slightly in the following way:

while ( m_bExecuteLoop )

{

//

// Process any pending window messages.

//

Singletons::PlatformManager.WindowSystem().ProcessMessages();

// NEW !!!!!!!!!!!!!!!!!!!
Singletons::GameManager.ProcessEvents()

// Call the scheduler to have the systems internally update themselves.

m_pScheduler->Execute();

// NOTE: This is still untested as noone is using it.

// if noone is using, I comment out...

// IssuePendingSystemPropertyChanges();

// I am not sure if this will be needed further

// m_pObjectCCM->DistributeQueuedChanges();

// m_pSceneCCM->DistributeQueuedChanges();

... continued as in original code

}

The Systems will be extended by a Method HandleEvent(Event const & event)
('am not currently sure about complete method-signature...) and they will
be able to subscribe via usage of observer pattern to several events, f.e.
PhysicsSystem can subscribe to "PositionChangeEvent".

Now, in GameManager.ProcessEvents() the EventQueue is processed. f.e.
InputSystem() posted RotateLeftEvent in the Queue, which will be consumed
by GameLogic-Handler, which calculates new position and sends
"PositionChangeEvent" to all subscribers - maybe after first checking if this
action is currently allowed. This is my foremost intention: get out calculation
of new position and reaction to input events out of the InputSystem. In
my opinion, this belongs in some form of "Game Application Layer", call it
the business logic of your game.

Now Subscribers receive this event, can update their
internal systems and are ready for the next turn of
m_pScheduler->Execute();

I am not sure if the calls to DistributeQueuedChanges() are needed
any longer in this architecure of the Engine.

As I said before, comments of you experts out there would be of
great value to me.

Many thanks in advance for your support.

With Kind Regards

Richard