Hi there Community!
I’d like to discuss with you some of my doubts concerning sprites, and I’d really appreciate any opinion and tip you may share with me because I’m very ignorant on this subject.
First of all, let me say that this is the first time I try to put sprites together using the new Unity tools ( the 2d ones) and yes, I’m a self-taught-newbie.
Okay so, I’m doing some traditional animation on A4 sheets.
Right now I scan my drawings at 75 dpi and images are 635 x 876 pixels but, to keep things smooth, I reduce them to 424 x 584 pixels.
Of course that is the size of the whole sheet, the character I’ve drawn will be smaller ( this is not pixel art though).
My idea is to increase to 100 dpi the scan, and then to keep the size appropriate to that resolution ( which is 848 x 1.169).
When I’ll get rid of the empty outline ( making it 100% transparent) I think my character will have a reasonable size.
Once all the drawings would be ready, I’d make an Atlas of them and give it to Unity.
I wonder if the Atlas size ( I mean its file’s weight and the sprites that will derive from it) will be a problem for Unity and the eventual performances of the game.
What size would you suggest to use for one single character sprite?
What about different monitors size and resolutions? How much can they influence the game?
Another thing, even if this is more of a question rather than something to discuss about… I’d like to let the player customize his own avatar colors.
I’ve seen how Unity’ staff dealt with a health bar’s changing color ( if I’m correct, they had a grey bar and then forced Unity to color it), should I do the same?
I mean, I can color my sprites with greyscales instead of the " original colors" I’ve planned, but I’ve no clue on how to let the player pick his own colors then.
I do know how to force Unity to color something with C# script, but not how to let you choose from a palette or a colorscale like Photoshop ones.
About this topic I’d appreciate if you point me in the right direction.
Are you targeting mobile devices? Some mobile devices are limited to textures of a max size 1024x1024 while the more advanced ones can go up to 2048x2048 or larger (like the PC).
While I can’t speak for mobile development and only speak for PC users…
SpriteSheet’s aren’t these amazing performance-savy inventions like people think. They are better on performance some of the time, but computers are extremely fast. If you’re using Unity, it honestly doesn’t matter what size your sprite sheets are or how many you are using, as long as you keep them in a reasonable size. (To play it safe, don’t go larger than 2048x2048. There isn’t much of a need to most of the time anyway.)
I could be wrong on SpriteSheet performance in Unity, but in most engines, framework, and code, it really doesn’t matter. Most 2D games are capable of running thousands of frames per second because of the power of modern computers. It isn’t as much about game performance as it is about memory requirements. You would have to have enormous sprites or hundreds of animated frames to break the typical 4GB-8GB of RAM most PC users have. But like I said, none of this counts with Mobile, and none of my advice is solid on Mobile.
For example, the transparency space you save by cramming in 20 sprites into 1 large spritesheet, isn’t going to be all that different than cramming 10 sprites into 2 smaller spritesheets.
PC’s are not these frail inventions people make it out to be when discussing spritesheets. Most games could not even use spritesheets and would function perfectly fine without them. IMO, the benefit of spritesheets is the organization of the files during development.
I’d just do whatever is easiest on you. In the end, you can always optimize later if you run into performance issues (Which you will certainly not, on the PC).
When in doubt or for simplicity’s sake, just make spritesheets that are under 1024x1024 if you can, or 2048x2048 if it’s more convenient.
For 2D in Unity though? Always make sure any texture you import (whether it’s a single sprite image, or a spritesheet) make sure it is a Power of Two. Unity screws with NPOT textures.
Monitor size is irrelevant. All that matters is the Resolution.
a 60" TV that is 1080p, is the same resolution as a 10" phone that is 1080p. They both will be rendering 1920x1080 resolutions and the hardware requirements for that resolution.
For a 2D game, resolution doesn’t really matter for performance. However, with 2D you start to have different issues with varying resolutions. For example, on a small resolution like 640x480 a single sprite may be HUGE, while on a 4K resolution they will be itty bitty. For 2D, there are typically 3 ways to resolve this problem.
The first, is to have a preferred resolution. Many older (and some newer) 2D games will start in very small resolutions. FTL for example, I believe goes fullscreen in a resolution much smaller than most users’ native resolution. This is done on purpose, to keep the scale of the sprites so they are not too large or too small.
The second, is to have pixel-perfect sprites displaying. This is normally done to prevent a lot of Unity’s 2D woes, such as pixels disappearing or distorting the quality of textures. However, I use this in my game regardless of resolution. The sprites ALWAYS display exactly as many pixels as they are. So a 40x40 sprite will appear 40x40 no matter if it’s on a tiny tiny resolution like 480p or an enormously large 4K resolution. The player however will see different amount of screen space.
This is not a problem for me, as the Camera can zoom in and out, by exactly half or double. Since my game is pixel art based, it ends up looking like this with zoom levels:
So if someone is playing on a small resolution, I will set the default zoom to allow them to see enough screen to play. On a larger resolution, I may simply have the default resolution zoom in more. In the end, I give the player the option after the default is chosen.
Very often the biggest annoyance with differing resolutions, is the GUI, the user interface. Your interface may look odd, overlap, or be out of place if you use absolute coordinates. This results in a common third solution to the problems of differing resolutions in a 2D game.
The third, is to create the size of the GUI buttons based on the size of the resolution, along with the placement (x, y, positions) based on math using Screen.width, Screen.height. In this way, even if the resolution is changed, the GUI adapts. This can also look weird until you get it right.
However, the placement of the GUI is something best left to optimize at the end of your game, once it is finished. Many developers choose to use an interface THEY understand, with the idea that it doesn’t matter until the end. The pitfall to this, like any strategy to do things later, is that a very large amount of indie developers forget or ignore the need to polish their game after it is finished, or feel the GUI is “good enough” or lose sight that new users will not think it is as great but the developer is so used to it he thinks “Oh it’s fine. It’s so easy!”
Besides those quirks, resolution in a 2D game isn’t that big of a deal. Not to say it isn’t a big deal in 2D, as like I said it determines the size of the sprites.
For 2D, there are many ways to do this.
Through a shader’s tint, through a color-changing shader, or through a color changing class. (Warning: a shader is really fast, and my color changing class reads and writes a completely new texture so it is much slower.)
There are two ways in that thread to do it, the Shader, or my class. If you do the class, remember you have to turn the Sprite from ‘Sprite’ to ‘Advanced’ and then enable read/write on the texture. The shader is better for all other purposes, but does have a bug where colors can loop. It’s mentioned in the thread if you have the problem. I’d suggest the shader.
edit: Also to add, the shader method of changing colors (dying pixels) can be seen in the Unity Editor. My class method, only works at runtime, so the undyed version will be seen in the editor. If I had the choice, I’d use the shader method. However, my class method has more control and no bugs. The shader in the link, is not good enough for my needs but may work perfect for yours.
Sir, your reply is simply awesome!
Thanks a lot for all the links and references, I really needed them!
I really appreciate also what you say about atlas and resolution, because it helps me understand better the whole thing!
Since it’s the first time for me, I think I’ll go with the first possible solution you suggest ( seems the easier), but I’ll give the other ones a try… who knows, maybe I can even put them to work!
Yes, as you may already guessed I was referring to PC only, so your reply fits in perfectly.
That’s more than what I was expecting, so thanks again for sharing!
