IntGrid Value -> Different Unity Layers

[stickynoteme]

One of the best things about LDtk is the auto-generation rules you can make by having complex Intgrids value layers to automate a lot of level design.

I'm running into the issue that I need different IntGrid value layers to be on different Unity layers, which seems impossible since all Intgrid values all get lumped under a single imported IntGrid gameobject.

Wouldn't it make sense for a lot of project layouts if the IntGrid value layers where children of IntGrid gameobject? That way they could have their own unique tags and layers assigned to them in Unity.

I realize you can place prefabs on them that then have grid sized objects with their own tags and layers, but this has the issue that they can't be used with a composite collider.

Specifically I'm having the issue that I have an Intgrid set up with two value layers:

IntGrid [Base] 1: Ground 2: Water

And I need ground to be on the Platform layer in unity, whereas I need water to be on the Water layer, I also need them both to be composite colliders to avoid seams that cause issues with the physics system.

I can* make them in their own IntGrids and have them work, but then the water and ground can't be "smart" eg: I can't create rules where if ground is bordering water it uses x edge...etc.

[Cammin]

This does sound like a good idea and makes a lot of sense to have.

Yeah, currently the system is just condensing all of the intgrid values to a single tilemap (per intgrid layer)

However with this new idea, maybe this might present some different composite collider problems, like if there are two different intgrid values that serve the same purpose (ex. 1:Stone, 2:Dirt), but end up not getting merged into the same composite collider?

Splitting intgrid values into per-tilemap components does seem like a good path to go on, but might still present some other composite collider merging problems.

Thinking about how to make a simple solution, maybe some sort of user-selective lumping system?

[stickynoteme]

That's true dirt and stone would be good to have merged, and thinking about it, it would cause issues if it was the only option.

Maybe a check box by each by each intgrid value layer in the importer that would place the checked intgrid value on it's own layer?

That way everything not checked would be merged into the mater, and everything checked would get it's own gameobject.

It wouldn't be super universal since you'd be limited to a single merged set, but it would be a fair bit more flexible and still keep the interface to a minimum.

For a more robust system you could have a combo box or drop down where people could pick what gameobject they wanted each IntGrid value to be on. I'd think 0-9 possible gameobject layers would be enough for most projects so a drop down with 0-9 could provide a lot of power in a small space.

Then you could for example: Stone - 0 Dirt - 0 Water - 1

Which thinking about backwards compatibility it would probably be better to make the split off GameObjects be siblings rather than children:

[edit contrary to this screen shot 0 should actually just be the current IntGrid GameObject]

[Cammin]

Both options sound really good, thanks for the suggestions 🙂

I was thinking about an idea similar to the robust system idea, where there could be a grouping system based on matching numbers. The challenge at that point would be to make the inspector relatively simple to set up without becoming too intimidating/confusing to the user.

A deeper idea I was thinking of for a grouping idea would be to (instead of an int) make a Scriptable Object to represent a shared group. And in this object, we could define some extra settings in a group, like layermask, tag, and physicsMaterial2D so that they don't need to be manual overrides. (excuse the crude drawing to understand the idea, haha) And if a field was left empty, it'd end up in the standard/default group, like the current IntGrid Object.

Another idea would be to add these new kinds of grouping options into the LDtkIntGridTile asset themselves, instead of introducing a new scriptable object.

I'll try these ideas out, and see where it goes 👍

[Cammin]

Introduce a better grouping system for intgrid tiles

[Cammin]

Progress on this, this is how it's looking so far. Adding two new fields into the tiles to set a tag and layer:
So in this case, if tiles have matching tags AND layers, they will be shared into the same tilemap.

However, I thought about not adding the tag field, to make the concept of composite collider merging a little more simple to comprehend so that we only need to worry about layer masks. So I'm not going to add tag support for now.

But if it makes enough sense to add the tag field later on or in some other way, then the doors are open for that. 👍

[stickynoteme]

Looking good & exciting!

I seem to recall somewhere when I was first starting out with Unity someone/someplace saying that layers are actually very expensive in physics heavy 2D games, and that for the best mobile support you should try to use only a small number of layers and focus more on tags. So if that's true I could see other's wanting to group by tags rather than layers.

For myself though since I'm using Corgi-Engine and the dev went all in with using nearly the maximum number of layers Unity supports right out of the box, I'm hoping that's old mobile folk lore that doesn't matter much anymore... XD

Edit:

After thinking about what I said for an extra few minutes I realized that rather an being immune to needing tags I could wind up be forced into using them easier because Corgi-Engine almost uses all the available layers in unity. As in the future if I wanted to make more of my own unique custom systems/mechanic, but still leverage some aspects of Corgi I could wind up very quickly being forced into using tags over layers because of lack of availability.

So the hard limit of 31 layers could be a good reason to support tag grouping as a way to future proof LDtk2Unity for use in bigger/more complex game projects.

[Cammin]

Yeah, I checked in with corgi's documentation to see if tags were relevant, but they are completely not used which also supported my decision (at the time). Layers however are used much more often by corgi, haha

Yeah, maybe I will keep the tag option in. It allows more freedom and options when hitting the layer mask cap. My main point of argument for not including tags is for simplicity purposes to lighten the number of fields used, but I think that overall after thinking about it, keeping the tag option should be good. You've also persuaded me 🙂

[Cammin]

Got the functionality working 👍 The tilemap gameobjects would be named after their tag/layer configuration. If any tag or layer is not custom-configured outside it's "Untagged/Default", then it will maintain a simpler name. The reason why I need to keep these unique names is because Unity's import system requires unique identifiers in the hierarchy. So I'm working around this. 🙂

This new feature will be coming in the next update. I'll close this issue when the update is out.

[stickynoteme]

I'll be looking forward to giving it some good testing, and restructuring my project. It was getting kind of confusing putting everything I wanted on a different layer on it's own Intgrid.

[Cammin]

I pushed the update! 🙂 Changelog Updated documentation

Give it a try and let me know if there is any criticism, issues, or design feedback. Good luck with restructuring your project 👍

[stickynoteme]

Been playing around with it daily for about a week now and thus far everything works great. I'm quite glad you decide to keep the tags, once I got rolling with idea's and started adding my own features I very quickly needed to use quite a few of them in combination with the LDtkIntGridTile's.

At this point it seems pretty perfect, I'll of course be getting a lot more use out of it, so only time will tell, and I'll be sure to let you know if I run into any bugs.

At this point I think the only thing that feels like it's missing from LDtkIntGridTile's is a way to set other default compounds and settings. Which is more of a nicety then a requirement since it would save time on repetitive work, but not really add any new use cases.

[Cammin]

Cool, I'm glad it's working out!

I think for setting default component settings, I'd try utilizing Unity's preset system for some components, like composite collider, renderer, etc. But yeah, It's more quality of life. A good idea nonetheless 🙂