Something which I find to be an interestingly common problem in many areas of software is the issue of how you make something discrete appear as though it is something continuous.

For an example of what I mean, consider audio: It is a stream of vibrations moving through the air, hence it is a continuous phenomenon. However, when decoding compressed data or even copying data to the sound hardware, it is sent in buffered frames of data. In practice, a larger frame size allows for more efficient processing (minimally due to less process switching) and sometimes better compression (if that is what you are doing). However, larger frames also cause latency. For example, if your frame processing size is 1 second of audio, you won't be able to have real-time communication. Hence, a trade-off must be made somewhere.

I am noticing a similar thing when it comes to October Project logic processing. Originally, I figured I would process update events in one parallel pass 10 times/second (so, 100 ms between tick starts). However, I assumed that I would need to process player movements more frequently than that if things like combat and smooth movement were to be feasible. Additionally, this could cause some odd-looking behaviour due to how mutations can only impact a single block, and then request another mutation for the following tick if they need some kind of "consequence" to also be applied. This would mean that something like a Minecraft piston would take 1 second to push 10 blocks, moving as a sort of caterpillar. This may not be an issue, and avoids any sort of non-determinism and exploits associated with that, and there may be other ways to do it (just try them all at once and realize failures may drop/destroy blocks more often), but it is still an interesting question.

When it comes to player movement, however, I will really need to wait and see how much "predicted movement" is needed, whether they should run at double-speed (which should be possible in this design, even if other updates are slower), or rather unchecked updates should be eagerly sent out before the processing loop has committed them.

Things are coming together, albeit slowly, but I am interested in seeing how things look once their is a visual perspective on the experiments. Still a little ways off as I am still bringing things together for a complete logical model of the system.

Jeff.