User:User-12316399

From Minecraft Wiki
Jump to: navigation, search

This page serves as a list of major features I want to see in Java Edition in the future. See /Technical changes for a list of minor to moderate technical changes.

Fluid changes[edit]

Technical split[edit]

While assumed to be underway, there hasn't been anything back regarding this since 2018, when Dinnerbone tweeted[1] a screenshot regarding a technical split removing minecraft:water as a block from the game. One can only assume that progress is being made.

Further waterlogging[edit]

There still remain many blocks in Java Edition that cannot be waterlogged under any circumstances.[2] Support for waterlogging should be extended to all non-full blocks, alongside select full blocks such as leaves and monster spawners which can be assumed to not actually block water, and excluding honey blocks, fire and snow layers.

The ability to place more blocks underwater could allow for more building possibilities than ever before - for example, placing normal land-based vegetation underwater could allow for the creation of scenes reminiscent of Grüner See in Austria. Also, this would also patch out several exploits used for underwater breathing, notably the door trick.

For cases like torches, this behaviour could be reasonably considered odd, as fire kind of doesn't exist underwater. This could serve as a perfect opportunity to implement burned-out torches - instead of them burning out over time, they would act more like campfires in that being waterlogged (as well as right-clicked, in analogy of using a shovel to smother lit campfires) would put the torch out, allowing them to be placed underwater like any other block while not actually functioning as a torch.

The waterlogged block state would be completely removed, except for beds, where it would be used to determine whether Water Breathing/Conduit Power would be neccessary for sleeping.

Lavalogging[edit]

Example lavalogging.png

Why this wasn't implemented with the Nether Update is a mystery.

Lavalogging is the obvious lava analogue for waterlogging - lava would gain the ability to occupy the same space as a non-full block and overall behave just as one would suspect. Lava would probably be more destructive to many blocks than water, and certain cases such as waterlogged wooden fences would end up burning as if in air and next to lava, leaving a lava block behind as neccessary. Lava would probably also instantly destroy most vegetation such as flowers and grass, whereas water would be completely compatible with all of them. Lava would also instantly kill submerged corals, turning them into their dead versions.

While people perhaps don't build around lava to the same extent that they do water, this feature would fill in a major gap in gameplay mechanics and soften the look of lava-themed builds nonetheless, and potentially allow for brand new gameplay mechanics and possibilities on the side.

Flowing waterlogging[edit]

Example flowing waterlogging.png

Perhaps a more controversial feature, but it'd be a welcome addition either way.

This mechanic was originally shown off during MINECON Earth 2017, but has yet to see a proper debut in-game. The concept is relatively simple: if a block reasonably has enough gaps for water to pass through, then water will pass through it. This would, among other things, make working around redstone for safer than it otherwise would be. However, this comes with a possibility to break several farms which utilise water to break blocks such as crops. In the interests of maintaining consistency, crops would allow water to flow through them without breaking, like any other block, unless the farmland block beneath them is treated with a special item as mentioned below. Crops grown on such a block would then have a special block state set causing water to force them to pop off as before.

Flowing lavalogging[edit]

Example flowing lavalogging.png

An obvious lava analogue to flowing waterlogging. The mechanics would be as expected, with lava destroying all incompatible blocks it flows into and simply going through ones it is compatible with.

Bubble column-logging[edit]

Bubble columns would also allow for blocks to be placed inside of them and still allow bubbles to pass through where it would make sense for them to.[3]

Preventing unwanted waterlogging[edit]

It may become undesirable for water to flow through certain blocks, with them being broken by the water or blocking it being the behaviour expected.

To mitigate this, it should be possible to "treat" blocks with a hydrophobic coating in order to stop water from flowing through them. This item could be honeycombs, or a material crafted from honeycombs and phantom membranes, giving a large amount of them as a result. When applied to a block that could be waterlogged, a block state would be set on that block which would prevent water and lava from being able to pass through the block. Farmland treated with this item will also set the block state for any crops grown on top of it, making them be destroyed by flowing water (flowing lava would destroy them regardless).

In order to remove this coating, an axe can be used to scrape it off, or the block can be broken. Both will drop the coating as an item.

Credits[edit]

The demonstration screenshots above were taken with the Towelette mod. This mod allows for the waterlogging of several more blocks, as well as lavalogging, and, if enabled via config, flowing waterlogging and flowing lavalogging. The mod uses a system of block states to accomplish this, however, as opposed to an actual complete splitting of fluids from blocks, and an intense amount of RAM is required for starting up the game with flowing fluidlogging enabled.

World size changes[edit]

