>> Doing so makes it easy to keep everything synchronised; it's the abstraction Céu uses to great effect for its synchronous concurrency model[0]. The only limi

>> Doing so makes it easy to keep everything synchronised; it's the abstraction Céu uses to great effect for its synchronous concurrency model[0]. The only limitation is that you need to keep your updates small and fast enough to finish before the next update is triggered, but that's a good goal to strive for anyway. I think the usual way games typically implement more or less what you are describing but without the hard-realtime update constrains, is what is commonly referred to as a 'fixed timestep'. It's what I used to implement the main loop of the game I'm currently working on, which has an 'action replay' function that has to be capable of producing the exact same gameplay sequence based on recorded input events, which means 100% accurate, discrete and predictable updates to the game state. It's pretty cool to record some gameplay on actual hardware, then replay it in the simulator, which has completely different performance characteristics, and get a pixel-perfect reproduction of the gameplay clip :-). Extremely useful for gameplay debugging and prototyping as well. There's a nice article here [1] that explains the concept much better than I could, so I'll just refer to that instead ;-) [1] http://gafferongames.com/game-physics/fix-your-timestep/ http://gafferongames.com/game-physics/fix-your-timestep/