JS and HTMLGaming: From Angry Birds to ZX Spectrum

There’s been a bit of an explosion in the HTML5/JavaScript gaming sphere of late. Browser games have seen a surge in popularity, and developers are beginning to find a suite of handy APIs and other tools at their disposal. Rob Hawkes is keen to sing the praises of HTML5 and JavaScript and their application in browser gaming. Rob is a visual programmer, author and technical evangelist at Mozilla, leading the gaming side of Mozilla’s work within the developer community. He gave the closing keynote talk at Web Directions Code, held in Melbourne back in May, where he showed us all just how awesome HTML5 and JavaScript gaming is rapidly becoming.

Hi Rob. Tell us about your background in development.

I’ve been developing on the web for about 13 years. I learnt bits and pieces about HTML and CSS — I was more interested in web design, but then progressed into PHP, when I learnt you could do quite powerful things in server-side development. Once I knew how to create a form I thought, now, how do you get access to that data?

Everyone starts off learning PHP with forms …

Right! It was really cool being able to send data to something. So then I went to work in the industry doing mostly front-end development for a couple of years. I got interested in media, and quite involved in JavaScript, and from there I realised I was not so interested in actually making websites, but rather learning the technology and pushing it to its limits. I was always very interested in game production and taking something and doing something crazy with it just to learn how it works, so while I was at university I was doing a lot of stuff with HTML5 — especially canvas.

You must have been mucking round with canvas in its early days.

Actually, canvas was around way before I started. Apple created their dashboard widgets with it. It was always in WebKit, although it never really stabilized in the other browsers — or at least it was never interesting. Nobody really did much with it. But when I came across canvas I thought it was really cool. I got in at a good point — there weren’t really any books around on it, but there were opportunities that arose with it. I was one of the few people that was digging round with it. Apart from that I was getting involved in experimenting with JavaScript APIs.

I see myself as being neither a designer nor a developer — somewhere in the middle. I like visual programming. Things like game production and canvas are perfect because you can tie together hardcore development with some really visual front-end experiences. That’s my focus at Mozilla; the game development side of the web — that and Boot2Gecko, which is a mobile device project we’re working on.

So what got you interested in HTML5/JavaScript gaming? Are you a big gamer?

I’ve always had games in my life — I had a ZX Spectrum, consoles …

Wow! You’re a fan of the ZX Spectrum?

My dad wasn’t that into computers, but for some reason he thought it was a great idea to buy one. And I was just fascinated by the idea of putting in a cassette and this game appeared! I mean, I was really young, but I still remember that — Duck Hunt, and all those crazy games. Then when I got into PC gaming it was the end of my productivity for a very long time! But games have always been very interesting to me. Technologies like Flash and JavaScript made me realise, cool, I can make a game now. And then once you start creating games it opens up a whole new realm of possibilities. It’s like the feeling I got when I first made a website — I created that! You get to learn so many different technologies within game development — input, visual graphics, sound – and you don’t always get that experience when you’re building a standard website. With games you’re always pushing things to the limit.

So if I was interested in HTML5/JavaScript game development, what would be the first thing I could teach myself and where would I head?

Get to grips with JavaScript; the standard language-related stuff. But then once you’re comfortable with JavaScript, have a look at some of the graphic APIs — things like the Canvas API. Canvas is such a good API. Before I came across it I didn’t really know how I could draw things in the browser without creating images. Also have a look at the Audio API. The multimedia functionalities in HTML5 are really interesting.

Take a look at some of the game engines. You might not necessarily want to learn them from scratch, but there’s a whole bunch of game engines that allow you to get up and running without having to fully understand the fundamentals. Things like Crafty, which I believe is an Australian engine, and that one’s free. And then there’s a really good one for $US99 and it’s called Impact — a fantastic game engine that’s really well documented. If you want to create a game with JavaScript but you don’t necessarily have the inclination to get too ingrained in the implementation, those engines are a really good way to start.

If you really want to get into the nuts and bolts of game development, learn about how to do animations using tools like requestAnimationFrame, which allows you to optimise loops in JavaScript. When you combine that with the Canvas API, and say, make a block move across the screen, it’s not a big jump from there to using keyboard inputs. From there it’s up to you where you want to take it.

So it seems that you still need a good understanding of basic JavaScript.

Right. I mean, there are jQuery-esque game libraries — the engines like Crafty and Impact are a little bit like that. But they’re not quite as abstracted as jQuery. If you want to do some more complex stuff you’ll still need to write JavaScript. But if you just want to do basic animation — like bring an image in as a sprite and move it around — you could do that with Crafty. The problem is then you’re not fully getting into the experience of what’s happening behind the scenes. Outside of the web, if you want to make a game then you can use Flash or Unity, simply because it abstracts a way to the complex animations and physics.

For me, though, knowing JavaScript means I can create a game from scratch. And yeah, it might be difficult, and it might take a while, but it’s worth it in the long run. If you can at least understand the basics of it — for loops and arrays and objects, that kind of stuff — then you’ll really appreciate it when you want to push things a little bit further.

HTML5 and JavaScript seem to have precipitated an explosion in retrogaming — strategy games, platformers, and the resurrection of old titles like Pong. Do you see it heading anywhere else, into more complex, interactive projects?

