The Many Resolutions of Android

It seems like most the games I see, even from the studio I work at in my day job, expect to make a game for the iPhone and iPad, THEN worry about Android later. Rather than what I try to do, which is make for Android and then it "just works" on iPhone.

Creating a resolution independent UI is by far the most important regard here, and every time I talk to anyone about it, they always say that they're going to worry about it later because "it's too hard". My concern with this process is that the Android version is hacked together with black bars or stretching, or (more likely) it never happens at all, which makes me sad. I do realize that it takes a little more time, but it saves you time in the long-run. And, of course, if you're targetting iPhone only, then it's very easy, but you throw iPad in there and all the sudden you have multiple resolutions and aspect ratios to worry about already.

So my point and question here is, why is making resolution independent UI harder on mobile than it's been for PC? We've been doing it on PC for years and so that's just the way I always think about it anyway.

 

The problem is with input.

With PCs, its "easy" to have resolution independence because you can just as easily anchor items to screen sections (corners/center/etc) and it does not matter that the elements become smaller on extremely high resolution as long as they are not too large in low resolution modes. At the end of the day you end up using a pixel with a hanging arrow to interact with those multi-pixel GUI elements.

In mobiles, though, you do need to know how it feels. It's not just about anchoring. Some elements can just be anchored, but others, like virtual joysticks, need to be proportional to the screen size you expect the user to realistically slide his thumb over. That’s not just hard because of resolution dependency, but because input area.
Example in case: Let’s look at the following Android Phones:

EVO 3D 4.0 in (540x960)
EVO 4G 4.3 in (480x800)
Samsung Galaxy S2 4.52 (480x800)
Samsung Galaxy Note, 5.2 (800x1280)

You can approach GUI elements in two basic ways, one is screen size percentage, the other is pixel perfect anchoring.

With pixel perfect anchoring, elements perfectly balanced to be displayed in the EVO 4G will look insanely small in the EVO 3D (the joystick will be about 82.6% the real world size) and it will be even smaller on the Galaxy Note at 72% the real world size, yet larger in the Galaxy S2 (although only 5% larger)

With percentage screen size, a joystick designed for the Evo 4G is 88.8% the size in the Evo 3D but 21% larger in the Galaxy Note, still only 5% larger in the Galaxy S2.

Note that although screen sizes grow or shrink, human fingers don’t. It’s not automatically easier, nor should it be expected, for users to have the same ease moving their fingers over the more restrictive space or forced to move their finger longer distances, not to mention accuracy on games that focus on tapping elements or moving things. Even if screen size percentage was acceptably usable, do you think the player would like to see larger GUI elements on his huge screen that feel obstruct even more of the action? Most well designed GUI elements tend to be designed to be entirely obscured by fingers so they minimize gameplay obstruction beyond what you would anyways cover up with player fingers, but such proportional increase will force GUI to extend beyond finger obstruction and just feel odd.

It’s certainly doable, but a lot of people that think they are doing a great job at resolution independence are ignoring these things and have no clue how the actual experience is on a larger or smaller device than the one they own. My point here is not that it’s impossible but that it’s not as easy PC resolution independence at all, touch brings a whole new dimension to concern with.

It’s actually a bit absurd to even think you can carry total resolution independence that would work on any Android phone all the way to the Tablet (at least for a every game, some may actually work.) At some point in the physical size scale you MUST rebalance percentage of screen size usage for every GUI element, reason why many iOS developers design alternate versions of their UI for iPad and iPhone.

Main reason iPhone developers don’t bother with resolution independence is because they don’t have to (to a point.) iPhones come only in one screen size (so far) and 2 resolutions, with one being exactly 50% smaller than the other allowing for easy resizing of elements without worrying for disproportionate pixilation or blurring.

I support iPad, iPhone and Mac on my Bombercat game. For Mac I mostly anchor stuff, some GUI elements resize dynamically with some blurring (but on computers I can use very high resolution images without much memory concerns) and others just remain pixel perfect. On the iPad and iPhone I must make dedicated exceptions to make sure relative touch only takes the percentage of the screen is realistically usable, plus then display the GUI elements that only cover those areas.

I have considered Android support sometime in the future, but like most iOS developers that look enough at the market, I won’t until I have a title that makes money in a way that justifies buying into the environment (Android Pro + development testing devices) without having to pull extra money out of my own pocket. As I point out here though, it’s something I given serious thought to already.

 

