the state of html5 games - fluent js

GAME DEVELOPMENT

The state of HTML5 games

Rob Hawkes

Hi, I’m Rob Hawkes and I’m here today to talk about the state of HTML5 game development.

I work at Mozilla, a non-profit fighting for a better Web. The same guys who make Firefox.

I’m pretty fond of Mozilla. So much so that my girlfriend made me a chicken and leek pie with extra Firefox goodness.

It was delicious.

I’m not sure how much time we’ll have for questions at the end, but feel free to grab me in person after the talk or on Twitter.

These slides will go online after this talk, they include links to more information on the technologies covered.

I’ll put all the details up at the end.

Games are important

They matter for m

any reasons

Now I think it’s safe to say that games are pretty important, for many reasons.

Games are universal

There is a game for everyone

One of those reasons is that they are universal.

There are games out there to suit all walks of life; whether that’s a board game, card game, or computer game. It’s all the same.

Over the years, I’ve played all sorts of games that each meant something different to me at that point in life.

It’s memories from games like Paperboy on the ZX Spectrum and its amazing noises and epic loading times.

I sorely miss those days.

And Bomberman on the SNES, which really got me addicted to gaming.

And Lylat Wars on the Nintendo 64. Star Fox for the non-European folk.

Do a barrel roll!

And the original Sim City.

I don’t bare think about the hours I lost to that game, building a city on what I’ve only just noticed was an incredibly muddy landscape.

And Red Alert, one of the first games I owned that let me play with others over the Internet. It was great fun!

And probably one of my all-time favourites, along with the original Command and Conquer.

Plus, it had an awesome soundtrack.

Games are damn fun

No (sane) people hate them

Another reason is that they are incredibly fun to play.

This is probably because they tap in to to our addictive, competitive personalities.

I don’t know anyone who hates games.

However, I do know people who hate fruit. A lot.

One of my favourite games at the moment is Fruit Ninja on the Kinect.

It pretty much justifies the Kinect’s existence.

I had a few friends over the other week and we all ended the weekend with Fruit Ninja-related injuries.

It was worth it though.

Trailer for Fruit Ninja - http://www.youtube.com/watch?v=UzsmDfKzk7M

Games push boundaries

Bigger, better, faster hardware

Aside from being universal and fun, games are important because they push the boundaries of what’s possible with today’s technology.

Games are one of the only things that deliberately use every ounce of your computer’s capabilities; from graphics, to processing power, to RAM, even to disk space.

As computers constantly get better, games improve to use up the new improvements in speed and power.

And computer hardware is improved, in part, because of the desire to create faster and more realistic games.

2011

2002

For example, this is Battlefield 3. It’s one of the most powerful and ‘realistic’ games out to date.

It came out in 2011.

Compare that to Battlefield 1942, which came out back in 2002.

Notice the difference? There’s barely 9 years between them and yet it’s quite clear that Battlefield 3 is far superior, at least visually.

Processor (Mhz) Graphics (MB) RAM (MB)

2000

512

2400

12832

500

Battlefield 1942 (2002) Battlefield 3 (2011)

Minimum specs

Just take a look at the minimum hardware specs of Battlefield 1942 and Battlefield 3.

In just 9 years we’ve pushed computers so far that the minimum requirement for a game today is way beyond what was even possible back in 2002.

Processor (Mhz) Graphics (MB) RAM (MB)

4000

1024

2400

2000

512

2400

12832

500

Battlefield 1942 (2002) Battlefield 3 (2011) Battlefield 3 - Recommended (2011)

Recommended specs

And the minimum specs don’t even produce anything near the quality that you saw on the previous slide.

For that you need even more powerful hardware.

These are the recommended specs for Battlefield 3. Aside from processor speed, they are at least double everything else.

We’re talking state of the art technology here, and even this still won’t run the game at its full potential.

Games mean a better Web

New features and better performance

We now have more and faster processors than ever before, we have insanely powerful graphics cards, and so much RAM we don’t know what to do with it.

The improvements that games help bring about in computer hardware mean that we can now do some really cool stuff on the Web.

