Android Gaming and the Importance of Multi-Touch

by Antonio Wells Jan 12, 2010 2:00 PM – 17 Comments

Andy Rubin, VP of Engineering at Google for Android, recently commented on Multi-touch for Android devices at CES 2010.

“It’s not an America versus outside America kind of thing. It’s a decision that is a result of the OEM model. I personally don’t like two-handed operations… there is no conspiracy.”

Don’t be naive and forget how significant native multi-touch ability can help Android gaming with on-screen controls.

Android gaming in comparison to Android Apps or even competitor iPhone gaming at this point is futile. Not to say that this won’t change, but to exclude this feature for developers to take advantage of in so many operating system releases further hinders the platform. Actually, multi-touch is in the SDK but disabled unless your phone is “Rooted” (the lesser percentage of Android smartphone customers). Google claims to leave this feature at the discretion of the OEM. But rumors circulate that Apple asked Google not to include multi-touch and Engadget’s reference above hints the reason at one Google Executive’s preference.

The platform is definitely taking steps towards advancing in Android Gaming with hardware releases like the Nexus One and software releases like yesterday’s public release of Android SDK version 2.1, however major obstacles like low internal memory, poor battery life, weak application sales still exists. Natively and unrestrictively allowing multi-touch is one step forward with for Android Gaming.

What are your thoughts on the future of Android Gaming? Comment Below:

Tags: Android, Android Gaming, Andy Rubin, Multi-touch, Rants

Categorised in: Apps Blog

17 Comments

By Min on January 12, 2010 at 2:30 pm:

There IS native multitouch in non-rooted 2.0 and (I assume) 2.1 devices. It’s the specific apps themselves that don’t use them. IE the stock browser, the maps app, the stock image gallery apps don’t support multitouch for pinch zooming. But other apps, such as Dolphin Browser or XScope or Picsay allow for pinch zooming, because the apps were written with that support in mind. Again, this is all in non-rooted devices.

Reply
- By anon on January 12, 2010 at 2:33 pm:
  
  I wonder if the writer of this article has even used an Android 2.0 device…what a waste of time having this in my RSS feed.
  
  Reply
By anon on January 12, 2010 at 2:32 pm:

Is this FUD or something? Multitouch works perfectly fine on my unrooted DROID for applications implementing it. a perfect example is Dolphin Browser, which has pinch-to-zoom.

The issue is Google applications not allowing pinch-to-zoom for the DROID, in Maps, Browser, and the stock keyboard. Maps is the only application you really can’t replace at this time.

Reply
- By Android Tapp on January 12, 2010 at 3:14 pm:
  
  Wow, it’s funny how people don’t read the content nor context… we’re talking about Android Gaming and Multi-touch. Insults… epic FAIL!
  
  Reply
  - By Donovan Colbert on January 12, 2010 at 4:00 pm:
    
    I think Anon is suggesting that the article misses a bigger point, that it doesn’t make sense to have multi-touch disabled for core apps.
    
    “For me, the important issue isn’t that multi-touch is disabled, it works with aftermarket apps. For me, the issue is that it is disabled in core apps that come bundled with the device – that is what bothers me”
    
    Does that make it clearer what Anon was trying to say?
    
    Try being less defensive and paying attention to reader input. Your article isn’t complete but brings up important points and observations.
    
    Reply
    - By Android Tapp on January 12, 2010 at 4:50 pm:
      
      Debates are always welcome here. But I think you guys fail to coorelate both your arguments to the the topic in discussion which can’t be said any simplier: “Android Gaming” and “Multi-Touch”. The lack of Google approved native support for multi-touch and their core apps is a topic of another discussion (actually I’ll thank you guys for giving fuel for a separate blog post to write on at a later date).
      
      Reply
      - By anon on January 12, 2010 at 4:53 pm:
        
        …and our point is that everything you’ve said on the topic is incorrect. Google provides enough to work with multi-touch, and games already take advantage of it.
  - By anon on January 12, 2010 at 4:03 pm:
    
    Yeah, because Games aren’t Apps…?
    
    Try playing “Pong Multi Touch” on the Android Market. Works fine on my unrooted Droid.
    
    From your article, two incorrect statements:
    
    1) “…to exclude this feature for developers…”
    
    2) “Actually, multi-touch is in the SDK but disabled unless your phone is “Rooted” (the lesser percentage of Android smartphone customers)”
    
    3) “Natively and unrestrictively allowing multi-touch is one step forward with for Android Gaming”
    (statement seems to imply it currently is restricted)
    
    If your hardware can handle it (Nexus One, DROID), and you have Android 2.0+, then you can use multitouch applications completely “unrestrictively”.
    
    The ONLY thing that’s restricted is what I mentioned before. Pinch-to-zoom and multitouch keyboard usage in the stock applications.
    
    Read the API reference if you think it’s “hidden” (if you can understand it, that is) — note all the “which pointer” language being used, which allows you to view ALL touch events for various pointers concurrently: http://developer.android.com/reference/android/view/MotionEvent.html
    
    Android knowledge FAIL.
    
    Reply
    - By anon on January 12, 2010 at 4:04 pm:
      
      EDIT – “3 incorrect statements” is what I should have said.
      
      Reply
  - By Joe Vega on January 12, 2010 at 4:07 pm:
    
    My understanding is Google/Motorola/HTC have simply chosen to not enable on the browser and gallery (even though the Milestone in England does have multitouch enabled in these apps).
    
    Since multitouch is available in non-game apps (e.g. Dolphin Browser), I would like to know why Games would not be able to use multitouch? If our assumptions are incorrect, please explain why.
    
    Reply
    - By anon on January 12, 2010 at 4:57 pm:
      
      Games CAN and DO use multitouch. The writer of this article has no idea what they’re talking about.
      
      Reply
  - By ari-free on January 12, 2010 at 4:58 pm:
    
    if dolphin can have multitouch then so can games. And they do.
    
    Reply
