At the moment I’m playing around with some differentframeworks for game development, but I’m almost certain that (for Android anyway) I’ll keep returning to libgdx. Love the way it’s designed and the ability to easily throw my game into a desktop version for quick testing is the major strength.
The 0.9.2 update has made me even more likely to stay with libgdx after reading this:
Fancy schmancy AssetManager. I haven’t talked about it yet on here but will do so sometime next week, telling you how to use it. It’s incredibly powerful and allows for asynchronous loading of assets. See AssetManagerTest for a taste of what it is capable of.
Now I can ditch the crappy one I wrote for Flip! …
One major problem with me trying my hand at writing games, even simple grid based puzzle games, is that ultimately one needs some artwork. I will state now that I am not artistically inclined. Download Flip! </subtleplug> and you can see that plainly. I doodle as much as the next man when I’m in a meeting at work, but like most engineers this seems limited to constructing expanding geometric shapes and patterns that mimic a structure (seriously, what’s with that, I swear I’ve seen others do this as well. Must be part of our wiring). So how did I tackle the artwork and animation for Flip!?* Well, essentially I cheated.
Everything starts with the design. It’s pretty much unavoidable and I had to revisit it a few times as things evolved and I realised I had made everything too small (note to other libgdx developers – I love the ability to easily test my app on a desktop deployment rather than an emulator or phone, but you forget sometimes that you are working on a bigger screen). The design just needs to be a simple sketch with a vague idea of dimensions / distribution / layout to make it easier to support varied devices.I was then left with three groups of graphical elements to tackle: backgrounds, the UI elements and the animations for the tiles. The background was simple. Once I’d written off the idea to have variable backgrounds, I tore out some notepaper from one of my pads and threw it in the scanner. Job done.
For the UI elements, other than the ripped up notepaper background of the in-game menus, I wanted to get the look to be both uniform (it’s a grid based game after all) and have simple solid colours. With my lack of experience, I didn’t want to invest too much time in anything but “simple” for this very basic game. I found the best way to achieve my goals was to use Inkscape. I’ve used Inkscape a bit before for illustrating things at uni so was fairly familiar with the interface. Because it uses SVG, I didn’t have to worry about neat curves with a pen, I could just draw to my hearts content then work it out in the exports later. I could then change the size of images easily without losing any definition. Once everything was created, into a texture atlas it went and all was good.
Inkscape Export Settings
The tiles were a tougher prospect. If I can’t draw, I certainly can’t animate. For this I turned to trusty old Blender. In fact, I had originally turned to Blender because I was going to render the tiles as 3D and animate them using rotations in OpenGL ES. Luckily, it was equally suited to 2D animation. By sticking an orthographic camera over a rotating tile model I could capture all the frames and then bung them back into a texture atas to manage the animation. Using comic effects with the materials got me the simplistic look I was aiming for while retaining the 3D looks of the animation (IMHO).
Lights, Camera, Action: Note the animation timeline along the bottom
To create my texture atlases in each case, I used an excellent app called TexturePacker Pro. This produced both an atlas and a file used to address the locations used for each image loaded into the atlas. This can then be loaded directly into libgdx using the TextureAtlasclass.
Texture Atlas Pro
* note to self. Stop ending sentences with the word Flip! or at least change the name to not self-punctuate.
I’ve pushed out an updated version of Flip! to the market. It contains a few bug fixes, an updated libgdx backend and 12 new levels featuring a new tile type. This “cascade” tile will cause adjacent tiles to flip when it is flipped.
One of the fixes was to make sure the game rendered properly on the Motorola Xoom. I don’t know if this was unique to that tablet, but for some reason it couldn’t load a texture atlas larger than 2048*2048. Seems rather crap to me, but there you go.
So far it’s not had massive takeup, but as I’ve repeatedly stated, that wasn’t the aim of the exercise and I haven’t put any effort into spreading word of its existence. When I get around to committing some of my other designs to code I will put a bit more time into these things.
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!
Well, I’ve finally uploaded my first app to the Android Market. It’s called Flip! LITE and it’s a simple puzzle game of the sort you’ll see appearing in many other games over the years. The goal is to flip all tiles over to be the same colour in as few moves as possible. Hitting a tile will cause the tiles next to it to flip as well. The app was built using libgdx and what could be mustered from my free time. It’s probably not quite what I had pictured for the first release, but I’ve had to balance out time available vs getting something completed. I did want to have more puzzles in the first release, but these can come in an update soon enough when I have a chance to create them.
Anyhow, give it a go and let me know any feedback. I know it’s not original, and it’s nothing amazing, but that was never my goal with this first app. I’ve achieved what I wanted to do: I’ve gotten myself back into a bit of development, I’ve learned a lot about the Android platform and gotten something published. There’s only up from here 🙂
So what’s next? Well, I’ll be reporting on the progress of the app in the market on this blog. I’ll also be working on the next update (some new levels and some better graphic asset management). I wouldn’t expect a rapid turnaround on this release as the next few weeks are looking pretty busy for me even for the times I’m allowed to get away from work. I also have a few blog posts lined up to cover things I’ve learned throughout the development process and a couple of new app ideas to start on.
A couple of weeks ago I set myself a target of getting my first build out by the end of the month. Well, the month end is looming and I think I need to review that target. So what’s changed?
Well, first of all I’ve had a look at the name and changed it to just be “Flip!”. Homogeneity proper will come some other time, so Flip! will end up being the first app deployed to the Market. Speaking of such deployment, that isn’t going to happen by the end of the month. I just don’t have enough spare time at the moment to focus on app development and I don’t want to release something that’s utterly flawed. Limited is fine, as I’ve got no issues with pushing something out that’s going to need some polishing later. I intend to release the first version with some art assets that may be subject to future change, but the app must work and have the basic structure stable.
What I am getting done by the end of the month is the first set of alpha testing. The game works, and has content, so I’ve pushed it to my flatmate’s tablet and my phone to test it. This means I’ve already hit tablet support, so one goal checked off. I’ve also gotten score recording wrapped up (not really hard to do tbh) and the extensible game engine built. So, what’s left to go before I get a market release done? Other than fixing any bugs that are thrown up or taking on board any suggestions for refinements from my testing, I need to do the following.
Generate some consistent artwork and make sure it’s not too big!
Sort out performance issues on low end devices
A few UI tweaks
Make sure the application lifecycle is correct
After the release I can do a bit of re-factoring before I add new features.
I’ve begun work on my first app. It’s called Homogeneity and it’s a game built with libgdx. The aim is to make it a new take on an old theme of turn based puzzle game.
I’m going to set myself a release target for the end of the month so I need to work out what has to be in the first build. Off the top of my head I think I’ll need the following:
Extensible game engine. As I have an idea where the design is going I should plan to support future features from the go.
Score recording but not score evaluation. As I said, this game is turn based. Now, I have some ideas about how to evaluate scoring (i.e. what’s a “good” number of turns, what’s a “medium” number of turns, etc.), but it’s going to require either a dedicated bit of work to create, or a complete abandonment of my plans and I’ll just fudge it … If I at least capture and record the best score so far I can map this back to evaluations later.
Two sets of levels to give an idea of what I plan to expand in future releases.
All permissions I’ll need. Now, this won’t be quite right. In the future I may require SD card access for a planned feature, but this can be made obvious at the time I request them. The last thing I want to do is keep adding little extra permissions with each release. It annoys me as a users and I can’t believe I’m alone with that. I want to have my minimum permission set in place up front.
AdMob support. This’ll be a LITE release so I should start as I mean to go on.
Tablet support. My flatmate owns a Xoom and I’m eyeing up a Thrive. ‘Nuff said really.
Basic rendering. I just want it to work for now. I can improve things later.