Box of Delights. Fun for all the family.

For my session at the amazing Reasons to be Creative conference I will talk through three areas that BBC Children’s have developed for in the last year. These are Installations, Desktop Browser and Mobile. Each is a different journey of how to make games in that space.

In the installation section I’ll talk through the implementaion of optical flow for the Flash Maestro project – a collaboration with BBC R&D and the BBC Philharmonic. Also, I’ll talk through a similar implementation with a game made for Blue Peter’s Big Olympic tour. Code will be cracked open, and the experience demonstrated – fully interactively.

BBC Children’s have made some amazingly successful desktop browser games this year. I’ll describe the efforts, processes and game design decisions that have helped bring extra quality.

In the mobile space, my team have put in a lot of effort into investigating the mobile web. We researched optimal methods for rendering graphics, making physics lightweight and also how to develop against the way kids use devices.

With a great deal of opportunity in the HTML5/JS mobile web gaming space, I’ll describe findings, and offer tips on why, how and what agencies need to ‘skill up’ on to be successful.

‘Box of Delights’ is on in the Brighton Pavillion from 2.30pm to 3.30pm. Sept 5th 2012

This is going to be a lot of fun.


Reasons to be Creative 2012

‘Reasons’ is a festival for creative artists, designers and coders. Bringing together the best minds from the worlds of art, code, and design.

Reasons to be Creative is the evolution of the amazing Flash on the Beach conference. It has a more inclusive focus, now covering all web technologies. This helps bring together an amazing set of speakers from JS/Mobile Web App guru Jake Archibald to the creative code behemoths who rose from the Flash community Mario Klingemann and Joa Ebert. The tone will be one of celebration – a festival for the creative mavericks of the world.

The sessions are split into three tracks. Speakers cover design, code, illustration, animation and the creative process – but the conference is about much more than that. Inspiration sessions are designed to refill the tanks and send delegates away from the event with drive, enthusiasm and ideas to last the whole year – this alongside a whole list of new contacts and friends that could help build the next web masterpiece.

My ‘must see’ sessions:

    Eugene Zatepyakin – Actionscript Computer Vision
    Ahmed & Gill – The Random Adventures of Internet Explorer
    Conrad Winchester – I’ve got a super computer and I know how to use it!
    Mario Klingemann – Better Livign Through Lasers
    Jake Archibald – Application Cache: Douchebag
    Frank Reitberger – Highly Illogical
    Rob Bateman – Forward to Foundation
    Joa Ebert – Abstract Abstractions
    Mike Jones – Designing Game Interfaces
    David Lenaerts – A Trick of Light
    Jon Howard – Box of Delights. Fun for all the family <– Of course!
    Grant Skinner – Building Fun (with CreateJS & HTML5)



Games for Kids: Flash vs HTML5 – Presentation Content

Here are the notes for the content of my FITC Amsterdam 2012 presentation Games for Kids: Flash vs HTML5. There are links here to some of the demos, notes and references.

I set myself the objective of learning best practice in game design using HTML5. To best discover all of the foibles and dark corners of this new technology I set myself the constraint of using NO libraries. I wanted to build a game that would work across many devices, and exhibit some sophistication. The presentation details the discoveries made on this journey, showing how I’ve optimised the game engines – and some of the hacks that I’ve felt necessary to apply.

Demo Panel for Session - Click through

While experimenting with HTML5 touch I found some Android devices had a terrible response. It took me a while to realise that it was my display method, Canvas, that caused the poor performance. Moving to displaying with DOM gave me a workable response on most devices.

Multi-touch Ball Physics

A first quick attempt at gameplay interaction was to build a simple ball physics engine. This gives many options in game design and allows for good utilisation of the major strength of mobile devices: touch input. Getting this to work across multiple devices and operating systems gave me confidence that I could achieve a consistency of performance.

Eggy Eggy Pig - visual design by Eloisa(9) & Lola(7)

With the help of my daughters, I set about designing and building a platform game. Eggy Eggy Pig. The requirement was for platforms and surfaces that could run at any angle, as well as spritesheet animations, triggered interactions, collectables and parallax scrolling. Of course control method was key too.

Optical Flow with Lucas Kanade (Flash)

After looking what can be done with HTML5, it is important to understand what can’t be done. Any game project should start with the question ‘what is the appropriate technology to achieve our objectives?’. In many cases the answer will not be HTML5. I show a couple of cases where Flash could be the only solution, including a look at Maestro Flash – a production implementation of the Lucas Kanade optical flow method.



Games for Kids. Flash vs HTML5

For my session at FITC Amsterdam 2012 I’ll be talking about making games for kids.

More and more, mobile devices are allowing people to visit our websites away from the desktop. The sites that I work on chiefly consist of games (Flash) and video content (delivered via Flash). This means that mobile devices without Flash will only be able to gain access to a very small amount of content. To improve this situation we are looking at broadening our game content to include HTML5 builds.

HTML5 has a great deal of promise, and in the future we will be able to achieve amazing things within the browser. But what about now? What can be achieved on the current crop of those mobiles and tablets that are available to children?

To explore the development of HTML5 games, I set myself the task of building whole game prototypes with NO libraries. Here, I felt the best way for me to discover and analyse the issues was to code raw.

With a target of mobile and tablet devices I figured that I’d need to hand-roll my own highly performant physics systems, and I wanted this to be fairly sophisticated. I will describe my methods with code and visual examples.

Throughout the session I’ll detail my discoveries. What are the most optimal ways to achieve cross (mobile) browser game builds? How do you achieve high performance on low spec devices? How do you optimise assets? What tools are good to use?

