Map view & Areas system

The map view

The map system is basically directly linking to the actual planet model components for probes, contents, biome and materials. Mainly the model itself is it's own instance to mange it's own state and tiles. Of course the depth of how much higher the resolution goes as you zoom in is limited, to not result in a 1:1 exact overdetailed map and provide a more abstracted representation of the actual world, just like real maps. Furthermore roads, lots/buildings, businesses with special icons etc will be shown depending on zoom level where you're at.


(Started implementing the shader visualizing data, here slopes are shown)


(Closer without slopes, howing isolines every 1.3km altitude. There might be some display options to show or hide slopes, or i make just one to not show and give too much information)

Managing Area

Since longer i've been figuring out how to store areas, while it's more simple for lots houses are build on (rotated rectangular areas) i wanted a sort of natural but especially efficient solution for areas that mark land ownership like countries and towns.

Dropped: Polygons
I think most map systems to work with actual polygons AFAIR from google maps api. However the cost for detailed borders, managing them so users can define them is just too complex and unpredictable.

Solution: Cell Indices with Voronoi
So the technique i had in mind since the beginning seems to be the most suiting and reasonable solution. On every type of layer (countries, towns etc) very low-res tiles store the property ID, as a texel is basically the minimum size this type of area covers.

(Mini map in a test environment: green are texels storing IDs, red are the mapped underlaying voronoi cells, bottom camera altitude)

The compound of the area ID texels form the actual area, voronoi giving it a organic and natural shape, additionally i'm going to use a minor noise displacement for the borders again. However a little more complex is merging the cells to render a outline of the compound of the cells, as well as mapping coordinates between the tiles in the atlas, but i've done this for world space mapping already so grass and paths/roads can align to the ground exactly matching the geometry resolution.

A big advantage of using bitmaps is they are easy to manage, they exactly cover a tile with a fixed amount of cells,  so they can be stored in individual chunks that can be streamed to the client. Also and most importantly dealing with validation, so a player marks land they want to buy, the server can check if any of these cells have been bought meanwhile already, create or update the affected tiles and mark them for update to other players being at the cells.

Difficulties
What i currently figure out is how to store the indices with 1 channel 8bit texelmaps, with the edge cse scenario of 255 locations (each every texel) in one tile. I think i will even go with 32bit, as the tiles being very low-res the majority likly is going to have only very few to a single ID, making compression doing the rest of the work, however uncompressed they take up quite a bit memory. So i'm still considering to go with 8 or 16bit and use a LUT to map to the big numbers, just to keep loaded tiles data low as it needs to mainly exist for CPU for business logic, but also on GPU when used for the map.

Who can actually create and own planetts, worlds/reams?

The main planet is very carefully designed with many main spots, that are relevant for you to advance. To clarify the terms, a realm is like a universe in a multiverse (the game), technically this means it's running on it's own server or server-node-network. In this universe depending on the tesseract component used, is a universe with planets to claim (later) or it's using the planar chunked world which is a planet size planar chunked infinite world, the latter was easier to work on and prevent complexity or possible error sources, but it also has various advantages i decided ot use it for now and later update to the spherical full universe realms or enable both. The solution of the attachment components of tesseract have both cases covered, however the spherical does and will always introduce some overhead with the coordinates mapping and slight distortion of surface-space at the corners, which is really not a visual problem but for the logic behind the scenes more complicated.

Even if the game can be see as sandbox, it's not full sandbox. The world has history, it has events and many things being added over time. Geographically there is a plan for the offical planet/s, future team members will manage so there is structure, and the community can help creating this virtual universe. How the rules are always depends hierarchically, from countries to lands, to towns or even the property or house you're in. But as regular user you're always able to have properties, it might change over time but there are some things that are privileges to supporters or going to be available through credits. I can't predict at this point how much it will cost to run all, and some things need to be more limited, even though the current default config planet has a diameter of over 22,000 km which is almost double as large as earth, there needs to be control, for a reasonable geography and to prevent many empty ghost towns. There also is a difference between a town and owning private land, any owned area also can be rented, sold or dropped.