So, how do you know your mobile specs?
Monkey Archive Forums/Digital Discussion/So, how do you know your mobile specs?
| ||
| Still plodding away on PC and Mac, which is fairly straightforward as far as specification is concerned. Easy to find out how much graphics memory you have, easy to find out your CPU speed, and all the rest of it. But how do you find out the specifications for, say, an iPhone 4? Or a Galaxy S2? Or even a lower-end Android phone/tablet? I figure this kind of info is vital when developing for mobile as standards will vary a lot and you might not want customers with crap Android devices to try your game and give it a bad rating just because their hardware isn't good enough. |
| ||
| I normally look on GSMArena, they give you heaps of info and you can even compare devices: http://www.gsmarena.com/lg_optimus_one_p500-3516.php |
| ||
| I should probably expand the question a little, to highlight what I'm really getting at. Suppose you've got a game that runs great on a Galaxy S3, but not at all on an el-cheapo "Android" phone from the bargain shelf in Lidl. This question is aimed at the iOS market as well as Android, but are there ways to restrict installation to hardware with a minimum specification? Otherwise you'll get all the folks with ancient 1st gen Android Crapola phones posting one-star "meh, it doesn't work and my phone is brand new, only 6 years old!" reviews. |
| ||
| With what I've noticed of the playstore lately it will notify you if the handset you have is compatible or not with what you are trying to download. Basically when you're setting up your device and link your google account to it, when attempting to download something on the playstore it will let you know if it is compatible or not. |
| ||
| But how does Playstore know what the game requirements are? |
| ||
| It pulls the information about your app from your device; what access/permissions have been granted etc! Other than that it's about all I know about the low level inner workings of googleplay. |
| ||
| access/permissions? Explain? |
| ||
| For instance you could end up with bad reviews for allowing your match 3 game to access parts of the handset that it should have no reason to access. An example would be allowing your game to access contacts lists, recent calls etc when it doesn't need to. So many times I've seen a great game on android get absolutely crappy reviews because the developer has allowed the app to access areas of the phone that it doesn't and should not need to. |
| ||
| Amon is talking about the AndroidManifest.xml. With the xml you specify access and permissions which your app needs. http://developer.android.com/guide/topics/manifest/manifest-intro.html In there you can tell Google Play that your game will only run on large screens, SDK version 13 etc. |
| ||
| Bloody hell... aside from writing a game, that looks like a chore in itself. |
| ||
| If you're interested in scaling the game on as wide a range of devices as possible, you're gonna have a bit of work to do. The way we have it setup at work is: Build a list (XLS) of presets for GPU ( usually 6 presets ), CPU (single-core, dual and quad) and MEM (256, 512, 1024+). Then, because devices have the bad habit of not reporting everything, build a huge list that matches GPU names and sometimes device names to the presets. If you can't find the GPU name, fall back on CPU to actually give a hint of the overall performance and maybe use the amount of RAM as well. Note 1: If you are fillrate (or pixel shader) bound, then consider the performance-per-pixel of the GPU. Example: iPad2 is better than iPad 3 at this. Note 2: Mali 400 MP is the devil itself. There are TONS of diferent implementation of this GPU alone: MP2, MP3 and MP4 refer to GPU cores, there's also different frequencies (250 up to 450 MHz) and there's no way to know unless you consult GSM arena or some wiki, and finally there's different mainboard architectures that permit higher fillrate and so on. So you can have a really Crappy Mali-400 (low-end Androids are super-fond of this one), and mid-high end ones (Galaxy S2). On iOS you cannot restrict your app per-device. Best you can do is per-OS version. That way you can eliminate 3G by restricting to iOS5+. You can also restrict by features: Compass (iPhone/iPod 4+), Camera (gets rid of iPod 4 in case you need more than 256MB RAM), etc. On Android you should have a lot more options of restriction, but at some point its not even worth bothering. The downside is that some people may rate the app negative due to performance issues on low ends. Another thing that's pretty uncool when it comes to scaling: resources. If you want to have nice graphics on iPad3/4 and Nexus 10, you're going to need very high-res resources in most cases. Those resources would slow down low end devices completely. This is why you should have different resources for different resolutions (although it will increase the app size). Sorry for the wall of text. May it be of help :) |
   |