Question Why entity per tile/block is bad idea?

Let's consider tile/block based sandbox game. Why it would be bad to use entity per tile/block approach? Everything would be so easy to implement that it seems dumb not to do it.

 

It is a bad idea when generating millions tiles, as creating that many entities will have impact in the performance that you would not have if using a simple HashMap (or something similar). But if it fits your use case and doesn't cause performance issues, then I don't see why not go for it.

 

It really depends on your data.

Does every tile in the game need it's own unique data? A one entity per tile approach is probably the way to go.

There's a good chance that your sandbox game doesn't really need per tile information for everything.

If your game has terrain that's composed of many different materials all with the same per tile properties, like sand, different kinds of rock, lava you can save a lot of memory just by having one entity per material type and just using a NativeArray of entities to map those material types to your grid.

It really depends on what you are trying to achieve.

 

But using Convert to Entity on everything in the scene already creates single entity for each tile that makes up the ground and also each tree, rock or a table and a vase. Otherwise we have GameObject for each of those, which i bet should be less performant.
So is there any difference? Or should one take another approach in this case?

 

I think it's only bad if you have a lot of computation between a block with other blocks positioned around / near it since there's definitely better data structures for those. But unless you have a lot of those kind of operations, I don't think using entity per block approach is a bad idea.

 

It depends what you want. If you want to use a tile/grid based approach to merely spawn your world, cool, easy. Doing this for a Gamejam right now and it works like a charm. Couldn't be simpler and I just construct my rooms based on maps I quickly write up in Excel.

If however each entity also needs to reference other neighbours (say to determine if the neighbour is empty so water can flow, or to see if grass should grow, whatever), it gets quickly annoying. VERY annoying.
I've tried to do that for a falling sand style of game, and it was MAGNITUDES easier and performant to have no entities at all and just evaluate one-dimensional Nativearrays.
You essentially need each entity to also reference the neighbours so they can properly "talk", and I'd just not recommend that approach. 2D alone already has eight neighbour references to store, and there's 26 in 3D. It's silly.

 

If you would go for each tile being a GameObject in normal Unity, so yes, the equivalent would be to each tile being an Entity in ECS Unity.

We don't know your entire use case, but my suggestion would be to try to keep the way that makes more sense for you and, only if it becomes an issue, then refactor your code when needed.

The entire point of DOTS is "performance by default", so I wouldn't care with performance until it becomes an issue. Keep your code simple to you.