Map (item) implementation

[BenCheung0422]

Is your feature request related to a problem? Please describe.
As mentioned in #345 and #566, there could be maps. 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 rewriting the save system as in #315.

Describe the solution you'd like
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.

Data content saving standard for items like books and maps

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 Minicraft+, 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 implementation

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 (described in #542), 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 in maps

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 128*128 tiles, there would be at most 16384 data values associated with each tile. The data type and maximum sizes would be different for each implementation:

• Color IDs (as in Minecraft with a color table) - In a map, there would be an array containing nullable Enums describing each color ID; and they will be converted into a byte array or short array depending the number of Enums in save. Null for unexplored area and -1 would be used as a numeric value. A Enum array (array of Enum references, usually 4 bytes as other object references for each reference, a serialized byte array and a serialized short array fulfilled with 16384 non-null values would have approximately 65536 bytes, 32767 bytes and 16384 bytes respectively (assume that the other array fields are negligible in estimations).
• Numeric tile IDs - The data type of the array depends on the data type of tile IDs, which may be outdated in the future as described in ID and resources rework #313. For the current IDs with short values, there would always be a short array, sizes as described above.
• String tile IDs - This is not possible with the current system but with ID and resources rework #313. However, the size of a string ID may vary for different ID, so if we take the maximum length of IDs as 20 characters and calculate the string array with each value having the maximum length, the data sizes would be approximately 1,245,184 bytes (~1.2MB) in memory (algorithm) and 327,680 (~0.3MB) in save (UTF-8). This would be the most unrealizable.
• Color values - As in 25-bit RGB values that commonly used in codes, integer values would be used. The serialized data size would be approximately 65536 bytes, but the values would not be essentially associated with a tile.

*A serialized data means that the data is stored as bytes in save files (as in memory) instead of in text-based format as in JSON files.

Considering the reliability and memory sizes, using color IDs would be the most reliable.

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.

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

[BenCheung0422]

Signs would also be implemented following this standard in the future, while it will be added with a temporary implementation as in #548.