Z position in 2D game

what is the Z position of the object in 2d responsible for? if I have different objects with different Z values, does it affect something?

 

if you set transparency sorting axis to Z it will render lower Z objects above higher Z objects ( just like in 3d )

also if your z is outside of the camera z clipping planes it wont be seen by the camera

 

For sorting in 2D I would recommend using order in layer to specify draw order directly and to not use the Z values.

 

though order in layer is a short so your limit of sorted positions is 65,535

which is surprisingly easy to reach since your characters will move in fractions of a unit ( 0.253 , 1.35, 2.4555 ) this all needs a different order in layer unless you do approximations

on the other hand ordering by Z gives you around 2billion levels of sorted positions ( near perfect sorting if your map is smaller than 99999 units)

 

Why would you need more than 65,535 sorting positions?. Most things would be on the same sorting layers at least in an Isometric Top-Down.

 

because characters are not locked on a grid

if char A is on position y = 10.01 and char B is on position y = 10.02 what is their respective order in layer? 65535 sorting postions cant cover this

 

You can just sort on the pivot points on the character and have them on all the same layer



Both characters are on Layer 5
--James

 

It's worth mentioning that there's functionally no difference between a 3D and 2D scene in Unity.
All a 2D scene is, is just an orthographic camera with a top-down perspective.

So you may or may not need to take z-positioning into account, but it can be useful in some cases for a 2D game still.

 

sorting on pivot points is not order by layer... In fact it is exactly the method I was talking about ( sorting by transparency axis)

if you are sorting by pivot point why bother changing order by layer???

 

Meant it more of a combination, you're going to sort by pivot on the objects you want that walk-behind effect and use layers to layer them on the scene (tiles and such). Just saying you would never need 60k+ sorting positions because you wouldn't be using it for that kind of sorting

 

if you leave that wizard on layer 5 he wont be able to walk behind the blocks on layer 4

 

Correct but he can't walk behind the blocks anyways because there colliders preventing that. Really just comes down to the level design on how you want things layered. If you wanted a walk-behind you probably could add some tile triggers to dynamic change the wizard's layer if you needed. Either way, I doubt you will be 60K+ layers even in the most complex scenes.

 

well you yourself have realized that you need more than 60k layers since you are using other features to sort. ( if sorting by pivot was not available to you, 60k layers would not be enough for your game)

 

Thank you!

 

For me I have never reached any limits; I can't imagine a scenario where you would. Likely you just need to rethink your design then.

Layers I would use in sets; Background, Foreground, UI; Background being a parallax aesthetic, Foreground being my characters and static objects like trees, then UI for anything I need on top of both. Then each one have available 32,767 Order in Layer. Let's say I simply use the Y axis in whole numbers to determine the Order in Layer at 1PPU then my characters will always be in correct order and if my map is bigger then 32,767 then they should be different scenes or the world can be adjusted to be back in camera range.

 

this method assumes 2 limitations:

1st - your characters y position can never be decimal ( no 1.2, 1.255 ), only whole numbers ( 1 , 2 , 445 )

2nd - your map Y size can never be larger than 65,535 units

which might be fine for your game but others need large maps and sub unit movement

its good that transparency sorting layer exists so you dont have to bother with order by layer

 

As I stated though, move your world to be at camera 0,0; eventually you will meet the limit of floating point numbers as well if you don't. You would only be delaying the inevitable anyway.

 

the limit is much larger though, since a float is 32bit and a short is 16bit

the float would support a world size from -99999y to 99999y with accuracy, and that includes sub unit positions ( not limited to 1 ppu designs ) ( this could mean potentially close to 2 billion levels of sorting )

while the short only suports a world from -32,767y to 32,767y and does not support sub unit positions ( literally 65,535 levels of sorting, 30000 times less )