The current tilemap system is terrible for runtime scripting

I just spent the last week working on a procedurally generated style game using Unity's 2D tilemap system, and I do admit I was suprised to find it didn't have the same functionality has GameObjects

Maybe it's just me being a noob with the tilemap system, but I find it odd that you don't have access to tiles the same way you do GameObjects, I know that makes sense if you're just going to lay out the tiles yourself and that's it, but using them for procedural generation is a lot more difficult and buggy than I would have expected, first off, you can't access all the tiles in a tilemap, and loop through them to do stuff or whatever else you would want, I mean, you technically can if you write your script correctly, but it's way more janky and time-consuming to do. And I also wasn't able to place a tilemap collider 2D object at runtime either, I ended up having to loop through a function that places tiles individually and place a new GameObject with a box collider 2D attached using the tiles position, which btw, the tiles position was the only useful thing I could get out of the tiles at runtime. I'm not even sure if I would use the tilemap system again if I were to make a procedural dungeon game again, it's just so difficult to use tiles in scripting for more than placing them

This is a niche issue though, so I get why the functionality hasn't been added, I mainly wanted to post this to see how you guys feel about it, and also, was I just bad with tilemap scripting? or is it actually that difficult to work with tiles.

 

Haven't used the tilemap, but...

It is highly likely that tiles are completely unlike game objects, are baked into a static mesh and aren't stored as a grid. That explains more difficult scripting interface.

 

If they were going to be the same as GameObjects then people could just use GameObjects instead.

The root of the issue is that "objects" are expensive. Having a grid of many individual objects has a huge performance and resource cost as compared to having a single object which represents their aggregate form. (To answer "why?" requires explaining a bunch about how CPUs and memory work together.) So to represent things like a grid of tiles efficiently you have a single object which contains a set of data, and updates its representation (renderer + collider) when that data is edited.

I haven't used it myself, but I've heard from others that there's basically no way to access some of that internal data at runtime. That was quite some time ago, but it could be that you've run into stuff that still isn't exposed.

As to the overall difficulty, if you've only coded with pure object-oriented stuff then I'd expect you to run into some bumps the first time you work with something that's "data-oriented". It's a different way to think about things and it'll take a little getting used to.