I’ll look at what we can and can’t do with HTML5 – some of the exciting possibilities and some of the game related (currently)missing features.

Also, what next for the mobile technology and gaming? HTML%, Apps or the cloud?

I’ll be posting the session content – game prototypes and performance tests – here on the GameLab before my FITC Amsterdam session.


HTML5 Game Dev. Removing elements from the screen. Finding the fastest method.

Using removeChild to clear off a few in-game elements I noticed a bit of lag when testing on some devices so thought I’d better have a look at what the fastest removal methods are.

The three methods I selected to test were removeChild, display=”none” and a simple hide the element offscreen. Again, testing has been carried out at JSPerf.com.

My first test was on Chrome 16 and the results were pretty conclusive. display=”none” was very slow, and hide the element was by far the fastest – over 4 times faster than display=”none”.

So, conclusive proof – I should just hide my elements off the screen.

Err, no. I next tested Firefox 9.0.1. Ah, here removeChild was 2.5 times faster than both display=”none” and hiding the elements.

IE7.0 then. display=”none” and the hiding elements method were nearly 3 times faster than removeChild.

What about devices?
With Android 2.2 (Galaxy Tab 1) display=”none” was the fastest method, but only marginally so over the other two.

Safari on iPad #1 (4.2.1) flips the results on their head again with removeChild() being nearly 3 times quicker than the other two.

So how do we interpret this data? A chief decision to make would be what the target devices are. Then choose the quickest method. If we wanted a more generic approach then a series of conditionals would allow for all three methods to be present, using the most relevant one for the current browser.

For the prototypes I am working on, number one target is the iPad. A lot of my focus has been on trying to avoid using the Canvas element (entirely due to horrible performance on Android with it).

Element removal.

The (very simple) code used is here (for simplicity’s sake I use the inverse method as well to bring the element back onto the stage for subsequent removal):

var testDIV = document.createElement(‘div’);
testDIV.innerHTML = “Hello World”;

function displayIsNone()

function removeChild()

function moveVideo()

Try the tests yourself here: http://jsperf.com/removing-an-element-from-the-screen/3.


HTML5 Game Dev. DOM Manipulation. It’s costly, so minimise its use.

Typically when manipulating display objects in Flash, applying positional data is a trivial task so you wouldn’t think twice about applying the data on every game loop. It doesn’t matter that the object hasn’t moved on that frame. The overhead would be minimal, you can just reapply without penalty – in fact to engage with any conditional to test for the need to apply could be more costly in the long run.

With DOM manipulation, any update seems to be fairly processor expensive. Very non-trivial. Here it is essential that updates should be applied ONLY when absolutely necessary.

I ran a test script at JSPerf.com which demonstrated the issue. I set up a Div with some simple text content. Then manipulate it on every iteration. I move the x-position by 0.2, then round off the position before applying. To optimise I only apply the dom manipulation when the actual object has changed position. The results are stark. A massive performance boost.

Optimise your DOM manipulations. It pays.

The code used is simple, and as follows. Create a div, populate then manipulate:

var targetDIV = document.createElement(“div”);
targetDIV.innerHTML = “test data”;
var posX =0, prevPosX=0;

function unoptimisedManipulation()
var roundX = Math.round(posX);

if(posX>500) {posX=0;}

prevPosX = roundX;

function optimisedManipulation()
var roundX = Math.round(posX);
if(posX>500) {posX=0;}

prevPosX = roundX;

The results aren’t indicating that DOM manipulation should be avoided – Android devices really struggle with Canvas so DOM is preferable – it just takes a bit of effort to make the DOM production ready.

Try running the tests yourself at JSPerf.com : http://jsperf.com/optimising-dom-access


HTML5 Game Dev. Flipping a DIV – Horizontally Inverting content with Javascript and CSS

As I prepare for my talk at FITC Amsterdam (Feb 2012) I’m building a web game in both Flash & HTML5.

I’m aiming my HTML5 build at the mobile web (but will try to reach as many desktop browsers as possible) – so it will need to run optimally across Android & iOS.

I’ve discovered a few issues so far that for the purpose of record and reference I’ll post here in game lab.

First up. I have a player character that I’m animating via a spritesheet. I need the character to be able to face left and right.

I made the assumption that I could drop the sheet into a div (as background image) and then apply a scaleX transition to the div when I need to face left, and remove the transition when I need to turn right.

I’m applying the horizontal flip by adding a CSS classname to the div.

The CSS:

-moz-transform: scaleX(-1);
-webkit-transform: scaleX(-1);
-o-transform: scaleX(-1);
transform: scaleX(-1);
filter: FlipH; /*for IE*/
-ms-filter: “FlipH”;

Then when I need my character to face left I add the class name to the character div:

function faceLeft() {characterDIV.className = “flip-horizontal”;}
function faceRight() {characterDIV.className = “”;}

So, is this good? Works fantastically on the desktop browsers and really well on Android.

BUT, on iOS (iPad in my tests) there is a BIG lag when the webkit transform is applied.

I mean big – in my game there can be up to a second long hang. Totally unacceptable for any game usage (unless as a one shot on initialisation).

The answer? Unfortunately I couldn’t come up with a technical solution. I had to resort to putting the reverse animation on the spritesheet. This gives me the performance I want – but at the expense of more weight to the game.

If my game has many characters then I am essentially doubling my asset weight for those characters. Boo.


Reasons to be Creative 2012

FITC Amsterdam 2012

Flash on the Beach 2011

Flash on the Beach 2010

Flash on the Beach 2009

Swingpants at FOTB2009

Twitter Updates


Get every new post delivered to your Inbox.