It sounds like you are overengineeing it.
Modern computers are fast; Program it naively and if you see it's too slow (which it probably wouldn't be) optimize the bottlenecks.
I am pretty sure you wouldn't need to make this multithereaded.
Modern computers are fast; Program it naively and if you see it's too slow (which it probably wouldn't be) optimize the bottlenecks.
I am pretty sure you wouldn't need to make this multithereaded.
What's for sure overenginered is using function of time instead of simple numbers for positions. But that is just to make it different.
The few languages that aren't overengineered are the ones that either have a very specific domain (JavaSript), slow to change standards (C), or are very new (Clojure).
OP's idea also doesn't sound very over engineered to me. The whole draw loop thing is simply a convention and not an obvious one. I've taught many a student who stumbled on the idea of the render loop because there's simply nothing natural or obvious about it.
In the real world everything happens at once, there is no update-render-loop. Snapshoting the state of a multithreaded physics engine at discrete intervals in order to render the game state is much closer to a model of how we perceive a fully concurrent reality.