My case is as follows: I am building a Tilemap-based platformer game. A key feature of this game is the ability to climb along poles and semi-solid platforms.
Now, naturally, I’d like to be able to build my levels primarily using tilemaps, given the comparative ease of placing a few tiles versus having to go and manually type in each and every ProGrids-incompatible point of an EdgeCollider. The problem is, the Sprite editor requires that all physics shapes be closed polygons–delete the third vertex, and the entire shape completely vanishes. I’ve had a decent bit of luck using pixel-width colliders before, but unfortunately this breaks down as soon as you need to be able to move the hold point along the platform’s length, at least in the simple implementation where you move the point along the collider-demarcated path, because you’d just end up moving around the closed collision shape of whatever tile you grab hold of. (Worth noting: I haven’t actually tried it, and in fact I have no clue how TilemapCollider works. Nonetheless, logic seemingly dictates…) I doubt I could just make the sprites’ colliders zero-width triangles, either, because internally it’d still be a triangle, still a closed loop. Doing that plus using a CompositeCollider on the TilemapCollider just erases the colliders from existence, since CompositeCollider apparently does not support open edges.
In other words, it doesn’t seem to be possible to create EdgeCollider-like formations using Tilemap, due to the way sprite physics shapes work. This is an incredibly annoying hole in Unity’s new 2D system (using a simulation of zero-width edges when the real thing is clearly accessible in the engine), but with this climbing system it becomes nigh unusable. (Before you ask: yes, I absolutely could just manually place EdgeColliders on my poles. Bear in mind, it would reintroduce the very ProGrids-immune coordinate fiddling that Tilemap is meant to circumvent.)
Is this a problem that can be fixed on Unity’s side? And if not, I would greatly appreciate some help implementing a fix (a.k.a. an EdgeCollider-placing grid brush) on my side so that I can start using Tilemap the way I need it.
EDIT: My original post apparently made it sound like I was asking for help with semi-solid platforms. Edited to put the focus back on the climbing system.
I don’t think you’ve fully explained how edge colliders will solve your problem. I don’t think you should really need edge colliders to do what you need.
Have you looked into the PlatformEffector2D component?
I can see this being solved by having a tilemap just for your one-way platforms, and using the TilemapCollider as well as a PlatformEffector2D.
TilemapCollider can use your sprite’s individually defined physics shape from the sprite editor. PlatformEffector2D can make them have one-way collision.
Ahh, that’s right, PlatformEffector2D exists.
I’m actually already set up with a working semi-solid platforms implementation (which does in fact use a separate tilemap with its own collider setup, thanks for the validation
). I guess my talk of that feature was unneeded and confusing? (This is why you don’t write forum posts at 4 AM.)
My problem’s not with that. My problem is with the other feature, climbing along poles; my only idea of how to do this involves moving a point along a path defined by vertices, which breaks down if colliders are comprised of many closed shapes
If by “many closed shapes” you mean each individual tile having its own collider, then you can use the CompositeCollider2D component, which will merge adjacent colliders into a single seamless collider mesh. You may want a separate tilemap for just your climbables if that’s the case.
If the issue is not that there are many small tile colliders, but that your climbing “path” will wrap around at the end or something, then perhaps you could validate the angle towards the next vertex before attempting to move towards it?
Or alternatively, probably the “correct” solution is to create a custom climbable tile class and generate a path or edge collider or something for climbing?
See an example of custom brushes that generate interactive elements in this video (27:30).
Here’s the brush files for that demo:
Yeah, the problem was path wraparound. Angle validation and custom brushes/tile types were the solutions I came up with also…
Thanks for trying to help. My preferred solution, the thing I really needed help with, was always the creation of an EdgeCollider grid brush, but I didn’t make that terribly clear (or at all clear), did I?
…I’ll just go stop whining and solve my problem now.
EDIT: Although, uh, thank you for pointing me to those GridBrush samples. Sometimes you just need a little kick in the right direction, I guess.