Without games, there would be little need to continue pushing Web technologies; like faster JavaScript, or hardware accelerated CSS and multimedia rendering.

Play more games

You are helping the Web move forward

So in a rather long-winded way, my point here is that you need to play more games.

You’re making the Web better and having fun at the same time. Win win!

Let’s shift our focus to HTML5 games.

Existing games

Some of the best examples

The number of HTML5 games out there is growing every day.

I’d like to show you a selection of my favourites, just a tiny amount of what’s out there.

Quake II

Fully-functional multiplayer Quake II port.

http://code.google.com/p/quake2-gwt-port/

Cut The Rope

Cut The Rope, ported from iOS.

http://www.cuttherope.ie

Bejeweled

Bejeweled is a massively popular game on a whole variety of platforms.

Popcap recently released a purely HTML5 version.

http://bejeweled.popcap.com/html5

Command & Conquer

Command & Conquer: Tiberium Alliances is a HTML5 game from EA that is part real-time strategy, part Farmville.

http://alliances.commandandconquer.com

GT Racing

GT Racing: Motor Academy is a 3D racing game by Gameloft and Mandreel.

http://www.mandreel.com/?page_id=1312

BrowserQuest

BrowserQuest is a massively-multiplayer RPG that Mozilla recently launched to the public.

It works great on mobile and desktop devices but what’s even better is that, aside from being an addictive game, the entire source code is on GitHub.

http://browserquest.mozilla.orghttps://github.com/mozilla/BrowserQuesthttp://hacks.mozilla.org/2012/03/browserquest/

Technology

The stuff that m

akes HTML5 games tick

There are key technologies that are involved in the development of HTML5 games like the ones you just saw.

Canvas

2D graphics platform

Canvas is a 2D bitmap graphics platform.

It’s quite amazing what can be done with such simple drawing and image manipulation tools.

In games this is used to do things like drawing sprites and performing image manipulation on the fly.

https://developer.mozilla.org/en/HTML/Canvas

Silk is a stunning example of what can be achieved by combining the simple drawing tools available in canvas.

http://weavesilk.com

Close Pixelate is a canvas app that lets you manipulate images on–the-fly to create a pixelated effect.

http://desandro.com/resources/close-pixelate/

You can even use canvas just for simple effects on a standard Web page.

David Desandro uses canvas to draw curved lines on his portfolio that indicate areas of focus. Before canvas you’d have had to have used static images or complex techniques to achieve this.

http://desandro.com/portfolio/

Last year I helped HTML5 Doctor implement a canvas-based rollover effect on their element index.

With canvas, we were able to create custom-shaped rollovers that were entirely dynamic.

We also cached these canvas-generated images so they didn’t need to be created on every page load.

http://html5doctor.com

<canvas id='myCanvasElement' width='400' height='400'></canvas>

Canvas

Using canvas is very straight forward.

The first thing you need to do is add a canvas DOM element to your HTML page.

var canvas = document.getElementById('myCanvasElement');

var ctx = canvas.getContext('2d');

ctx.fillStyle = "rgb(200,0,0)";

ctx.fillRect(10, 10, 55, 50);

ctx.fillStyle = "rgba(0, 0, 200, 0.5)";

ctx.fillRect(30, 30, 55, 50);

Canvas

From there you can then access the canvas through JavaScript to draw on it and do other cool stuff.

This is small canvas demo that draws a solid red square underneath a blue one with half transparency.

‘myCanvasElement’ refers to a HTML <canvas> element that you’ll need to place in your HTML file somewhere. In this example, I’m assuming that you’ve already done that.

WebGL

3D graphics platform

WebGL brings the ability to provide advanced hardware-accelerated graphics directly within the browser.

Games use this to create immersive 3D worlds and models, or for accelerated 2D graphics.

https://developer.mozilla.org/en/WebGL

HelloRacer is a little game that lets you drive a Formula One car around your browser. It’s a beautiful example of WebGL in action.

http://helloracer.com/webgl/

Tinkercad is probably the best use of WebGL that I’ve seen in a production situation.

