Add Event-Handling to Smoke Engine

Add Event-Handling to Smoke Engine


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.



// NEW !!!!!!!!!!!!!!!!!!!

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


// 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

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


5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Richard, I'm glad you're having fun with this code!Very cool idea! I think you might be over-solving this, though.A bit of background: All systems (fire, trees, physics, graphics, etc.) run independently of each other during a frame, and queue up changes for all other systems to consume. At the end of the frame, the queued changes are shared with all other systems.It seems to me like you can just build a new system for GameLogic, rather than building a new kind of thing and changing the framework. This GameLogic system would get any updates that systems wish to give to it (you have to hook that up by hand, see how the other systems subscribe to each others' outputs). So on frame n, each system would queue changes for GameLogic, on frame n+1, GameLogic would process the results and queue changes for other systems, then on frame n+2 all the systems would consume these changes.If you want to get really tricky, there are some short-circuits possible to share data directly between two systems without waiting for the change manager to share them at the end of the frame, but they're hacks and I don't recommend you start with that.And yes, you definitely want to keep the distribute changes steps in the main Execute() loop; otherwise, no data flows between systems. CCM is the Change Control Manager, and it keeps data flowing between all systems.I hope this helps!Paul

Thank you for the bit of background, Paul.
I was quite surprised myself figuring out the need of a event handling and game logic system.
The fact that only frame n+2 consumes the changes caused in frame n also looks like a performance trouble.
I would personally think about the old approach, where game loop has the "Update" call and the "Render" call, and thread them within a frame separately, so that the same frame n pulls the operating system messages, then parses them as input, then runs the "Update" related systems (Physics), then runs the "Render" related systems (Graphics, Audio), just to guarrantee the frame n data affecting the same frame n rendering.
What would you say about that now, while most of the machines CPUs are still equipped with just about 4 cores, or maybe 8 cores.

Nice model, it is a little bit like "observer" design pattern.

Yes, it was built following the observer pattern. If you want to see more about the use of the observer pattern in this code, check out the design paper at


Leave a Comment

Please sign in to add a comment. Not a member? Join today