Getting Started In Android Game Development 43
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."
Slashvertisement (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?
Re: (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 wo
Re: (Score:3, Interesting)
Re: (Score:2)
This is the first android thing on front page in a long time. Agreed that it sucks though.
Re: (Score:2)
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.
Re: (Score:1, 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.
Re: (Score:2)
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 o
Re: (Score:2)
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 fo
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
"Android is going to be running on different phones"
Already is, I have it on my Freerunner. It's pretty.
Re: (Score:2)
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.
Evening the playing field (Score:2)
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.
Interesting... (Score:4, Interesting)
Re:Interesting... (Score:4, 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.
Re: (Score:3, Interesting)
This is slightly offtopic, I actually did some research for nethack for Android. Found this thread [google.com], and if you look on sourceforge there are a few java implementations of rogue-like games. Of course, with the supremely awesome ConnectBot [google.com] (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 a
Re: (Score:2)
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 u
Re: (Score:1)
Re: (Score:2)
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 belie
Good general guide for game development (Score:1, Interesting)
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?
Re: (Score:2)
Because you have a lot more computational power available to you (note: it's between your ears) than the computer player.
Re: (Score:2, Funny)
No, I don't. You insensitive clod.
Re:Good general guide for game development (Score:5, Insightful)
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.
Re: (Score:2)
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.
using mobility, blending realities (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.
Re: (Score:1, Funny)
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
um, ok..
Great Article. (Score:2, Funny)
How about writing a Web game? (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. =)
the platform is cool, the service is expensive (Score:2)
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
Performance with Java (Score:2)
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 pe
Re: (Score:1)
Also, at the recent Google Summer of Code [google.com] mentor summit in October, an Android engineer mentioned in a presentation to attendees that native (ARM) code
So, yes,
Re:Performance with Java (Score:4, 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.
Re: (Score:2)
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.