By Donovan Colbert on January 12, 2010 at 3:56 pm:

So I agree, the article is poorly written in that it seems to assume that all North American Android phones have hardware multi-touch disabled, when it is well documented that Droid and all (?) recent Android 2.0 and 2.1 phones support hardware multi touch. I only know for certain that the Droid and Nexus have hardware multi-touch support, so, forgive me if there are others that do not.

Beyond that, in the native apps that exist, the lack of multi-touch is not a deal breaker. Tap to zoom works fine for most of those apps. It is arguably less granular than multi-touch, but it is also more precise. I find that Dolphin tends to be pretty sensitive and the pinch-to-zoom is not as accurate as I would like it to be, but I recall having similar experience with iPhones and iPod Touch units I’ve played around with.

Why we should talk about this *strictly* in the context of games is beyond me. It has an impact across the Android ecosystem – and the fact that there is a drought of quality games across the Android platform and that where multi-touch *is* implemented, it is *not* in games, makes it inevitable that non-game apps need to be mentioned in any meaningful discussion of multi-touch on android platforms.

Now, it strikes me that with under-performing sales, battery life issues, and memory challenges – app design is already handicapped compared to the *other* big app store for mobile devices. The article indicates, and I believe is correct, that G1 Android devices do not support multi-touch unless they are rooted. Those facts combine to mean that backwards compatibility to make a game that is as broadly compatible and accessible as possible means that currently developers must throw out Multi-touch, or design a multi-touch (Android 2.0 or higher) and a non-Multi-Touch (G1) version of their game. That is a lot of development overhead for a platform that seems hesitant to actually pay for apps – especially when there exists a device that supports multi-touch at all generations, has no memory issues, and has an app store that has made developers relatively large sums of money for very small investments.

Which one would YOU develop a game for, considering these things?

I think this paints a dismal picture of the prospects for iPhone quality entertainment and gaming apps to come to the Android platform. It may happen, but it should happen sooner, not later – and Google should be aggressive about trying to correct this issue, way more aggressive than they seem to be.

Reply
By ari-free on January 12, 2010 at 4:55 pm:

The Droid has multi-touch if games need it. But more important is for android games to distinguish themselves from iphone games. Android phones have keyboards and trackballs so the games should use them instead of being the same old ‘twist and touch’ iPhone ports.
Apple will probably never make an iPhone with all this extra stuff as they are interested in simplicity but gamers aren’t. Apple comes out with the Magic Mouse but gamers want a mouse with scroll wheels and all these buttons. Likewise with smartphones. It’s the story of PC gaming all over again.

Reply
By Patrick on January 13, 2010 at 3:44 am:

I agree with most all the commenters here. This article is a complete HACK, and the fact that it was published without any research is horrible! Android 2.x natively supports multi-touch in all applications. Because Google has chosen not to implement multi-touch in the applications that they ship with the device does NOT mean that the device cannot handle it.

The system natively supports *AND* implements multi-touch out-of-the-box in Android 2.x. The native Latin IME soft-keyboard (i.e., for all languages using the Latin alphabet) is multi-touch aware. Also, any application that codes for multi-touch events can take advantage of them, regardless of whether the device is “rooted” or not. The only difference is that the non-North American versions of the MOT Milestone (aka, Droid) have multi-touch natively enabled in the browser, and the NA/US version does not. But this has nothing to do with whether the device has been “rooted”.

What a poorly written article! Any game that wishes to take advantage of multi-touch on Android 2.x can, without any issues whatsoever! Such shame that an Android-centric site is spreading such FUD!

Reply
- By jared on January 21, 2010 at 12:32 pm:
  
  i have a nexus one and i completely agree with the writer. at first i did not care about the lack of multi touch and tried to ignore it. for web browsing it is a complete non issue. but it is a HUGE missing feature for the phone overall. it affects TYPING and GAMES. also half the time i cant press a button because part of my palm is already touching the screen. that is why it is complete nonesense to argue otherwise. without native support the problem of holding the phone will never go away. plus there are barely any multi touch apps out there, wow pong multitouch! how about every game have multitouch!?!?! i dont care about dolphin and browsing. i want typing and games and native OS support. and to ask developers to code for it is just making them do extra work that google could have already enabled.
  
  Reply
By rzrshrp on January 13, 2010 at 9:31 am:

Please fix the facts in your article. The Droid has hardware, and sdk support for multitouch. I’m not sure about the older phones but I’d imagine that with how competition works, a great majority of android phones released from now on will also be multitouch enabled. It is still a mistery that multitouch is not enabled in Google’s own developed apps.

While I’m grousing, I also wish that apps on the droid swiped more. Why doesn’t the gallery swipe? It’s much quicker than tapping an onscreen button.

Reply