Question best practices regarding "cutting" your sprite sheets

Hello

I am a seasoned developer but a rookie in Unity world, so apologies if my question is silly, but I could not find any definite advice on the topic...
I am working on a tile-based 2D multiplayer game where the players will be moving on a grid similar to HoMM 2 & 3.

My question is, does it make a (big) difference performance-wise to cut bigger objects from my sprite sheets as one big sprite as opposed to having them as multiple 32x32 tiles.
Please see attached images to better visualise what I mean:


The reason I'm asking is:
After creating the world, I want to auto-generate a grid and save that on the server, so on each player's move the server will verify if the move is indeed correct (player is not trying to go through the wall etc).
This grid will be generated based on which tiles are populated in the tilemaps that have Tilemap Collider attached to them. So basically if there is a tile the grid will get a "1" making the tile inaccessible for the player. I hope that makes sense.

Also I like the characters to be able to walk behind the trees etc so having everything cut to 32x32 makes it easy to put bottom of the object on the "collision tilemap" and the rest on another one (without collider), so the character can walk there freely. I know I can edit the collider for a bigger object but this seems like more work to me.

Also are there any pros and cons to the two approaches I did not consider?

Thank you in advance!
Karol

P/S. I forgot to mention I came across third option, i.e. making a prefab out of my "bigger sprites", and adding them to the scene as Game Object, but I believe this approach is discouraged as not performant...?

 

Profiler testing (Window -> Analysis -> Profiler) on the actual target hardware is the only way to answer questions like this.

It may impact whatever process you contemplate for making content. If you have to drag 57 sprites in to make a single house, that might get tedious.

You can do crazy oldskool collider-mapping schemes like this (I cut my teeth on them in the 1980s/1990s) but with Unity remember that you have the power to do a lot of the work directly in Unity objects, which relieves you of all the generational code to marshal a "1" into some kind of player-blocking mechanism.

 

Hi Kurt

Thank you for your reply!

Will try this, thanks!

Not sure if I understand correctly... I can select multiple and drag all of them in one go, so why would that be an issue...?
On top of that I can customize the object easily, but replacing a single (or few) tiles with something different (some tile sets provide additional elements, like windows for houses etc) without worrying about adding another tilemap to host those customizations.

Yes, I know Unity will handle all of the collisions for me on the front-end, but since this will be a multiplayer game I also want to validate every move on the server. This is why I need a grid of 0s & 1s on my server (where "1" is an obstacle and "0" is a square available to walk to/through). Are there some built-in mechanisms for that in Unity too?

Now I am thinking, instead of reading all the tiles from the tile maps that have a Collider attached (and setting equivalent tile in the grid to "1", perhaps there is a way to check in which grid squares there is any collider present?[/QUOTE]

 

for performance its better to have only 1 big sprite

for sorting its also easier to have 1 sprite

how do you plan to sort? if you make many tiles like that its gonna be messy when the player walks behind the house, you will have to create some workarounds that will create more performance costs

 

thank you karderos for chipping in!

I created a test scene and it seemed to work fine, let me illustrate my solution with this tree here.



So the bottom square I would put on a tilemap that has a Collider attached to it. Order in layer is smaller than player's so the player appears in front of it.

The two other squares are on the higher sorting layer than the player so when he walks behind the tree, he is "covered" by it.

Anyways, I agree it feels somehow hackish and I am not sure what other problems I could face following this route...

Alright! Thank you. So lets say I go for this approach, which you say is easier plus more performant,
also also feels the right way to do.


I am left with my original problem still, though.

If I create the house as one big sprite then on my tilemap only one square is considered to be set to something (although the house covers many squares). How can I successfully "convert" such tilemap to a grid that I can store on the server to verify if player's move is valid (please see my original post and my reason to build objects ion tilemap (like houses) using separate tiles)? Can I somehow loop through all the tilemap's cells and determine if there is a collider in each of them?

 

well you can always add extra code that fills the grid with impassable terrain where the house is occupying

also you should note that for the order in layer you are limited to a short so if your map has more than 65,535 positions your sorting will break

 

well, that's the thing... how can I do this if from the tilemap point of view only one tile is occupied by the house? (although the house is covering 30 or so tiles....)

I am only using 3 positions in this trivial example... for example
player is on Order in layer 0
top of the tree is on 1
bottom of the tree (the tile with collider) is on layer -1

 

can your players walk freely between tiles or are they confined to 1 tile movements like a tactics game?

between 0 and 1 you can have 2 positions or you can have 1 million (0.001, 0.5003...)

 

so yes, "confined to 1 tile movement"

no, in this simple example there would be only 3 positions/layers, because all of the collision objects would be on -1, player on 0 and objects that are supposed to be a "foreground" on 1.

in the actual game I would have maybe up to 10 different layers