pruett: hi, folks.so, this is building aggressivelycompatible android games. and you're allin the right spot. great.nobody got [indistinct]. hi.my name is chris. i am the ceo of a companycalled robot invader, which isa mobile game developer for androidand other mobile platforms. and actually,up until about a month ago,
i was a google employee. i workedon the android team as a developer advocatefor game developers. my role was basically to goto game developers and say, hey, you should makea cool game for android, and here,here's how to do it. i'll help you do it. if you've been to previous ios,you might have seen me or if you ever, you know,watch io sessions on youtube,
i've spoke a couple of timesabout a game that i built while at googlecalled replica island. this talk is not aboutreplica island. this talk is about games that are aggressively compatibleacross devices. but i think that replica islandfits that description and so i'm going to reference itin my talk and try to, you know, use itas a case study of how a game can runon everything.
so like i said, the topic todayis device diversity and we all knowthat there are a lot of android devicesout there, and guess what? the common factor is that on every single oneof those devices, every single oneof those devices is owned by somebody who wouldlike to play video games. and they would probablylike to pay you money to play those video games,
and that's why you should beinterested in this. replica island,i released about a year ago, it's getting close to 2 millioninstalls at this point. we're not quite there yet.but it's doing pretty well. the ratingsare pretty good. and i think that,um, part of the reason that it's beenas successful as it is is that it runson all of these phones. you know, we've gotover here on one side,
we got the g1. that's pretty muchthe minimum spec. i put the nexus sas the high end, although they arevery quickly phones that are coming outthat are faster than that. but that's the range, right?it runs on all those phones. it doesn't just run onthose phones, actually. it runs onall these phones too. i tried to get this slideto go faster,
and this is the maximum speed that keynote would allow meto show these phones to you. there's a lot of them. there's like, 160 or something,the last time i checked. and actually, that data pointis probably three months old, which is an eonin this industry. it runs onall these devices. and actually, this isnot an exhaustive list. there's quite a number ofandroid phones out there today
that replica islandworks fine on. oh, yeah. it runs on tabletsand tvs and stuff too. i didn't really plan this. i, of course, i wantedthe game to run on everything but when i wrote the game, you know,it was designed for a g1. that was the platformthat i was building it on. it just turned out that i madesome correct assumptions
and because i madethose correct assumptions, it was very easy to runon all devices and in a couple of cases,extend what i'd already written to work on all devices. so today i'll tell you aboutwhat those assumptions were and how you can replicatethat on your own games. there's also a bunch of stuffthat i did for replica island that isn't relevantany longer. for example, i spent a long timeon java optimization.
java optimizationmatters a whole lot if you are targeting a g1. it doesn't matter very muchanymore for any other device, and there's two reasonsfor that. one, java has gottena whole lot faster with different versionsof android, and number two, the phones havegotten a whole lot faster. actually, i'll saythree reasons. number three is,how many game developers
do we actually havein the room here who are writing games right now? okay. okay.that's a pretty good number. how many of youare writing them in java? how manyare using dalvik in the java languageto build your games? yeah, that's right. how many of you are usingc++ and ndk, right? okay. so, that's why java optimizationdoesn't matter any longer.
and i'm not gonnatalk about it. dalvik is really fast. if you want to do that, you can. i'll skip it in this talk. before we start talking aboutdiverse diversity, you need to understand how the android compatibilityprogram works. so, let's do anothershow of hands. how many peopleactually knew
that android hasa compatibility program? okay.that's not bad. what? 30%, maybe? yeah, android hasa compatibility program. and if you want to buildan android device that's considered compatible,you have to pay attention to it. this is an open sourceprogram. you can go check the spec out,you know, online. it's compatibility.android.com
and you can read throughthe whole spec. and any android phone that'sgonna be considered compatible has to meet that spec. it's pretty detailed too. i mean, it givesa device manufacturer areas where they can makemodifications. like, say they want to havea different sized screen. well, there's a rangeof screen sizes that you can support
and still be consideredandroid compatible, but it goes intoa lot of detail about what you canand cannot do. and the purpose of this specis to require that peoplewho are building phones to build phones that aregonna run applications for android marketthat are written correctly. so, remember,i had mentioned, you know, all these phones back here?
well, guess what?they're all compatible. every single one of these has met the androidcompatibility spec. well, how do weenforce that? right? how does--how do you knowif a device has passed this arbitraryopen source spec? well, google providessomething called cts, which is a compatibilitytest suite. this is about20,000 plus tests
that a device manufacturercan download. it's also open source,can run on their device and get output from. and that output basically says,yes, i passed, or no, i did not. and if there were failures,it says, well, you screwed this up,and you screwed this up, and you screwed this up. and if the oem doesn't go backand correct those failures,
then there's no chance for themto access google services like android marketand gmail and maps. these services are not partof the android open source. they are given to oems on thecondition that they pass cts. so, if you don't havea compatible device, you don't have any of theseinstalled. another way to think about thatfrom a developer's perspective is that you're usingandroid market as your distribution platform,
you're guaranteed that you'reonly going to be distributing to devices that have passedgoogle's 20,000 tests that are requiredfor compatibility. so, that's the basis. that's the bedrock stuffyou need to know before thinking abouthow a single binary can be compatible withall these different devices. i'm gonna saythere's three steps to aggressive compatibility.
the first step ischeck your assumptions. i worked witha lot of developers in my role at google who hadtrouble with compatibility, and it wasn't becausethey wrote bad code and it wasn't becausethe devices were broken. it's because they originallywrote that code for some other platform, and they made a bunchof assumptions that were specificto that other platform.
and when they ported the codeover to android, they didn't changethose assumptions, and those assumptionsturned out not to be the same set of assumptions thatyou have to make on android. so, the first point here ischeck your assumptions. the second isfollow the rules. we'll talk aboutwhat these rules are in a little bit of detail. but the main message hereis there are rules
that you must maintainto be compatible, and if you break them you will crashon certain devices. and the third rule ismanage your spec. i'll get into a lot of detailabout that. but basically, you can tellandroid market what kind of requirementsyour application has. there's a secret fourth rulethat's specific to video games, and i'll talk about it later,
but i'm not gonna tell youwhat it is right now. so, let's talk aboutassumptions. there's a lot of weird hardwareout there, right? i mean, there's weird hardwareout there right now. and the thing is,android devices are coming out really,really, really fast. so you can be guaranteedthat whatever is normal today, or whatever is weird today,will be normal tomorrow and something weirderwill have shipped.
and i had that idea in mind when i was working onreplica island. i didn't knowwhat was gonna ship, but i knew that it wasn'tgonna be exactly the same as what had already shipped. and i made fourbasic assumptions that sort of future-proofed myapplication for compatibility. you have to understandthat i shipped replica island, i want to sayjust over a year ago,
and most of those phoneson that mega slide were not out yet. most of those phones shippedafter i released replica island. and without me doing anything,they are still compatible. so, i'm gonna chalk that up tothese sort of basic assumptions that i made. first assumption--there'sno standard for screen size. your screen can be any sizeand it can be any resolution. now, there are requirementsin the spec that i mentioned,
the compatibility spec, that require physical sizeand density, so there's a range that you'regonna be working within, but you can't be guaranteedthat, say, all of your devicesare gonna match 480x320. that's what the g1 is. nor can you be guaranteedthat all devices will match 800x480,or something like that. there's basicallyno standard at all.
and so you need to dealwith that. and the best wayto deal with it is to allow your graphicsto scale. if you're using opengl and if you've attended my otherio sessions in the past-- you should be-- it's very easyto scale your graphics. very often, it can come downto a gl viewport call. in my case, i actually changethe gl viewport,
and i also scale the contentof my scene a little bit to match the aspect ratioof the display. you can see here that atthe 480x320 version of the game, you can see a little bitless to the right than the 800x480 version. a more dramatic example isthe qvga versus fyvga versus the game. same game, same graphics,but what i do is i look at the sizeof the screen at runtime.
i have a fixed heightthat i want to align to that i've fixedfor game design purposes. it's basically 480 pixels tallbecause that's what the g1 had. i scale everything upto match that height and then i allow the leftand right sides of the screen to grow or stretchor stretch or contract. and for my particulargame design, that's completely acceptable. allows the game to runon any device.
if i'd been using, if i'd madea 3d game that has perspective, this would have beena lot simpler. i could just change the viewportto match the display, no problem, just a matrix,no big deal. but if i wasn't using opengl,the actual android layout system has all kinds of toolsfor scaling graphics and moving things aroundand adjusting them. but i think probably most peoplein the room here are using opengl.
key message is notthat it's hard but you have to think about itbefore you write your game. the other thingthat i did correctly but i would do better next time is i shipped one set ofresolution of graphics and i scale up. and the resolutionthat i shipped was hvga. hvga scaled up on a widevga display like a nexus one or galaxy s.
it looks okay. the space, still pretty smallso i can get away with it. when you run replica islandon a zoom, you'll see it looksa little bit pixilated and that's becausepretty low resolution art is being scaled up to apretty large resolution display. so if i were smarterwhen i built this game, what i would have done is madehigher resolution graphics and scaled downon smaller screens.
ship with, say,zoom compliant graphics and then plan to scaleeverything down, you know, when you run on a g1 orwhen you run on the nexus one. that way, scaling downalways looks good. scaling up, not so much. second major assumptionthat i made was that the g1 wasgoing to be the minimum spec. that turned out to bepretty true. there are two devicesin the world
that i know to be slowerthan the g1 for games. those are the htc tattooand htc wildfire, and those devices are slowerbecause they do not have a gpu. game still runson those devices because android providesa software renderer for opengl es1.0 which is what you useif you use the emulator. but as you know,if you use the emulator, it's a little bit slow.
so, game is playableon those devices. it's a little bit slowerthan i'd like, but you know, no big deal. for all intents and purposes,the g1 is the minimum spec. for the vast majority of devicesout there, it doesn't get any slowerthan that. i assumed that opengl, yes,was going to be the fastest way across all devicesto draw 2d content. this turned out to be true,but it's a subtle point.
it's a subtle point becausethe way to draw fast 2d graphics on a nexus one might actually beto use the cpu. that's because the nexus one cpuis really, really fast. it's in fact so fastthat it can outrun its gpu for doing 2d blitz. there are actuallya lot of devices that have really fast cpusthat you can do this on. but it's onlythe high-end devices. i say the nexus one,probably the galaxy s,
those are about the two thati've tested, the nexus s. right? there are devices out therethat have real fast cpus and can--you can renderthe same thing in software faster than you canrender in hardware. but the reason to useopengl es is that you want to becompatible with every device, not just those superfastcpu devices. and generally, the gpuis the way to go.
it is the fastest pathfor rendering 2d concept. i wrote this applicationcalled sprite method test, which is open source. you can search for it if youwant to test this stuff out. but it lets you draw thesame scene with cpu and gpu and, you know,see what the differences are. i also--this ismy fourth assumption. i assumed that all the devices were gonna kind of belike the g1.
i knew that they weregonna change and be faster and have different sizedscreens, but i assumed that they weregonna have a trackball and that they were gonnahave single touch displays like the g1 and that they mighthave a keyboard or not. you know, that was totallyfalse, as we know now, right? there's a whole lot ofdifferent phones out there. and they've got a lot ofdifferent interfaces that people are gonnaplay with.
some of them like the nexus oneactually do have a trackball. some of themhave keyboards. some of them have little dinkyd-pads on those keyboards. some have really nicemultifinger multitouch. some of them are weird, likethis device up in the top left. that has a track padon the back of the display that the xperia playof course, has real game controls,a d-pad and buttons. and then there are devices--so far only one that i know of--
like the original xperia which are problematicfor game developers because it doesn't havereally any hardware buttons except for backand menu and home. it doesn't supportmultitouch. so, where do you putyour game controls? if you have a game you can playwith a single finger, you're all right. but if you are--if you're like my game,
which is--requires at leastmotion and jump, you know, how do you deal with that? well, a solution for me was toprovide customizable controls. this is a solutioni did not come to until after i'd shipped the game'cause like i said, a lot of those devices came outafter i shipped replica island. but in all of the updatesi've made since shipping have been to add morecustomizable controls. so now if you downloadreplica island
and go into the options, you can set up how you wantto control the game with a lot of granularity. breaks down intofour major spots. there's the trackball support, which is the original versionof the controls that i wrote. there's keyboard supportwhich gives me access to things like the xperia playwithout any changes. virtual pad which are for
just buttons on the screenbut requires multitouch. and tilt for devices likethe original xperia that only have single touch. and between these four, i pretty muchseem to have covered all of the devicesin the world. like i said, as far as i know,all devices out there that are compatible and haveandroid market installed you can play this game on.
the original control schemethat i came up with was designed around the idea that some displaysare gonna be single touch. so i had the trackballfor motion and i have these two mutuallyexclusive buttons on the screen for jump and attack, and that way, you never have tohave two fingers on the screen. but nowadays, you know, now we know that there'sa lot more devices out there
that have all kinds ofmultitouch points. so it's probably importantto talk a little bit about the different typesof multitouch screens that are out there. multitouch screens basicallycome in three flavors. there's single touch.right? multitouch. and then there's what i callcrappy multitouch. and crappy multitouchis what my best friend,
the nexus one, has. crappy multitouchis a multitouch display that can--that can detecttwo fingers at the same time. but when those pointersare moving, it can swap the componentsof one pointer for the other in a very specific case. and that case iswhen the two pointers cross the same horizontalor vertical axis. so the caonical problem casefor this type of display
is if you have a fingeron one side of the display and another finger onthe other side of the display and you drag them across, at that vertical linewhere they pass you may getcomponent swapping. so, your x from pointer onemay suddenly become your x from pointer two. and if you're drawing a lineon the display where those fingers are,you'll see them go like this,
which is really frustratingfor game developers because if you want to havea dual stick control scheme-- which i recommendyou not do anyway-- but if you wanted to havea dual stick control scheme, you know, that's gonna betwo fingers that are passingthe same horizontal axis, and you're gonna getcomponent swapping, and it's gonna bevery difficult to control. so you can still deal withcrappy multitouch displays.
my solution was just to get ridof all vertical motion in the fingers...you know, i have a slider that moves left and rightwith one finger and buttonson the other side. and there'sthis horizontal line that they are both on, but they never move verticallyto cross it. and so, this actually workspretty well on the nexus one. in fact, when i showed itto some colleagues
who were aware of the crappymultitouch problem, they were impressed that i was actually ableto get this to work. they thought i'd done somecomplicated heuristic, you know, to unswap my controlpoints or something. nothing like that. just made sure that there wasno vertical motion. couple of other tricksrelated to screens. the back and menu keyson a lot of devices like,
again, my friend, the nexus one,are flush with the display. and that meansif you have buttons on the right sideof the display or you're gonna usea trackball for control, it's pretty easyto slip off the track pad and hit the back or menubuttons. and that's a pretty baduser interface because usually those buttonstake you out of the game. so, for replica island,i ignore those buttons
if they happen to occurwithin 400 milliseconds of a game event. a game event is the usertouched the screen or the user touchedthe trackball. so that means if the user'stouching the screen and they slide offand they hit the back button, nothing is gonna happen, 'cause i'm gonna ignorethat back button. but if they picktheir finger up
and they put it back downon the back button, that actually takes longerthan 400 milliseconds. so the back when we read it,it'll be fine. there's no mis-clicking. you should also be awarethat these devices have really small buses,right? the memory bandwidthis not good. that means loading your textureto vram takes time, and you probably can't do itat runtime.
one solution to that is to usetexture compression. there's about four typesof texture compression in the worldout there today. there's atitc, whichis proprietary to ati devices-- snap dragon, okay,things like that, stuff that qualcomm makesmostly. there's pvrtc, which isproprietary to power vr devices like the droid. there is dxt which you'll findin video devices
like the zoom,also proprietary. there's etc1. etc1 is a non-proprietary formatthat's supported by all devices that support opengl es2.0. so it's great.you can use it. its fatal flaw isthat it doesn't support alpha. you can't havean alpha channel or do any sort of transparencywith etc1. so, some developers arereally tricky. right?
some developers have shown methat they take their colormap and they take their alpha mapand they save it as two different texturesand they put them back together in the shader. solved. okay. you know, or you canchoose to do what i did which is just not compressyour textures. i was actually able to fitthe whole game uncompressed in vram, so didn'thave to worry about it.
but if you are not like me,and you're worried about fitting into vramon all devices, you should be aware that texturecompression is device specific. now, there is a little solutionthat's better than etc1 that we'll talk aboutin a little bit. but you should know thatif you do decide to use etc1, opengl es represents a 2.0,which is what is required. it represents the vast majorityof devices out there, over--greater than 70%.
there's some question markson this slide because the parsing tool we usedto generate this data, like, totally failed. but even if we assignedopengl es1.0 to that question mark part, we could see that the vastmajority of devices are 2.0 capable. so if you want to rely onsomething like etc1, you can safely do it.
same goes foropengl extensions. extensions are a system by which the opengl speccan be extended. they're optional. some hardware's going tosupport them, some is not. there's a gl extension stringwhich contains at runtime which extensionsa current device supports, and you can query that. you should definitely do itbefore using any extensions,
otherwise you maycrash on a device that doesn't support theextensions you want to use. i used two in replica island, draw textureand vertex buffer objects. both of those are optional, and support for themseems to be universal. but i still check for themjust in case. so, let's move onto rules. we talked about assumptionsyou need to--you can make,
and those assumptionsthat you cannot make to build a compatible game. now, what are the rules? what are the borderline thingsyou should totally not do? probably, at least threeother people at google io have talked about thisbecause it ended up affecting a lot of appswhen the zoom came out. but if you didn't know, it turns out that devices havedifferent default orientations.
if you're holding a tablet, its default orientationis landscape, and if you have a phone orsomething like the galaxy tab, its default orientationis portrait. and you're like,like, why do i care, right? because when yourun your game, you're gonna justset the orientation to whatever you want,and that's what's gonna display. well, you care becauseaccelerometer data
that you getout of the hardware is relative to the defaultorientation of the device. so if you have any sort oftilt or orientation controls in your game, and your methodis just to suck those out of the hardwareand say, okay, it looks like y decreased-- that means the useris tilting left-- you're gonna besorely disappointed when you run on a device
that has a differentdefault orientation because your controlswill all be 90 degrees off. this is really easy to fixonce you know about it. in fact, nvidiahas provided a useful function to just convert between the device specificaccelerometer data and a canonical screen spaceaccelerometer version. and this is my sort ofjava language version of their function.
but if you check out theirtegra zone developer area on their website, you can find the originalc++ version. i just dropped thisinto replica island, and it solved all my problems.it was great. another rule--if you're using jni, which isthe java native interface, that's the system by which youcall from some other language, like the java language,
through dalvikinto native code. if you're using it,you need to be careful because it's a little fragile. in particular,the jnienv variable, which comes downwith every callback, you can't cache that. it changes every time,or it could potentially change every time you makethat callback. and it could changeif the callback is called
from a different thread. and just for a lot of fun,if you cache it, and if you use the wrongenvironment variable in the wrong context, you will get extremely difficultto debug crashes, and they won't be universal. they'll be things likehorrible race conditions that work on some devicesand not others. don't ever cachethis variable.
i worked with onevery well known developer who had releaseda popular android game, and it workedon all devices except for one. and the developerwas positive that that device was brokenbecause... it just didn't workon that thing. everything else worked. just the one device...didn't work on. and we debugged it together
and when we gotto the bottom of it, it turned out that he wascaching this variable and on that particular device,there's a race condition where, you know, thread one wonbefore thread two and it caused a crash.on every other device, it happened to be thread twowon before thread one. by not caching this variableany longer and just passing it throughwhen and he got a callback, problems went away.
i think this is old newsfor most people here, so i won't spendtoo long on it. but there's differentversions of android. each new version of androidintroduces new apis. if you're going to bebackwards compatible across a bunch of differentversions of android, you need to only call apisthat are available in your minimum version. so you know, you gointo androidmanifest
and you say, oh,i have min sdk s3. that means i can run onandroid 1.5 or higher. but i compiled against eight,which is android 2.2, i believe. so what happensif you want to call a function that was addedin android 2.2? well, if you just call it,it'll compile okay. but when you run on the g1or that other 1.5 device, it's gonna crash. if you use dalvik reflection--or you could even branch
on the build idor the version id-- just be careful not to callmethods that may not exist in your minimum supportedsystem version. and actually, the docsare really useful for this because they will show youexactly how-- exactly which version every functionin the android api was added. another rule. you should be frugalwith your ram use.
if you are writingto dalvik, you have a fixed size heapand you know what it's gonna be. on a minimum spec,it's gonna be 16 megabytes and on newer devices,it's much larger than that. so you can deal withthat memory stuff pretty easily. if you are allocatingfrom native code, which most of you said you are,there is no fixed size heap. you can allocate as much memoryas you'd like until the device runs outof ram, which is great, right?
because you're notlimited to 16 megabytes. but it also means that if yourapplication needs 100 megabytes to run at its high watermarkand your user is on a phone that doesn't quite havethat much free, you may run intoan out-of-memory situation that you didn't expect. so the message here is befrugal and fail gracefully. try to fit into as littleruntime memory as possible. for reference, replica islandruns at 6 megs.
keep your applicationas small as possible. older phones, especially the g1,but some other older phones have very littleinternal flash. you should also absolutelysupport the apps to sd configurationin your android manifest because that'll let peopleto move the application to the sd card. you don't want to benon-compatible with a device just because you just don't haveenough space to install it.
if you are coding in c++, you may have consideredusing neon. neon is a special architectureinstruction set that allows the optimization of certainfloating point operations. now, neon is only supportedon devices that have rmv7 chipsets. but the trick isnot all rmv7 chipsets support neon. so if you assumed that bybuilding against rmv7
you are guaranteed neon support,you are wrong. for example, the zoomdoes not support neon. now, there is a librarythat comes with the ndk called cpu featureswhich you can use to check at runtime, whether or not this particularinstruction set is available. but do that. make sure you check. otherwise, it will crashon the device [indistinct].
and, you know, i thinkeverybody here knows this because we pounded it intotheir heads at every google io, but don't call ondocumented code. don't use private apis. you can go into the androidopen source tree and you can find a bunchof interesting-looking functions and you can find tricky waysto call them from your code, and if you do that, you guarantee that your gamewill crash at least--
if not now, then in the future,when those apis change. apis that are privateare private because they'relikely to change. they're not readyfor primetime. and if you rely upon them,you will crash. so the main message hereis lots of diversity. right? i mean,there's lots of rules. there's lots of flexibility and this is probablythe point in the lecture
where everybody in the roomis like, oh, my god. how am i gonna deal with this? this sounds horrible. like, for example, maybe you have some weirdocontrol scheme that only workson a subset of devices. right? like, maybe you requirediscreet multitouch which is the non-crappymultitouch. or more likely,maybe you just want to use
opengl es2.0because you want to write your whole graphics back endin shaders, and there's no way that's evergonna work on a device that doesn't supportopengl es2.0. what are you gonna do,right? that's the segueinto our next talk, and the segue itself is thatmarket has a solution for you and it's calledandroidmanifest.xml. so, what isandroidmanifest.xml?
i mean, everybody fills it outwhen you build your application. you put your app name in there and you describe your activitiesand stuff. and it's metadataabout your application, but what is it really? as far as market is concerned,it's your minimum spec. for example, say we say,oh, i require this feature called android.hardware.touchscreen.multitouch. and i really do require it,
'cause i put the required fieldto true. that means i cannot run-- this application is notcompatible with devices that do not supportmultitouch. and if you put thisin your manifest and you upload itto android market, android market will notdistribute it to devices that don't meetthat requirement. so, your g1 users are noteven gonna be able
to find your appin android market. it's just not there. if you use the web interface, find the app and try toinstall it to your g1, it'll say, oh, sorry. your phone is nothigh enough spec. it doesn't meet the requirementsset by this application. there's tons of stuff you canrequire in android manifest. this is why i call ita minimum spec.
there's all kinds ofrequirements you can put in here. here's a little taste. say you want toonly ship to phones that have auto focusing cameras. okay, you can do that. or say you want to shipto phones that support wi-fi. you might think that all phonessupport wi-fi, but it's probablyan optional part of the spec.
so maybe if you require it, you won't be gettinguser reports from your users who are on the crazynon-wi-fi supporting device that comes out in six months. or here's a more commonrequirement for game developers. say, you do want to use oneof those proprietary texture formatsthat i talked about. you can require it. you can say,well, you know,
i know i'm gonna cut outsome of my users but i want to usepvrtc. put this in your manifest and market will not shipyour game to a device that can't support that versionof texture compression. we talked aboutcrappy multitouch. you can cut out crappymultitouch devices. say, i'm sorry, i have mydual sticks and i like it, and i don't want to even want todeal with you nexus one users.
whatever. however manyother crappy multitouch devices might be out there. set this stuffto require it, and they will never see itat market. by the way, if you saidrequire to false here, it meansthat you want that feature but you can deal with itat runtime. you can say, oh, well,i really wanted multitouch, but since you don't have it,here's another configuration
you can use,some other way. if you set it to required,market will be real strict about how it filtersyour application. couple other examples. we talked about requiringa minimum sdk version and a maximum sdk version. you could also requirecombinations of different screen sizeand density. that's physical size,physical density,
and this isthe most common one. if you want to requireopengl es2.0, that's that one at the bottom,you just say, well, i need an openopengl es2.0 and those old deviceswon't appear. so by carefullymanaging your spec, you can effectivelycut out devices that you don't want to manage. you know, we talked abouta lot of assumptions
and a lot of ground rules, anda lot of them have to do with, well, there's a deviceover here that's this, and there's a deviceover here that's this. and if you would like to say,you know, i don't even careabout this stuff over here, i only want to focuson these guys-- androidmanifest and androidmarket will let you do that. if you think about this, this is actuallyreally powerful.
because if we look atthe low end and the high end-- what i'm gonna call the g1and the zoom are probably the goodrepresentations of those two partsof the spectrum-- that's a pretty big deltalike in terms of-- let's just talk aboutperformance. that's a pretty bigperformance delta. but let's say we requireopengl es2.0, say in our manifest.
now we have to haveopengl es2.0. now the delta isa lot smaller. now the minimum specis the droid, because that wasthe first device to ship withopengl es2.0. doesn't even matterif you use opengl. your whole thing might belike this 2d cpu game. who cares? if you say in manifest,in the manifest file,
that you require opengl es2.0,it will cut out the low end. you know, the caveatto this approach, right, is that every timeyou do this, you are cutting outsome number of users, right? the size of your user baseis getting smaller. and of course, you know, in addition to writingawesome games, we'd probably all like toalso, you know, make moneyoff of those games.
so having more usersis always a good thing. so it's in your interest to tryto be as compatible as possible. but when there'san area of diversity that's just too open for you, you can put your foot downwith manifest and require somethingin the spec. here's the specfor replica island. i don't really require anything. i work on all screen sizes.
i run on everythingandroid 1.5 and higher. now because i'm able to supportsuch a wide variety of devices, you can see thatin my install information, i have more android 1.5 users, a lot more than what's normalfor this category. i have 15%versus the standard, which is 4%. and i believe that this isbecause if you are a... user has a two-year-old device
and it's only gotandroid 1.5 on it and you go to android marketlooking for some games to play, it's a little bit slim pickings,you know. like, most developershave moved on and said, well, i'm gonna requireandroid 2.0 or i'm gonna requireandroid 1.6. but since i was able to supportthose users, that makes my app very visible, and so as a resulti have a lot of 1.5 users.
it's up to you. if you want tosupport everybody or you only want tosupport a subset, you can control thatwith androidmanifest.xml. okay, now, i want to talk aboutthe secret fourth rule. this is specific to games. this is a subtle pointthat i did not understand until after i shippedreplica island. it is true that these devicesare very different.
it's true that there's a lotof device diversity. it's also truethat you can solve it. there's dalvik reflection, there's scaling your graphics,there's, you know, using the android apisto do automatic scaling for you or adding customizable controls,things like that. those are alltechnical problems. you can solve them. you sit down,write some more code.
it'll work. much harder problemis that your users are also gonna bea very diverse group. it used to be-- you know, my backgroundbefore i went to google was writingconsole games. so, i wrote a lot of gamesfor game boy advance. game boy advance,you pretty much know who your target group is.
it's kids between the age of6 and 12. right? or if you're gonna writean xbox 360 game, you can bepretty much guaranteed that your target audienceis males between 15 and 30. all right? just by the market segment thatthe console itself controls. but on a phone, i mean,everybody's got a phone. right? what do you knowabout your user? how much do you knowabout what they want
or what kind of gamesthey want to play? you know very little. i found outthat when i added all this customizationfor controls, what surprised me about itwas that users who didn't need tocustomize their controls, because i'd alreadyprovided a solution for them, were going inand customizing them anyway. you know, i addedlike the tilt stuff in there
for the basicallythe xperia users. and i kind of thinkthat that's a difficult control scheme to use. but i had users telling methat they preferred tilt over the originaltrackball control scheme even though they hadlike an nexus one or a g1. that surprised me. the user was different,not just the device. you know,in designing replica island,
i had some idea that usersare gonna want different things. so in the game design,i tried to provide different aspectsof interestingness, different poles by whichpeople could, you know, become interestedin the game. one of those thingswas just a game play, right? some users are gonnalike crushing stuff and moving through the level and trying tofigure out the puzzle
and making itto the next level. that's the whole gamefor them. that's enough.right? so try to make that part good. another aspect ofinterestingness was a story, right? some people might not care very muchabout crushing stuff, but they want to find outwho they can trust
or who's the real bad guy?what's the secret ending? you know, art stylewas another thing. i tried to go for a retro16-bit game look even though the gameplays very differently than a retro game,because i thought that that would drawsome users in. that's what they're gonna beinterested in. and recently,i've actually added explicit difficultysettings for new users.
i had some dynamic difficultyadjustment in there before, but it turns out that the userbase is so wide here that i can makea much better game if the usertells me upfront what kind of gamethey'd like to play. some people want to puttheir pride on the line. they want a challengeand they want to feel awesome when they've completedthat challenge. and other people are like,you know what?
i'm just gonna play thisfor five minutes. i don't really wantto play the same level over and overand over again. i just want tosort of glide through. so by providing specificdifficulty levels, i was able to accessnot just more devices, but more users. one thing i didn't have to dobut you should think about is i did not provide an option
to customizethe graphics quality. if you want to customize thegraphics quality in your game and you're using opengl,it should be really easy. it's one call to thesurfaceholder.setfixedfunction. sorry.setfixedsize method. what that does isit makes your window that you're rendering to smallerthan the window of the display, and then the systemwill automatically scale it up. so the effect isyou're filling fewer pixels,
and actually fill is the partthat's slow on these devices. so you're fillingfewer pixels, but it still takes upthe whole screen. the graphicslook chunkier. i don't knowif you can tell, but on the leftis native resolution and on the right is 50%reduced and scaled back up. it does looka lot chunkier. although at 75%most users probably can't tell.
if you need to getsome speed back or you want to givethe user an option to dial downthe graphics quality because maybe they're on a phonethat is lower quality than you anticipated,you can give them an option to set this value,and that would let them play even if they havekind of a crappy phone. so the goal istarget all devices, right? that's a technical problem.you can deal with it.
i did.i kind of got lucky, but you follow the assumptionsthat we talked about today and the rulesthat we talked about today, and, you know,i think any game that's onthe android market today can be aggressivelycompatible. much harder is to understandyour user base. building a gamethat is compatible acrossa large number of people
is actuallya very difficult problem. and it's not justabout controls, and it's not justabout game content. so i urge you when buildingandroid games to think not just about thetechnical side of compatibility but also who your users are. you know,who is this market? and what do theywant to play? and give them optionsto tune the game
the way that they like. and i think if you do that,you have a lot more-- bigger chance of success. this is the endof my remarks. i sped through ita little bit 'cause we're runninga little late, but we do have timefor some questions. if you're interestedin what i'm up to next, my company is calledrobot invader.
we're at robotinvader.com. at twitter,i'm at c_pruett. and we don't haveanything to show quite yet. we're only a month old. but we will havesome pretty cool stuff. so please stay tuned. if you'd like to ask questions, please come upto one of these microphones. thank you very much.
[applause] man: you mentionedputting restrictions in the manifest to limitthe number of devices and there wasthe required true-false. it's obvious what happenswhen it's true. well, how does the marketrespond to that requirement when it's requiredto be false? are you just saying,i would like this but i can deal with it?
what's the point of just-- what's the pointof even saying that? pruett: right.so, the question is about what doesthe true-false thing do? now, i believe you saidthat the false market will not treat itas a strict filter so it will allow devices--it'll basically ignore it. but the purpose of the manifestis not just android market. right? the manifest is supposedto be all metadata
about your application. and android applications aredesigned to be self-describing. so you should be able to lookat the binary, understand what kind of devicesyou can install this on. if you set that requirementto true, i don't think you'll even be able to installlike over adb... man: right.pruett: a device--or application that doesn't meetthe requirements of that phone. so i think that if you havethe field set to false,
you're just giving android moredata about your application, whether or notit acts upon it or now, or maybe in the future,i don't know. i don't think that marketin particular does anything with itif you set it to false. but it's probably a good ideato give your... give android or marketor any of those systems as much information aboutwhat you want as possible. man: okay.pruett: over here.
man: so when you parsethe extension string-- pruett: yes.man: if you come across devices that don't supportthe extensions that you need, how do you fail gracefully? do you just tell themyou can't do it? or do you have a backup?pruett: sure. depends on the extension. but, generally,extensions are fast paths for stuffthat's in the spec already.
so, for example, draw texturejust takes a texture and blitz it, you know,access-oriented to the screen at the scalethat you specify. now, if draw textureis not available, you could fall back on a quad that's orthographicallyprojected. it's the same thing. man: is that what you do, or...pruett: that's what i do. man: yeah.pruett: yes.
or another exampleis vertex buffer objects. fast path for regularvertex buffers, right? now,there are some things like you will seethe texture compression formats that are supportedin the gl extension string. and if your texturesare all in some format that that device doesn't support,i don't know what you can do. you can try toranscode them, but i think you'repretty much up a creek.
so, that's probablywhere you want to start putting requirementsin the manifest. man:right. thanks. man: before i ask my questionto play off his a little bit, then that's assuming you'renot filtering in your manifest. pruett: that's right.man: therefore... not filtering in the market.pruett: that's right. man: and then you would wantto handle it at runtime. pruett: that's right.so when i--
one developerthat i spoke with was interested in transcodingbetween atitc and dxt because those formats areactually at a binary level pretty similar. so there might be liketricky things you could do. like, oh, i encodedall my stuff in dxt but i'm finding out, i'm actually runningon an atitc device. at runtime, i can transcodethis or something.
but probably what mostdevelopers are gonna do is not anythingthat complicated. they're either just gonnause a non-proprietary format like atc1, or they're gonna requiretheir manifest. man: okay.so, my question. say i'm really motivatedand a little bit crazy and i want to do a gameor a graphical app that's really, you know,
it's taking advantageof opengl es2.0. it's targeted at, say,tablets. it's really high end.pruett: hmm-mm. man: but i also want to appealto the lower-end devices. would i, i guess,in more general terms, would i develop two separateapps with different manifests just so that it could appearto any given user to be the same appbut only be exposed to the devicesthat are necessary?
pruett: you could.you shouldn't. yeah, i mean, you certainlyhave the ability to do that. the problemwith that approach is that then you'll havetwo apps on market. they will have two differentsets of ratings information. they'll have to haveslightly different names. and if one of your appsgets voted way up, it won't change the ratingof the other application. man: what's the right wayto do that?
pruett:the right way to do that is preferably to have a singlebinary that you can do both in. i mean, what would you changebetween the low-end version and the high-end version? well, you'd probably changethe resolution of the textures. you can do thatat runtime. if you were gonna switchbetween, say, a fixed function rendererand a shader renderer, that actually might bequite a lot of work.
but it's also you know, a classyou can swap out at runtime. the trick is...to understandthat you can control, you know, which devices get yourapplication based on the spec. but if at all possible,your ideal scenario is a single binarythat supports as wide a range of devicesas possible. man: so then the concept ofa minimum spec in the manifest gets real tricky becauseit may not so much be minimum as i can do thiswith a low-end device
but otherwise i can do thiswith a really high-end device. how do you filter? pruett: so in that case,you don't need to filter, right? if you can actually spanwhatever you're doing, if you can run on the low-enddevice and the high-end device, you don't need to tellthe manifest anything. you're available to everybody.right? that's a runtimecomputation. so what the manifest is foris for areas
where you couldn't makeany concessions at runtime. you can't just degradethe graphics quality or you know,resize the textures. like, if you havea shader based rendering engine and you don't careabout fixed function, you know, rendering engines,you can require opengl es2.0, and then those devicesjust won't get it. does that make sense?man: i think so. thank you.pruett: thank you.
man: a little bit moreof a gut question. pruett:sure. man: how do you balancethose factors when you want to makethose changes like you did for the difficulty settingsand really you know, deciding, okay, well, this marketisn't big enough. i want to includelower-end devices. what do you use?hard data? you know,do you get feedback?
pruett:yeah. man: you know, are you lookingat the competition? you know,those are the tough choices where you decide, okay, now i'm gonna spendtwo extra weeks working on this. pruett:that's a good question. in my case, the game was writtenagainst the low end. so all i had to dowas scale upwards, and that wasn't very hard.
in fact, it pretty muchworked out without me doing anything. if you have shipped something,and now you go back and decide, well, you know,i shipped something and i required opengl es2.0,but i don't really need that and boy, there'sa lot of users out there who have older phonesi'd like to support, that's a little bit trickier. google does publish informationat developer.android.com.
about the distributionof screen sizes and also of androidinstalled versions. so you can get a sensefrom that data, you know, what the whole landscapelooks like. you can also use...there's a bunch of metrics that just got addeda couple of months ago to android market to seewho your users really are. so if you got complaintsthat like, oh, it crasheson wide vga displays
and you went and you lookedand saw that 30% of users have wide vga displays, that's probably an importantbug that you want to fix. above and beyond that,i highly recommend that you doyour own analytics. you know,actually android can-- there's an android versionof google analytics which you can plug in. it's aboutthree lines of code.
super simple. you can send whatever datayou like back and it'll aggregate youon a webpage and give you graphsand all kinds of information. and it'll tell youin excruciating detail, depending on what valuesyou send back, who your users are andwhat they're doing, you know. i worked with a developerwho tracks how long it takes for users to completeeach level.
and they found outthat everybody completes the first level, and 80% of userscomplete the second level and 10% of userscomplete the third level. okay. there's a problemwith the third level, right? doing your own analytic trackingis super useful anyway. that said, if you are talkingabout a group of users that you're notshipping to now and you don't knowhow large they are,
it's pretty hard to tell,because absent data which only aggressivelycompatible applications have, you kind of have to either takea chance and ship something and try to make itas compatible as possible and ship itand see what happens. or try to relyon third party data. you know,in addition to google, there's a flurryand there's, you know, admob and other peoplewho will publish data as well
help youmake those decisions. my suggestion would be to,you know, choose a minimum specas low down as possible, you know, try to makeyour minimum spec as old a phoneas you possibly can and then work from there. man: hey, chris.pruett: what's going on? man:everything's been pretty good for us native developersfor arm so far,
but intel announcedmaybe a month ago that they're gonna startdoing x86-android. man: so what do you recommendwe do for compatibility for you know, arm? because right now, as it stands,my native games are i'm gonna have to dosomething quickly. pruett:sure. sure. well, you know, the ndk will have to support arm.or i'm sorry--
other architectures like x86-- before you canreally do anything. if you look at the ndk, there's actually alreadysome preliminary support for x86 chain in there. and what's gonna happenwhen that support shows up or support for any otherarchitecture, say, you know, like a power pc device comes outtomorrow or something, right? the way it's gonna workis your...
if you look insideyour application that you built withthe ndk, you end up with a foldercalled libraries and in that folder,you have the output of your compilation,your libraries. and actually, you can havemultiples versions for different architectures. so, right now,you can choose to compile against both arm 5and arm 7.
and it will automaticallyload the correct one. in the future,what i would expect is that you hit the sameindicate build command and if you setyour make file up correctly, you will get a libraryfor x86 as well as for arm. now, that makes a lot ofassumptions, right? it assumes that your codeis first of all just gonna compile againstan x86 code base
and that your, you know, data is a little [indistinct]or whatever. but i think that functionallythe way it'll work is that your application-- it's already a sort ofa fat binary, right? it's already able tosupport multiple architectures, and they will just addarchitectures onto that. man:but do you think the market-- that makes perfect sense.
but do you thinkthe market is gonna have an opt inor an opt out? because the one thing i don'twant to have happen is, you know, all the newx86 devices roll out, and just we're crashingon them. pruett: right.that's actually already there. if you...one thing i didn'tmention in this talk is that market willlook at your manifest to figure out its filters,but it also draws filters
from intrinsic informationabout your application. so for example, if you targetarm v7 right now, you will not appearon arm v5 devices 'cause you said i can't supportarm v5 by nature of you compiling only againstarm v7. so, if you havea native application and some other architectureshifts, by default, you're not gonna show upon that device until you explicitlygo back and recompile
and then ship an update. did that answeryour question? man:oh, yeah. pruett: okay. are thereany other questions? if not, thank you very muchfor coming. appreciate it.
08.58
Unknown
