Who am I?

I am a:

• British Chap
• Senior Developer at Fantasy Interactive Stockholm
• Creative Coder
• 3D engine author

Good questions!

• You can totally do it in HTML5
• It's fun
• It's a challenge
• It's satisfying

The Game Maker's To-do List

• Drawing
• Sound
• Physics
• Input

2D Canvas

var canvas = document.createElement('canvas'),
    context = canvas.getContext('2d');

2D Canvas

• Software rendering (Accelerated in some cases)
• No concept of layers or objects; it's a big bitmap
• Well supported
  Chrome, Firefox, Safari, Opera and Internet Explorer
• Works on mobile
• Pretty easy to get started with

http://caniuse.com/#search=canvas

2D Canvas - Performance

• Avoid clearing the whole canvas if you can.
  You can use boxes to track dirty regions
• Tracking what to clear might end up being more
  expensive than just clearing the whole thing!
• Use sprites instead of procedural graphics where you can
• If you need to you can draw canvases in canvases;
  can be a form of frame buffer

WebGL

var canvas = document.createElement('canvas'),
    context = canvas.getContext('experimental-webgl'); // will be 'webgl' eventually

WebGL

• Hardware rendering
• Faster than a speeding bullet
• Lots of boilerplate code
• There are libraries that can help!
• Getting a lot of browser love
  Chrome, Firefox, Safari, Opera Next but sadly not Internet Exploder
• No word on mobile support as yet

http://aerotwist.com/a3
https://github.com/mrdoob/three.js
http://caniuse.com/#search=webgl

WebGL - Performance

• Palm as much off to the GPU as you can - it's faster than JS
• Keep the number of glDraw* calls to a minimum
• Keep poly counts down and use textures
• Optimise your data, e.g. interleaving

Drawing: decisions, decisions

• Use WebGL if you can
• 2D Canvas has better support
• Three.js has both a 2D canvas and WebGL renderer

requestAnimationFrame

• It's the correct way to schedule your drawing
• We need a shim to make it work for now

/**
 * @see http://paulirish.com/2011/requestanimationframe-for-smart-animating/
 * @author The Paul Irish
 */
window.requestAnimFrame = (function(){
  return  window.requestAnimationFrame       ||
          window.webkitRequestAnimationFrame ||
          window.mozRequestAnimationFrame    ||
          window.oRequestAnimationFrame      ||
          window.msRequestAnimationFrame     ||
          function(/* function */ callback, /* DOMElement */ element){
            window.setTimeout(callback, 1000 / 60);
          };
})();

Sound

• It's very important
• HTML5 audio is (sadly) pretty weak:
  • Timing issues
  • Clicks, pops
  • Dropped audio
• Mobile is even weaker than Desktop

Sound advice

• HTML5 audio is bound to get better but...
• Use Flash for commercial work if you can
• This will mean using ExternalInterface and handing off events
• You can always degrade back to <audio>

There are two different ones, one for Chrome and Firefox. Nothing for Opera, Safari or Internet Explorer.

Physics - The Problem

• We have one game loop. At 60 fps we have 1000ms / 60 =
  ~16ms to do everything
• Time spent on physics is time not spent doing other critical stuff, like drawing, sound or input
• Physics calculations can get expensive
• We could end up with no time to handle everything else
• That's bad

Three potential solutions

Otherwise we just go home and cry

1. Only do simple calculations

You may not be able to do this if the game relies
on more complex simulations

2. Reduce the framerate to 30fps

Give ourselves 32ms to do everything.
(Or we alternate between physics calculations and everything else, 16ms each)

3. Use a Worker

We can spawn a new OS-level thread just to handle the physics

Workers

var worker = new Worker('physics.js');

// initialisation where we send all the
// required world data to the worker
worker.postmessage(world.data);

// callback handler for incoming messages from the worker
worker.onmessage = function(evt) {
  processPhysicsDataFromWorker(evt.data);
};

// now start
worker.postmessage("start");

// later we stop
worker.postmessage("stop");

Workers

• Workers do not block the main thread
• Workers do not have direct access to
  the main thread
• Workers do not have access to the DOM

Workers - Performance

• Keep the worker and main thread as decoupled as possible
• The message passing should be kept
  to a minimum

Input

You can take input from the following:

• Keyboard
• Mouse
• Accelerometer
• Joystick / Gamepad (Firefox only for now)
• Webcam (May be a while off)

https://wiki.mozilla.org/JoystickAPI
http://caniuse.com/#search=getusermedia

Input: Mouse

Let's assume some kind of FPS

function onMouseMove(evt) {
  var x = evt.pageX || evt.clientX,
      y = evt.pageY || evt.clientY;

  moveCrosshairTo(x, y);
}

function onMouseClick(evt) {
  fire();
}

document.addEventListener('mousemove', onMouseMove, false);
document.addEventListener('click', onMouseClick, false);
        

Input: Accelerometer

Query the device. Really cool for mobile

// This is the Webkit style; Gecko does it differently!
function shakeItBabyShakeIt (evt) {

  // beta maps to z, gamma to x.
  // (If you have a gyro that should be alpha.)
  thingy.velocity.z += evt.beta;
  thingy.velocity.x += evt.gamma;

}

window.addEventListener('devicemotion', shakeItBabyShakeIt, false);
        

Input: Joystick

Heck. Yes. It's Firefox only for now. It's pretty much what
you'd expect API-wise.

window.addEventListener('MozJoyConnected', onJoystickConnect, false);
window.addEventListener('MozJoyDisconnected', onJoystickDisconnect, false);
window.addEventListener('MozJoyButtonDown', onJoystickButtonDown, false);
window.addEventListener('MozJoyButtonUp', onJoystickButtonUp, false);
window.addEventListener("MozJoyAxisMove", onJoystickAxisMove, false);

I want to see this in other browsers, though!

Webcam Demo

There's no way this can fail. It's only an alpha feature...  o_O

On this Mac, one() took 53.25%
of the time; two() took 44.81%

A while loop going backwards was, in this case, faster than a for loop*

If you're serious about
performance, use jsPerf

http://jsperf.com

...Maybe

Engines - Pros

• It's probably going to be faster than
  building your own
• It's more likely to be stable!
• It's the commercially sound choice

Engines - Cons

• Not all engines are free
• Engines are not optimised for your game
• It will probably not be a perfect feature fit
• It's less fun

Some Popular Engines

• Crafty ($0 license)
• Impact ($99 license)
• Isogenic ($100 - $310 license)

http://craftyjs.com/
http://impactjs.com/
http://www.isogenicengine.com/

Build your own

Some good advice given to me that I'll gladly pass on

Conclusion

• You can build games using HTML5
• It's rewarding
• There are lots of helpful technologies and resources
• You might want to try making your own engine ;)
• But most of all, have FUN!