Its a pain in the beginning but once you get over the hurdle and learn to design everything with all the possible variables in mind I find its actually easier and more intuitive to build presentations that are automatically dynamic. You can get away with a lot on larger, desktop screens, but with mobile any weaknesses or mistakes with presentation become magnified.

Edit:

Wanted to add, building your game for desktop then refactoring to mobile is a huge mistake. I thought the same thing that it would just be a little work and didn't matter so much. I ended up starting a new project from scratch and rethinking almost everything.

 

I'm using NGUI, it actually works fairly well for making something resolution independent. I have the same UI running on my Galaxy S and Nook Tablet with no problems.

 

I think what tharsman was getting at is resolution-independent gui does not always make for good gameplay. If a virtual joystick is the size of a quarter on a handset, on a tablet it's going to be the size of a soda can. I can't imagine that being very fun to play with.

 

I also have to acknowledge some games can scale just perfectly without much trouble. Fruit Ninja is a good example of a game that in theory can be just resized to work on the larger screen. They still made some GUI elements smaller for the iPad, much smaller than they would had been with pure pixel perfect anchoring.

... I guess it also an example of "just because you can does not mean you should." Resizing would had been just fine, but they felt it would be even cooler if you had less obsrusive GUI and more game area.

 

Tharsman, I see why you have come to those conclusions, but you are thinking from a lazy approach, just like most everyone else I discuss this with. I would say that at least 50% if not more of the most popular games on both iPhone and Android use nearly the exact same UI assets and scale it to the proportionate size. In fact, most games I've played on my tablet just set the resolution to 800x480 and don't worry about it at all.

I have done several tests with all the devices we have at work, and just making everything pixel perfect works very well for most devices. We don't have an of the low-end 480x320 devices (but we can test on the iPhones). Almost every Android device is either 800x480, 960x540, and now with Kindle Fire 1024x600. 1280x720 is quickly rising up. None of those resolutions are drastically different from each other, so most everything works fine. The Galaxy Nexus is the only issue I've run into where the buttons are just too small, and so a scaling calculation may need to come into play (thanks 3.5 for access to the DPI).

Anyway, feel that Android users would be much satisfied just to get those great iPhone exclusive apps, and would not be concerned that the button is a little too large because their screen is big. Also, I do not feel that Android users would view your game poorly if assets were "blurry" because of stretching, because almost all games on Android are like that. (Though any developer will see it as less than ideal)

I am not saying any way is correct or not, and I realize that porting over to another system is costly and that should not be overlooked.

 

Interesting thing, points of view. I would say the examples you give ARE the lazy approach. My notes (if you did read my admittedly too long post) together (in isolation points can be misinterpreted) are that I would refuse to go that lazy road and so do many developers. iOS developers with heavy Mac backgrounds tend to see GUI design as a sacred art that cant be left to resizing. I would also wish very bad butt pains to the developer that actually attempted to make my iPad run at iPhone resolution stretched up to the full screen.

Unfortunately, most phones are stuck on 2.2 or 2.3 if not lower versions. Same goes for the best selling tablets, the Nook and Kindle Fire.

It's not always about users caring as much as the developer caring. iOS developer is full of developers that pride themselves on good design, and some of us (I consider myself to be part of that group) just grind our teeth if we have to do such sacrifices. In fact do a few searches and you will find many iOS sites criticizing the conformist nature of Android users on what they consider "horrible interface design."

