Game created while learning Unity 3D. First person take on a classic.

 Play Online



  Solo project – cross platform game. Now available on Google Play and coming to the Apple app store.


    PixelMix – Solo project. Draw you own tunes with Facebook and Twitter integration.



Gambling portal website and games.  Created the client wrapper and 8 games.



  Lead developer in the team building the BTvision video on demand portal on the YouView platform.


Handling asynchronous calls can be a pain. When we make a call like load() there is really only two thing that can happen we get success or failed. For 90% of applications that’s all we need. The native flash API is unwieldy and messy and overly complex.

I was using something I was calling a fluent responder but it was pointed that this is similar to the JS design pattern promises. There is a javascript proposal here and a nice JS implementation here and Shaun’s as3 version here promises.

I’ve since tweaked my implementations to be more true to these versions but with the focus on making it simple to use in as3. I’ve called it a pledge to differentiate and the code is on github here on github.

Ok so what is it. Basically I simple way of handling asynchronous calls in a nice clean manner. Here is what a using a file loader looks like using a pledges.

    public function Example() {
        var loader:FileLoader = new FileLoader();

    private function successHandler(event:Event):void{
        var xml:XML = XML(;

    private function errorHandler(event:IOErrorEvent):void{

    private function progressHandler(event:ProgressEvent):void{
        trace("loaded:" + event.bytesLoaded + " of total: " + event.bytesTotal);

So the call load() is returning a pledge object to which we can add our handlers. Its very simple we can added as many handlers of either type as we want or none at all. There is no garbage collection worry about because as soon as success or failuer is triggered its automatically cleaned up. We can also pass the pledge around if we need to.

So to create a class that makes a pledge our loader now look like this

 public function load(url:String):IPledge{
        var pledge:Pledge = new Pledge();
        var request:URLRequest = new URLRequest(url);
        var loader:URLLoader = new URLLoader();
        return pledge;

The first thing to note is the return type is IPledge which gives our listener the ability to add handlers but not to trigger the pledge them selves. We then create our new Pledge object. Next we set up the loader and map the native as3 loader events to it. Finally we call load. You can use this for almost any asynchronous calls. Progress updates are optional.
That’s it, dead easy.


I’m going to start with a disclaimer this is not a fully fledged polished game engine more a proof of concept and hopefully something to show the way. If you want more features then please add them 🙂

So I wanted to create a little demo showing what Entity Systems can do for you and why you should care. Now they solve a lot of structural issues but also by there nature are data driven. This means by being a bit clever we can get automated serialisation. A fancy way of saying we can save the game state with out writing any special code. If we are a bit smarter still we can create an Editor that will magically work for any components we add. What’s more this editor works “in game” as you are playing you can tweak and save you levels. Arrow keys to move and E to bring up the editor.

This movie requires Flash Player 9

Obviously there is a lot missing both from the editor and the engine. But hopefully for those who don’t quite know where to start with Entity Systems this will be a nudge in the right direction.

The code for the demo is here on git hub. The code for engine is here and it uses Ember2


Well Its been a while but I’ve been busy in the back ground and finally have something to show for it all. In the shape of Ember 2 first up I need to acknowledge some major contributors. First Alec McEachran @alecmce and his take on things with xember. Second Richard Lord @richard_lord and his clever suggestions in how to get around the performance cost of removing items from a vector.

Although the new versions API is in many ways familiar although simplified it is a complete rebuild underneath with a much more test driven approach. Also while some of the changes are a bit more subtle there are two biggie’s. All in all I made the decision that it deserves the version 2 badge.

So the first big thing is Ember is now a Robotlegs2 extension. To pre-empt the reaction of some that robotlegs has no place in games it does. Its perfect for the UI and menu’s systems etc. the issue is that the MVC doesn’t fit real time game play which is where Ember steps onto the stage. For Ember2 I wanted something that solved the issues of integrating with the Robotlegs framework whilst still being able stand alone. I also wanted a way of being able to add any functionality required without having to bake it in. Lucky Robotlegs2 appeared and its new context where functionality is constructed from extensions rather than being built in was exactly what I wanted. So rather than doing It my self badly it made sense to use it and save me a lot of work.

Second on the list is some clever trickery. With some magic behind the scenes I have been able to ditch the cumbersome linked lists and still keep performance practically the same. The best part is the nodes are now in juicy vectors and they can now be injected directly into the systems. No casting and funny loops any more just inject and “for each” you way over them.

Other more minor changes are that Entities are now objects in them selves. This may sound like a minor thing but it allows for pooling of whole Entities which was previously impossible and can help performance. Also taken for Alec’s xember is the auto inspection of the node classes so there is now minimal typing required when creating your nodes. All these things add up to make Ember 2 simpler and neater so it can just get out of the way and allow you to get on and code. If you want to get started check out the bunnies demo code on github. Have fun.


Administration portal for a payment system. Built a Flex client with the robot legs framework and signals. Also built the corresponding BlazeDS back-end. Features included a skin-able UI for client specific branding. User level permissions and customisable menu settings. Highly customised charts.


Tink very kindly let me talk at the FLPUG last month about entity systems. Its now up online and you can watch it here.

It was a pleasant surprise to meet people that other people are working with these ideas and even using there own versions of Ember. Hopefully I managed put it on the radar of at least a couple more.