Horizontal expansion[edit]

Example extreme distance.png

The maximum Minecraft: Java Edition world size, from Beta 1.8 Pre-release through to release version 1.16.2, is 30 million blocks from the center to an edge, a 2 million decrease from the playable solid area from March 13th Infdev through Beta 1.7.3 of 32 million blocks from the center to an edge. With some very simple modification, though, it is possible to see that the game is completely capable of handling blocks, entities and basically all other game mechanics all the way out to the 32-bit signed integer limit of 2,147,483,647 blocks.

The 32 million limit was likely put in place in order to stop the player from encountering a vast array of precision-loss bugs which would manifest with increasing distance from the center of the world. However, as of 1.16.2, no such significant bugs exist in the game anymore (a full list of all historical effects can be seen here). The only bugs which would impact gameplay to a detrimental degree is light no longer functioning beyond 33,554,432 blocks (due to a lighting rewrite which happened in 1.14), and the player getting stuck in the sides of blocks beyond 1,073,741,824 blocks. (Neither of these bugs appeared in 1.12.2.) While the latter may be a simple fix, the former may end up being far from trivial and may require significant changes to allow for light to work out to the 2 billion limit (although two bits could be borrowed from the y-axis and dedicated to the x and z axes, allowing for light to work fine out to 67,108,864 blocks).

These aside, extending the world limit outwards to make new terrain accessible would be an extremely easy task, and would come with no more major issues. The world border could be extended out to a few thousand blocks before 2,147,483,648 blocks (or, if round numbers are preferred, exactly 2 billion), allowing for far more world area to be playable in than previously.

Attempting to rewrite the game to allow generation and functionality beyond the 32 bit integer limit would likely bring more problems than it would solve.

Vertical expansion[edit]

Example extreme depth.png

The current world height, as of 12w07a, is exactly 256 blocks (from 0 to 255), a doubling of the previous world height of 128 (from 0 to 127). Three quarters of this space is reserved for surface terrain generation, leaving only 64 blocks worth of height for underground and ocean generation - which for a game called Minecraft does not lend itself particularly well to underground features.

Increasing the height of the world while keeping the game in a playable state would be a considerably more difficult task than just expanding it on the x and z axes. The world format would need a complete rewrite for this world, as to allow for chunks to unload vertically as they currently do horizontally. The size of chunks is currently 16x256x16 blocks - this could be changed to 16x16x16, 32x32x32 or 64x64x64 for a perfectly cubic chunk, whichever size is desired. This would have some further implications for other game mechanics - notably sky lighting - although solutions for this are proposed below. For weather, a good way to deal with infinite height would to make it only exist where the clouds are and below. The y=-64 damage would be removed, as there would be no way to reasonably access the new bottom of the world in survival.

Adjusting world generation to account for infinite height[edit]

With a world height increase, it would be wise to make changes to world generation such that it generates terrain to take advantage of said space. This section only lists changes that could be made while still retaining an experience similar to current vanilla. Such changes to world height could pave for exciting new updates which add wealths of content based on terrain found at great depths and heights - one need only look at Terraria to see the potential that comes with greater world height.

For starters, generation of the Overworld and the Nether would be adjusted such that the sea level of each biome exists at y=0, rather than y=64. Old worlds converted to the new format would be shifted downwards accordingly. The generation of the End could also be similarly moved downwards to have the exit fountain at y=0.

For the Overworld, changes would be relatively minimal at the surface, although underground generation would obviously be able to continue downwards practically indefinitely. It would also be a wise decision to remove the "lava layer" from caves, such that they can be reasonably explored as deep down as desired. Alternatively this layer could vary from cave to cave (with most not having one at all), such that bubble column underwater ravines would still be a feature that could be encountered in oceans. Some underwater caves would still only generate with water down to the bottom of the world. Oceans themselves could also be made considerably deeper.

For the Nether, changes would be more significant. Caves would now also be able to extend upwards as far as possible, and lava oceans could be just as deep.

For the End, the outer island layout around the central island could be changed to be more spherical. A cheap, but effective, way to do this would be to make outer islands spawn in layers, separated by perhaps 512 blocks on the Y axis. The central layer would be the same as the current End in vanilla, with all other sheets being continuous islands even near x/z 0. This would also solve the problem of void damage in this dimension - eventually a player will have to die of fall damage after falling off an island. Falling off will therefore no longer be a death sentence for the player's resources, with a careful expedition to the lower layers of islands allowing for a full recovery. Clever players may also be able to save doomed mobs by exploiting unloaded chunks.

Credits[edit]

