Author: by Will Eastcott

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 caniuse.com.

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.

JavaScript

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.

Mobile Support

HTML5 games work very well on the desktop, but transitioning them to mobile is not trivial. Claims that HTML5 games built for the desktop will transition with minimal effort to mobile platforms are generally exaggerations. You need to be prepared for a weaker class of CPU (meaning slower JavaScript execution) and GPU (meaning reduced vertex and fragment throughput if you are targeting 3D).

Screen resolutions can vary wildly, and developing your game in HTML5 will not magically enable controls that work well on both the desktop and mobile. WebGL support on mobile platforms is fairly embryonic at the moment, although the landscape should look very different six months from now.

In the meantime, there are some options worth investigating. Technologies such as PhoneGap, AppMobi, and CocoonJS can wrap up HTML5 games in a native wrapper that yields better performance. A limitation at this time is that none of these technologies include workable WebGL support, but it is likely that some middleware developers are already building a solution.

Ease of Development

In the scheme of things, developing HTML5 games is very easy. The browser makes for an incredibly solid development platform, particularly when compared to the tools provided by some hardware vendors.

The tools themselves are free and largely integrated into the browser itself and there is no compilation step when coding. The dynamic nature of JavaScript allows for a powerful edit-and-continue type development, and an ever-present console is very handy. Everything about web development is geared towards fast iteration times and simplicity.

APIs are clean and straightforward, and because of the huge community of web developers there is plenty of sample code and live tutorials.

Accessibility

If there is one pretty much universally understood paradigm in computing, it is navigating to a web address in a browser and consuming the content located there. Be that as it may, gamers are an impatient bunch (apologies for the sweeping generalization). Make them download or install something, and you will definitely lose a significant chunk of your clientele at the first hurdle. And not all of them will be inclined or able to install a proprietary browser plugin in order to run a game.

HTML5 games require no install or permissions to run, and contrary to what some believe, they can be permanently cached to a device after an initial download of resources. Obviously, this can facilitate offline play if your game does not require an internet connection.

So if your game is delivered as a reasonably fast, seamless page load, you will have happy users that actually make it into Level 1.

Finding an Audience

As of Google I/O 2012, Google Chrome has accumulated 310M active users all by itself, a number significantly larger than the total number of current gen game consoles out in the wild today. When you then go on to consider other HTML5 capable browsers, we are looking at a potentially vast audience.

Just because your game sits on a URL and is visible to the world does not mean people are going to find it. Discovery plays an important role too. App Stores have a notoriously narrow "shop window" and it's easy for games to be lost in the crowd. HTML5 games are no different, but have some key advantages over native applications.

As web pages, they are indexable by search engines for organic discovery. Also, there are multiple game portals and stores, including the Chrome Web Store, where you can make your game known. But you are not restricted to web distribution alone. As an example, you can sell your HTML5 game on the Mac App Store by packaging it as native application with an embedded WebView component.

It is important to reach as many users as possible, and HTML5 allows you to combine many distribution channels, rather than any single one.

Getting Noticed

Like it or not, building a game atop a bleeding edge, "hot" technology will only result in better coverage. If you code two identical games, one with C++ and one with HTML5, it is fairly obvious which one is more likely to be picked up on by the media. It is not necessarily fair, but that is simply how things are with HTML5 right now -- people are excited to see what developers can do with it and there a lots of opportunities to be a pioneer.

Rethinking Game Development with HTML5

Hopefully you are now in a better position to determine whether HTML5 can work for the games that you want to make. But here's where I think the debate has fallen short. HTML5 is not merely a set of standards to power the innards of video games and should not be judged solely on that basis.

It is powering a new generation of productivity apps that is stoking a trend for moving our digital lives into the cloud. The potential that this trend has to shake up the tools and workflows that we use in order to make video games is astonishing and we have not yet begun to scratch the surface.

A Window To The Cloud

Today, we think nothing of using cloud apps. Web mail is by far the most popular example, and where we might have once been wary about storing our personal correspondence on a remote server, we have now become very relaxed about it. There are now productivity apps of just about every type that exist in cloud app form: word processors, image editors, code editors and so on.

