Few applications on the web have benefited from the improvements brought about by HTML5 more than browser games. Before its inception and widespread adoption, browser games were almost always developed in tools like Shockwave or Flash because the alternative was simply too time-consuming. While it was theoretically possible to create browser games without these tools, it was a far more laborious process which entailed not only developing the game itself but also coming up with some creative hacks to get around browser limitations, performance issues and compatibility problems. Shockwave and Flash content is cross-browser by nature and at that time had far better performance than almost all browsers’ Javascript engines, so they became the natural choice for many years.

Nowadays the situation is very different. In addition to the variety of multimedia features introduced in HTML5, changes to the way browsers deal with Javascript code have brought significant performance improvements as well – there is still a lot of progress to be made, but by and large the situation is a drastic improvement over that of even a single decade ago. Shockwave and Flash have all but vanished from the web, and with all major browsers moving to deprecate the 21-year-old programming interface which allowed these plugins to operate they could soon become a thing of the past entirely. This seems to be borne out by the relatively short life of Silverlight, which was Microsoft’s attempt at creating a competitor to Adobe’s products in 2007 but was deprecated after being around for only 6 years.

The open nature of HTML5 means that individuals and organisations are free to build their own frameworks around the features and technologies offered in the standard, as opposed to the closed approach pursued by the successive custodians of Shockwave and Flash. These frameworks both make it quicker to get started developing browser games and easier to implement common functionality such as collision detection and graphics effects, making the whole process much nicer to get to grips with. It’s certainly possible to write browser games without them and some developers may even prefer this approach as it allows them to specify the precise behaviour of the game, but in many cases there’s no value in re-implementing common functionality. This blog post looks at two such frameworks, one free and one paid, which allow games developers to concentrate on the details of their game and not the minutiae of things like physics calculations and graphics initialisation.

Phaser

http://phaser.io/

Under development since 2013, Phaser has become a very well-rounded game development framework built upon the similarly capable pixi.js graphics framework. An important feature of pixi.js (and thus Phaser) is its ability to determine whether a user’s browser can use a faster WebGL renderer instead of plain old 2D canvas drawing operations, and automatically set them up with one if so. This can not only increase the performance of games, but also gives more advanced developers the opportunity to create and use their own shaders to achieve impressive graphics effects.

Beyond its graphics capabilities, Phaser offers three different physics engines. Depending on the complexity and target audience of the game being created developers can either opt for a simple “arcade” physics system or one of two more advanced simulations which allow for complex interactions between objects. There is also a built-in particle system and input handler, each of which abstract away the difficulties of coding these common but sometimes troublesome aspects of games. Another interesting feature is the ability to import and use tilemaps created with the third-party Tiled (http://www.mapeditor.org/) which allows developers to create tile-based levels visually in a quick-and-easy tool. Phaser also recently released their own visual editor for games themselves, making this a very attractive package for beginners and more experienced developers alike.

Game Maker

http://www.yoyogames.com/gamemaker

While not intended specifically for browser games, Game Maker has the capability to export games created in it to an HTML5 player which can then be embedded in a web page. Whereas Phaser comprises a Javascript library which is downloaded and coded around, Game Maker contains a fully-fledged development environment complete with a drag-and-drop interface for building levels. It also incorporates its own C-like scripting language for implementing game behaviour, making it familiar to work within for many programmers. Testament to its versatility is how it is the engine behind a number of popular games, from the action-based multiplayer stylings of Nidhogg to the subversive RPG Undertale.

In common with Phaser it incorporates common functionality which many games will need to make use of – input handling, sound playback and physics interactions are common ones. However it also includes some more complex functionality not featured in Phaser, such as networking capabilities which enable cross-platform multiplayer gaming and analytics which let developers analyse player behaviour in their games to find bottlenecks and less enjoyable areas. When married with the comprehensive development environment, this looks like an attractive package for developers willing to spend money.

The technology which powered browser games of old will likely still be around for some time yet – the web is notorious for taking a long time to fully shed outdated technologies. However the adoption of HTML5 for producing browser games is already well underway, and it likely won’t be long before Shockwave and Flash join the increasingly long list of orphaned web technologies. It remains to be seen if we’ll eventually find ourselves in a similar version of the browser hell of the past with inconsistent standards and vendor-specific extensions, but as of right now the signs are moderately encouraging that we’re heading for a more standardised future for the development of both games and apps that function in browsers.