It’s a Web app that allows you to create 3D objects in your browser using WebGL, then get them printed and sent to your doorstep in just a few simple clicks. It’s seriously awesome.

https://tinkercad.com

Eve Online WebGL ship viewer.

http://www.eveonline.com/universe/spaceships/

Both Google Maps and Nokia have recently added support for WebGL. The Nokia version is particularly impressive because they fully render and texture 3D shapes of buildings.

http://support.google.com/maps/bin/answer.py?hl=en&answer=1630790http://maps.nokia.com/webgl/

Undulating monkey by Paul Lewis.

http://lab.aerotwist.com/webgl/undulating-monkey/

I’m not going to lie, WebGL isn’t the easiest thing to learn. Then again, no raw 3D code is that simple.

Instead, I recommend checking out a library called three.js which abstracts WebGL and makes it much easier to implement.

https://github.com/mrdoob/three.js/

requestAnimationFrame

Optimised animation loops

requestAnimationFrame is the new, better way of managing animation in JavaScript.

Instead of constantly running a setTimeout or setInterval function, which lack performance and spike CPU usage, requestAnimationFrame puts the browser in control of things and keeps things running smoothly.

https://developer.mozilla.org/en/DOM/window.requestAnimationFrame

function update(timestamp) {

// Do something

window.mozRequestAnimationFrame(this);

}

window.mozRequestAnimationFrame(update);

requestAnimationFrame

In this example, I’m only using the Mozilla prefixed version of requestAnimationFrame. In reality, there’s a really good shim by Paul Irish that handles cross-browser requestAnimationFrame.

http://paulirish.com/2011/requestanimationframe-for-smart-animating/

HTML5 audio

Sound effects and background music

HTML5 audio allows for plugin-less audio.

For games, this would be used for sound effects and background music.

Audio data APIs implemented by Mozilla and Google allow for manipulation of audio and much more fine-grained control.

https://developer.mozilla.org/en/HTML/Element/audiohttps://developer.mozilla.org/en/Introducing_the_Audio_API_Extension

This is something I made especially for the ASSEMBLY 2011 event in Finland.

It’s an audio visualiser that uses WebGL and the HTML5 Audio Data API.

http://robhawkes.github.com/webgl-html5-audio-visualiser/

Local storage

Storing more than cookies

Methods like the application cache, Local Storage, and IndexedDB are great for storing relatively large quantities of data locally.

This way you can cache data and allow the website to pick up where the user left off.

https://developer.mozilla.org/en/DOM/Storagehttps://developer.mozilla.org/en/Offline_resources_in_Firefoxhttps://developer.mozilla.org/en/IndexedDB

WebSockets

Multiplayer communication

WebSockets can be used for the real-time communication between a browser client and server.

For games, this would be used for fast-paced multiplayer functionality.

https://developer.mozilla.org/en/WebSockets

BrowserQuest

The BrowserQuest game that I showed earlier uses WebSockets to provide real-time multiplayer.

Pretty much every character in the game is actually another person playing the game, with their movements transmitted to you in real-time via WebSockets.

GoSquared use WebSockets for real-time website analytics.

http://www.gosquared.com

var ws = new WebSocket('http://example.com/socketserver');

ws.send('This message is sent to the WebSocket server');

ws.onmessage = function (event) {

console.log(event.data);

}

WebSockets

WebSockets are created entirely from JavaScript without the need to add elements to the HTML page.

A new WebSocket connection can be opened by calling the ‘new WebSocket’ constructor and passing it the URL to the WebSocket server.

From there you can call the ‘send’ method to push data to the server.

Or listen for the ‘onmessage’ event to handle data pushed to you from the server.

Web Workers

Multi-threaded JavaScript

Web Workers allow you to run JavaScript in separate background threads.

This allows you to offload computationally-heavy tasks with a single worker, or tackle large quantities of data in a fraction of the time by spreading tasks over multiple workers.

Another benefit of doing this is that you don’t lock up the browser during heavy tasks, meaning a user can still interact with things and get stuff done.

https://developer.mozilla.org/En/Using_web_workers

var worker = new Worker('my-worker.js');

