This next release (OctoberPeaks 1.9 - "The Formalization Update") isn't very concretely specified so it is slowly turning into a grab bag of all the loose ends from previous releases, on top of fleshing out some mechanics I did plan to complete in this release.

This has meant fixing up some details in arrow collision, partially-colliding updates between server and client, the feel of how to adjust motion in the air, improvements to general movement interface, and optimizing entity updates from the server. There are several other small items planned, too.

In terms of big changes to mechanics, the enchanting mechanic is now implemented, but more of the related content needs to be added. The approach I used is similar to an "infusion" mechanic seen in some Minecraft mods: You place materials on pedestals around the table, then place a tool on the table, and after several seconds of charging, the ingredients disappear and the enchanted tool pops on top of the table. This is also used to create some special types of blocks (like the blocks to build the portal frame). I am generally happy with it but I need to figure out the UI to make seeing the recipes possible (since you interact in the world, not in a crafting interface).

The next big mechanic is to allow the user to make custom portals, but that should be relatively simple since the existing portals already work the way custom ones would, just without exposing this to the user (that is why "portal orb" is an item in the creative inventory - it is a non-stackable with a location property which the portal reads when it is placed inside the keystone).

However, I had originally thought that I would change the way that the data file are specified, so that adding new blocks would be added in one place, not in a few small files. After thinking more about this, I don't want to change this as the data files are already perfectly aligned with how the data is represented in the code and this problem of ease-of-use could be resolved in tooling, if it is ever required (which I would want, anyway, for verification). That said, I do still want to come up with some way of defining a kind of "grouping" of common blocks, to make some content updates less error-prone, and I am considering defining a sort of "layering" so that things like user-defined content (content mods, essentially) could be added to the world definition in a supported way. Of course, an open question is whether these content layers should be able to be added/removed in an existing world. I don't think that will be supported, to begin with, since it requires each cuboid/entity data file describe its content in more dynamic ways for a feature which may never matter. If it matters, that kind of indirection can be added in a later release (where the testing considerations would be more obviously known).

Other than that, I do want to remove any other hard-coded item ID assumptions out of the implementation (they can stay in tests, though) and into data files, defining a "special bindings" data file if needed (since things like "air" are universally important blocks).

So far, so good, and the changes to the movement already feel very nice.

No estimate yet on when this will be done as there are a lot of small items still to come,
Jeff.