Where we’re at with HTML5 games so far
HTML5 games have come a long way in the past year or so. We’ve gone from being extremely cautious with the technology to going full-on crazy with it. We’ve gone from making very basic retro-esque 2D games to creating rich 3D first-person experiences. We’re basically experiencing the beginnings of the Web as a viable platform for games without plugins.
Loads of games
2 years ago I could have counted the amount of decent HTML5 games on one hand, perhaps even on one finger. Today I have the opposite problem – I just don’t have enough fingers to count them on! There are now many games out there that feel great, look great, and perform great. Here are some of my favourites…
There are plenty more out there but they give a good overview of the quality of HTML5 games that we’re starting to see. And the best bit? We’re not even seeing the full potential of graphics and possible functionality in these games.
If you’re interested in discovering more HTML5 games then you can check out places like Scirra, GameSalad, and HTML5games.com
Better tooling and frameworks
One of the reasons that we’re seeing so many new, decent HTML5 games is that the tooling for creating them is also getting increasingly better. As well as that, we’re now seeing developers getting used to these tools and learning how to push them to their limits.
There are a huge number of game engines and frameworks out there today. Here are some of the best…
We’ve been trying to validate the platform
The sad thing about the state of HTML5 games, at least to me, is that we’re currently stuck in the mindset that we need to prove that the Web is ‘good enough’ to make games like you see on iOS, desktop, and console. We’re constantly porting games to HTML5 then comparing them to those on existing platforms and acting surprised when they look different, feel different, perform different.
Guess what? A game built for a specific device or platform is definitely going exhibit some quirky behaviour when ported somewhere else – it doesn’t mean that the port platform isn’t able to handle games. I can see why we do it though, it’s hard to create games from scratch and especially so when you’re also trying to understand how to use a new platform. It’s simpler and easier to bring over games from somewhere else that we know already works and is successful.
Another thing is that we’re used to building and playing games on the Web with Flash, but we often forget that HTML5 is a completely different beast (arguably a much more interesting beast). For example, a game in HTML5 doesn’t need to sit within a traditional rectangular box. Sounds silly? Perhaps, but there is inherently much freedom to be had with games created with Web technologies at their core.
Call to action for games created for the Web
The way I see it is that we’ll be forever limiting and holding back the full potential of true Web-based games if we constantly aim to replicate experiences elsewhere. The Web should be seen as a unique platform in its own right, not as yet another channel doing the same thing. In short, we need to be building games for the Web, games that understand and use the Web to its full potential.
So what would games created for the Web look like? What kind of games could we create if we took what we know about building websites and Web applications and applied those skills to games?
Using URLs to link to in-game content
At the simplest level, we have the humble URL. Often taken for granted by Web developers, this most basic of features is what allows us to reference any piece of content on the Internet so it can be easily accessed by others. There’s no alternative feature like this that works across multiple game platforms in the same way, let alone one that is as standardised and simple to use as the URL.
We’re used to using URLs to link to entire pages and applications. Hell, we even use those fancy # URL fragments to link to specific pieces of content within a page. Yet we don’t seem to be applying this same logic to games on the Web, at least not in the ways it could be done.
For example, imagine that you’re fighting the boss in BrowserQuest and you decide that you’re going to need your friends to help you out. Instead of just linking to the main game, and requiring your friends to travel all the way to the boss, how about if you could send them a link (via Twitter, perhaps) that takes them directly to your location within the game world.
It’s such a simple feature but it’s likely the most important one that we need to utilise more for games. All you’d need to do is convert the current player’s coordinates / area position into a unique link that they can then send to whoever they want. Why convert the coordinates into a unique link? You wouldn’t want to transmit raw coordinates as that could result in players abusing the system an teleporting all over the place. Not fun.
Going beyond position URLs, what about simply using URLs to link to levels and progress throughout a game? We tend to treat things like games as one-page experiences via a rectangular embed or canvas elements. That doesn’t mean that you can’t use URLs to dynamically change the content of that game. You could use the History API, for example.
User-generated content
Another ‘feature’ that’s very much part of the Web is the idea of user-generated content. Now, you can sort of get this in other games but it’s not woven into the fabric of the platform. The Web, on the other hand, is constructed from user-generated content – that’s what it’s all about.
How does this apply to games? Well, allowing players to create new content and customise their gaming experiences with ease. HTML and JavaScript are perfect for this and the concept of ‘hackable games’ is one that’s just beginning to take off.
One great recently example is FightCode, where you code your own bot with JavaScript and share it to do battle with other bots from the community. It’s fantastic fun and really highlights how games on the Web can be unique and user-generated.
Breaking free from embedded rectangles
It’s fair to say that the vast majority of HTML5 games are displayed within a rectangular element (usually canvas) contained within the browser window. This is what we’re used to from embedding Flash games, and the default behaviour of canvas sort of forces you into this approach.
There’s nothing inherently wrong with this, particularly for simple games, but it’s limiting and the experience isn’t as immersive as it could be.
One alternative approach to take would be to expand your game to fill the entire browser window, or even use the Fullscreen API. This still constrains things within a rectangle but it’s a much more immersive experience.
The second, more Web-like alternative is to forget about the rectangle and build games that can interact with other content on the page. For example, you could use DOM elements instead of the canvas and then have the ability to move them around, to interact with other DOM elements on the page.
I have seen the second approach only a few times, usually with a mini game that runs along the header or footer of a webpage, or perhaps in the background. The game is part of the site, rather than embedded within it. One cool example had a rocket ship you could fly around the page and blow up other DOM elements with.
Providing APIs to access in-game content
Something that we now expect from Web services is a decent API that allows us to access all the juicy data. Interestingly, this is rarely, if ever seen with games.
I would love to see games created that have rich APIs that allow for all sorts of data to be retrieved and analysed. This is one of the situations where we can take our knowledge of building services for the Web and apply that directly to games.
One great example of how this data can be useful is with DayZ. This Windows FPS doesn’t itself provide the data to players, but if you run a server that hosts DayZ games then you can access the APIs and resulting data that is subsequently stored within a MySQL database. What this has resulted in is a blossoming set of tools and data visualisations that help the server admins keep an eye on the players, and for the players to keep tabs on their and their friends progression.
The beauty of this API-led approach is not that it becomes part of the game, more so that it opens up the possibility for countless modifications and tools to be created by the community. It is unlikely that this approach will succeed, let alone happen on any other platform than the Web.
Second-screen experiences
Coupled with the idea of APIs that provide in-game content is the idea of second-screen experiences. In a nutshell, this is about having a game playing on one screen (like your desktop) and a supplementary experience happening on another (like your mobile phone).
Going back to DayZ, many players inherently have second-screen experiences while playing this without even realising it. What happens is that they open up and use third-party mapping services on their phone that allow them to get more information about where to find the best gear in the game. This secondary experience within DayZ is not directly connected to the game (you could play without the map) but it directly enhances your game experience if you do use it.
If we create games that open up the data within them, then what other secondary experiences could we give players? Perhaps data visualisations of their journey, or a real-time map of their position using WebSockets, or a way to de-clutter the main screen by offloading UI elements.
This is still a relatively new area and one that we will start to see progression in with things like the Wii U.
Using mobile devices as controls for games on a separate screen
Related to second-screen experiences is the idea of using a separate device to control a game. Not a mouse, keyboard, or gamepad, but rather a device that we wouldn’t normally associate with input. In this case, the idea is that mobile phones can be used as a powerful and customisable gamepad for any game that is playing on another device.
The concept is being explored in a few areas, with a fully-functional concept now available from Brass Monkey. It still requires some native code and plugins, but with the forthcoming WebRTC functionality in browsers I believe that we’ll be able to replicate the experience with pure Web technologies.
Asymmetric gameplay and persistent data across devices
I’ve left my most demanding request till last, mostly because it’s the one I want to see happen the most.
The concept of asymmetric gameplay is one that is starting to gain a lot of interest, though it’s rarely been seen in the past. The idea is that the game experience on each device is entirely dependant on the features, performance, and capabilities of that device. In effect, the same game played on a desktop computer would look and feel different when played on a mobile device. A more fitting Web-related name is responsive game design.
Imagine for a moment that you’re playing the latest WebGL version of Battlefield 3 (BF3, a hugely popular FPS) on your desktop computer. It’s a great experience; it has rich HD graphics and it’s using WebSockets for real-time multiplayer with your friends.
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 – it should be asymmetric.
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 again that 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.
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.
I came up with this concept quite a while ago, and not long after that I discovered that EA had already produced a working demo that they showed off at the last Google I/O.
They called it Strike Force and the idea was that you have desktop players competing in a rich 3D arena using the Gamepad API. From there, mobile players could jump into the same game but instead of seeing the rich 3D world they’d see a top-down map that allowed them to drop airstrikes and generally help or frustrate the other players.
It’s a very promising concept and it appeals directly to the core of HTML5 and the promise of cross-platform games. I truly hope that we see more of these games in the future.
Where will we be in 2 years?
I hope it’s clear by now that HTML5 games have made significant progress over the past few years, and that we have huge untapped potential with the Web for it to become a games platform in it’s own right.
So what do the next 2 years have in store for Web games? Here are my predictions…
- We’ll see some big games and announcements as a result of the huge interest from AAA (no, not the batteries) game studios and tool-makers
- Browsers will be even faster than they are today as a direct result of improvements made for games
- Mobile JavaScript performance will be significantly better than it is today, particularly with things like WebGL
- We’ll be tantalisingly close to replicating near-native speed with JavaScript
- HTML5 games will move out of browsers and into ‘native’ experiences that show no sign of being a ‘browser’
- HTML5 games will move to the TV as a result of things like Ouya
- We’ll experience the first original HTML5 game (not a port) to become a huge success and make a bucket-load of cash
- The idea of seamless gameplay across devices and platforms will be every-day
Whatever happens, I’m hugely excited about the future of games on the Web. We’ve really not even scraped the surface of what’s possible yet!