worker.onmessage = function(event) {

console.log('Worker message: ' + event.data);

};

Web Workers

Web Workers, like WebSockets, are created entirely through JavaScript.

You create a new worker by calling the ‘new Worker’ constructor and passing it the path to a JavaScript file.

You can then listen to the ‘onmessage’ event that will be fired every time the worker script sends data using a ‘postMessage’ method.

Fullscreen API

Simple, yet powerful

The Fullscreen API allows you to expand any HTML element to fill the users screen, even if the browser isn’t running full screen itself.

For games, this is great because you can make the small canvas element fill the entire screen.

Outside of games, this is useful for video elements and Web applications.

https://bugzilla.mozilla.org/show_bug.cgi?id=545812https://wiki.mozilla.org/Platform/Features/Full_Screen_APIs


// Wait for user input

canvas.mozRequestFullScreen();

Fullscreen API

The Fullscreen API can be requested from any DOM element.

In this example you’re asking a canvas element to expand to fill the screen.

One thing to note is that you can’t just make any element fill the screen whenever you want. Right now, the user has to click or press a key to initiate the Full Screen API.

Pointer Lock API

Locking the cursor in one place

The Pointer Lock API is an attempt at improving the mouse as an input device.

It would be used in situations like games and 3D visualisations where the mouse position rotates or moves you around a 3D space.

As it stands there’d still be a cursor moving around the screen causing all sorts of trouble when you want to click on something in your game.

With the new API you can lock your mouse position and stop it from getting in the way and being a nuisance.

https://developer.mozilla.org/en/API/Pointer_Lock_APIhttps://bugzilla.mozilla.org/show_bug.cgi?id=633602


// Go fullscreen

canvas.mozRequestPointerLock();

Pointer Lock API

The Pointer Lock API can be requested from any DOM element that is already in full screen.

Gamepad API

Bringing the console to the Web

The Gamepad API is one of the major improvements to input that is coming.

Both Mozilla and Google are working an an implementation of this and there is actually an experimental build of Firefox available to the public that has it working. The API is also in the dev build of Chrome.

What I find most interesting about the Gamepad API is that it might be just the thing we need to finally justify HTML5 gaming on a TV or console.

Who wants to use a keyboard and mouse while sitting on the sofa?

https://wiki.mozilla.org/GamepadAPIhttp://www.gamepadjs.comhttps://github.com/jbuck/input.js

Gamepad API demo

I’d like to show you a quick demo of the Gamepad API.

In this example I’ve connected my Logitech controller to my Mac, but I could also use a PS3 controller or practically any other USB controller.

This is another little demo that I put together to show off the Gamepad API implemented in my game Rawkets.

function onGamepadConnected(e) {

var controller = e.gamepad;

console.log("Gamepad connected", controller.id);

}

window.addEventListener("MozGamepadConnected", onGamepadConnected);

Gamepad API

MozGamepadConnected

It passes an event object that itself contains a gamepad object in reference to the connected gamepad.

Screen Orientation API

Must-have on mobile devices

The Screen Orientation API allows you to do things like changing and locking, you guessed it, the orientation of the screen.

Before now, it’s been incredibly difficult to lock orientation on a website or game using nothing but JavaScript.

https://bugzilla.mozilla.org/show_bug.cgi?id=740188http://dvcs.w3.org/hg/screen-orientation/raw-file/default/Overview.html

// Go fullscreen

screen.mozLockOrientation('landscape');

Screen Orientation API

The Screen Orientation API is another relatively simple one.

It just landed in Firefox Nightly on mobile.

All you need to do is call the ‘lockOrientation’ method of the screen object and pass it a orientation string.

It’s important to note that you also need to be using the Fullscreen API for the orientation lock to work.

Node.js

Server logic and network communication

Node is often used as a multiplayer game server, controlling the logic and handling the WebSockets connections to the players.

It can be used for player authentication and the storage of data so gameplay can persist over multiple game sessions.

This is all made relatively easy with great third-party modules, like Socket.IO for WebSockets, and others that handle Redis and MongoDB for storage, for example.

http://nodejs.org

Web applications

