In this post I will review the technology used to develop Islariön and my thoughts about it .

 1 - Tile intercommunication (WFC-ish) 

Every time the user places a block in the scene a lot of processes are executed to check how this block has to be created (which mesh to use, its texture, if it has decoration, etc). 

Some of these parameters are defined by the user, but some are arranged by the “tile intercommunication algorithm” that checks the neighbors information and sets the parameters of the block according to this data. 
This algorithm is bidirectional, this way not only the tile on focus will be updated but its neighbors too.

For instance, if a block is placed at the side of another block, the mesh of both geometries will change to avoid having colliding faces.
This feature is also exploited to generate smooth transitions between blocks with different biomes.

2 - "Virtual Matrix" vs "Scene Grid"

Any input the player does when generating a new block in the scene is used for various purposes. 

The input coordinates are used to generate the block in the desired position in the “Scene Grid” (this is what the player sees), but at the same time these coordinates are used as an index for the “Virtual Matrix” that stores all the block information. 

This allows us to make the gameObject of the block independent of its data, this way we avoid exposing the data of all blocks in the scene.
With this feature we gain access to the information of any “tile” (block holder) without having to reference any scene gameObject.

3 - Chunk System

Performance is one of the big problems that had to be solved in order to be able to make the game accessible to any modern android device. 
One of the several approaches used to overcome this problem was to use a system that combines the geometry of the blocks to groups called “chunks”. 
This way the “draw calls” to the GPU are highly decreased. 
These chunks hold up to 10x1x10 blocks and are dynamically generated once the user stops the input or the input goes to another chunk area.

The previously explained “Virtual Matrix” allows us to “destroy” each individual gameObject to generate only one big combined mesh without losing their data. This is because the data is not dependent on the (now not existing) object.

4 - Tile ID and Pooling System

Another approach to overcome the performance problem (this time more focused on CPU) was to reduce the amount of processes needed to be executed to generate a block.

As explained in “Tile Intercommunication '' earlier post, each time a block is generated, their contiguous positions are checked, and the original block parameters are set according to their data. 
This method requires that every time a block is generated to hold and access all the contiguous tile information during the generation process. (Check the contiguous tiles and modify the parameters to be in line with the contiguous tile data specifications).

To avoid this, the first time a block is placed an ID is generated representing the first process of the “contiguous tile checking”. This ID will be used as an index for the result of the parameters used to modify the block, this way if an ID is repeated there is no need to access the parameters, there is a bridge between the ID and the result, avoiding the whole parameters process.