When I was writing Flip! I started with grand schemes. I wanted to make the engine completely flexible so I could support all sorts of form factors, screen rotation, system power, etc. I also wanted to be able to define all sorts of characteristics of each level – changing backgrounds, sounds, colours, look & feel and so on.
As I wrote the app, I began to realise just how daft this was. For something being created with such limited visible complexity and for a very small target audience, I was spending far too much time adding in the potential for these features that wouldn’t be noticed unless one actually dug into the source code! I’ve always maintained that one of the best games in existence is still Tetris on the original GameBoy (you know, the green and black screen one). The gameplay (and of course the music) was spot on. It didn’t need massive complexity and it didn’t need startling visuals. It was then, and remains now, a complete win.
With games on Android there are still some things that are worth putting the extra effort into supporting. We all hear the claims of hardware fragmentation problems, and this hits home more than ever when designing a layout for different screen sizes and aspect ratios. For Flip! I took the approach of having the layout work itself out from the screen size by saying, for example, I want to make sure at least 4/5 of the screen is devoted to the game area itself and then working around that. I’ve tested on a few different devices that tend to fall into three main aspect ratios and it seems to work well as an approach.
I’ve kept the artwork fairly simple. I’m not an artist so don’t actually have anything to offer by adding all sorts of variable backgrounds. For the tiles I cut myself back to just a couple of different colour options (Black/White and Red/Blue) whereas originally I had wanted each level to define the RGB values of the two colours used. I don’t think this is a great loss to the game, but saved me a hell of a lot of effort.
All of these changes came as part of a (necessary) re-write and I’m much happier with the underlying code as a result. It’s cleaner and easier to maintain, while still leaving me very happy with the end result. I’ll be taking a lot of these lessons into the next app I write.
The moral of this post is this: don’t think that limiting your ambition is a bad thing. It’s very easy to be over-ambitious and this has the potential to leave you in a state where you’ll never actually finish anything! It’s a lesson I was taught many years ago by the chap supervising my thesis, and I have to apologise to him that it’s taken me this damn long to learn it!