Handling Different Screen Sizes in Mobile Game Development

Developing Games for iPad vs. iPhone: Core Differences

Whether there are fundamental differences for building an iPad or iPhone app depends a lot on the type of the game. We have games in the past that work nicely on both iPad and iPhone. Take a game like Mario, for example, where you just have a platform so you can jump—you can build that on iPad and iPhone in very similar way. In the iPad you can probably see a little more of the game or maybe scale the game up a little bit, but the experience is still great. If you build a game like Words with Friends, then you likely don’t want the same experience on the iPhone and iPad.

You’d have to decide to pick one of the platforms, then optimize and make your UI look good on that.If want to add an additional platform, you would likely have to build an entirely different interface and won’t be reusing the same interface. You will reuse the same game logical that every other possible thing,but the interface for an iPad game that allows you to play a puzzle game will look a lot different from that on iPhone.

I would say if you’re working on a type game you know will have very different interfaces, then focus on one for the beginning. Otherwise, for other games, SpriteBuilder has really great support to add assets that work nicely on iPad, iPhone, and all different screen sizes. If you’re not working on a game that would require different interfaces, I will recommend not cutting out one platform too early, since it only requires a little added effort.

Another thing you see is that Apple seems to like Apps that are available on iPhone and iPad. They seem to rank them a little bit higher in search, so if you can put iPad version of the game out there, it’s worth a try.

Screen Rotation in a Mobile Game

Screen rotation is actually a thing that is really poorly handled by most game engines at the moment. Right now both Cocos2D and Sprite Kit do not really respond to the screen size changes by the rotation. There are some people who have implemented certain hacks to their game to deal with screen rotation, but those are not really a part of the Coco game engine.

However, for Cocos2D this is actually going to be changed with the Cocos2D4, which will be rolled out before summer around April. Cocos2D4 will be able to actually have UI components on the screen to respond to screen rotation.

I can talk about my experience in how to do this for regular iOS apps. Usually, you’d just need to have your interface designed, and then set up some constraints. For example, say your button is on the top of the corner is 10 points from the left side of the screen and 10 points from the top edge of the screen. If you rotate the screen, these rules get applied again, which might result in your UI components moving a little bit, but it doesn’t really messed up your interface.

So the basic idea is to set up rules at the beginning in the way they’d work for all rotations for all different screen sizes. Then, the game engine will just decide when it will reapply the rules. At to moment it’s not possible for games, but if it starts to become possible, the rules will be still the same, so when you think about screen sizes and you will automatically think about screen rotations.You just make your game work in all different dimensions that are possible.

Resource Files: Retina vs. Regular Assets

Would you scale them by same amount for a retina display?

That is actually built into the game engine itself. How that works is typically when you build a game that supports iPad, retina iPad, iPhone retina and regular iPhone, you’d provide assets and what is called the 4x size. The 4x size is basically the image size you need to represent the same thing in iPad retina on an iPad as it would be on a non-retina iPhone.

This means if you have a character that has a size of 50×50 on an iPhone, then you will provide an asset with the size of 200×200. This will be used on iPad retina, and it will look more like or less similar compared to the screen size, and that is typically the way how you scale your assets. This is built into SpriteBuilder and Cocos2D so assets are entirely automatically scaled for you.

We actually have a full tutorial on our website on different ways to handle asset sizes. When you have an iPad game and you just want to show a huge amount of the gameplay that is a lot bigger than what it would be on the iPhone, you could just use the same assets you’d use on an iPhone retina as on an iPad retina, and the aspect ratio of what you see on a game will be much larger. By default, provide the largest screen size possible, and Cocos2D will downscale them to all these different devices so they would look the same size.

Porting to Android Games

Most of you probably know Android is way more fragmented than the iOS with tons of ratios and screen sizes out there, so it’s really hard to port all of them. The important step is using the dynamic layout system that Cocos2D provides, which means if there different device sizes, most of your games will look decent on them, and it comes out of the box once you start using these tools correctly.

Another common problem is the different constraints on the hardware. On the iOS, it is pretty easy to test on these devices.Even the iPhone 4 is a pretty good device that has a big memory that can handle graphics, so you can take big textures and put them out there. However, if you want to support all Android devices, you have lots of higher limitations. So you probably run into things like such as having the resolution of 2000×2000 on your Sprite Kit that looks great on your iPhone and all iOS devices, but looks horrible on, say, 20 Android devices out there that have max. resolution of 1024×1024.

So most of the time, you’d need to get Android devices in hand, figure out which limitations they have, and then see and decide whether you want to support the device. If yes, you must figure out how to change the assets of the game, and if not then you just cut out a certain level of devices. The large amount of configurations is one of the biggest problems you will face with Android devices.

Other Posts in this Series:

• 5 Best Practices for Mobile Game Development
• Swift vs. Objective-C: What Should Beginners Learn?
• Q&A With Author of Official Cocos2D Documentation

About Benjamin Encz

Benjamin started developing for the iOS platform in 2011 and has worked on a variety of enterprise apps to mobile games. He has written about graphics programming in WebGL, and is the author of the SpriteBuilder and Cocos2D documentation. He educates next generation of software engineers at Makeschool and also writes tutorials for them (you can also see their transcript of this office hours here.)