Idea we played with was one step further--take the entities and have their components/state data backed as atoms, and create separate buffers. During update, read from buffer A and write state to buffer B, then swap. This should allow for fairly trivial use of a worker pool to handle concurrent updates.
What happens with concurrency was the area I was thinking about too. Particularly what happens if you want a render thread accessing various nodes while the rest of the engine could be in another thread updating the same data.
Yep. We ended up thinking in terms of entities passing messages to each other and being described in terms of functions mapping their current state to their next state.
Comments
Idea we played with was one step further--take the entities and have their components/state data backed as atoms, and create separate buffers. During update, read from buffer A and write state to buffer B, then swap. This should allow for fairly trivial use of a worker pool to handle concurrent updates.
What happens with concurrency was the area I was thinking about too. Particularly what happens if you want a render thread accessing various nodes while the rest of the engine could be in another thread updating the same data.
That's how I wrote the inner core for one of the Tiger Woods PGA games for EA.
Ha! That's awesome, you're awesome. :)
Really cool idea! This scheme also facilitates a immutable-centric engine.
Yep. We ended up thinking in terms of entities passing messages to each other and being described in terms of functions mapping their current state to their next state.
And then we'd badly reinvented Erlang, in C++. :(
greenspun's tenth rule?