27
\$\begingroup\$

I'm making a 2D (Android) game. Android devices vary quite a lot in screen resolution; what do I need to keep in mind when making my game?

  • Do I need to keep big versions of all images and scale down depending on the resolution (doesn't that waste space)?
  • Do bitmap fonts scale well or do I need to use something else?
  • Anything else I'm forgetting?
\$\endgroup\$

5 Answers 5

26
\$\begingroup\$

I'm the developer of an extremely portable mobile game that runs on everything from PCs, to TVs, to even the Black & White Amazon Kindle (Smiles HD - http://smileshd.com - More devices and platforms than you see there).

The best way I've found to support any device is to pick a base resolution, then scale up (or down) to the current screen. If you want to cheat, you can fit to the new screen resolution, but ideally you should keep the same aspect ratio. Fitting a game made for a 4:3 display looks hideous on a 16:9, but fitting a 16:9 on to a 16:10, nobody might notice. You'll note I refer to screens by aspect ratio and not the dimensions, which is especially helpful way to think in this era of totally random LCD sizes.

To make artwork that suits any screen while maintaining the aspect ratio, create backgrounds that are larger than most typical screens will ever see. This is similar to the concept title-safe areas with Television.

http://en.wikipedia.org/wiki/Safe_area

Generated backgrounds work really great for this. Tiled patterns, checkerboards, fractal shapes, etc. You just need generate a little bit more to fit a new screen.

Also, creating static images larger than what your typical user will see. Wider than widescreen (16:9), and squarer than standard def (4:3). Again back to title-safe areas, fit your important information in to a safe area, scale up a bit so your safe area touches one of the edges of your screen, and leave some run-off for devices that are just a little bigger.

A variation I'm working with today is creating "title safe" 3D objects. Since they're 3D, composed entirely of vertices, making them larger than the screen takes up practically no more memory than if they were to fit. Just as the density of pixels goes up, you may want some higher detail textures available. If not, oh well, it's a little blurry.

User interfaces, I like to fit the main UI within a perfect square in the middle of the screen. The corners and the middle edges also make really good places to put things; You should calculate their coordinates as such (relative the corner or the middle edges).

http://www.smileshd.com/press/iPad/png/UI01.png

If you really want to get fancy, you can support both Tall and Wide orientations. Some devices do report their screen resolutions as taller than wide (iPhone for example), so you may have to do something for those devices anyways, even if it's simply rotating all of your coordinates.

A User Interface that adapts to both tall and wide screens can be a pretty impressive sight.

Wide: http://www.smileshd.com/press/iPad/jpg/SmilesHD01.jpg

Tall: http://www.smileshd.com/press/iPad/jpg/SmilesHD02.jpg

On the plus side, design wise, you only really need to consider Tall and Wide, instead of Portrait+Reverse Portrait+Landscape+Reverse Landscape. When you pick the positions of things on the screen, consider having a more appropriate alternative position for the other orientation.

Do I need to keep big versions of all images and scale down depending on the resolution (doesn't that waste space)?

Well you can either "waste space" and support a wider variety of devices with a single build, or "waste your time" and have to make MANY builds and resize artwork for many devices.

Best case, you should create your artwork at higher resolution than the final size would be on a 1080p Television (1920x1080). 2048x2048 should be a common size in your source artwork. Either that, or consider using Vector artwork tools like Flash and Adobe Illustrator.

I'd strongly recommend creating an automated process for resizing your artwork. Most mobile devices today, tablets included, do not exceed resolutions greater than 720p (1280x720)... at least, not by much. Come next year though, we just don't know if that will be true anymore (iPad 3?).

Either way, for best performance, you should get used to the idea of source artwork and source assets. You can then perform a process that optimizes the data for whatever device(s) you are targeting.

Do bitmap fonts scale well or do I need to use something else?

They scale well if you're using a good filtering. If you're making your 2D game with 3D hardware (OpenGL ES), then I must strongly recommend that you use Linear Filtering combined with MipMapping (i.e. a set of scaled down images). You can get perceptively perfect results with this, and it's often faster to use mipmaps than not to.

http://en.wikipedia.org/wiki/Mipmapping

Anyways, I hope that helps. Best of luck with your project.

\$\endgroup\$
2
\$\begingroup\$

In general, every texture you make should be either 256x256, or 512x512. If you are also targeting pads (Galaxy Tab, Honecomb, iPad), then 512x512 will not fill the entire screen, so you might want to include larger versions of those art assets which need to fill the screen. Apple includes a native "@2x" image suffix to handle this case.

The simple solution, which I've used myself, is to simply create your game for a 320x480 screen (iPhone). Let this double naturally for iPhone 2 (640 x 960), and then the only other case you really have to handle differently is the fact that some Android devices have a taller screen - so just put a buffer on the top and bottom (in portrait mode).

In short - build your game for one neutral screen size, and then cover the exceptions, based upon

\$\endgroup\$
1
  • 2
    \$\begingroup\$ I think you missed my Android tag. Anyway, buffer sucks; it's better if your game actually scales up and looks nice. \$\endgroup\$
    – ashes999
    Oct 15, 2011 at 6:02
1
\$\begingroup\$

It's best to keep the working copies of any assets you have. If you're developing an image in photoshop, for example, save the original psd file. Any time you need a different res image, you can open it up and export the new image with minimal quality loss.

Rather than build for one screen size or another, I would strongly suggest you build for a variety from the beginning. You're not only talking about different pixel densities, you're also talking about different aspect ratios. 16x9 and 16x10 can yield a very different visual experience. So make sure you test new changes on a variety of different screen shapes and sizes.

In my experience, bitmap fonts do not scale well at all. It may depend a lot on the style of font you use, but in general, resampling the font bitmap yields very poor results. Bitmap fonts work best when your texture sampling is not set to multisampling (GL_NEAREST, and without mipmaps) and it is rendered such that it maps pixel-for-pixel to the screen. You may want to consider using a series of renderings of the same font at different sizes and ensure that the font always appears at scale == 1 in your game; this will allow you some limited options when choosing a font size to use in a particular scenario.

\$\endgroup\$
1
\$\begingroup\$

Android provides some help for this...

You can specify "alternate resources" for items like your graphics.
Take a look at "Providing Alternate Resources" section at this link: http://developer.android.com/guide/topics/resources/providing-resources.html You should be able to find examples in the SDK examples or via Google.

Also, Google provides an Android Emulator that you get with the SDK. You can define several virtual devices with different configurations to test your code. Here is a link to more info: http://developer.android.com/guide/developing/devices/emulator.html

Good Luck amb

\$\endgroup\$
0
\$\begingroup\$

Besides the technical aspects (addressed by Mr Strange) be careful when designing a game with variable screen size. Just as an example, imagine playing streets of rage in a landscape-like screen and then in a portrait screen.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .