[ A bit late on this post, but as the guy in Ghost Busters 2 said when the Titanic arrived in New York… Better late than never. (What? too obscure?) ]
So my friend and I have released our first Android game!
It is small in all respects. We intentionally picked a very simple game so we could focus on refining our process of working together, and the tech and idioms specific to Android, and how the release & advertising process works.
However, while small, we still wanted it to be a quality and polished effort.
And I’m happy to report that I think we succeeded gloriously in all areas 😀
It’s a fast paced “whack-a-mole”-esque game set under the surface of the ocean. There’s a circuitous mess of oil pipes which… low and behold… begin springing leaks! You must rush around and fix the leaks as fast as possible. As the oil content of the water rises, the poor fishes who are swimming around die and float to the surface 🙁 Poor fish.
And no matter what you do, you always lose. (It’s sorta like the helicopter game, you always lose, but you’re trying to beat your previous high score for how long you stayed alive).
There are a few extras thrown into the mix, like a supply plane that drops power ups randomly. And a rescue boat you must find when you run out of bandages for fixing pipes. But like I said, it’s a small game in all respects.
There are a few interesting things (at least I think so) technically that bear mentioning. The game is written entirely in Java, based on a great library called libGDX. GDX abstracts away the platform specific stuff (Think SDL, or SFML) and provides back ends for PC & Android. The great thing is that you can develop right on your computer, run and debug right on your computer (much nicer than debugging over the USB link) which makes iterations MMUUCCHH quicker.
As GDX develops it’s starting to provide a robust set of base classes for game development. Which is even nicer than it sounds because the GDX author is a performance Nazi! (You know… the good kinda Nazi) Always benchmarking and improving. So if you go that route you really will get the best performance possible out of Java. And the heaviest lifting is done in native Android back ends.
For this project, the team was just me (programmer) and my friend Mike (artist/anything creative). We have already started pre-production (doing a much more robust planning stage this time around) and have brought in a long time friend of ours who works in the AAA industry to do art and game design. We’re learning a ton from his experience and adapting some of the process he has seen that work well. (Still keeping the process pretty light weight as this is just a 3 man side project.)
With both of these artists though we officially have WAY more asset bandwidth than technical bandwidth. And our next project is a fair bit more ambitious which worries me. So I’m mulling over the idea of a 2nd programmer. For side projects I’ve found it exceedingly difficult to find competent programmers who have both the desire, and time to devote. Which is to say I’ve never found a programmer with those 3 elements 😛 Also if there is going to be money involved (which we sure hope there will be lol) then it gets more difficult bringing in someone you don’t know. There can be some sticky legal issues down the road.
Well anyway, I’m really rambling now, so go give our game a try if you have an Android phone!