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 …
You must have been mucking round with
canvas in its early days.
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
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.
I’ve always had games in my life — I had a ZX Spectrum, consoles …
Wow! You’re a fan of the ZX Spectrum?
If you really want to get into the nuts and bolts of game development, learn about how to do animations using tools like
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.
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.
Tom is the online managing editor at SitePoint. His working day consists of arming himself with an assembly line of long blacks and overseeing the curation of content and flow of traffic across the SitePoint network. His passions include bargain vinyl bins, yoga, juggling sci-fi novels with classic literature, and axolotls. He's currently wading into the world of Android development and HTML5 gaming.