Not just a fancy website

The concept of Web apps is something that is gaining a lot of traction at the moment.

It’s no doubt this this traction is as a result of the success of native applications and games on the desktop and mobile, particularly with iOS and Android.

https://developer.mozilla.org/en/Apps

It’s something we’re spending a lot of time on at Mozilla.

We envisage Web apps to run on any device, any browser, and to be distributed through any store or website.

https://apps.mozillalabs.comhttps://developer.mozilla.org/en/OpenWebApps

App-like experience

Launch from the desktop or home screen

Something that needs to be tackled with Web apps is how to make them feel like real applications rather than glorified websites.

One way that is being considered is completely removing the browser chrome and running the application in it’s own window.

This will effectively mean that you have full control of the app UI and it won’t look like it’s being run in a browser.

At Mozilla we call this WebRT, which stands for Web Run-Time.

By using WebRT you can install a Web app directly into the OS just like you would a native application.

The WebRT app will look and feel like a native application when launched but will actually be running a browser rendering engine behind the scenes.

This is an example of the game Sinuous running as a WebRT app with the Firefox rendering engine. Notice the lack of browser UI.

https://developer.mozilla.org/en/Apps/Apps_architecture#Web_runtime

Game engines

Create HTML5 games today

If you haven’t already then I encourage you to give HTML5 game development a go.

And you don't have to create an entire game infrastructure from scratch, you can use some of the existing engines that are proving popular.

Impact. A 2D game engine.

I used this recently, and it’s really well made and has a good level editor and development tools.

The documentation is great and the author is active and very helpful.

http://impactjs.com/

Crafty. Another 2D game engine.

It’s a free engine and is doing much better than other free engines out there.

http://craftyjs.com/

Construct 2 by Scirra.

Windows only for now.

http://www.scirra.com/construct2

Gladius is a 3D game engine that we’re working on at Mozilla.

http://blog.mozilla.org/labs/2012/04/gladius-a-modular-3d-game-engine-for-the-web/https://github.com/gladiusjs/gladius-core

Conversion & porting

Using a single code-base

A lot of game developers want to target browsers but don’t want to rewrite their existing games in JavaScript.

To help this process, various methods of converting an existing code-base to JavaScript are starting to appear.

However, these methods also apply to non-games. Many people are now converting utility scripts from native languages over to JavaScript. Things like SQLite, even Ruby!

Emscripten

https://github.com/kripken/emscripten/wiki

BananaBread

BananaBread Cube 2 port via Emscripten

https://github.com/kripken/BananaBread

PlayN and Google Web Toolkit

https://developers.google.com/playn/https://developers.google.com/web-toolkit/

PhoneGap

http://phonegap.com

Keeping up

So much stuff on the horizon

I’ve really only touched the tip of the iceberg here.

There is much more coming in the near future.

Here are a few ways to keep up with things and get yourself prepared, particularly the things happening at Mozilla.

Are We Fun Yet? on the Mozilla Wiki

https://wiki.mozilla.org/Platform/AreWeFunYet

Multitouch

WebBluetooth

WebGL

WebTelephony

WebSMS

WebNFC

Geolocation

CameraWebUSB

Battery API

WebContacts

Full Screen API

Settings API

WebVibration

Are We Mobile Yet? and B2G

http://arewemobileyet.comhttps://developer.mozilla.org/en/Mozilla/Boot_to_Gecko

Firefox Aurora

“Get a first look at the latest developer tools, security features and innovative HTML5 and other Web technologies.”

http://www.mozilla.org/en-US/firefox/channel/#aurora

Firefox Nightly

Bleeding edge functionality.

Testing only.

http://nightly.mozilla.org

Final thoughts

Some things to bear in mind

Before I finish, I’d like to talk about some things I’d like you to bear in mind regarding HTML5 game development.

HTML5 is not magic

It cannot do everything

There seems to be a lot of buzz around HTML5 in that it is seen as *the* technology to create absolutely everything with.

This thinking is wrong.

Just because games can be made with HTML5 & JavaScript, it doesn't mean that all types of games should be made with those technologies.