The horizontal world expansion is achievable through simple modding, some of which are linked below. The vertical world expansion was made possible by the Cubic Chunks mod, which can also be found linked below.

Lighting changes[edit]

Make smooth lighting... actually smooth?[edit]

Smooth lighting in the current version (Java Edition 1.16.3) is frankly an absolute joke, and finding sharp discontinuities and other ugly effects takes little to no effort. Here is a showcase of several examples of smooth lighting doing anything but what it says on the tin:

Here are examples of expected situations:

Changes to lighting with infinite world height[edit]

As mentioned before, an increase in world height (especially making it infinite) would have major implications for lighting, and these would need to be taken into serious consideration were such a change to be implemented.

A cheap, but nasty, solution would be to assume that all blocks receive full sky light until it can be confirmed that an opaque block exists above it at some point. This would obviously work, but would cause problems in structures such as massive naturally-generated caves whose heights are greater than the chunk loading distance. Also, if structures or terrain existed in the sky, for example if a layer of floating islands were added to the Overworld a few thousand blocks above the regular terrain, generating these would cause massive and ugly shadows on the surface of the world, which would also provide ample opportunity for hostile mob spawning. A solution for this latter problem could be to make sky lighting spread laterally somewhat as it travels downwards; an implementation of this could make one-block columns of transparent blocks with sky light values between 1 and 14 inclusive increase by one every vertical chunk border crossed, and columns with light level zero change to one if adjacent to at least one column with a light level greater than one.

Coloured lighting[edit]

Example colored light.png

This would be an amazing change, and allow for not only diverse presentations for builds but exciting new mechanics for generated structures to take advantage of.

The implementation of such light could vary, although most methods would likely come with a major performance and memory impact.

One way would be to use sixteen bits for lighting, by having separate channels for invisible (used for ice and snow, plant growth and mob spawning and burning), red, green and blue lighting, which themselves use four bits each as to range from 0 to 15. A more expensive approach, which would stop certain mixed light colors from looking weird as they fade, could be to have eight different colors and 32-bit lighting: a channel each for infrared (used for handling the formation and melting of ice and snow, and plant growth), red, green, blue, cyan, magenta, yellow and ultraviolet (for handling mob spawning and burning), which would all still have 4 bits each.

Different blocks would outright forbid the passage of some colors of light, while allowing for others to pass through. For example, if we were to use the 16-bit implementation, blue stained glass allows blue light through, blocking all other channels. Cyan stained glass would allow both blue and green light through, blocking only red and "invisible" light. These could be generalised to the 32-bit case with some experimentation. Light gray and gray stained glass would significantly decrease all light passing through, but not completely block it. Black stained glass would block all light from passing, allowing for the observation of a dark room from a well-lit one without any fear of interfering with it. Assuming the 32-bit implementation, normal glass as well as white stained glass, in order to reflect reality somewhat, could allow all visible and ultraviolet light to pass, but block the passage of infrared. As such, an area where the player intends to build with snow and ice, or farm it, could be lit up for visibility and spawn-proofing without fear of hampering their generation.

Many vanilla blocks could themselves be changed to emit colored light. For example, the light fire, lava, torches, lanterns and jack o' lanterns emit could be slightly reddish, nether portals could emit purple light, soul fire, soul torches and soul lanterns could emit blue light, and redstone ore and redstone torches emit deeper red light.

It seems an official implementation of colored lighting by Ryan Holtz was extremely close to fruition, but ultimately never made it.[4][5]

Directional light emission[edit]

In snapshot 12w39a furnaces were tweaked as to only emit light from their front face, rather than nonsensically emitting it from all faces. This change was reverted in the following week, and has not returned.

Fixing this would involve making furnaces, blast furnaces, smokers and jack o'lanterns emit light exclusively from the direction they're facing, rather than from everywhere on the block. With the support added for directional block emission in snapshot 18w46a this shouldn't be particularly difficult.

Directional opacity should also be extended to carpets, shulker boxes, composters, cauldrons and hoppers.

Dynamic lighting[edit]

This would involve light not being handled on a per-block basis, and allow entities to emit real light. This could allow for held torches and dropped torch items, or indeed any held or dropped light emitting block, to emit light. Further applications could for example be to add a "Minecart with Glowstone" which can be added to minecart trains to illuminate dark tunnels on the fly. Implementing real dynamic lighting would itself require a ridiculous overhaul of lighting.

Credits[edit]

The fixes for smooth lighting were taken with the Sodium mod, which among other things makes smooth lighting considerably better than it currently is in vanilla.

The colored lighting example was taken with the Colored Light mod for 1.7.10.

References[edit]