I have been thinking about how to introduce "sky light" and "time of day" mechanics to OctoberProject.

Originally, I was thinking about making this part of the data model, first per "cuboid column", later directly per cuboid (and just merged at runtime). I was also thinking about how/when this would need to be communicated to the client. However, I think I was worried too much about being perfectly accurate, when I don't think that is actually a requirement. Ultimately, a perfect solution is impossible (since the world has infinite height and anything could generate later) so why not just worry about making it "feel right"?

After all, what do I need this for? Well, the server needs to know the sky light for purposes of monster spawning (and potentially crop growth or logic detection block, in the future) and the client needs to know it to draw the world in a meaningful way. I don't think perfect accuracy is required since refusing to spawn in a cave isn't game-breaking and drawing light under an overhang isn't likely to upset users when they can't even see it.

So, in light of this perspective, I am looking into prototyping a different approach, where all the sky light data will be ephemeral, initially discovered on load and incrementally updated as the world changes.

Ultimately, the TickRunner can keep this as another per-thread data fragment, trivially merged by the master thread at the end of the tick (just take the max of any conflict). It will need to do some work to build the height map when a new cuboid is loaded (unless below the current height map) but then incremental updates should be simple since it already knows which blocks have changed. Not exactly trivial to build and maintain but not super difficult and only the initial construction takes any non-trivial computational power.

On the client, much of this behaviour will probably just be inherited as a result of it using the same TickRunner logic. Beyond that, it will just require interpretation for the UI (again, not trivial but not too complicated).

Since the client sees a subset of the world, it may light more of it than the server sees but I don't think that matters.

There is a question of whether or not (and how much) this light should diffuse beyond the block where it lands but I will probably ignore that for the first cut and might even make any interesting blending client-only. Not sure on this one, yet.

So, it is a bit of a cheat but it makes things far simpler and avoids extra storage and computation. It reminds me of something I once told someone about high-order optimizations: If nobody can prove that you lied in your response to improve performance, did it actually cause any problems? Of course, that situation was simpler in that it was returning stale data because you could prove that nobody in the stale path could depend on the newer versions.

We will see how this goes,
Jeff.