So I’ve basically built a level out of 64x64 tiles, each tile has it’s own collider. For example, the flat ground tiles are just plain box colliders, and so I have used the scene view’s vector snapping function to line them all up neatly. Problem is that even though they’re neatly lined up, the fact that they’re separate box colliders gives the player bumpy movement when running along these aligned tiles. A quick fix is to just set the y velocity to 0; however when the player moves down a slope, this cannot be zero, and I haven’t found a way to set a ‘relative y velocity’ to zero. Another idea would be stretch a single collider over a collection of tiles, however this can get inconsistent with the position of the tiles.
So does anyone have any suggestions on how to counter this issue?
_
This issue carries over to having smooth, realistic movement over slopes… why is this such an issue? I’ve found no solid solutions to movement on slopes, is it even possible to have something like Sonic’s controls in Unity 2D? If it is, then the next sample assets needs to have a character controller that deals with slopes the way everyone wants. Also, the assets should include a one-way platform… just another basic thing that everyone wants, I think.
I’m not totally sure but I think it’s to do with how a new collider that the player reaches, triggers off a collision and maybe the corner of the collider is considered positioned enough to make the player move a bit. … OR, maybe the ACTUAl floating point values of the position/size of the colliders is very slightly off, enough to register as a bump?
The ‘interpolated’ physics check is on, and I have noticed that even with the vector snapping that the y value can be off by 0.0000001… even after correcting that it STILL has the bumpy motion.
You’re stuck with it if you are going to use a collider per tile. You could write a map class that will deal with tile collissions and so not have that, or simply take off your colliders and redo them using the least possible, which would also make your game faster.
If your levels are really small, this could work. Otherwise, it’s better to do what Irlelaldl said. Create an empty game object and nest your tiles beneath, then Use Edge Colliders 2D.
Okay, so I’ve come up with a solution. Just made a script that is attached to a basic shape (say, a square), and if I want to make a long flat plane then I increase it’s local scale and instantiate tiles along it based on it’s scale.
So if a standard 64x64 block has a localscale.x of 3 (so I want it 3 tiles long), I instantiate tiles using a while loop so that when i=0, it creates one at origin; when i = 1, it creates one at 0.64 to the right of the origin’s x and one to the left. Also it’s adjusted for a localscale.x that’s an even number so it creates on at 0.32 to the right/left of the origin’s x.
And of course if the tile is a slope then the y value has to be adjusted too.
As a result, the (one) collider is just on that basic shape that stretches across the tiles which are just plain sprites. Problem solved!
Thank you for all the replies!
But a couple of follow-up questions:
-Does making them static (the collider and the sprites) make the game run faster than if they weren’t static?
-Should the ‘instantiates’ be done in Awake() or Start()?
It would be better to make them static(collider without rigidbody is automatically static) as it assumes that it will never move and so will not be trying to recalculate it all everyframe. If it ever has to move though, it would be better to have akinematic rigidbody attached as well.
In Start() would be the “best” way.
As for your earlier question, the class would handle all of your map, including checking against the tiles and correcting if the character collides with something. Basically writing your own collision detection over a map of tiles, rather than using the native box colliders to do so.