Slashdot Mirror
Getting Started In Android Game Development
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."
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.
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.
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.
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.
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.