Spritekit Scene Scaling and Image Sizes

Hello all,


I am designing a game for iPhone devices, including the SE, 7, and 7+ sizes. I have been tackling screen resolution and scaling issues for some time now, and I think I have all but one problem fgured out.


I'll use a background image for this example (portrait that takes up the entire screen). I create my scene with the following code,


SKScene * scene = [BeginScene sceneWithSize:CGSizeMake(375, 667)];
scene.scaleMode = SKSceneScaleModeAspectFill;


I can design my app for the screen size of a 7 and it will scale up to 7+ sizes and down to SE sizes. If I want a node to be placed in the center of the screen, I set its position to (187.5, 333.5). I also create the image with dimensions of 1126x2002. Then I scale it down from @3x to @2x and @1x. This way I can essentially create one image with three resolutions, and use one game design and it works on all iPhones.


Here's the question. Should I instead design the graphics with dimensions of 1242x2208 and set the SKScene size to 414x736, that way all graphics are saled down (thus looking best on all devices)? And the second question, is this an acceptable and profetional way of creating games wih SpriteKit? Or am I going about this all wrong?


Note: My current systetm is workign well, I just want to check to see if there is a better way of doing things


Thanks a ton!

-Xhale

Answered by QuinceyMorris in 218347022

I don't know of any API contract that will tell you the correct answer.


Conceptually, two scalings are involved:


1. From the raw pixels to the scaled pixels at the resolution required for your scene at 100% (in relation to Sprite Kit).


2. From your scene's pixels at 100% to the scaled pixels at the actual resolution implied by your Aspect Fill mode.


There may also be another one, behind the scenes:


3. From the high-resolution screen backing store down to the true hardware pixel resolution.


But you can't really tell how many actual scalings will occur, because this (AFAIK) is not documented. It may also depend on the hardware capabilities (e.g. Metal vs OpenGL) and the iOS version.


Personally, if I wanted the best quality display for a game deployed across multiple screen sizes, I wouldn't use Aspect Fill at all, but let the game scene be the size of the screen. From that, I'd calculate the sizes of all visual elements in game scene coordinates, and render hi-res assets into textures or nodes of the correct sizes (letting the frameworks handling the choice of 1x, 2x or 3x resolution by specifying logical image sizes only). In effect, that means there's no further scaling after textures are created. Still, this is harder to implement than it sounds, especially if you want your game to resize on rotation between portrait and landscape.


Within the context of your current approach, my opinion would be to design the assets at the equivalent of 3x for the largest screen you support. It may not matter much, but scaling down typically looks better than scaling up. Then you have to decide what memory footprint implications this has, and modify your approach accordingly.


You might also try just looking at your app on a 7 and a 7+, side by side. If the one that's actually scaled (the 7+, if I've understood properly) looks fine, I don't think you need to change your current methodology.

Accepted Answer

I don't know of any API contract that will tell you the correct answer.


Conceptually, two scalings are involved:


1. From the raw pixels to the scaled pixels at the resolution required for your scene at 100% (in relation to Sprite Kit).


2. From your scene's pixels at 100% to the scaled pixels at the actual resolution implied by your Aspect Fill mode.


There may also be another one, behind the scenes:


3. From the high-resolution screen backing store down to the true hardware pixel resolution.


But you can't really tell how many actual scalings will occur, because this (AFAIK) is not documented. It may also depend on the hardware capabilities (e.g. Metal vs OpenGL) and the iOS version.


Personally, if I wanted the best quality display for a game deployed across multiple screen sizes, I wouldn't use Aspect Fill at all, but let the game scene be the size of the screen. From that, I'd calculate the sizes of all visual elements in game scene coordinates, and render hi-res assets into textures or nodes of the correct sizes (letting the frameworks handling the choice of 1x, 2x or 3x resolution by specifying logical image sizes only). In effect, that means there's no further scaling after textures are created. Still, this is harder to implement than it sounds, especially if you want your game to resize on rotation between portrait and landscape.


Within the context of your current approach, my opinion would be to design the assets at the equivalent of 3x for the largest screen you support. It may not matter much, but scaling down typically looks better than scaling up. Then you have to decide what memory footprint implications this has, and modify your approach accordingly.


You might also try just looking at your app on a 7 and a 7+, side by side. If the one that's actually scaled (the 7+, if I've understood properly) looks fine, I don't think you need to change your current methodology.

Thanks! Thap pretty much confirms what I was thinking.


The reason why I used aspect fill is because the SE, 7, and 7+ have the same aspect ratio. My game looks good on all three sizes, as there is no stretching or warping. I figure that creating my own method of scaling and re-positioning assets would ammount to what aspectfill does. But I assume aspectfill is more efficient than what I would come up with.


Anyways, thanks again!

I've flown from one side of this galaxy to the other, and I've seen a lot of strange stuff, but I've never seen *anything* to make me believe Aspect Fill isn't the way to go.


=)

That's good to here.


But what do you think about how the scene should be built. Should it be built to run on plus phones and scale down, or on the standard phone? I'm leaning towards the larger phone.

This thread inspired me to just write an article on it...


spritekitlessons.com/what-size-to-make-your-skscene-image-sizes-in-sprite-kit/


Hopefully that explains this. If not, hammer me with more questions here. But yes, design for the larger devices in the family (the bigger iPad / iPhone), because its better to scale down than up. You lose crispness scaling up.

I think your article tells only half the story. You say:


>>Smaller iPhones will simply scale down slightly to their point size.


and move on. It depends on the game design whether the "slight" scaling down due to using aspect fill mode (on a scene point size that matches the 7+ screen point size) is acceptable. On a 7, the game will look only 90% as large, and smaller still on a SE.


For some games, that would be perfectly acceptable. In some others, it would be unacceptable. In yet others, it might be more-or-less OK, but there might be problems, like small text becoming too small to read easily, or targets becoming too small to fat-finger reliably.


If it's unacceptable, then one option is make the game's field of play smaller on the smaller screens, so that the scene scaling stays at 100%, but keep the sprites the same size on all screens. (This means they'll look the same, but be larger relative to the smaller screen.) Again, this isn't going to work for all games.


It's actually (IMO) one of the most difficult design decisions to make, about how to choose the game scene size. (You also have to decide whether the game play area should scroll, which plays into the size decision.)


Regarding the OP's question, which was (a) is it acceptable for a professional-looking app to scale the game scene?, and (b) what's the best strategy for scaling?, then my answers were:


(a) sure


(b) downscale from a much higher resolution whenever possible


and those are the same as your answers. The thing that freaked you out was that I added this:


(b') but if you want the highest quality imagery to appear on screen, avoid scaling the game scene to anything but 100%


Even so, I recommend only worrying about this if you can see a quality drop across devices, and only if it bothers you.


(Thanks for your site, BTW. It's a great resource.)

I'm glad I inspired you to write an article. I'm suprised that I couldn't find anything like it before.


I'm curious, what would you reccomend I do if I wanted to port my app to iPad? It can't, and shouldn't, be scaled from an iPhone. There needs to be new images, new locations for nodes, new organisations of GUI elements, and so on. There are too many thangs that need to change to allow for an enjoyable experience on iPad. But if your play scene has, say, 10,000 lines of code, it seems unrealistic to duplicate the class and readjust each node. And when it comes time to update the scene, you need to ensure updates are the same across two separate classes.


Any ideas?


Thanks again for that article!

Spritekit Scene Scaling and Image Sizes
 
 
Q