I am finally at the point where 0.0-demo9 can be released but I do want to make a few non-essential changes before declaring the release build. This is mostly just to make play-testing less tedious.

The core features for this release were around blocks which have multiple variants for different states (doors, for example), basic automation (hoppers), and what I am calling "logic wire" (which is essentially my answer to a Minecraft-esque redstone automation mechanic). This feature doesn't yet interact in complex ways with many blocks (there is just a switch, a door, and a lamp - plus the actual wire) but the fundamentals of the feature are there (flowing through wires and responding to logic level changes).

However, before release I wanted to make some changes to how difficulty is managed (it is now in a config file, instead of just a hard-coded parameter), change how hostile mob spawning works (it should account for light), change some details of AI idle motion (idle movements should be less common and not at full speed), and add some more information to the crafting UI. These aren't essential for the release but they make the play-testing easier to do, are relatively small (no new mechanics), and were going to be needed soon-ish, either way.

I still have some ideas for how to accelerate light and logic flooding so that they can happen within the tick which triggered them (as opposed to the next), but that will probably wait until the demo releases are done. It will be somewhat interesting, though, in that it will require creating a sort of "mid-tick fenced data hand-off" mechanism.

Looking forward, there is only one more planned demo release, before development shifts gears into pre-releases, where there should be no new mechanics but just a fleshing out, formalizing, balancing, and optimizing of existing systems. That next release is 0.0-demo10, which includes swimming and drowning mechanics. I am not sure if I will be able to continue with the current motion design for that release or if I will be forced to change to a softer "vector-based" movement design.

I know that this different movement design is pretty much essential, as the current system creates a lot of complexity for things like falling (which already uses a vector-based approach), knock-back (part of why there is no weapon knock-back), or the possibility of slippery surfaces, in the future. The original reason for the current design is that it made detecting failures in applying the mutation trivial, so things like cheating or de-sync would simply be "stopped". However, I think that the original difficulty I had in tests of a vector-based design were related to the reversible logic design the SpeculativeProjection originally used. In short, it was impossible to tell if a change had become invalid in local state (meaning the client and server will silently drift out of sync). That said, I think that the new entity-set design, where the server tells the client its current state and commit number (not using the mutations), may solve this problem since the SpeculativeProjection can now blindly apply its local changes, knowing that it will eventually receive a canonical state and its local changes will eventually be dropped by commit number.

More testing required and this may happen in the 0.0-demo10 timeframe. Not sure yet.

So, I hope to make the final 0.0-demo9 release in the next few days, depending on if I run into snags with these last little items or stumble into motivation issues.

We will see,
Jeff.