The cloud brings a lot of benefits in the context of games. There is nothing to install since the web app is delivered to the browser from the server (or the browser's cache). The tools always stay seamlessly up to date, which ensures that users remain in sync with each other and are always using the latest and greatest release. User data is always safely backed up and trivially restorable. A user's OS or browser can even crash and work will have already been saved to the server.

These are all really useful features when it comes to development, and to give users a view onto a cloud-based system, you are going to need a browser. And the best way to build the interface in the browser? In my opinion, it's HTML5. Although it is possible to use Flash, Java, or write a custom plugin to implement a game tool, when it comes to writing a complex web app, HTML5 is the most scalable solution. The case for this is only becoming stronger with the ongoing evolution of easy-to-use web app frameworks such as ExtJS, Google Closure, and SproutCore to name but a few.

A New Way to Collaborate

Having worked on a number of different game editors over the years, I recognize that most of them have supported collaboration via an integration with some form of version control. A game is usually made up of a number of documents that we may as well call "levels". A level might persist as XML or some other format. If two or more people edit this data file simultaneously, there are a couple of things to note. Firstly, user A may not be aware of what user B is changing and vice versa. Second of all, when user A has committed changes, user B will have to merge her changes with user A's.

It is possible to limit the tool to exclusive checkouts, but this just means one user can block others and hold up development. Performing merges is fine when they can be automated, but this is not always possible. Merging code visually is something a coder is used to, but how do you have a designer intuitively perform a manual merge on two sets of level data? Although not impossible, it is a very hard problem to solve well.

So let us take a different approach. If our dev tools are running in the cloud, with all clients connected to one server, why not allow seamless editing from all users? Again, HTML5 gives us everything we need.

Using WebSockets (bi-directional comms over TCP), we can stream edits between clients so that real-time collaboration is possible. Once you have worked in this way and experienced the benefits first hand, there is no going back to the old "exclusive checkout", single-user environment.

Social Game Development

If you are a coder, it is a fair bet that you have a GitHub or BitBucket account. Just a few short years ago, most of us were content to install a local instance of Subversion or Perforce, to name a couple of popular version control solutions. And why not? They are marvelous pieces of software that backup and manage your code very well indeed.

So why the rise of version control as a service? There are many reasons, but the key driver is community. Coders can now network like never before, following other developers or interesting projects, and receiving immediate notifications as soon as updates are made. Bugs are fixed and features are added by a committed follower-base. And projects stand a far greater chance of getting exposure than if they were sitting on someone's hard drive or personal website as a ZIP archive.

So why let coders have all the fun? The same principles are perhaps even more relevant to game development, with the whole process provided as web service. This includes code development, but also covers other functions such as asset management, level editing, localization, QA, and publishing.

Let's face it: making games is hard, and making a (good) game alone is not an option for most developers. The spectrum of skills required is often just too great. Developers need to be able to find each other and get involved in the game projects that excite them the most. Want to allow the community to build extra levels for you? Not a problem. Need your game translated into Spanish? Perhaps your followers can help.

The Cross Platform Holy Grail

Making a game cross platform matters. It broadens the potential audience and can therefore make a game more commercially successful. It is now many years since Sun Microsystems coined the phrase 'Write once, run anywhere' in reference to the Java programming language and most contemporary games middleware is designed with this in mind. In a similar vein, HTML5 certainly has the ability to deliver game content to a wide variety of device types.

I would argue that it is very important for game development tools to be cross platform as well. Perhaps 15 years ago, a tools programmer would have built an app with a technology like MFC. With the passing of time, better technologies have arrived, to the point where .NET application development is generally acknowledged as being fairly painless -- but with it, you are still limited to Windows. In our multi-device lives, it seems overly restrictive that we have to be sitting at a desktop PC to access our projects. You should be able to access, edit, and publish your work from any device via tools that have a consistent interface and suitable controls.

Interface building with HTML5 is fast, straightforward, and designing web applications to work across multiple browsers is a well-trodden route.

Just a Link Away

One of the key strengths of HTML5 as a technology for tools is that all content sits on a URL. Each of the resources that make up a game can be accessed at a specific web address: a script file, a texture, a sound, a level or even the game itself. If a new asset is added to a project, the developer can tweet, IM or mail the link immediately. Nothing for other people to sync; it is there for viewing straight away.

This also simplifies publishing a game. If the game is already on a server and playable, publishing it to the wider web is really just a matter of access rights. A developer should be able to make a game live quickly and easily -- nothing to upload and no HTML to write. Publishing should just be a matter of pulling some simple levers in a web front-end.

In Summary

When it comes to writing video games, no technology is perfect. Depending on the game you are looking to build and the commercial objectives that you have for it, it is important to fully appreciate the implications of selecting one technology over another. HTML5 constitutes a truly awesome platform, not just for powering games, but also for powering the tools that are used to build them. If you can live within its limitations and work with an evolving standard, it does have the potential to make you more productive and help your games reach more people.

As we look to the future, the process of making games will continue to become ever more accessible. Development tools will run on more platforms, be easier to use, and make collaboration far simpler. The global community of game developers will strengthen and knowledge will flow more readily. The ultimate result will be that more people will be making better games and we will all be better off in terms of what is available for us to play as consumers. All of this would not be possible without the web, HTML5, and the Open Web Platform to which it belongs.