Desktop versus browser, gaming edition

2012-07-23

When I announced my first experiments with Pygame, a couple of friends asked me why I would bother to make games for the desktop. Weren't my games designed to showcase HTML5? And aren't casual games a better fit for the browser anyway?

They have a point. The web browser is an ubiquitous and powerful runtime; Javascript is powerful too, as a language, and excellent for prototyping. Last but not least, a HTML5 game can be played on the same Web page where you go to read about it: there's no download and no setup involved.

So I sat and thought about the question. Still am, in fact.

When the first personal computers and game consoles appeared in the late 1970es, they were primitive compared to institutional computers and arcade games, respectively. Yet they were enormously successful. Playing in a social environment, be it an arcade or computer lab, is a special experience, but it's trumped by simply not having to wait and/or pay every time you want to play. You buy a game, you own your copy, just the way you would a book, and you answer to no-one.

How easily we forget.

Nowadays broadband is ubiquitous (unless there's no coverage) and always on (unless there's an outage). You can always make an account online (unless you're banned by mistake... with no recourse...) and login to play whenever you want (unless the servers are overloaded).

But I digress.

When I first started making games for the Web, HTML5 wasn't yet called that and games like Square Shooter were being mistaken for Flash, despite the fact that the technology behind it exists since at least 2006. Compatibility across browsers was considered a lost cause. Saving data was only possible through cookies -- or on the server. I braved all these obstacles, proved naysayers wrong, learned a lot and had tons of fun in the process.

Fast forward three years. Everybody and their dog makes HTML5 games. They run on machines where Flash doesn't. People are experimenting with 3D on the Web, and emulating old gaming platforms in the browser.

On the other hand, you try explaining someone why your game doesn't work in Internet Explorer 8. Or why the arrow keys aren't working in Safari and Chrome. Or why your sound can't be heard in the same two browsers. And did you ever manage to get localStorage working? Because I couldn't, not in any browser. Also, were you hoping to target mobile devices with the same codebase? Forget about it, those are "special". Each in its own way, of course.

It's the death of a thousand cuts. The whole thing has lost its novelty and all those minor annoyances are piling up. On top of that, I have friends who dislike playing games in the browser. Can't blame them either; I'm fed up myself with games that just don't fit in my window because the author didn't take the chrome into account. That, and games exacerbate the already absurd resource consumption of a modern web browser -- a platform that's overstretched as it is, trying to be everything at once.

I need a change. I need to rely on certain things. I need game development to be about games, not the DOM, event bubbling and namespace pollution.

I need to make it fun again.