koobas.hobune.stream
Proper/Standard way to create a top down / isometric sprite sorting solution
Hi,
For my next game I'm trying to create a game with a camera similar to "Age of zombies, Zelda minish Cap, Hyper light drifter, etc" Top Down tiled ground with sorted sprites for characters, items, npcs, buildings...
Now I wonder whats the proper solution for sprite Y sorting.
I've been reading a lot about this topic.
I found two groups:
a) People who approaches the game in pure 2D. Using a "spriteRenderer.sortingOrder" solution, either on late update for each element or for specific elements when they collide to others.
b) People who takes a real 3D solution. Using flat ground (maybe tiled) and sprites facing the camera (you have to update their rotation every time)
I'd like to know whats the best one, I don't want to take a solution just because you can do it in some way but based on real experience.
What do you think?
Thanks a lot!
Well, we're making a game using 2d sprites positioned in 3d space using a perspective camera, which I guess counts as your option b.), but I'm not sure what you mean by updating the sprites rotation every time? Billboarded sprites always face the camera direction - there's no additional work required.
You have if you rotate the camera, not my case jj.
Do you have any screenshots of your progress in twitter or smth?
This is our desert environment. We use a perspective camera so the positioning of the player among the stones, grasses, rocks etc. is resolved by simple Z-sorting. 
Ever since Unity started offering 2D support, I would say that option A became the norm. Option B would've been the way of handling it before the support was offered. I would suggest using option A. If things are going to be constantly moving, Late Update may be appropriate, but another option would be to determine if the object actually moved before updating it. For instance, you have a tree that is static. That will never need to have it's sorting order updated. If you have a person, they may be updated quite frequently, but a non-playable character who just sits in one spot waiting for the player to purchase something from them might not need to be updated at all. Likewise, a box that can be moved by the player should only be updated when it is moved! I would say that you should have a Boolean value stating that the object is moving, and when it's moving in the Late Update function, set the sortingOrder to the y value. This will be the most efficient way of doing it rather than every object constantly changing their sorting order. You could also have this functionality in a class/component of it's own and any class needing to sort will have a Require Component Attribute at the top of the class.
What about if you have many of characters, monsters, they will be colliding each other, causing a lot of updates every time frame if they are surrounding you?
I don't understand the question. Are you stating that those updates will occur anyway? If you are, they actually don't. Yes, they will cause an update to occur, but every frame they don't hit you, an update isn't being called and a little less memory is being used as this occurrence snowballs and more and more updates don't occur. If they move, they update... if you move, you update... If you move, you both update. However, in the long run you are, not everyone is constantly updating.
If that wasn't your question, feel free to comment with a more direct question and I'll respond to it the best way I can.
In this approach, whats the actual benefit from using 3D camera where you same all the scripting? I read some posts around this and people just use it because 2D is now "natively" supported by unity. It feels like both options come with pros and cons, I'd like to have some heave reason to use one ins$$anonymous$$d of the other so I don't regret when project is 60% completed.
