So right now I am trying to figure out what my options are for building a game that at least will have a similar sandbox block presentation style that games like Terraria, Starbound, It Lurks Below, etc. have.

The core parts that I am looking to achieve that related to the world are:

- Relatively large map size (for example, I would like to support a map size that is the largest that Starbound has which I believe is 18 million blocks being 6000 x 3000)
- Multiple layers of blocks (layer for the background, main world, vegetation, etc.)
- Certain layers will support colliders, other won't (like the background really would not need a collider)
- Dynamic lighting (similar to games mentioned above)
- Falling blocks (like how sand works in Starbound)
- 2D fluids (again similar to how it works in Starbound)
- Dynamically growing blocks (like how vines can grow in Starbound)

Currently I am prototyping with https://assetstore.unity.com/packages/templates/systems/terrain-engine-2d-115381 which is a promising solution and really the only asset I can find geared towards this exact style of game presentation however I want to have a fallback option in case for whatever reason I find that asset doesn't work in the end (at a minimum it will allow me to prototype a number of things quickly which is worth the price right there).

If I find the asset above is not viable for everything I am going to want to do for the complete game, I don't mind having to some of the heavy lifting for the world management however there are 2 high level things that I do want any solution to provide:

- manage the renderer of the blocks / tiles to the screen (I am fine managing the underlying "grid" of data the represents that world if needed)
- manage the generation of the colliders dynamically (so when blocks are added / removed, the colliders are automatically updated)

I think the rest of the things I would need to do I would be able to figure out is a reasonable time / am interested enough in them that researching them would not seem like too much of a chore (while I know developing a game as a solo developer I am going to have to do stuff that I don't necessarily find exciting / engaging but with this being a personal side project at the moment, I need to be able to limit that if I am going to finish this).

Two options I can think of are:

- Using a different tilemap solution: For example I have the Super Tilemap Editor asset that I used for a number of top down prototypes however most other tilemap assets seem to be geared towards top down (or at least that is what I see demo of for them), not sure if they would work for this kind of game.
- Use Unity built-in tilemap solution as a base: Never used this so not sure how feasible it would be in using this as a based for my worlds in this kind of game.

I would like to get people opinions of the above 2 options (maybe there is a different assets that I missed) or if people think I need a completely custom solution, I would like to hear the thoughts on why, thanks.

I can't help with assets (especially those from the asset store) but if I would start such a project, there are a couple of thoughts I have to this topic.

Use a quad tree. This is a standard structure used in any game that has a map and/or is open world or at least open world in the meaning of a limited sized map you could walk arround like in Starbound. This will help locating where the player is, where the blocks are he/she could manipulate.

Use a two dimensional byte or 16 bit integer array in your quad tree to represent the editable map. This way you could place an ID inside the cells that stands for a specific block asset in your game. I think 65536 -1 blocks should be way enougth for such a game and will just consume round about 35 MB of RAM. -1 because you should not forgett the <empty> block so air.

For the back- and potentially foreground I would define texture regions. This way you don't need to manage a second and third array because your background won't be shuttered the same way as your editable middle map is. On the surface you have sky, inside the earth you have an earth background, going deeper you have some lava caverns and whatever so a reagion is enougth here. Append this information together into your quad tree and you are done with the general management of your map.

I wouldn't append a collider to each block because this would be overkill for the physics engine. Instead you could just check against your map data and because this is made of a grid, either apply colliders/do collidion detection on demand only in a very small region or remove it completely and handle basics physics by yourself. Doing cell physics isn't that hard in this scenario.

Last but not least map generation. What you need to make your game performing well is a good editing vs. static texture management. This is also a reason I suggested the quad tree because you already have your map ordered in cells that could go down to different resolutions. Bake a static texture for each of those cells (where a cell should be at least a couple of blocks wide) and another static texture for each quad of higher ordered cells. This is your LOD (level of detail) you want to swap each time the player moves because of render performance.

Sending each block one by one to the graphics renderer will cause an infinity long render loop, baking regions together the player can't actually see or even edit and send those as batch to the render engine will pass a lot faster and you could show a lot larger maps.

When a player now walks arround, you need to enable a minimal set of blocks for modify by stop render their LOD and instead render each block by its own. This sounds against what I talked about above but as you just enable a minimal region for edit, you'll end up with lets say 5x5 blocks so a 25 block region or even less you pass to the render pipeline and anything else will still be a huge LOD.

For multiplayer you do the same on the other player's side and just send LOD updates to any other player in the party, that would be enougth to handle that