The retrogaming thing is quite cool. HTML5 gaming is at quite a simple stage, so the retrogames are perfect — they didn’t require too much power, they’re mainly in 2D and they are pretty easy to create. It was the same when Flash gaming was big. There’s nothing stopping developers using JavaScript to create more immersive game experiences. We’re starting to see that with WebGL. A lot of people are beginning to create games closer to that which you would see on iOS — even 3D games as well, using technologies like hardware acceleration.

Pong is great, but it doesn’t push the technology that much; even Angry Birds doesn’t push it too much. I’ve seen people creating Quake 4 in WebGL and it runs smoothly. We need to see more of those games to help legitimise the web as a platform for modern games. We have the tech and the power to now create proper games. And by proper games I  mean what you would see with PC titles.

We’re starting to see companies and developers leaning in that direction now. We need to create web games that are built for the web. Right now we’re seeing a resurgence of interactive games, but we’re not seeing too many games created specifically for the web. I want to see games that use the benefits of the web while also being aware of the limitiations of a device. Just because you can make the same game on two platforms doesn’t mean it should be exactly the same. And I think the web has the opportunity to be a gaming platform in its own right — a unique target rather than just another place to put standard games. Once game developers have got that, I think we’ll see some really interesting stuff.

Right now games on the web are really just replicating other platforms — the games are pretty static, and they don’t really use anything that the web provides, such as social functionality or the ability to connect to other APIs. All of this stuff is inherent to the web, and we’re using it in websites, but what would happen if we used it in games?

A lot of what developers are doing with browser gaming tends to involve mining the past, which is not necessarily a bad thing — but can you see concepts and ideas expanding?

That would be my dream. Right now I think we’re being unfair to HTML and the web as a gaming platform. We’re comparing it to previous platforms; so, for example, we’re porting games from iOS — we have Angry Birds running on the web in HTML, but it was never created for that. We brought it over because it was successful. It’s unfair; we compare the web platform to the native platform it was built for. And of course the native one is better — it was built for touch controls, and for a certain programming language and technology.

We’re never going to allow the web to flourish on its own by restricting it to what we’ve been doing previously. We can unleash the power of the web, and try something that isn’t as constrained as the games we normally play — where, for instance, we’re seeing games contained in a little box in the browser. There’s no reason why a game has to be in a little box as part of a website — it could be part of the web; you could chase the game around the web. There’s no reason why you couldn’t play a game over Twitter.

I’m hoping that we see an explosion of new games as people warm to the idea of games on the web. JavaScript APIs are built for the web. It’s very basic technology; make a web socket connection and a couple of events, and you can send and receive messages to a web server in real time — it’s not a big jump from there to making a multiplayer game.

How do you make these ideas marketable?

This is something we’re trying to tackle at Mozilla. And it’s one of the questions we’re getting from game developers in general — “It sounds great, but what if I don’t want to give my game away for free?” People are used to DRM and code protection and they come to the web and it’s all open; the source code is all there. So we’ve got two issues to tackle here. One: how do we convince people that having open technology is a good idea? I think that’s an easy problem to solve, because if you are worried about your game being stolen, then I don’t think the web is right for you. Just because you could make a game in HTML does not mean that is the best platform for your game. And there are ways to alleviate these things by, say, minifying code – methods that could help developers to be a little bit more comfortable about releasing code they’ve spent many hours working on.

The second issue is the marketing: how do you sell your games? If you can’t make a living, then there’s no point making the game, as a company at least. And you could go down the route where you don’t worry too much about stopping people getting into your game if they don’t pay, but you work on a donation model. On the flipside if you want to actually lock people out if they don’t pay for the game, you can do that. We’re working on open web app APIs at Mozilla which allow you to provide a receipt that needs to be validated on the game developer server. We’re looking at ways to embrace the openness of the code and not prevent people from looking at source code, but just creating a point where you can say, have you paid for this game? If not, then you’re not going to get the full experience.

It’s not a magic bullet. If it was just a single-player game which they’ve paid for, there’s no stopping someone, once they’ve got all that source code, taking it and doing what people do with web technology. I highly doubt games on the web are going to be pirated any more than games elsewhere. There’s a lot more to pirating games than just taking the source code. If you have a server-side component then you’ve got protection, and that’s where a receipt system could come in. If you know the game can’t be played unless someone accesses your server, you can control that experience. If they steal the front-end code, they still can’t play the game because they haven’t got hold of your server-side code, and if they can get into your server then you’ve got another problem entirely.

I think there is absolutely no issue with monetising games on the web — the issue right now is we have yet to have a resounding success. It’s a chicken and egg thing — people are waiting for that success and that success is not coming because people are waiting. We need someone to step up and give it a go.

And it’s the web, so you don’t have to sell games like you did previously. You might be able to make money from in-game payments, so you can still have that free game experience but control what kinds of things people experience in the game — what level the player reaches, what armour or power-ups they have. Once we fully understand what’s possible, we’ll work out how to monetise it, particularly now we’re getting big players on board like EA — if anyone knows how to make money it’s those guys. And I think the indie developers will follow suit after that. It’s not as easy as it is on, say, iOS … but they’ve had a massive headstart. There are ways on the web. Newspapers have started looking at introducing paywalls …

Which aren’t necessarily working.

And that’s the thing, should you be locking out content? Is that not going against what the web is? Are there other ways to make money that suit the web in a better way? Maybe that is the answer to the question — not, “how do I stop people from playing my game unless they pay?”, but, “how do i make money out of this game using what the web is good at?” Maybe that’s not even getting the money from players, but from sponsors. I’d be interested to see where we stand in a year’s time. We may see a successful bunch of games making lots of money.