Slashdot Mirror

← Back to Stories (view on slashdot.org)

Getting Started In Android Game Development

Posted by Soulskill on from the android-needs-tetris-too dept.

rbgrn writes "If you're interested in developing a game for the Android platform, there is a lot you need to know. If you have previous experience with game development, moving over to the Android platform won't be all that difficult. You will mostly just need to learn the architecture and API. If you're new to game development, here is a list of must-knows for getting started in Android game development. This is a good starting point for developers seeking to write any type of mobile game."

43 comments

  1. Slashvertisement by Enderandrew · · Score: 2, Insightful

    They're not selling a product here, so much as a concept, but why is this on Slashdot's front page again?

    Mind you, I'm excited about Android, but what here is newsworthy?

    --
    http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
    1. Re:Slashvertisement by Anonymous Coward · · Score: 3, Informative

      More than anything else, this article read (yes, I'm new here) like a generic "Game Programming for n00bs" intro, with occasional references to Android in particular and mobile development in general. There was no real discussion of any specific challenges raised by Android, and no description of actual APIs. Their single "code sample" could have been for any C-like language on any platform.

      It was nice as a brief overview for people who are non-programmers of what goes into programming a game. Not really worthy of Slashdot, though.

    2. Re:Slashvertisement by Anonymous Coward · · Score: 0

      I agree with you, I'm sick of Android being on Slashdot every couple days! I'd much rather read a fun blurb about Tofurky or something.

      I bet Obama eats Tofurky. Oh wait, politics, no!! Boo! Hiss!

    3. Re:Slashvertisement by bonch · · Score: 1

      If it's not newsworthy, why did you stop scrolling through the Slashdot page, click on Read More for this article, and post to it? Slashdot posts stories for people to read and talk about. Maybe some folks would like to discuss game development on Android or other embedded devices.

    4. Re:Slashvertisement by LingNoi · · Score: 1

      This is the first android thing on front page in a long time. Agreed that it sucks though.

    5. Re:Slashvertisement by terminal.dk · · Score: 0, Troll

      I think all the attempted iPhone clones suck. Android included. Android is just another one. Based on Linux instead of BSD like the iPhone.

    6. Re:Slashvertisement by gbjbaanb · · Score: 1

      generally considered that the problem is not the linux base of Android, but the java base for its API. There's a lot of Symbian c++ developers out there with a ton of code they're ready to reuse... except they cannot in Android. A lot of them are also complaining about performance of low-level coding they've had to use previously. They don't want to write image processing routines in java for example.

      Considering Android's built on Linux, and the difficulty in using an API is the features and documentation of that API (and that Google's done a good job there), and the Android low-level stuff is written in C++ anyway, then a C/C++ API would probably have been a better choice for it.

    7. Re:Slashvertisement by g0dsp33d · · Score: 2, Interesting

      Really? Anyone on Slashdot should have enough experience to know coding something that complex is hard, whether it be first-hand or not. Especially when it is for this type of hardware platform. Hell, half of us probably tried making a game at some point. I tried making Pacman in high school and Tetris in Visual C++ / Opengl in college. Neither were as easy as they sound, and that was for relatively simple games on relatively homogenized systems.

      --
      lol: You see no door there!
    8. Re:Slashvertisement by LingNoi · · Score: 1

      Android is going to be running on different phones, processors and architectures so making an app in C++ for the phone means it's only going to work on that one phone, defeating the whole point of cross platform for phone manufacturers.

      and also to be honest, fuck Symbian, the bringers of software patents to the UK. fuck them in the ass with a hot iron rod, everything they touch turns to shit so I hope they don't get anywhere near this. ..and last but not least you can in fact do c apps on android however for the above reasons it's pointless to do so.

      http://benno.id.au/blog/2007/11/13/android-native-apps
      http://devphone.com/java-why-not-write-an-android-application-in-c

    9. Re:Slashvertisement by tobe · · Score: 1

      There is at least one company that sells a product that allows you to write native C/C++ apps once that target many different platforms: I3D

    10. Re:Slashvertisement by gbjbaanb · · Score: 1

      erm.. remember that the low-level Android API is entirely written in C++. And the whole thing runs on Linux.

      So your "cross platform" problems are immediately concerned with the APIs Android and Linux gives you, so your C++ apps will be as cross platform as Java. (ie its not the same as running a desktop app on Linux, Windows and Mac - here you're running solely on the Android platform).

      Symbian is irrelevant, its the huge amounts of code those Symbian developers have that they want to reuse that matters. If they now have to write the same stuff all over again for Android, they're less likely to do so. Why would any of them bother to port to Android if they already have a huge market for Noika phones? If they could port easily (or semi-easily) then I'm sure they would - the market for Android suddenly increases dramatically. To rewrite in Java means they won't until they see a large market already, and that won't happen if they're not developing for it.

      Don't forget that a Java implementation (on mobile) is not as cross platform as you'd think, and mobile phone development is never "it just runs" simply because of the different resources available like screen sizes.

      See the link here where he describes one mobile java developer who had to make 100 versions of his java app to make it run on lots of phone models.

      I think Android on Linux is a good idea, a common platform and a common API means all the hard porting work is done by the manufacturer. Putting Java on just doesn't make sense when you've got that niceness; and you have a large developer base waiting to port their apps and suddenly finding they can't.

      PS. the java used on Android isn't really JavaME, due to Sun licensing. I suppose its a possibility that Google could develop a c++ compiler that turns c++ code into dalvik bytecode, or perhaps (more likely) a C# or VB.NET one. Wouldn't that be fun?.....

    11. Re:Slashvertisement by Nursie · · Score: 1

      "Android is going to be running on different phones"

      Already is, I have it on my Freerunner. It's pretty.

    12. Re:Slashvertisement by LingNoi · · Score: 1

      The example of a 100 different variations of a java program is not on the android platform.

      This is the whole point of android, so that you don't have to do that anymore.

    13. Re:Slashvertisement by geekoid · · Score: 1

      Not really.
      It means you ahve to compile it for different platforms.

      Unless your app really needs the speed, just do it on Java, it's plenty fast.

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
  2. Interesting... by Darkness404 · · Score: 3, Interesting

    I really didn't consider it, but there would be a major market for an MMORPG for Android. Think about it, when you are waiting for a bus you can hop on to finish a quest, if you want you can receive alerts about your character at work and the keyboard would make typing messages easy. The only problem I see with all games for Android is all the phones that could (potentially) use it. For example, a phone with only a touch screen is going to demand a totally different form of input than a phone with both a touch screen and keyboard, as is a phone that is all buttons and no touch screen. And I can see this really being a limiting factor, does the Android marketplace allow you to "restrict" apps to certain phones or download different versions?

    --
    Taxation is legalized theft, no more, no less.
    1. Re:Interesting... by Opportunist · · Score: 3, Interesting

      I've been rolling that idea around for a while now. Tossed ideas what could and what could not fly on a mobile phone.

      Basically what it ends up at is the mobile phone transfer rates and the amount the companies charge. We pay about 20 bucks for 5 Gigs worth of traffic. Ok, people might not play as much as they do with standard PC based MMOs, but then again, I'm sure they will. And 5 Gigs ain't that much traffic. Factor in the mostly horrible stability and unbearable lag and any kind of "normal" MMO is pretty much out, especially when you consider, as you have pointed out already, that input is usually by no means as easy as with PC games. Can you imagine trying the bard twist on the buttons of a cell?

      I'm currently toying with the idea of a turn based/real time hybrid game which would result in a rather slow pace. But then, I'm quite sure people are willing to accept slower gameplay since they're probably playing in a situation where they can't do anything "sensible" anyway, like waiting on a bus or riding it.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    2. Re:Interesting... by VValdo · · Score: 2, Interesting

      This is slightly offtopic, I actually did some research for nethack for Android. Found this thread, and if you look on sourceforge there are a few java implementations of rogue-like games. Of course, with the supremely awesome ConnectBot (the ssh client) + screen, you can pretty much do anything consoley, including games like rogue, MUDS, etc.

      To get back ontopic, Android is actually a cool little platform to learn to program Java in. I've never programmed a line of Java before or ever used eclipse, but after reading the first few chapters of thinking in Java, downloading and installing the SDK on my mac, reading the SDK documentation, and asking tons of dumb questions in #android (freenode), I got my first little all-text game going in about a week and a half.

      Seems like right now when everything is now there is so much good stuff that can be done with Android-- so much "low-hanging fruit" - simple apps that people would love to have if only someone would write it.

      Lovin my g1,
      W

      --
      -------------------
      This is my SIG. There are many like it, but this one is mine.
    3. Re:Interesting... by chibiace · · Score: 0

      vodafone nz charges something like NZ$1/10MB now i think. too expensive even to play MUDs.

      --
      he who controls the spice controls the universe
    4. Re:Interesting... by fan+of+lem · · Score: 1

      MMOs in mobile devices remind me of Charles Stross' Halting State. It also introduces the concept of "servers" as a cloud where data is passed around via a peer-to-peer protocol (fragments of data - encrypted - reside on all players' devices).

    5. Re:Interesting... by Opportunist · · Score: 1

      Well, I was on a pay-per-MB line back when MUDs were in fashion, so I know you can actually get quite far with 10MB text (if the client allows you to cut the spam to a minimum, like only giving room desc on demand and such). So doing a MUD would probably be quite possible and maybe even affordable, but, well, this ain't 1995 and people are used to MMOs. Reading is sooooo 90s.

      You can, of course, limit updates to about once a second or even less, with some good motion prediction, but you will invariably end up with jumpy graphics. But I could well see people accept that, considering the state current mobile games are in. Hell, they'd probably blame their cell and its mediocre processing power. :)

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    6. Re:Interesting... by IorDMUX · · Score: 1

      Hmm... It would appear that Runescape is poised to make a comeback, then. It should be a cinch to port to Android, it can be played in small bites, and it's limited interface makes the phone-migration issues far simpler, too.

      Not that I'm thrilled about the possibility or anything--I lost a college roommate to Runescape for a while... I still remember him staying home from class to mine ore and wander through town shouting "Selling cooking pot!"... "Selling pot!"... "Selling high quality pot!".

      I believe he made a veritable in-game fortune dealing his pot on the back streets of whatever-ville.

      --
      >> Standing on head makes smile of frown, but rest of face also upside down.
  3. Good general guide for game development by corsec67 · · Score: 1, Interesting

    Learning how to write AI is out of the scope of this article but the general idea is that the AI will press buttons just like the user does.

    I hate games that don't do this. If the computer player and I are the same species, we should have the same limitations. Why should the computer player be able to do more stuff than a human player?

    --
    If I have nothing to hide, don't search me
    1. Re:Good general guide for game development by QuantumG · · Score: 1

      Because you have a lot more computational power available to you (note: it's between your ears) than the computer player.

      --
      How we know is more important than what we know.
    2. Re:Good general guide for game development by Anonymous Coward · · Score: 2, Funny

      No, I don't. You insensitive clod.

    3. Re:Good general guide for game development by Jimmy_B · · Score: 5, Insightful

      I hate games that don't do this. If the computer player and I are the same species, we should have the same limitations. Why should the computer player be able to do more stuff than a human player?

      Because reproducing the player's limitations is an enormous amount of work for nearly zero benefit. You can either spend months writing code to compute what the bots can see, AI to make it look around at the right times and remember where players that have ducked behind cover were and predict where players might come from, or you can just let the bot see through walls. If you want the bot to only use the buttons the player does, you then repeat that sort of problem twenty times, each with a theoretically possible solution but extremely tricky solution. Forcing the bot to use the player's interface is basically a waste of time, time which could have been spent on features that actually make the game fun.

    4. Re:Good general guide for game development by MobileTatsu-NJG · · Score: 1

      If the computer player and I are the same species, we should have the same limitations. Why should the computer player be able to do more stuff than a human player?

      Compensation for lack of good AI. Usually the reason for lack of good AI is processing power, but I cannot tell you first hand how true that is.

      --

      "I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)

  4. using mobility, blending realities by Singularitarian2048 · · Score: 4, Interesting

    I'd like to see an RPG that uses the google phone's GPS feature to involve you in quests that blend real life and the video game universe. Perhaps certain tasks can only be achieved from a particular location in RL. Perhaps you are assigned to meet a particular player in RL in a certain location and achieve some goal together.

    This is like Hideo Kojima's game Boktai: The Sun is in Your Hand, which comes with a solar sensor for your Gameboy, and certain portions of the game cannot be completed without actual sunlight. However, GPS adds a lot of potential that hasn't been explored.

    1. Re:using mobility, blending realities by Anonymous Coward · · Score: 1, Funny

      You best make sure you don't put the quest at the bottom of a cliff or the ladies toilets though or you'll be meeting some pretty mean lawsuits!

    2. Re:using mobility, blending realities by tobe · · Score: 1

      I so want this to happen it hurts. Would be a huge amount of fun to develop as well. If anyone's at all interested in exploring this idea then get in touch.

    3. Re:using mobility, blending realities by T.E.D. · · Score: 1

      So instead of 30 people crowded on a mob spawn online, you'd have 30 people looking at their cellphones crowded around a mob spawn in RL? Ick.

    4. Re:using mobility, blending realities by Anonymous Coward · · Score: 0

      There have been quite a few experiments with augmented reality games, which is what you're describing there. There's an interesting paper on augmented reality and also 'seamful design' I looked at whilst studying you can find at: http://eprints.gla.ac.uk/3423/01/Gaming_on_the_edge.pdf. The main premise of the game described there was to collect coins or steal them from other players by physically being in the correct location, GPS would determine that you were in range to collect or steal a coin.

  5. Re:Not a gaming platform people by LingNoi · · Score: 1

    um, ok..

  6. Great Article. by dkarma · · Score: 2, Funny

    Clean and concise. Tells you exactly what you need to know. I've been looking for this exact information for the last month now. Nice to finally have it in one spot.

  7. How about writing a Web game? by DraQ · · Score: 1

    Write a Web game application and ensure it works smoothly in the Android browser. i.e. Tweaking the CSS for bigger buttons etc. etc.

    BONUS: Should work on the Iphone too and any Web browser ... yowsers!

    I think the most compelling games platform is the Web. Someone needs to write a cool simple game like BRE or Planetarium. =)

  8. the platform is cool, the service is expensive by Speare · · Score: 1

    While I have all the game development experience, and the Java development skills, and the interest in supporting the Android platform in my spare time, I have to say that at this point, I can't see spending the dough on buying a G1.

    I don't mind the idea of paying for a data plan for a data-oriented device, but I just don't need a phone. The cheapest voice plan is more expensive than the data plan. With the required voice plus data plus hardware, I'd pay $1,520 over two years. Many little apps are being released for free (which is as it should be) but we have yet to see how for-pay apps will fare on the Android Market.

    There's no way for users to get a G1 with no voice plan, as they do with a Sidekick. AT&T apparently briefly offered a "deaf users" plan, or said they were going to do so, but then retracted that offer.

    I guess the only other option would be to develop what I can on the SDK without owning a device, then ask other people to help me test it. That doesn't really seem particularly fun or useful, if I can't use the apps I write.

    --
    [ .sig file not found ]
  9. Performance with Java by Dan+East · · Score: 1

    I'm not java expert, but I have written some things for Blackberry (a Klondike Solitaire game for one). I've done some very, very performance intensive work on Pocket PC (Quake 1 & 2, my own 3D engine with ARM ASM optimizations, etc). All in all, Java will be a substantial hindrance and cap the performance of what can be achieved on the hardware when it comes to real-time rendering.

    As a small example, most mobile devices use 16 bit RGB 565 pixel format, and the CPUs are RISC 32 bit. So for maximum performance, you try to always work with two pixels at once to halve the instructions required. With java, if your pixel buffer is of a 16 bit type then you cannot simply cast a pointer to a 32-bit aligned value in the array and then do 32 bit math on it. At the very least you will have to pack and unpack the two shorts individually. I hope someone can correct me if I'm wrong on that (that you can do 32 bit math on two adjoining, aligned 16 bit values with no extra overhead), because I'll certainly make use of it.

    With these types of devices, if you work within the APIs - using available drawing primitives and hardware rendering capability - you'll be in decent shape. However if you need to do direct pixel manipulation (rotozooming, custom 3D renders, voxel terrain, bumpmapping, etc) then the language will be barrier.

    When performance is most important (inner loop of texture mapper rasterizers for example), nothing can beat hand-coded ASM native to the CPU. I have a friend who can code StrongARM / XScale ASM like a fiend. He can take my best, carefully optimized C loops and usually cut the execution time in half over the compiler.

    So not only can't you do decent high-level performance-optimized coding in Java, but the option of hand-optimized routines native to the processor are out.

    --
    Better known as 318230.
    1. Re:Performance with Java by RealTime · · Score: 1

      Android includes an OpenGL API. I have personally seen Quake 1 running on the TMobile G1, which has an on-board GPU as part of the Qualcomm chipset in the phone.

      Also, at the recent Google Summer of Code mentor summit in October, an Android engineer mentioned in a presentation to attendees that native (ARM) code .so files would be bundle-able in .apk files soon. These libraries would be accessible via JNI. They would initially only have access to libc and libm in the first incarnation, though.

      So, yes, I do believe Android is a mobile gaming platform.

      (This was discussed in a public forum at an open source conference hosted at Google, so I don't believe it is secret information...)

      --

      Yesterday it worked; today it is not working; Windows is like that...

    2. Re:Performance with Java by Dan+East · · Score: 3, Interesting

      Nice. As a side note, ATI contracted me to do the Quake GS OpenGL ES conversion a few years ago (the NDA has expired). I got to fly out to one of their labs in California to do performance tuning with the guy who drafted the OpenGL ES specification. It was a nice experience.

      As another side note, I had asked the marketing guy who arranged for me to do the conversion (it was done, along with MotoGP by another group to market ATI's new mobile 3D chipset) to not release the source. It was of course GPLed, and since ATI was only demoing it on their own hardware and not distributing the executable, the source did not have to be released. I wanted to contact Id about potentially marketing the game. The ATI marketing guy's contract ran out, so someone else started demoing it. That person handed the source code over to the first guy that came along. He ended up contacting me with some questions about it, which is how I found out. I told him that he would have to release the source if he distributed the game since it was GPLed. He had already flown to Id headquarters and met with Todd and had a contract in place. He then changed what he said, and told me that my work was crap, and he had another programmer totally redo the conversion (which is complete BS). I have proof that their version still incorporates that code that I modified and added under the GPL. In Quake GL the particle textures are hardcoded into the engine. They used a simple square texture which looks exactly like what was done in the software engine (a square particle was used in the software renderer purely for performance). I thought it looked particularly poor having a square particle, so I made it into a more rounded, diamond-like shape. That is what is in their version to this day.

      So if the version of Quake you're talking about is from Pulse Interactive, then thanks, I'm glad you like my work, and you were seeing software running in violation of the GPL.

      --
      Better known as 318230.
    3. Re:Performance with Java by Civil_Disobedient · · Score: 1

      Completely off-topic, I just wanted to say that I've been a big fan of your work on the ARM platform since your Quake port all those years ago (that and DEXplorer) and really appreciate your efforts.

  10. Evening the playing field by ClosedSource · · Score: 1

    The fact that Symbian C++ developers have a bit of a learning curve to climb before they can produce android apps should be a source of encouragement for anyone who is starting from scratch to develop one. Let one of the kids on the bench have a turn at bat.