It can be the case that HTML5 & JavaScript might not be the best platform for your game. That isn’t a bad thing.

We need to be realistic.

Create games for the Web

Stop replicating other platforms

Right now, we tend to be looking at games on the Web by comparing them to other platforms, usually by porting successful titles to HTML5 from another platform, like iOS.

By doing this we're setting things up to fail, because the Web isn't the same as other platforms, and nor should it try to replicate them.

This fails because we just end up comparing the Web port of the game to the version from the native platform, which is unfair and will usually always leave the Web version looking inferior.

This isn't because the Web can't replicate the performance of native platforms, it is really because the game was never created for the Web.

The other thing is that you’re actively limiting the capabilities of your game by replicating the experience from a iOS, PC or console game.

The Web is inherently different and doesn’t require you to think about games in the same way.

For example, the game doesn’t have to be stuck within an embedded box, it can be spread across a page, or even spread across the Web.

We need to think differently.

Embrace device limitations

Same game. Different experience

Just because HTML5 is supported cross-platform doesn’t mean that a HTML5 game should work the same way cross-platform.

Say you had a multiplayer Battlefield 3-type game running on the desktop using rich high-resolution WebGL graphics and WebSockets for real-time multiplayer.

Should it even be playable on other platforms, like mobile? And if so, should it look and feel the same as it does on the desktop?

My opinion is that it should work on other platforms, where necessary, but not look and feel the same.

This is purely down to hardware performance, input methods, and general experience. It would be crazy to think that a bleeding-edge desktop HTML5 game would perform at the same level on mobile hardware – we don't expect this from other platforms, so why HTML5?

And even if it could run at the same performance, things like screen size and input methods would make the game unplayable – everything would be too small and your thumbs would be in the way.

So imagine you're playing the HTML5 BF3 on your desktop, you have a fullscreen, immersive first-person experience with complex mouse and keyboard controls, like any other native desktop shooter.

Your friends are also playing in the game via WebSockets and you can see them running around in the game world.

Now imagine you need to leave the house for a while (god forbid) and you don't want to stop playing the game.

So on your way out of the door you open up HTML5 BF3 on your mobile phone, but instead of trying to replicate that epic immersive experience from your desktop you now jump into a mobile-optimised version of the game.

In this version you're still using WebSockets to connect to the same game that you're friends are still playing in, but instead of the intense 3D WebGL graphics and complex control system you get a 2D birds-eye view of the game world.

In this view you can see little green dots that represent your mates, and little red dots that represent the enemies.

From here you can basically act as the commander of the team in the same game you were in previously, while playing to the strengths of the device that you're currently on.

By clicking on each teammate you can send them a message that will show up on their HUD on the desktop, or by clicking on enemy players they will be highlighted in the 3D world that your friends are still playing in, or call in a airstrike by dragging out a target area on the map.

The point here is that you're still able to take part in the same game world that you were playing in previously while keeping a realistic and enjoyable experience by adapting to the device that you're using.

Go forth and make games

The future is awesome

So I hope that I’ve managed to peak your interest in HTML5 games enough for you to go out and play more with these technologies.

Even if you don’t want to make a full game, I encourage you to experiment with some of the individual technologies that we covered.

The future is very bright for games on the Web.

I’m really excited to see what comes in the following months and years.

Rawkes.comPersonal website and blog

Rob Hawkes

Rawkets.comHTML5 & WebSockets game

Twitter sentiment analysisDelving into your soul

RECENT PROJECTS MORE COOL STUFF

Rawket ScientistTechnical Evangelist at Mozilla

@robhawkes

Slidesslideshare.net/robhawkes

Get in touch with me on Twitter: @robhawkes

Follow my blog (Rawkes) to keep up to date with stuff that I’m working on: http://rawkes.com

I’ve recently worked on a project that analyses sentiment on Twitter: http://rawkes.com/blog/2011/05/05/people-love-a-good-smooch-on-a-balcony

Rawkets is my multiplayer HTML5 and JavaScript game. Play it, it’s fun: http://rawkets.com

These slides are online at http://slideshare.net/robhawkes