If your real question is "why iOS developers don't port for Android", that has way different answer and resolution fragmentation is just an umbrella. The real reasons are numerous, complex and interlinked (makes it hard to bullet point them but I'll try.)

Android has a fame of not making too much money. Most iPhone ports that make money on the platform tend to do so after already having huge success in the iOS App Store, that brings me to:

Most iOS Game Developers don't make that much money, even when the games are good. Without making a lot of money they cant justify the cost of doing the Android port, and that brings me to:

Most iOS game Devs also happen to already own an iOS device, they developed for it because they owned it, not the other way around. Jumping to Android means buying an Android Device. At least you likely need a regular device and a tablet (if you want to pursue those.)

Now, if you are an Unity developer there is also the cost of the Android exporter to be factored in, depending on your preferences and game features that's either 400 or 1500 bucks (I would not go Basic personally.) Unity makes it a bit easier to port but has that cost barrier.

If you are not a Unity developer and made your game the old hard Objective C way, then you have a code base you can't easily port to Android and the port may mean entire rewriting of a game that already may had not made enough money.

Also there is fear of support. The App Store pamper us. If a user has an issue and wants a refund, they deal with Apple and they handle it. If that happens in Android and the user has the issues after the 15 minute window, the developer must handle any refund process himself (and am not sure if he is also forced to refund 100% out of pocket with Google keeping their cut.) Due to the variety of CPUs and graphic chips out there, it can be hard to know exactly what device will run your game so you never know how many of these cases you will get due to accidentally saying your game runs in the wrong hardware (or users ignoring the filters.)

And finally, there are many true iOS Fanbois. I hate the term but they do exist and despite their blind loyalty they do tend to have amazing taste and do amazing products. Since they hate anything that competes with Apple many of them will never port any to another platform but specially not to Android (since it's THE rival.)

One point I wont fully cover is increased piracy rate, something that may not be a big pain but sometimes your game uses server resources where piracy can be a huge hit.

I'm sure there are many more reasons why specific iOS devs will not even consider supporting Android.

If I had enough reasons to think that my game would make back at least $5000 in the Android Platform, I would tomorrow buy the Android Pro, some 1.5 year old Android Phone (I would want to aim to devices introduced around then) a Kindle Fire and a Nook and start working on the port of Bombercat ASAP.

Although there are also problems with file size. Kindle Fire I hear has no file size limit but the Nook has a limit and so does the Android Market (although I hear they will host some alternate file you can download later... it's still extra encumbering on the development process... why not just let you sell any file size and require wifi for the large apps?)

Unity would make most the headaches of porting non-existant so my only barrier would be just one of money and time, so I'm not entirely opposed to the idea, just cant justify it economically right now.

If my next title (or the next or the next) is successful enough for me to be able to gamble the costs without any pain, then I will surely get started porting every single title I have made (so far that's only two and to be honest, Chicken Panic was an experimental thing.)

 

Off topic but wanted to add: Loved the game in your signature.

 

480x800 is the general res and is on most phones.

 

I completely understand what you are saying. It is very comforting to know that some iOS exclusive developers (at least one so far!) actually does their Android research, and I'll admit that I haven't been doing this for too long. The studio I work for has all the licenses and devices I will ever need for any of my after work "research", and so I frequently forget about the costs of all the test devices, though I am sure everyone has at least 2 friends with Android phones they could test it on.

Thank you for this discussion! I feel like I understand your point of view perfectly. After I got done reading I felt like we actually had a physical conversation over lunch....It's all to unfamiliar to experience that over the internet these days.

To clarify, my intent of this thread really was only about people refusing to make games for Android because they'd have to redo their UI, and I wanted to say shame on them, but what you say is understandable, and even though they don't say it, people's reasons extend beyond UI and that's good to know.

Oh, and thanks for complementing my game, I am attempting to make a mobile version of it that is far more deep (aka a full game) and I hope you like that too! It will be for iOS and Android

 

Welcome to the thread! That was mentioned earlier. I can't expect everyone to read our long posts, however, I definitely recommend it as Tharsman has been quite informative and pleasant to talk with. (Sorry I can't say the same for myself )

 

@Ayrik Look forward for that game to be complete. Looks very promising.

I would like to note that some developers have valid reasons to even think just about the UI. iOS gives a lot of extremely advanced graphic libraries that are much simpler than OpenGL that can be used to do gorgeous UIs with little effort, something you are likely to leverage if you are doing native code and no Unity usage. For those porting UIs can be a nightmare as now they have to accommodate the entire UI drawing code themselves, settle for something a bit more rudimentary, or force a UI system into their custom made engine.

For Unity users that’s a non-issue though, but not every dev you ask is going to be using Unity. Also, non-games use a lot of OS provided controls. One of the biggest complaint I hear from some devs that have ported non-game apps over to Android is precisely the complete absence of equivalents for many controls their apps depend on (don't ask me which, I only make games on Unity never done native development.) So for non-games, UI redesign can be the #1 and very valid reason for developers not to adopt Android.



As for android owners... that’s an... issue. [Tangent]There are articles around the web that pinpoint the market dominance of monetary exchange on both app stores about 85-90% going to iOS and 10-15% going to Apple. That’s a huge ratio that’s too disproportionate given install base. I see Mac press always just either dismiss it calling Android owners cheap or other strange theories. As someone whose wife had a Samsung Gravity S, I say the issue reason is phone types. [/Tangent]

Everyone I know that has an Android device owns something in the line of the Samsung Gravity S. It's garbage. It's a dumb phone with Android in it. We even attempted installing Angry Birds on day one and we were not able to because the memory was not sufficient. The thing is so cheaply done it can’t even accommodate a rather basic game. Other games we installed just would not run (can’t remember now the titles was a while back.)

So even if Android is widespread, I know no one with a game capable Android device.

That brings me to another thing I would like to see from Google. They do list information on resolution and OS <a href=http://developer.android.com/resources/dashboard/platform-versions.html>"fragmentation" in their dashboard page.</a> Thanks to Unity, I don’t care much about OpenGL versions, or installed Android Versions. What I want to know is graphic chipsets being used, ram amount and storage space. How many of the Android phones out there being used actually can run a game I make with Tegra chips in mind? How many devices can even fit a 400MB game in app memory or have 100MB of ram not reserved for OS use? Those are things that may encourage many devs to pursue the platform. They may make the platform look weak in some views and that may be why Google does not show those numbers, but they also make it crystal clear to devs where they have to set lines while developing games for the platform.

 

I guess most the people I know are tech savvy so they all have nice phones. Though, up until about 2 weeks ago I was living in the dumb-phone world, too, so I can't say much. All I have to go on is the current top grossing list in the Android Market and Amazon App Store (why do they all start with A's? lol) and see what's up there to agree with you. It's full of poker, ville games, facebook games. Until you get to about 30 when it moves into better games like Zenonia, GTA III, and Minecraft.

 

Well this not rocket science: the best chance you have to make a buck is iOS (10:1 to Android). That said, the likeliest outcome is that you will make more or less $100 from your mid-range, generally pleasant, decently polished iOS effort. It leads to consider leveraging the risk to others while you work as a contractor (developer, artist, what else) for them.

 

I do know a few people with nicer Android phones, (older brother for one) but none living in a commuting area (brother not even in the same state.)


It would also be cool if there was anything like the iPod Touch for Android. There is the Galaxy S Wifi but that starts at 200. I know that’s the same startup price for iPod touches BUT for that same price I can get an android Table (Nook or Kindle) making the Galaxy S wifi feel a bit expensive.

Google should help subsidy on that thing with perhaps 2 or 3 year developer program contracts or something. Would be very smart for them to tie up developers for a long time and giving them the device for development purposes.

 

Do you have anything to back that up with? Because we've released several unsuccessful games on iOS that did not have a return on investment for our clients, and it's not because they're not good games (see Cyber Defense), while others do OK, but most do not do well. I'm not saying Android is any better, but I have no experience in that area, do you?

Are you talking about the Galaxy Player? Seems pricey like you say, but I'm sure it's built a little better.

 

http://tech.fortune.cnn.com/2011/05/27/why-its-harder-to-make-money-on-android-than-on-apples-ios/

 

It's hard not to make at least $100 in the App Store. With my "experiment", Chicken Panic, I did a huge F***up. I had a bug that prevented the game from reporting high scores to the leaderboards or even record them locally. Since the game was a high score game I considered that a crippling feature and removed it from the app store the first day. Big nono: I lost my chance at spending a week in the new section, by the time I fixed the bug and returned it to the app store the week had gone by and without purchase history it faded out into obscurity. Did $66 (between sales and ad impressions.)

And the game, seriously, is extremely simple. I did it over a week of casual toying around in Unity and have not updated it since release. I'm nearly sure had I allowed the game to remain online despite the bug, it would had hit the $100 mark already.

Nothing to call home about but that was the range GiusCo said you may be able to hit.

Apparently they are having some branding redundancy going on. The first instance I saw of it was this page for Galaxy S WIFI BTW did hunt a bit and noticed I may be able to get one for 175 at Amazon. May give it a shot.

 

One trusted analytics source among devs is http://blog.flurry.com/ and they still report a very recent, neat 4:1 cross-platform revenue proportion iOS:Android

In my much more limited experience this is about 10:1, but we (a bunch of hobbyists plus a few focused indie devs organized as a network) are not using ads.

 

Back on thread title topic, the problem on Android are f***** tablets.

The OMNIpresent control bar below, scrap your effective game video res to something like 1280x748, sometime, even worse,
the tablet(also Samsung) has DOUBLE FIXED control bars, stripping away also something in the width !

This is crazy.

Unless you do ALL in 3D, and DONT use pixel positions hence GUI elements or GUITexture GUItext you will get a lot of problems with your app.

I really hate this approach of the various manufacturer, each one decide for each very own resolution, with the control tab SIZE eating less or more on this or the other tablet.

This is absurd !

 

In my experience its fairly easy to make a few 1000 but then again it doesnt matter because its still not that profitable.

That is the problem that isometric gui looks like ass but otherwise you are stuck trying to handle all the resolutions with pixel prefect.

 

+1!!!

This sir, is a well written response! Kudos to you!

Gigi.

 

Been answered already. Dozens of threads. Search is your friend. IOS has ~90% of the $$ revenue. Android has ~10%. Considering the vastly larger number of Android devices, that's ... surprising. One stat I saw shows that 25% of IOS users spend $$ in the app store, compared to 5% of Android users. Both sets of statistics are born out annecdotally (sp).

Gigi.

 

Since I been porting Misu Misu Kaboom for Android, I think I should post an update on this.

For 1) I had to entirely rewrite my GUI logic to be able to even start testing on Android. Given the resolution differences I just was not able to use the built-in GUI calls since they become smaller the higher the pixel density and larger the lower the pixel density.

With the iPhone 3gS i simply hardcoded an exception to render everything half the size. With Android, there seem to be some API to get the DPI of the device but it either is not working properly through Unity or devices have a very poor implementation. So now my entire GUI is 3D elements that automatically scale with the screen. The code also ended up being much more efficient but that’s heavily due to the new structure I approached during the rewrite. GUI calls are also slow anyways so I get a small boost in performance for doing it this way anyways.

I still get the issue of "large" elements on tablets, and the way I addressed this was by making the visual elements much smaller. This does have the issue of elements perhaps being too small on phones, but despite the visual size, I am giving a huge "aura" of input to all buttons and virtual joysticks so the small elements end up doing simply a feedback job of telling the user about where to aim their fingers to. Nearly the entire left side of the screen is dedicated to the joystick, while the buttons at the right actually have overlapping auras (that make it possible to jump and shoot at the same time.)

This has the side benefit of doing less screen obstruction and may end up doing the same small scale input in the iPhone later.

I can see this being an issue in overly-control heavy apps, though. If you made an app (not necessarily a game) that has a lot of links and buttons close together, this aura approach may not be viable.

I am not sure how long I spent doing this... 2 or 3 weeks maybe? If I only use this code in this game, it may be a waste of time. If I reuse it, then it may be considered worthwhile (and I plan to reuse it.)

At the end of the day, this is working. There are at least two compromises:
Visual fidelity (no pixel perfect gui, but offset by wasting a bit of memory and hoping you only scale down and never up)
Fixed proportion visual controls.

They may be worth it. Even at the worst case the code I wrote should be useful. Also important: there are strong rumors that Apple is working on a small iPad and a larger iPhone. The rumors for the phone are odd but have solid backing from people with credibility. If true the aspect ratios will be changing.

Adapting for a flexible interface, despite the compromises, may make it easier to handle anything Apple tosses at us in the future, not to mention making PC ports a bit easier to handle (even if virtual controls are irrelevant in the PC.)

It WILL add extra planning to new projects and complexity to every project, but sooner or later we may have to deal with it in the iOS world anyways. May as well be ready, I guess.

Edit to add:
If you have an android device you can give it a test run here:
http://dl.dropbox.com/u/10944097/MMKARM7.apk

Keep in mind it's still beta!

 

It's an old thread, but I found it very informative and because fragmentation is still an issue...

These rumors came true and now we have 5 different resolutions for iOS. (6 combinations if you also take the physical size of the iPad Mini into account.)
And did you notice that the 9. most used resolution for Android is still 320x240 (2.8% and increasing 06.2013 it was 1.8%, see Unity Stats)?

I've created an Editor Extension called xARM to reduce the effort and time (=costs) necessary for build a resolution independent GUI or for porting it to another platform.
With xARM you can see how your game looks with different resolutions right in the editor.
You should have a look at it (more info).

 

Interestingly my tone has changed a bit since that last post.

Today, if you have a couple or two couple hundred dollars to spare, I would suggest you start developing for android first. For one, your project iteration will be way quicker. You can get at least two very different sized android devices for very cheap without contract too, as Android Tablets are very cheap and there are some prepaid phone options you can use to test the smallest sizes. Just try to make sure you get something with Android 4.0 or higher.

I would recommend targeting 4.0 and higher too, because by now, users stuck on an older version of Android are also likely the kind of users that handle their smartphones as fancy dumb phones and mostly never buy or download apps.

Don't hunt down for expensive tablets/phones, you want low end devices that can run 4.0, to make sure your game runs on those slower devices (I keep seeing posters here ask about the fastest possible device to test with, when they should instead be looking for the slowest possible device to test with.)

If you make your game for android first, and design it to take account of varying screen sizes and resolutions, you likely will end up with something that very easily ports to iOS once you are done, even if apple starts going for newer aspect-ratios. Biggest disclaimer is I still would hold and launch iOS first, or simultaneously, or delay the android release by a week or few days after the iOS version.

I strongly recommend you keep varying screen sizes in mind and offer options for players to resize virtual controls, if applicable.

I also suggest you look at this thread. You will notice that for every dollar the author made on iOS, he made about 52 cents on android. It's less, yes, but that's still about 33% of the combined mobile revenue. That can add up to a lot of money if you are successful.

BTW, by now Apple no longer supports the iPhone 3Gs so the 320-by-480 resolution for iOS is no longer something you should worry about. Even when it was supported I saw very little activity from users that were still running those devices.

 

I'm pretty sure that's not true, as recent as 2 months ago. I support it in my current apps and will again, in a week, when I make another release. Oddly, the 3GS runs faster than a vanilla 4 iPod.

I look forward to dropping both soon with iOS 7.

Gigi.

 

What's wrong with dynamically scaling based off the devices screen.width? With the ratio of the original image?

Not perfect but it's far better than not doing.

 

I said *I* dont see activity, unless you are saying I'm lying about that. Apple also no longer sells it and they are not supporting it with iOS7. Not sure what part of what I said is not true.

Right now 3Gs accounts for less than 3% of my total (all time) users and at it's peak it never got to 5%

Your millage may vary but what I said is certainly true.

 

Yes, if your GUI can handle the Android fragmentation, iOS shouldn't be a problem. But if you are targeting Android and iOS from beginning, why separate their resolutions?
I'm still working on my first game, but for me there is a bundle of resolutions (all iOS's and most popular Android's) my GUI must handle. The platform doesn't matter. Only the width and height. If the GUI is working on all targeted resolutions you can still focus on some and give some extra love.
Focusing on some resolutions (like iPhone and iPad) in the beginning is imho a big mistake. I did it first and realized quick that switching resolutions messed everything up. While editing you have to keep an eye on all resolutions (thats why I delayed my game and created xARM).

Isn't it best to publish whatever is ready first? I would also try to publish the iOS version first, because it will probably make more money. But if the Android is ready first, why hold it?

Do you have some experience how many players (mobile) change such settings? I fear the most won't expect such a setting or understand and change it.

Unity Mobile Stats (08.2012) for 320x480
- iOS: 2.2%
- Android: 8.7% (4. most popular)
So I still worry about this

Here in Germany we have a saying "Traue keiner Statistik die du nicht selbst gefälscht hast." (Don't trust a statistics which you haven't faked yourself.) Unity Stats aren't faked, but why is iOS 320x480 at 2.2%? May be most of the million devices aren't used any more, but may be most Unity developers do not worry about this resolution (because it seams so rare) and so less games are published for this and less games can report this resolution back to Unity while running...:roll:
Self fulfilling prophecy...

 

If you use things like Unity's built in GUI (that seems to be resolution dependent out of the box, unless you do some scaling tweaks) and target iOS first, you may feel very tempted to target specific resolutions. Its one of the reasons it becomes too big of a burden to port to android post that fact. That a reason I say target Android first; and test with at least two varying resolution devices; you will be forced to do your work entirely resolution independent without temptations.

The success of all versions will be dependent on how much noise you can generate. Also, if you have a quality game, its easier to create a bigger splash on iOS than on Android thanks to Apple's weekly features. Apple is also much more likely to feature you if your game is not available on other platforms, I don't know if they actively do this, but the fact that they had "iOS Exclusives" features in the past point that at lest sometimes they do search other mobile markets to see if these games are already available there.

This is no magic or proven formula, but it sounds to me like a good strategy:

Release on iOS, get your feature (if), immediately unleash the Android version. Players will grab the game on that first week, and iOS users also have Android friends. When one asks "what you playing" you likely will want the android friends to find it. The same may also hold true the other way around, but you maximize your chances by having both things come out at the same time (and again, increase chances of Apple feature by not being on Android during the review process.)

(I'd also aim for the Mac App Store)

I didn't add such feature to my game, but wish I had. Use of such features is likely going to be as good as the visibility of the feature. Regardless, if implemented right, your gui should be able to scale and stay anchored to the right screen areas without more than a couple days of coding, a week tops if you have a big spaghetti code base (it happens.) Implementing such a feature may save you from some negative feedback and accommodate players with larger hands or poor eyesight.

Those numbers for iOS seem very close to what I have, I actually have slightly higher with 3%, but there may be some rounding going on there. I made 100% sure I supported the 3Gs when my game launched (and still, although I have not pushed an update in a long time.) The truth is most smartphone users that actually spend money on apps will upgrade their phones every 2 years. Personally, I only care about users that actually spend money.

I cant speak for Android because I (stupidly) messed up my analytics code on that version and never collected any data.

 

Worry about it? No. Support it? Yes. At least for now. I wanted the earlier poster to know that it may still affect him, as it will me, when I submit an update to the App Store this weekend. After iOS 7 goes live, well, ... maybe I can consider 320-480 a thing of the past, like floppy disks.

Gigi.

 

Thanks for sharing. I will keep this in mind.

For Paid: yes, for Free2Play: doesn't matter, but again for Free2Play + IAP: yes
Right?

I (targeting Free2Play + IAP) find it hard to exclude players by device, by OS version its more easy, but may be that isn't enough...
Currently I would say any resolution used less then 1% isn't worth testing.
Where would you draw the line?

 

There seems to be a big confusion between Free2Play downloads and popularity of Free2Play games. At the end of the day, the people that spend money on Free2Play games are those with deep pockets, and I have not seen any statistics but dare bet most of those users upgrade their phones too (its not easy for them to withhold temptation.)

Now, for a F2P game to get reach, you have to make it go viral. The goal of F2P games is that they will land on lots of players hands, who may not spend a dime on them.

Quote from the free to play wiki:

If you happen to be making a game with very limited appeal (a first person shooter, a side scroller with virtual controls, etc) you may already be limiting your audience to a sub-group that also cares about hardware updates. Not every game is the same, and maybe a game like Candy Crush may feel every player counts and support aging devices like the 3Gs and low res devices.

Mind you: I'm not saying you exclude those players, but I think it may not be worth too much trouble if you finding it hard to accommodate a GUI on such a low resolution. If you find your adaptive GUI works at that size, great. If you find it starts breaking and looking awful at that size... well you may want to just not spend much work fighting with it and let it go, either releasing it as is or demanding higher res devices.

This is starting to go into a different path, but you must keep in mind that F2P does not work for everyone or everything. Some games just wont fit that model, in fact, the target audience to some of these things is much more likely to hate your title for being F2P.

Think about this: how successful you *know* you will be? Likely chance is you don't. Every release is a gamble. Every day you spend fighting with the ultra-low resolutions is a day you don't spend working on the game as a whole. You could work on something that will benefit 100% of your players, or something that would benefit only a potential (not certain) 2.5% (on iPhone) and there is no warrantee those users with such low end devices will ever spend a dime on IAP.

Again, if you can streamline your support of such device to take next to no time, go for it, but if you notice you spending too much time trying to get things to work there, it may be best to not support those low resolutions and maybe revisit in an update if y our title is so popular that an additional 3% would mean thousands and thousands of dollars in extra revenue.

 

Hmm weird.

Isn't there a way to know the size of the screen? You should be able to know the resolution, right? With Screen.Width... but how do you know the real size of the device's screen?

 

Yepper. You can then base the height off the width of the screen using the ratio of the orig image's width/height, can then position wherever you want on the screen, top center, any corner, or wherever in between.

 

You can easily get the pixel size, but may not be able to easily get the inch or centimeter size. Without that you don't know how big you making the elements.

I have not tried it on Unity 4, last time I tested a function that supposedly did that (giving me the DPI) in 3.x it did not work (at least with any of my test devices.)

 

There's a Screen.dpi, but I don't know how accurate it is on various devices. I guess you can multiply the pixel dimensions by that to get the physical screen size? (EDIT: I meant take the pixel dimensions and DIVIDE by the dpi of course)

 

Since my neighbors stole my iPod touch 4th gen and I have now only a PC similar to a Windows Surface and my old MacMini the Windows Store and the Mac App Store will be my first targets. I'll buy a new iPod touch and target iOS after I leave this neighborhood.

My main goal is to write a fun, device independent game so I will be avoiding excessive details, bells and whistles.

 

Pretend you have a texture 800px wide by 600px high.

600 / 800 = 0.75

You set the width to Screen.width and height to Screen.width * 0.75f

 

I'll be glad when Unity GUI comes out. As far as creating original art: be reasonable! create for BlueRay resolutions (1920x1080) and let Unity and the various OS operating systems scale accordingly. We ain't Disney Studios after all!

 

Do they also hate it if its an non-casual game and F2P but not Pay2Win?

I saw "The Temple Run story" (Unite 2012) a while ago and found the strategy F2P+Ads+IAP a good solution for my game (board game (kind of) with local and async online multiplayer, similar to Hero Academy (which is also F2P+Ads+IAP)).

I hope like poker. The better strategy wins in the long term.

Back to topic:

You mean: start with less supported devices and add them later, right?
Do you have experience with terminating support of some devices/OS versions (e.g. drop support of iOS 6 when iOS 7 is released)?
Doesn't that drive the players angry?

Edit:

++

Or create SD/HD/UD atlases and switch by resolution (height or width).

 

I'll have to watch that later today once I'm off the office (all media streaming blocked here) but I would say Temple Run is a rather casual gamer's game.

You can have some success with less-casual, more niche, f2p games, but do count how many are out there and actually making lots of money. You may be able to handle things and make players want to spend, but you have to REALLY go viral for that. Team Fortress 2 is a perfect example, a hardcore-ish game that you never need to spend a dime, but you are offered a lot of appearance stuf for money. Some people that really get into it will shove money because they got hooked on the free game and decide to pay.

Leage of Legends is another one. For the most part, the very hardcore gamer seems to accept F2P where the buy stuff is entirely optional, 100% (like appearance or wow-like pets or other plain gimmicks) but those games can be big gambles, they require lots of polish to become strong contenders.

Just don't dare set time-gates (and those are what make F2P insanely profitable) on hardcore gamers.

I mean the other way around, start supporting the most used devices, expand to less used ones later (apple wont let you publish without support for the current devices anyways.) I would say: never remove support for an older device, unless the game is absurdly popular that it demands continuous updates. If the game is "meh-popular" then, if you find yourself you cant continue support without killing support for older devices... it may be time for you to get to work on a sequel, or separate title.

 

The best strategy is releasing MORE products. As the only metric demonstrably tied to success is the number of products previously released. So, fail fast and often, to develop wisdom and experience, which when combined with tenacity and grit is a good strategy for winning ... eventually.

Gigi.

 

This is 100% true.

You think Gameloft made a game and laid back to relax? They got where they are by cranking up titles continuously and building a huge catalog of titles. Constant app updates are things that should be reserved for very rare gems that are extreme money-makers. You should make a title, put it out there, and start working on the next thing. Only stop and go back into maintenance mode if that previous title was an absurdly huge success, even then better to hire someone to maintain it while you work on more new stuff.

 

That's been our motto for a while. Build, release, reflect, build another, release, reflect. And recently, we noticed that our 3rd product had the oddest statistics. It never spiked, and it never long-tailed - instead, it's grown steadily over time, to about 200 downloads/day. Given its popularity and its low conversion rate, we decided to go back and kick-it-up a notch.

With luck, I'll submit it this Sunday and we'll get to see what happens when a KICK-BUTT update goes out to 40,000 users at once!

Gigi

 

I'd really like to know what you guys are thinking about that video.