[music playing] todd kerpelman: hello andwelcome to episode five of game on. i am your host, toddkerpelman. and with me today--
Android TV box game controller, kristan uccello: krispy,developer relations. todd kerpelman: it'skrispy uccello. and we are here to talk to youtoday about game controllers. but firstly, with some newsand updates from the
google-play-game-servicesside of things. first off, we have an officialstack overflow tag. so yea! if you've got questions aboutachievements, leader board, cloud save, multi-player, anyof that, you can go to stack overflow and find us under the google-play-games-services tag. hopefully by the time this videocomes up this tag will be available.
they're working on it. and you can start askingus questions there. we've got guys much smarterthan me that are monitoring that tag. and they answer a lotof your questions. so go there if you've got aquestion about support on a specific platform. you pair it with an androidor ios tag. and we'll try and answeryour questions.
also, there is a great newfeature on the play games developer console. it's the greatest feature thatyou've probably overlooked because it's this tiny littlelink at the bottom. but it's the new "getresources" feature. so you've got tocheck this out. this is from our sample game,the typer-number-challenge. you'll notice i've got sixachievements here. and i've got a coupleleader boards.
and in the past i had tocopy and paste all of those random strings. and half the time when i clickedon something to try and copy the string it wouldtake me into the details page and it was really annoying. well, now i can clickon this little link here at the bottom. and this will bring up a dialogbox where i have all the text i need ready to copyand paste into my android
application or my iosapplication or my javascript application. and if none of these codesamples exactly matches the way you're implementing yourachievement in leader board strings we also just have plainold text version that you can copy and paste and runthrough a python script or what have you. so for all of you that areimplementing 200 achievements all at once, this should bea really big time saver.
and we're really excitedto have this out there. so check it out. if you haven't seenit yet, it's the greatest new feature ever. well, maybe not ever. but it's close. and so with that out of theway, let's get into game controllers on android. i'm going to hand the clickeroff to krispy here.
kristan uccello: thankyou very much. todd kerpelman: sure thing. because he's the expert. kristan uccello: i don't knowif i'm an expert yet. i'm hoping to become one. and this is sort of thefirst foray into that. so i spent a lot of time withgame controllers, working of the stuff that i work on. and i've had a slew ofthem cross my desk.
and with that, this isthe first thing. what does it mean to support agame controller on android? because there's so manydifferent devices. and they all choose slightlydifferent ways of connecting to android itself. a lot of them are eitherbluetooth or usb. those are typically theonly options that you're going to have. but one interesting thing is,when you're building an
application that utilizes gamecontrollers, you have to factor in that you're taking theuser's ability to really touch a screen away from them. and this is a good thingand a bag thing. it's a good thing in that itgives you that tactile feedback when you'remanipulating the controls, pressing buttons. it's something that doesn'trequire you to focus your attention on whatyou're touching.
you could, instead, looksomewhere else. so this is great for google tv,android tv, anything that is far away from you thatyou can't really touch. but on the opposite side,you can't really input text that easily. so if there's a lot of inputcontrols that would require keyboard input that'snot always there. so the plus points, i'lljust summarize again. physical feedback, somekind of [inaudible]
feedback with vibrators. the negative side, harder toinput text and there's a little bit more design work thathas to go into your ui. but we're going to cover somemore later on in the slides. so let's talk about wherethe apis came from. api level 12 we saw theintroduction of a lot of the constants that were availablefor dipping into game controllers, understandingwhether an input device is actually a joystick or whetherit has joysticks, whether it's
a game pad, whether itsupports buttons. and this has all that availablein the documentation since api level 12. there's a link on theslide right now. if you're new to gamecontrollers this is the place to start. there's a summary section thatreally details things like what to do with source-classjoystick and source-class buttons and game pads.
it's a good primer. it's not going to tell youeverything you need to do. but it's a good placeto start to get ramped up on that material. now, with api level 16 we saweven more game controller support added. and this is where you can,actually, tap into listening to connection and disconnectionevents. previous to api level 16, youhad to write your own
broadcast listeners to tap intowhen a usb devices was connected or disconnected. and you would also have toimplement a bluetooth event listener that would tell youwhether a bluetooth device had connected or not. you didn't have to write a lotof boilerplate code for all these applications. now with api level 16, there isthe input listener that you can take advantage of.
and it's definitely a big one. so there's a lot of supportalready there for game controllers. so the two places you're goingto want to look, api level 12, the link is on the screen,and api level 16. check those out. todd kerpelman: i notice theslide here says something about querying. what's that?
kristan uccello: querying ispulling of a sort to find out what devices are actuallygame pads. one of the things that we'lltalk about later on in the slides is how to identify aninput device, whether it's a keyboard or a pointer, or astylus, or an actual game pad. and querying is kind of an easyway to just getting the subset of input devices that youcare about in that case. we'll cover some of the methodsof detecting input devices without usinga query right now.
i don't want to go toomuch into that. all right? so moving along here. oh, i'm scrollingthe wrong thing. there we go. so connecting controllers,this is the first step in being able to use them. phones and tablets, you'retypically going to rely on a bluetooth connection.
because it's really hard to pluga fat usb port into your nexus device, i found anyway. but on android tv devices likegoogle tv, you can typically plug right into the usb portand take advantage of that. and you can leveragebluetooth. so i think i'm kind ofrecommending bluetooth here. but you shouldn't feel thatyou're limited to only using bluetooth, especially ifyou want to target a living-room-console style gameplay for your users.
so just quick, short facts aboutwhere usb came from. it was from 1994. there was a collaborationof a bunch of companies that got involved. and they created theusb standard. and that's evolved over theyears to our micro standard that we see now. you're not going to find anygame controllers that really connect with themicro usb spec.
i haven't found any yet. i'd be interested ifthere were any. but we'll see. i'll just mention, again, apilevel 16 introduced the ability to easily search andlisten for connected and disconnected devices. and actually, before i forget,the button mappings, when you connect your game controllers,button mappings are a little weird if it's non-hid orhid device sometimes.
you can press the a button orthe b button on your remote or on your game pad. and it will act asthe back button. so we'll talk about howyou can fix that a little later on. but just be aware that when youfirst connect, even though you can navigate the homelauncher with it, it might not have the expected behaviorright out of the box. so it's good for applications,maybe not so good for
home-screen navigation. todd kerpelman: ok, kristan uccello: so let's talkabout querying for game this might be a littlesmall on the screen. i say that because eveni'm having trouble reading this slide now. but i'll cover thebasics here. what you want to do, isyou want to take the input device class.
and you're going to basically,say, get all my device ids. and you'll get back an integerarray of all the devices that are currently connected to theandroid system, whether they're virtual or real. what you want to do, then, isactually iterate over all those device ids and request,again, from the input device class, getdevice. and you're going to pass in theid that you're currently iterating on.
that will give you aninput device object. and you can now start toask that input device object about itself. and the key here for detectinggame controllers, is in fact, to use device.getsource. so devices, our input deviceobject that we've created, getsources, returns an integervalue which is actually a set of bitmaps, bitmapped valuesthat create a large integer. you will logically end thosewith an input device
source-class joystick. effectively what you're doingthere is you're filtering out all the other bits. and you're just looking at theone that's going to tell you, hey, this is a joystickdevice or it's not. and if that returns non-zerothan it is a joystick device. that means there's an analogstick on it that is a joystick axis. from there, you're going towant to possibly check the
ranges that are available forthat joystick device. so we're going to lookat that now. todd kerpelman: ok,actually, sorry. so going back-- kristan uccello: you wantto go back a slide? todd kerpelman: so i actuallycan't tell the device, like, are you a game pad? i would say, hey, out of all thefeatures that you have, do you have maybe a couple ofjoysticks and some buttons?
kristan uccello: exactly. you're going to take thegetsources and you're going to ask it yes, do you havethe ability to provide me joystick input? do you have the ability toprovide me button input? chances are, if it has ajoystick, it's a game pad. todd kerpelman: yeah? is there anything that wouldhave a joystick that would not be a game pad?
kristan uccello: i've done lotof tests with a lot of different input devices. i haven't come across any. it's entirely possible butprobably not the normal case. todd kerpelman: what about astylus then, that would say, i'm not a joystick. kristan uccello: yeah, thestylus does have axes based on the angle. but it's not classifiedas a game device.
it won't registeritself that way. todd kerpelman: got you, ok. kristan uccello: so with ourjoystick identified, or the device having a joystick, we cango in further and ask that joystick what motionranges it has. and this is useful fordetermining the number of axes that are available. so if you have a game pad orsome sort of game input device that had two joysticks on it,it's going to have eight axes
right there. one for the vertical on eachstick and one for the horizontal on each stick. now, if it also had analogtriggers for the left and right, those will also show upas axes but single axes. so you could have a device-- or maybe i did my math wrong. todd kerpelman: yeah, i wasgoing to say, that would be four for the joysticksand then two
more for the triggers. kristan uccello: idoubled it up. two more for the triggers. i was jumping ahead ofmyself in my head. so six axes in that case. and the thing that looks likea d-pad, actually, on game input devices, people thinkthat it's a digital input. and it's not. it's actually a hatdevice with axes.
so you get anothertwo off of that. todd kerpelman: so a d-padlooks like, basically, it looks almost like an analogjoystick except that the numbers aren't really analog. kristan uccello: right, while itreturns it's axes values as floats it'll eitherbe 0 or one. you won't get any ofthe middle ranges. whereas the other moreanalog-style inputs like the triggers and the joysticks willreturn in an analog value
range between 0 ornegative 1 and 1. so that's just somethingto be aware of. so we check the motion rangesjust to get a principle idea of how many axes are actuallyon this device. and from there, we want totake that information. we want to restoreit in a state. we want to create a class thatallows us to know how many axes we have, the ids of thoseaxes and the values associated with them.
so i'm just showing, really,the skeleton of a state class here. you're going to want to extendthat with things to process the axis input and normalizeit and all that stuff. and we'll cover a bit ofthat as we go forward. but i just want to point out thecritical things you want to store, the number of axes,the axes values, and you're going to want to use, probably,a sparse array to store the number of keysthat you encounter.
and the keys are actuallythe buttons. so these map as keys. i think it's a little weird,but buttons or keys. todd kerpelman: ok, correct meif i'm wrong, but an xbox 360 controller, for instance, ibelieve those buttons are actually analog. is that true? and if i had something thatwas similar would those-- kristan uccello: i'm actuallynot aware of that.
i didn't know thatthey were analog. todd kerpelman: ok, i couldbe totally wrong. that's what i vaguely rememberreading sometime. kristan uccello: differentmanufacturers can do different things. and this just goes back towhat i said earlier. there are so many differenttypes of, again, controller inputs out there. it's really hard to knowwhat they all are.
which is why the way androidhas approached it is really good. it lets you query the devicefor what it's capable of, which lets you, then, determineif the device is capable of providing the rightkind of input for your application. or game. todd kerpelman: ok, so let'ssay a query device, it's a standard two-analog joystick,a couple of triggers. and it says, ok, i've gotthese six analog axes.
how do i know which two, forinstance, correspond to the joystick on the left? kristan uccello: we'lltalk about some of this going forward. when you get a dispatchon-motion event from your activity class, that the eventobject is either a motion event or a key input event. we'll ignore the keyinput event. so you get a motion event.
and the event object itselfhas information about what input source on the device isproviding that particular input event. so there's a couple thingsyou can check. whether it's a move, action,associated with a particular axis label. so back to the apis i mentionedbefore, api level 12, it introduced a whole bunchof constants that you can use to determinewhich axes it
actually is on the device. so they all map to differentconstant values. todd kerpelman: got you. so for instance, looking ata controller, that analog control on the left, those twoaxes generally correspond to constants like what? like move vertical andmove horizontal? kristan uccello: it's actuallyaccess underscore x-axis underscore y.
now the one on the other sidethe controller, if it's there, is typically labeledaxes underscore rx. my memory's a littlefuzzy on this. but it's labeledappropriately. todd kerpelman: so i got my axisleft, axes y, axes rx and axes ry basically? kristan uccello: right, but it'snot always guaranteed to be that way. you might actually end up in thecase where that secondary
joystick axis is labeledwith a z. so zx, z, none of it isconstant with game and so you have to do a bitof experimentation. my advice is to stick with someof the more established brands because you're going toget consistent behavior across them, more or less. but it's a bit oftrial and error. and you will probably end uphaving to map a couple of different types of controllersand adjust what they're
reporting their axes tobe to be consistent with your game logic. todd kerpelman: and the time tofind that out is on my very first get move eventfrom that game pad? kristan uccello: exactly,because you're not going to be able to determine everythingon initial poling yet. but everything can be dealtwith on those events. so one thing i want to put in,since we've talked about the state of the device and storingit, you're going to
want to probably figure out anabstraction where each player should be assigned a controllerdevice and let that be consistent. as well, you want to let theusers sort out or whose controller is mappingto which player. so one concept i have forthis-- which i haven't implemented yet but i'veseen in certain games-- is something along theselines, where the game starts up.
and it's like, all right, whichplayers are assigned to which controller? so you have a list of all thegame pad identified devices down one column and all theplayers along the top. and any device can push thesecontroller things into the right player slot. and then that player could goahead and configure their device to their preferences. so just something i wantedto point out.
it's always a good idea, if it'sa multi-player game, to allow the players to decidewhich controllers are which. otherwise they're having tophysically switch it. and it's not a greatuser experience. todd kerpelman: that'snot so good, ok. kristan uccello: so now let'sget back to what we were talking about before that,the handling of events. so there's two methods you'regoing to want to override in your activity.
and that is dispatched genericmotion event and dispatched key event. my recommendation is, whateveryou're going to write for your logic to manage your input froma game controller, you're going to want to feed thesemotion events from your activity into that class. don't try and deal with them,necessarily, in the activity. because it'll just bloat yourcode and it's not a good way to abstract, i think.
so whenever there is an accessmovement or a hat movement or an analog trigger you're goingto get the motion event. so anything that's analogwill cause motion. any button event will triggerthe dispatch key event. and this is where you startto get into filtering. so you use the constants-- again, look at api level 12documentation on this-- to sort out which mappingsare actually to the keys you care about.
and i'm not going to cover toomuch about establishing how to remap keys. but allow the user toreconfigure the layout of their device, theirabstraction layer. so you're going to want to passthis off to something that manages the device stateand then returns it back to whatever's going to use thatstate to then modify the player-controllable objectsin your application. so it looks somethinglike this.
so your dispatch key event andyour dispatch generic motion event come into the activity. you're going to hand it off towhatever system to get the state back and use that topower your application. i want to point out a few thingsabout analog joysticks. you will have to be awareof the dead zone. not all joystickscenter on zero. they're moved around a lot. they're mechanical things.
and so they can get a littleoff and it can report to the sensors. luckily, we have this thingcalled the dead zone, usually by calling getflat onthe motion range. this allows you to determinesome sort of air tolerance when the joystick is releasedand not being touched by the player. use the motion rangeof the joystick to determine this stuff.
so the ones you care about aregetmin, getmax and getflat, which i just mentioned. you'll have to normalize youraxis values accordingly. so i actually have a bit of codehere that shows this off. pardon me. so if we want to process anaxes and we have some axis value that we've gotten from ourinput state or controller state object, so we havethe motion range. we have the axis value.
what we want to do, is we wantto get the absolute value of that axis value. and then we want to determinethe dead zone. so we're going to go getflat. and then we want to determine ifthe absolute value is less than or equal tothe dead zone. if it is, return 0. that means that it's actuallywithin that range. and we shouldn't do anythingwith this.
or if the access value isgreater than 0, we want to return the absolute valuedivided by the minimum range, which gives us a normalizedvalue. if it's less than 0 we're goingto do absolute value divided by maximum range. todd kerpelman: so whatdo these numbers typically look like? so i'm assuming getminis a negative value? kristan uccello: yes so getminis a typically negative one.
and getmax is typicallyone, yes. but you can actuallymodify this. if you want to actually get outof, let's say, a method like this, you wanted toget some greater range. you want to expandit as you're not dealing with decimals. you're instead dealingwith integers, which is completely possible. you could add biases to yourcalculations here to actually
spit out oh, 1,000 or 200. todd kerpelman: and getflat herewould probably look like, say, 0.05 or somethinglike that? kristan uccello: oh, i thinkit would look even smaller. from what i've seen, from whati've played with, it's like, 0.02 or 0.02, 0.01. it's a very small percentage. because remember, the valueswe're dealing with here are negative one to one.
and 0 is supposed to bethat absolute center. but it fluctuates a tiny bit. not a great amount, but ifthere's a lot of wear and tear on the physical device youmight see greater values. so one more thing that i wantto talk about here is just about the user experience. when you're designingapplications and games that utilize digital input-- and i'm going to steer away fromthe analogs for a minute
because you're not really goingto navigate around with that-- let's say, using thehat or d-pad, don't punish your users. provide layouts that areactually navigable and don't lead them into traps. so patterns that we found usefulare using shelves. you might remember or you mighthave seen this in things like netflix, where everythingis stacked as a shelf and you can just go along.
it allows you to jump down orjump up to get out of your current horizontal scroll. because you might have gotten100 units over. and you want to get back to somemenu item on the other side of the screen. todd kerpelman: if i go downand up or something? kristan uccello: yeah, that'syour shortcut out, as opposed to having to scrollall the way back. and tabs can be utilized in thisfashion to help a user
jump between a lotof content lists. it's ok to use lists butalways provide the out. allow the user to jump to theleft or to the right as appropriate. and great grid is always good. grid, it maps very wellto d-pad we find. so one last thing, i thinki mentioned it already. allow the user toremap the keys. this is important.
some people have preferences. some people, when playingfirst-person shooters, prefer the inverted axes control,which means down is up and up is down. todd kerpelman: those peopleare crazy, i think. kristan uccello: well, whatdo you prefer to use? todd kerpelman: no,i like up is up. kristan uccello: noinverted control? i like up is up too.
todd kerpelman: what, you? this is crazy. kristan uccello: so yeah,allow the user to assign different controllers todifferent players, which we already covered. so at this point we'regoing to demo. so we'll just go to that now. all right, so we chosecordy 2 here. i like this game because it'svery responsive when using
i had a lot of fun playingit on the tv. so on the first screen here,we've got an example of using focus to your advantage. so those little white-- todd kerpelman: yeah, if imove my game pad left and right it'll go back and forthbetween buy full game and choosing a level. kristan uccello: so this is areally good example of how to illustrate visual focus.
and this goes to what i wastalking about before when we were talking about the layoutsand how not to trap the user. so it's very important to orientthe user when they're navigating with an analogstick or d-pad or hat. so we've got our littlegame intro piece here. and cordy's coming out. all right, let's jump throughthe text that comes up. so this is all being done withclicking on the button. todd kerpelman: right, you guys,we're full screen so you
can't see me. but listen, these arejoystick noises. i'm really actually playingwith a joystick, not the game pad. kristan uccello: it just itfeels very natural, almost like you're playinga console, really. todd kerpelman: yeah, kristan uccello: it'snice and smooth. and you can actually doublejump in this.
there you go. todd kerpelman: oh,look at that. kristan uccello: and for me,playing platformers like this, it just makes all thedifference to use a controller. you're not distracted by anyon-screen touch needs. even though the ui, in thiscase, is still showing some touch commands, you have theoption to jump back on touch screen, which is great.
todd kerpelman: yeah, i have tosay, this a lot more fun to control using a gamepad controller. i don't have to look tosee if my fingers are in the right place. i can just feel that. and this just feels, for me, alot more natural, playing a platformer game like this. kristan uccello: absolutely. and one thing that actuallyfrustrates me a little bit
about the on-screen controllersimulators, and that's what i call them is just simulationof game pads. sometimes when there's garbagecollection going on within the app or even on the platform,you can get some lanky feedback from what you'retouching and actually cause the game not to do whatyou intended it to do. i don't know if you've everexperienced that. todd kerpelman: i haveon occasion. kristan uccello: so it justmakes, for me, anyway, the
argument that all games, really,should try and strive and support game controllersin this way. todd kerpelman: sounds good. yeah, my only complaint hereis i'm sure this maps to a game pad button. but i don't know whichone it is. kristan uccello: yeah, actually,that's a good thing to point out. a lot of the on-screeninstructions in a game, if
there is controller support,they should detect that the input is mostly coming from acontroller and maybe adjust the instructions to mapto the buttons. so there you go. you figured it out. todd kerpelman: there'sthe b button. wee! look at that. there i go.
all right. kristan uccello: so yeah, agreat game to play with a there's lots out there. a lot of the controller vendorshighlight the apps that support their controllersin the market. and you should check itout for some examples. todd kerpelman: cool. all right, well, i couldplay this for the rest of the video.
but i won't because we gotsome wrapping up to do. kristan uccello: all right,let's get back into it. todd kerpelman: all right,and so we've got some q&a at the end. i actually had a couplequestions that are not on here. kristan uccello: oh, yeah,let's do some improv. todd kerpelman: so at thebeginning, you talked about there's two ways to do connect,bluetooth or usb.
does a developer need to care? do i need to know how mydevice is connected? kristan uccello: if you'redeveloping for android at anything less than api level16 you're going to care. because while android treatsboth usb and bluetooth devices as just input devices, when itcomes to monitoring their connections and disconnections-- which is something you will haveto do on anything lower than api level 16--
you're going to have to writetwo broadcast listeners, one for the usb, onefor bluetooth. that's where the differentiationcomes in. ok, so if i've got a high-endgame, clearly only modern devices might work movingforward, maybe i don't have to care if i want to reachthe broadest range of customers as possible. kristan uccello:exactly, yeah. todd kerpelman: ok, now i'veseen some game controllers or
gaming devices where essentiallythe controller is integrated right intothe device. kristan uccello: i've seena few of those myself. they're quite amazing. todd kerpelman: how isthat represented? and i guess, do i need tocare about connected or disconnected? because it'd be hard todisconnect a shield controller without breaking it.
kristan uccello: you'reprobably right. if we think about other onesthat are similar form factor, it all depends on howit's connected. if you're just targetingone device-- i don't know how likelya case that would be-- you're still going to have todetect the input device as being there. so that's a good question. i'm not quite sure what theright answer is there.
you get a point for that one. i would say, just treatit like you would any other device. don't assume that it's there. you're going to try and buildyour application as you said before, for multiple devicesand form factors. don't make assumptions. that's what i would say. todd kerpelman: fair enough.
moving forward, the world'sgoing wireless. do you think bluetoothis basically going to be the standard? kristan uccello: i absolutelythink so. if we just think about what itmeans to have wires-- and i'm going to go back to tvbecause i'm a bit passionate about tv-- it really doesn't make senseto have a really long usb cable plugged into your tv pryour set-top box while you're
sitting on the couch. people trip over it. yes it provides a veryclean signal. but it's at the expenseof being tethered. so as we, in our lives, movearound more and care about bringing our data with us andinteroperability between devices, i think bluetooth isonly natural as the de facto standard, if it's not already. todd kerpelman: is that goingto be replaced by a
new-and-improved standard? kristan uccello: i don't know. do you know of a new standard? todd kerpelman: no,but i figured if anyone knew, you would. kristan uccello: imean, who knows? it could be the internetis everywhere and just powers things. todd kerpelman: ok, let's see.
and then, so speaking of moderngame controllers, there's been, certainly inthe news, a lot about android-powered gamingdevices. i'm thinking like the ouya andthe shield and probably more in the future. if i'm a game developer, isthere anything i need to know specifically about developingfor this new generation of android-powered game devices? or can i just address themlike normal controllers?
kristan uccello: i'm goingto answer it this way-- first piece of advice, donot lock yourself in any vendors' apis. that is a good way to shootyourself in the foot. now, there are reasons to dothat if you have deals with a particular device. but it means you're goingto limit yourself to just that device. a lot of these android gameconsoles all share a lot of
similar characteristics. they're usually boxes. they're usually boxes connectedto televisions. and they usually have wirelesscontrollers. and they all have four buttonson the right hand. and they have an analog stickavailable on the left hand. some of them have a secondanalog stick. and they usuallyhave triggers. so if you've ever played withany one of the popular
consoles out there-- todd kerpelman: you generallyknow the capabilities? kristan uccello: they kind ofall look the same, yeah. that said, what thosekeys map to for that device could be different. so i would say, see if you cantake a controller from one device and connect itto another one. and see if it actually givesyou what you expect back on what the axes names are andwhat the buttons are when
those events come in. todd kerpelman: all right, andfinally, if i'm looking at all this and thinking, boy thissounds like a lot of work. maybe there's a game enginethat can do it all for me? kristan uccello: thereare game engines. i'm partial to a few myself. i mean, i haven't playedwith unity that much. but i hear good things andi've seen it around. libgdx is one of my favorites.
and it does come with gamecontroller support. it's an open-source project. i played with jmonkeyengine,which is also pretty good. if we were to think about webgames just for a second-- and i know it's a little weirdto mention it. but if you load a web page onyour android device and you try and use a game controller,none of that ever works. todd kerpelman: i'venever tried. but i'll assume that.
kristan uccello: so there'sno good engines-- is what i'm trying to say-- that i've seen that support gamecontrollers on a browser. todd kerpelman: but it seemslike most modern game engines these days will have some typeof controller support? it's sort of essential fora game engine to provide game-controller support. so if you're choosing one and itdoesn't, maybe you want to question using that.
todd kerpelman: write theman angry letter. kristan uccello: or you knowwhat, better yet, if it's an open-sourced project,fix the problem. submit the code. patch it. make the internet and worlda better place. todd kerpelman: oh, it's muchbetter than an angry letter. kristan uccello: there'stoo many angry letters in the world.
todd kerpelman: that is true. i get them. all right, well, i think thatjust about wraps it up. let me see, do we have anythingelse on our slides? kristan uccello: i thinkthere's just one more. todd kerpelman: oh,that's right. kristan uccello: so i guesswe'll point out here, i'm in the process of writing aseries of blog posts. i'm targeting about fivedifferent posts right now that
really go in depth technicallyon all the stuff that we talked about today anda little bit more around the ux guidance. so keep an eye out for those. they should be inthe near future. todd kerpelman: where wouldi find these blog posts? kristan uccello: you wouldfind them on the android developers blog. todd kerpelman: ok, isometime read that.
kristan uccello: i readthat regularly. i'm a fan. todd kerpelman: all right,so people just keep an eye out there. and they'll see your blog postsin the next week or two? kristan uccello: i don't knowif it's going to be in the next week or two. i want to make sure all thedetails are nailed down solid. i don't want to giveanybody bad advice.
so very, very soon. todd kerpelman: i'm trying tohold you to a deadline. kristan uccello:i don't get it. you can't estimatethings like that. todd kerpelman: so by the timethis video's out, all five blog posts will be publishedand they'll be perfect. kristan uccello: todd'sgoing to write them. todd kerpelman: you heardit here first. kristan uccello: thanks, todd.
todd kerpelman: allright, well, cool. thank you very much for joiningus, internet audience. and thank you, krispy. kristan uccello: my pleasure. todd kerpelman: for providingsome really excellent content this week.
kristan uccello: thanks. todd kerpelman: andwe will see you guys in a couple weeks.
bye.
