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.

References:

• Vic20 Emulator – Vice – viceteam.org
• CBBC – bbc.co.uk/cbbc
• CBeebies – bbc.co.uk/cbeebies
• RaphaelJS raphaeljs.com/
• JSPerf.com – jsperf.com
• Lucas-Kanade Method – wikipedia.org
• Notepad++ – notepad-plus-plus.org/
• Jesse Freeman – HTML Game Development(ImpactJS)
• SoundManager2 – schillmania.com/projects/soundmanager2
• Rover – theroverapp.com
• OnLive – onlive.co.uk
• FITC Amsterdam 2012 – FITC.ca

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.

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()
{
testDIV.style.display=”block”;
testDIV.style.display=”none”;
}

function removeChild()
{
document.body.appendChild(testDIV);
document.body.removeChild(testDIV);
}

function moveVideo()
{
testDIV.style.left=”10px”;
testDIV.style.left=”-9999px”;
}

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

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”;
document.doby.appendChild(targetDIV);
var posX =0, prevPosX=0;

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

if(posX>500) {posX=0;}
targetDIV.style.left=roundX+”px”;

prevPosX = roundX;
}

function optimisedManipulation()
{
posX+=0.2;
var roundX = Math.round(posX);
if(prevPosX!=roundX)
{
if(posX>500) {posX=0;}
targetDIV.style.left=roundX+”px”;

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

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:

.flip-horizontal
{
-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.

Finally getting around to have a play with HTML5 Canvas – enabled by attending Seb Lee Delisle’s excellent CreativeJS course.

I’m impressed with performance from Canvas nowadays – my first sight of it many moons ago left me pretty disappointed – but now it actually feels useful and some pretty impressive visual effects can be achieved without resorting to WebGL.

The prototype I threw together here demonstrates a growing tree, in 3D with numerous branches, leaves, leaf fall, faux-shading and colour phasing. The demo will re-grow a tree on mouse click, and will allow for left and right rotation by means of mouse position (left/right).

3D Tree with Leaf Fall

To talk through the code a little: The tree is constructed using a recursive buildBranch function. Every branch spawns two new branches, or in the last generation it has a 90% chance of spawning a leaf. The branches are coloured from brown to green related by the recorded generation of the branch.

No 3D libraries were used in this demo – all of the 3D is via a simple scaling calculation for 3D points [ fov / (fov + point.z) ]. This allows for any 3D point to be translated (scaled) onto the 2D canvas.

The Painter’s Algorithm (priority fill) is applied via the sorting of all branches and leaves on their mid-point. This means that those furthest away are drawn to screen first.

Shading is applied by mapping colour to the z value of a branch’s position. This is very simply applied. There is a related alpha to add a fog effect to the furthest away elements, this gives some subtle but nasty artefacts and could be improved.

When a branch is fully grown the leaves will then appear and grow to their full size. When they fall a sine value is applied to rotation to make it rock as it falls. Leaves will collect on the ground.

Performance is pretty good here, but I did have to restrict the number of branch generations to 9. Of course some of the out-of-the-box features that Flash has such as Glow and Blur filters don’t exist – which means work-arounds or approximations have to be used – sound implementation isn’t very consistent across browsers – it is still early days, more and more JS will be used across the web, as it is the browser manufacturers will hopefully drive their products into more useful areas and consistent implementations.

The demo is a fast turn-around ‘prototype’, so not optimal or well formed. Feel free to have a play with the code, offer improvement suggestions or adapt in anyway you wish.

No attempt has been made to cover HTML5 cross-browser issues – so don’t expect this to work in IE!

Direct Link: 3D Tree with Leaf Fall

Games:

Swingpant's FOTB Flinger

Test your keyboard here: http://bit.ly/keytest
(Sorry users of keyboards that aren’t exactly like the one I have here – I made the app from a pic of this one)

Accessibility

Recommended Reading on Game Design:
Game Design Books:

Academic Papers:

Flash on the Beach Titles by GMunk

This year I’m speaking on the monday morning – great for me as I don’t have to sweat it for the following few days.

Some major clashes this year – I may have to miss Seb Lee Delisle, Stray, Joel Gethin Lewis, Keith Peters, Conrad Winchester and Stefan Richter. Sorry guys – my arm is up for being twisted though.

Mon 12th Sept 2011
Keynote.
Jon Howard – Playability: Making games for kids
Rob Bateman – Flash 11: Get Ready for Gametime
Eugene Zatepyakin – Natural Features Tracking and Image Pattern Detection / Recognition
Han Hoogerbrugge – Prostress of the graphic universe of Han Hoogerbrugge
Jon Burgerman – A short talk about working and not working and how to waste your time proficiently

Tue 13th
Tomek Augustyn – Riding the Hislope
Joa Ebert – The Tale of a travelling salesman and his four colours
Mike Chambers – Deconstructing theexpressiveweb.com
David Lenaerts – Keeping It Real
Remy Sharp – HTML5: Where flash isn’t needed anymore
Cyriak Harris – Destroying my laptop with After Effects
Jame Victore – Who died and made me boss

Wed 14th
The Elevator Pitch.
Thomas Vian – All aboard the game engine
Lee Brimelow – Render for Speed
Frank Reitberger – Real(hard)time
Joshua Davis – The Unknown Voyage

The subject is playability in relation to making web games for kids. As a lead developer, tech lead and team leader I have had huge amounts of experience working on game design and development with major kid’s TV brands. It is exciting, fun and always a privilege.

In the session I will be looking at how a gamedev team is made up, the product lifecycle from idea to release. Important points I’ll look at are the specific needs of the game’s audience. How to design the best control method, the most appropriate aesthetics and which mechanics work best.

I’ll dig into the elements of a successful game – which measures are used to find out if a game is ‘good’ and successful.

With constantly shifting sands in the world of the web,I’ll touch on what I see as the future of games for a major broadcaster – what technology will be used and on what platforms.

During the session I’ll be showing examples of games, video examples and I’ve arranged for a Skype call to the TV offices…

Playability at FOTB2011

Belgian, Flemish geographer and cartographer Gerardus Mercator, in 1569 presented a cylindrical map projection. The Mercator Projection quickly became the standard map used for nautical purposes. It’s advantages were that the scale is linear in any direction around a point, meaning all angles were preserved (conformal).

Gerardus Mercator

Around the equator feature shapes are accurately portrayed but as the poles are approached there is a size and shape distortion. The scale increases as the pole is neared, eventually becoming infinite when the pole is reached.

If you imagine the world as a beach ball. The Mercator Projection is the equivalent of cutting open the ball at each pole and stretching the skin to form a cylinder. Now slice down the cylinder and you have the map.

The first Mercator projected map. 1569.

All map projections distort the shape or size of the Earth’s (or for that matter any other planet’s) surface. The Mercator Projection exaggerates areas far from the equator. Greenland seems as large as Africa, but is in fact 1/14 of the size, Antartica appears to be the largest continent but is in fact only 5th in terms of area.

Despite the obvious distortions, the Mercator Projection makes a great interactive map. Thanks to the conformality it can be zoomed nearly seamlessly.

So here we have a system that converts a 3D scene, the real world, onto a 2D plane, the map. This system can just as easily convert the 2D back to 3D. It is a coordinate system that requires two positional parameters and one constant: the planet radius.

The positional parameters are latitude and longitude. As developers we are used to standard coordinates x and y. Across then up. Horizontal then vertical. With latitude and longitude we have to think differently. Latitude is vertical and longitude is across. Up then across. Latitudes run from pole to pole, while longitudes run around the planet.

There are 180 degrees of latitude from the South Pole to the North pole, and 360 degrees around the planet. Imagine yourself sat at the centre of the Earth with a laser pointer. Point at the Equator then you are at 0 degrees latitude, at the South Pole -90 degrees and at the North Pole 90 degrees. Now point at the Equator again you can turn 180 degrees around the equator to the right (-180 degrees longitude) and to the left (180 degrees longitude).

With these any point on the surface of the planet can be recorded or indeed any position on a map.

So we have a system for calculating a position on the surface of a sphere, a 3D coordinate, but how do we convert latitude, longitude and the planet’s radius into a 3D x,y,z coordinate?

Here the latitude and longitude are converted into radians ( TO_RADIANS:Number = Math.PI / 180 ). Then the trigonomic functions are applied to the planet radius to return a vector3D x,y and z.