Map (Item)

[BenCheung0422]

Original: MinicraftPlus/minicraft-plus-revived#568

Background

This feature would be considered to be added when the same requirements to book items are also met. Both map and book items would require the new save system.

Data Content Saving Standard

Both books and maps need some data like book contents and map contents that may consist of many data like lines and tiles. However, the way to save map data as in Minecraft may not be considered in TerraModulus, similar to the plan to the book items. Saving item data (that is only used by items) or instantiated data (used in instantiated items, tiles or entities) in separated save files may not be the best to these instances. I would like to suggest using completed instantiated data content over ID-linked data content

Problems Introduced from Using ID-linked Data Content

If all of these instances are destroyed, as the number of linkages cannot be reflected without calculations, the item content data is left. Also, each client interactable instances (items, tiles or entities) are required to link with a data content instance with the corresponding IDs.

In books, there would only be 1 instance for each book data in writable books as they should be unassociated with each item when they are "signed", "written" or "completed", but for written books, there could be clones and if we can modify book attribute, there might be slightly differences between each book, so there could be infinite number of books can be created. If we use numeric IDs, the number of possible instances is limited, and even if we use string IDs, we would still need to create data files or objects for each variation of content in the separated save file, but the instances can be destroyed easily and the detection to detect all items associated with the data content is expensive in computation, so this is unreliable in book items.

In maps items, there could be limited number of map instances in worlds with limited boundaries, but there could be unlimited number of locked maps for different variation of map data even on the same place. The problem is similar to the books that the same problem introduced to books might be appeared in maps. There can be more variations for the same original instance compared with books as books cannot be modified when completed while maps can be modified anytime when not unlocked. We would implement locks, so this problem might be more significant.

Alternative Approach

We could implement data content for each instance, to overcome the problem described above. There might be another problem mainly as the save size, but this would not be a critical problem currently. If the player has controlled the number of instances how they create depending on their memory power, this would not be actually a problem, and as for the current game, saves are still scaled as small. If we have the chunk system in the future and such instances are stored in a particular chunk, they are saved in the save file instead of being loaded into memory when it is unloaded, so the problem to memory would not be important.

We should store the data contents in each instance and implement them in this way once we have dynamic attributes implemented in the future, so this would actually be a more later feature, but this is still a critical feature for future development on more items, tiles and entities.

We would implement books like in Minecraft, but we would have some differences from them by these.

Implementation

When the player is holding a map item, the map continuously updates the region the player is visiting.
I would like to introduce a standard when creating items that have additional attributes that are not only simple strings, numbers and Enums.

As we would have unsynchronized maps from the alternative implementation, we would have a useful and dedicated workstation (cartography table). Each map would store some essential map simple attributes like "locked" and position. If we have a map with scaled 128x128 tiles, there would be at most 16384 data values associated with each tile.

The data content would use a numeric array with a palette of tile IDs, so both the memory use and the variability could be assured, and it is enough reliable if certain color mapping for tiles has changed, which should only rely on the client side (it is a texture-related element). Therefore, it could be done without a critical need to store the map data separately apart from level and entity data, i.e. like Minecraft saving map data separately on disk and using the map IDs.

As each map is not synchronized to each other, for maps that have different information on the same location, we can do copying and overwriting on 2 selected maps as the source and the target. The source map can copy (only overwriting unexplored areas),
partial overwrite (all explored areas from the source map) and completely overwrite (all areas from the source map) onto the target map, to achieve synchronization. We can implement synchronization (linkages) with a magic system/mechanics if we want to, like when the one of the maps updated, the changes would be reflected on another map (bidirectional) or all the changes on the source map would be simultaneously reflected on the target map without manual synchronization by using the workstation (monodirectional).

We can also clone (copy all information from the source map and there would not be synchronization at the same time), scale up and lock maps.

If we have map boards, we can still use the similar mechanics on tiles with dynamic attributes.

Map Types

As being equipable, there could be conventional and electric maps. While they can be held on hand, player can equip them into inventory. However, the conventional map can only be seen when taken from the inventory even equipped (but a status icon on HUD). Electric map can be seen on the HUD like in JourneyMap.

The size of a conventional map would be limited, but perhaps paged. And an electric map can be infinitely sized and zoomable. I am not sure about markers, perhaps both are markable. Having capacity thing (expanding by inserting disks) in electric map can be complicated so likely not made.

Conclusion

In conclusion, we can still take the saving standard as a direction or guideline also for items that may be added in the future.