search

sanderman01 / unity-gridgame

A chunked grid system for use in the Unity3D game engine. This system intends to facilitate games containing grids with large numbers of tiles or blocks.
GNU General Public License v3.0
6 stars 0 forks source link

How to do tile meta data? #1

Closed sanderman01 closed 7 years ago

sanderman01 commented 7 years ago

We have a few options:

  1. Store 16 bit unsigned integers (c# ushort) and use the 4 least significant bits for meta data and the remaining 12 bits for tile type.

  2. Store 32 bit unsigned integers (c# uint) and use the 8 least significant bits for meta and the remaining 24 bits for tile type.

Option 1 has as advantage that it takes the least amount of memory.

Option 2 has as an advantage that it will be much more future-proof. In the future, if modding takes off, we might need the ability to have more than 4096 types of tiles. Unfortunately it would also take double the amount of memory compared to option 1.

There is also another option:

  1. Store tile meta-data in a separate byte buffer.

I don't really like option 3 because this means that for rendering a single tile, you'll need to access at least two different buffers per chunk, which might impact performance of the game. (These buffers may not be located near each other in memory, which could affect cache efficiency)

Let me know your thoughts on this topic.

References: Explaination of how minecraft handles block metadata

Blocks with metadata: The metadata of a block is a number between 0 and 15 which is stored along with the block when the world is saved. With this metadata you can either give a block several different types (like the different colours of wool) or you can store for example the rotation of the block (like with stairs or pistons). You should give a block subtypes if you want to create some blocks which are basically the same but with some small differences (like the colour of the wool).

sanderman01 commented 7 years ago

I've done some calculations to determine how much memory we would be using both in the case of option 1 and in the case of option 2. My conclusion is that the amount of memory required to store a large number of chunks remains very low.

The main factor here is that this will be a 2D game. There is no need to deal with the third dimension like other games like Minecraft need to, which massively reduces the amount of memory required to store a chunk in memory. Even a huge number of chunks will not require all that much memory. The little bit of extra memory required to use 32 bit values is trivial enough that I feel it is worth spending in order to have a future-proof design.