Revamped World Spatial System #20
Description
Original: MinicraftPlus/minicraft-plus-revived#199, MinicraftPlus/minicraft-plus-revived#317, MinicraftPlus/minicraft-plus-revived#396
Background
The world spatial system includes the coordinate system, world tiling and world sizing/boundaries. Current world generation allows only a fixed size 128, 256 or 512 per dimension, so entire world is loaded at once without any chunks. For coordinates, the top left corner is (0, 0), all the values of x and y are non-negative integers. However, there are 2 coordinate systems: tile coordinates and entity coordinates. The implementation is similar to graphics canvas coordinates, but should not be.
Layered Tile Structure
Originally, each tile position is just a tile, so only one layer on a level. This causes a limitation that if there is a tile on top on another, the resolution and handling is poor or insufficient.
Instead, each tile is replaced by a column of layers which are the tiles. By rendering, they are still rendered from top to the bottom until fully blocked. Technically, the world becomes 3D, but in the point of view of player, is still in 2D. However, rendering may still be in favour of 3D to emphasize the layered structure. Anyway, the extension of this feature would be further of this issue like dimensions and levels, so briefly, this forms the height or elevation in the world.
New Coordinate System
First, (0, 0, 0) becomes the center of world coordinates. Since, the world would consist of columns instead of just a single layer of tiles, there would be 3 axes (screen direction/cardinal direction):
- X-axis: Left/West as negative; Right/East as positive
- Y-axis: Front/Down as negative; Back/Up as positive
- Z-axis: Up/North as negative; Down/South as positive
If fact, 2D directions (without the y-axis above) would be called as screen directions and cardinal directions, but 3D ones would be called as spatial screen directions and cardinal-vertical directions. Screen directions are based on user's canvas while cardinal directions are based on the world. However, plane directions (usually used on canvas) would be:
- X-axis: Left as negative; Right as positive
- Y-axis: Up as negative; Down as positive
So, the y-axis in plane directions corresponds to the z-axis in spatial screen directions on the canvas.
When an entity is located at a tile coordinate point (bare integers), it is then located as (x+.5, y, z+.5) or (x+.5, y+.5, z+.5) based on the context. So, if an entity is located at (0, 0, 0) (no decimal), it is typically translated as (0.5, 0, 0.5), and so on.
Chunks & Regions
Each chunk consists of 16x16 columns of tiles and each region (save) consists of 32x32 chunks. It is still 16 by 16 for chunk since a chunk will no longer consist of just 16 times 16 tiles, so the computational and memory complexity would not be too high.
Coordinates to index formulae (integer division):
- Coordinates (
$x_1$ ,$y_1$ ,$z_1$ ) to chunk ($x_2$ ,$y_2$ ): (floor(x/16), floor(z/16)) - Chunk (
$x_1$ ,$y_1$ ) to region ($x_2$ ,$y_2$ ): (floor(x/32)), floor(y/32))
Then, random tile update is ticked for each chunk instead of the whole world. Besides, both rendering distance and simulated distance (ticking) would be done in terms of chunks for performance configurations.
World generation would be mainly in terms of chunks instead of the entire world since it is not practical to generate the entire map at once for all chunk generation. It should be ensured that it is regeneratable even the chunk is regenerated. May refer to https://minecraft.wiki/w/Dimension_definition.
Regions are for saves only, so the details about this would be included in the world save issue instead.
Also, there may or may not be the soft limit of building heights. Given that tiles would be layered, entities would have heights too, and some mobs may jump. Ocean or deep water biomes could also be implemented in favour too.