I work and live in London doing project management in the finance industry. In my spare time I'm trying to get some Android development done to keep my hand in.

Mar 092012

Another gap in posting, but a productive one. In January I was investigating some cross platform Lua based frameworks (Moai and Gideros) but between a skiing holiday and recovering from injuries sustained while on a skiing holiday I didn’t get beyond a few proof of concepts. Both are worth a look, and I’ll probably return to them in the future, but my investigations were derailed by this post on the Inside Blackberry Developer’s Blog.

So, with PlayBook OS 2.0 comes (limited) Android support and RIM were offering PlayBooks to developers who submitted apps within a timeframe. Hard to resist really (and it’ll be interesting to see how this pays off). As I have no willpower I went ahead and signed up, hoping to easily repackage Flip! for the PlayBook. I ran into immediate problems as (among other things) native code in Android apps is not yet supported, but this provided me with an opportunity to pick up one of my other to-do list items and learn to use cocos2d-x along with relearning C++ so I could re-build Flip! using the BB Native SDK. I’ve now completed this and just had the app approved on the App World! I eagerly await my new shiny shiny and will tell all about it when it arrives.

I’ll get a post up this weekend about the process of signing up for PlayBook development and my first impressions.

 Posted by on March 9, 2012 at 10:51 pm
Feb 052012

I buy a lot of random geeky stuff (evidence: the second copy of Aliens vs Predator for PS3 I bought only so I could get another plastic facehugger), but one of my geekiest recent investments has to be CPU Wars Volume 1.0, and I couldn’t be happier. CPU Wars is the brainchild of Harry Mylonadis and his project has just come to fruition after successful Kickstarter funding. CPU wars is a top trumps game featuring the specs of thirty different CPUs. Ever had an argument with a friend about whether the Phenom II is better than the Core i5? No, neither have I, but now you can and the result can be decisive (SPOILER ALERT: the Phenom II is inferior in all but one category)! Anyway, head over to http://www.cpuwarsthegame.com to check out more on the history and future of CPU Wars and to pick yourself up a deck or two.

Master Chief Looks Up The Specs For 343 Guilty Spark

Jan 222012

I bought myself a Macbook Air last year to replace my ageing laptop. The theory was that I’d be using cross platform apps so the underlying system didn’t matter. Or rather it didn’t matter enough to outweigh the pretty :)

Anyway, not all of the niggles I have are down to OS X (Apple’s “we must have our own way” GB keyboard is bloody awful and seems designed to piss off developers), but many are and I’ve just come across another. Trying to set consistent environment variables across all apps, regardless of whether terminal based or launched from an icon is an absolute mess. Worse still, Apple doesn’t seem to offer any standard friendly configuration methods for environment variables. Pricks. Anyway, the best resource for troubleshooting these that I’ve found recently is this post on stackoverflow. I’ve reproduced it below in order to ensure it is captured and kept!

There are several places where you can set environment variables.

  • ~/.profile: use this for variables you want to set in all programs launched from the terminal (note that, unlike on Linux, all shells opened in Terminal.app are login shells).
  • ~/.bashrc: this is invoked for shells which are not login shells. Use this for aliases and other things which need to be redefined in subshells, not for environment variables that are inherited.
  • /etc/profile: this is loaded before ~/.profile, but is otherwise equivalent. Use it when you want the variable to apply to terminal programs launched by all users on the machine (assuming they use bash).
  • ~/.MacOSX/environment.plist: this is read by loginwindow on login. It applies to all applications, including GUI ones, except those launched by Spotlight in 10.5 (not 10.6). It requires you to logout and login again for changes to take effect. There is no reason to use this one any more.
  • ~/.launchd.conf: this is read by launchd when the user logs in. It applies to all programs launched by the user, GUI and CLI, on 10.5 and 10.6. Additionally, you can apply changes at any time by piping this file into launchctl (maybe grep ^setenv first if you have other commands you don’t want to run). Then the new variables apply to any application launched by launchd from that point on. This means you should restart Terminal.app for the new variables to cascade down into the shells it launches.
  • /etc/launchd.conf: this is read by launchd when the system starts up and when a user logs in. They affect every single process on the system, because launchd is the root process. Again, to apply changes to the running root launchd you can pipe the commands into sudo launchctl.

The fundamental things to understand are:

  • environment variables are inherited by a process’s children at the time they are forked.
  • the root process is a launchd instance, and there is also a separate launchd instance per user session.
  • launchd allows you to change its current environment variables using launchctl; the updated variables are then inherited by all new processes it forks from then on.

Sample setting an environment variable with launchd and storing it into your personal config so it works for your login even after your reboot:

echo setenv REPLACE_WITH_VAR REPLACE_WITH_VALUE >> ~/.launchd.conf

Now, launch your GUI app that uses the variable, and voila!

Jan 082012

I set myself a couple of goals over Christmas to get some Android development done and migrate this blog onto a new host. So, how did I do? The answer is: better than I expected. Migration done, some code written up (no new release though as I want to put a bit more in).
I’ve also set up a new blog that I’ll be writing about once it’s ready for public consumption. This blog is for a friend of mine who is running from John o’Groats to Lands End this year to raise money for the Royal British Legion (a charity for those who are serving and have served). That’s over 30 marathons in a row! This chap is insane, but insane with a big heart.
Anyhow, am currently in a taxi to the airport as am of skiing for a week so will provide an update on my return.

 Posted by on January 8, 2012 at 3:32 am
Dec 312011

I’m currently in the process of migrating hosts to the wonderful people at Arvixe.  I’ve been very impressed with their pre-sales and initial tech support so far so let’s hope it continues!  Right, back to sorting out my e-mail ….

 Posted by on December 31, 2011 at 5:38 pm
Dec 292011

Q4 of 2011 has been somewhat hectic for me and so I’ve put no time into any Android development.  Little drabs of time are getting thrown into forums & comments here and there, but nothing productive.  I’ve also totally screwed the images on this site so am in the process of sorting that out.  As there’s a three day weekend coming up (and allowing for a massive 1st January hangover), I’m going to dedicate a few hours on Saturday and Monday to:

- Updating Flip! with some feedback received over at the Making Money With Android forums

- Getting some code written up for some of my parked ideas

- Sorting out this blog

I’d give myself a 75% chance of actually getting round to this!

 Posted by on December 29, 2011 at 1:46 pm  Tagged with:
Sep 232011

At the moment I’m playing around with some different frameworks 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! …

 Posted by on September 23, 2011 at 12:45 pm
Sep 162011

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 (Ctrl+Shift+E)

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

Texture Atlas Pro

* note to self.  Stop ending sentences with the word Flip! or at least change the name to not self-punctuate.

 Posted by on September 16, 2011 at 1:02 pm
Sep 112011

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.

 Posted by on September 11, 2011 at 5:47 pm
Sep 062011

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!

 Posted by on September 6, 2011 at 6:29 pm