Multi-threaded Design?

My view is that the Intel Smoke framework is somewhat over-generic (universal scene, which is extended with system scenes, change management) and some of its concepts are dubious, such as conflict resolution if several systems change the same property such as object transform (IMO that should not happen in the first place.) It doesn't really address the ordering of tasks within a frame, which doesn't hurt in the demo, but in an actual game it could lead to nasty non-determinism if for example AI is sometimes running one frame ahead, sometimes one frame behind in respect to physics. I'd consider it potentially dangerous if used directly as a basis for learning or for own engine.

I'd recommend, at least in the beginning, to be very explicit (even hardcoded) of what systems or tasks are actually running simultaneously, and what are the changes they're propagating to each other. For example physics updating object transforms, which the renderer picks up. Then profile constantly to discover the bottlenecks and to able to decide if threading will actually benefit them.

Some more resources (in case you're not familiar with them yet)

http://www.gamasutra.com/view/feature/1830/multithreaded_game_engine_.php

http://www.gamasutra.com/view/feature/2463/threading_3d_game_engine_basics.php

http://bitsquid.blogspot.fi/2010/03/task-management-practical-example.html