Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Will HTML5 Change the Way Games are Made?
View All     RSS
October 31, 2020
arrowPress Releases
October 31, 2020
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Will HTML5 Change the Way Games are Made?

August 29, 2012 Article Start Page 1 of 3 Next

Will Eastcott is a video game technologist that has worked for EA, Sony, and Activision on triple-A titles and is co-founder of PlayCanvas, a technology company that provides a cloud-hosted development and publishing platform for HTML5 games. In this article, he shares his opinions on how the emerging technology will really affect game developers and makes a case for the language as a great next step in game development.

You have probably seen the headlines. "Consoles are dead!" "HTML5 is the future!"

The talk around HTML5 is often quite sensationalized and, dare I say, biased. Let's put all of that aside and introduce a little calm objectivity. Here is my measured proposition: HTML5 will fundamentally change the way we make video games. Before I explain why, let me summarize the state of play with HTML5 today.

Over the last 30 years, we have witnessed a general trend of increasingly powerful hardware platforms coupled with ever better strategies for exploiting that hardware through an evolving ecosystem of tools and languages. The drive towards hyperreal gaming environments has been relentless, with console manufacturers delivering ever more powerful technology into the hands of developers.

However, with the rise of mobile gaming, we have witnessed a new phenomenon. Gamers have responded exceptionally well to playing simpler games in any location, on any device, with any of their friends. These are the key demands of the user now. Technology is still important, and beautifully crafted pixels still matter, but what matters more is that a game is accessible and connected. What is more accessible and connected than a web browser?

So what are the options for building such a game? You could write it from scratch, but targeting more than one platform can be a tall order for a small dev team. There's Flash, although with every passing month Flash seems less appealing. A retreat from the mobile space and confusing messages about Stage3D licensing costs have generated considerable negative feeling amongst developers.

There are engines like Havok Vision Engine and Unity, for example. These engines generally target the desktop browser via proprietary plugins and mobile devices via a native build. And then there's HTML5. Before you finally plump for HTML5, it is vital to understand its strengths and know how to mitigate its weaknesses. Let's take a closer look.

An Evolving Standard

HTML5 is not done. It is still being developed by the standards groups W3C and WHATWG, so browser vendors are tracking a moving target. Therefore, the level of support for HTML5 is different across every browser. This is illustrated in painstaking detail by the site

An oft-cited example of cross browser inconsistency is audio. There are currently three distinct APIs: Mozilla's Audio Data API, Google's Web Audio API, and the Audio element JavaScript API. In recent days, Mozilla has announced that it has deprecated its own API and will soon begin work on implementing Web Audio. So it is clear that browser vendors are working hard to simultaneously innovate and converge the HTML5 platform to make life easier for the developer.

There has been a concerted drive from browser vendors to deliver new HTML5 APIs specifically for game developers. The three main examples are the GamePad API (which can read input from all natively supported pad devices), the Pointer Lock API (which hides the mouse cursor and reads raw mouse movement), and the Fullscreen API (which can make any HTML element go fullscreen).

These APIs have all been specced and implemented into multiple browsers in a consistent fashion in a short space of time. With their arrival, games like first person shooters are suddenly far easier to implement in HTML5.


Coders harbor remarkably strong sentiments about programming languages. Those coming from a console background are likely to view JavaScript with suspicion. It is yet another new language to learn, JavaScript will be slower than the equivalent C++ code, and optimization strategies such as vectorization are not possible with JS. Plus there's the fact that a game's code is available for all to see in the browser's developer tools.

I think it is important to reference Douglas Crockford's assertion that JS is the "The World's Most Misunderstood Programming Language". For C++ programmers, JavaScript is actually a breeze to learn. It is syntactically closely related to C++, although concepts such as closures and the "this" keyword can take some getting used to.

For those of us who don't like the rigidity and verbosity of a language like C++, JavaScript is a fantastic, dynamic language. Powerful features like first-class functions will drastically reduce the amount of code you have to write and the time it takes to write it. It's likely that a lot of people who convert to JavaScript won't be going back.

Performance is better than you might think. Firstly, the Web Workers API enables multi-threaded programming in JavaScript. Secondly, and more importantly, JavaScript engines have come a long way in the last few years. To illustrate, there is already a JS port of the open source physics engine Bullet, and although performance is not stellar, it demonstrates you can run some very CPU intensive algorithms at acceptable speeds using JS.

Let's face it -- cloning exists on all platforms, but when it comes to HTML5 games, it is important to keep a couple of things in mind. Tools such as Google's Closure Compiler do an impressive job of optimizing the source, and poring over the obfuscated source code is not the same as access to the original code. As a codebase increases in size, the more impractical it becomes to attempt to reverse engineer it. Secondly, if a game is to have an online component, much of the code can be run on the server, and the client is really just a thin visualizer. Much of the "value" resides hidden on the server.

2D vs. 3D

One of the most fundamental choices when designing a game is whether the graphics are to be 2D or 3D. 2D HTML5 games generally use a 2D context queried from a canvas element on the page. Every major browser now has good support for the 2D canvas context, so if your game is sprite based, there are no worries.

Things are more involved if you are looking to develop a 3D game. The only way to get high quality, hardware accelerated 3D graphics in an HTML5 game is to use WebGL, a JavaScript interface almost identical to OpenGL ES 2.0. Support for WebGL on the desktop is strong in Chrome and Firefox, and only Internet Explorer is holding out. Fortunately, Google Chrome Frame provides an elegant mitigation for Microsoft's resistance to WebGL, and although Apple has yet to enable WebGL in Safari by default, it is available to developers now.

WebGL has come a long way since the 1.0 spec was announced in March 2011. With OpenGL ES 3.0 freshly unveiled at SIGGRAPH, you can bet it won't be long until the corresponding spec for WebGL 2.0 is released. Exciting times for 3D browser gaming, to be sure.

Article Start Page 1 of 3 Next

Related Jobs

Insomniac Games
Insomniac Games — Burbank, California, United States

Technical Artist
University of Utah
University of Utah — Salt Lake City, Utah, United States

Assistant Professor (Lecturer)
Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States

Junior Gameplay Programmer
Remedy Entertainment
Remedy Entertainment — Espoo, Finland

UX Designer

Loading Comments

loader image