Web 2.0, Destroyer of Dreams

I had an idea for a game.

No, not that one, a real one.

And it wasn’t so much an original idea, but an idea to take one of the truly classic network-based games of the past and bring it into the modern era, so that people all over the world could play it.

But it wasn’t just an idea, but a plan. After all, one of the problems with writing a game — or software in general, for that matter — is incompatibilities between systems. Something compiled for my Linux laptop, say, wouldn’t run on someone else’s Windows machine. Sure, there are cross-platform scripting languages out there, but how many Windows machines do you think have the necessary interpreters pre-installed?

Handing someone a game and then telling them “by the way, you need to go download this other thing and install it first” is more of a buzzkill than finding out that your precious 4/20 is also Hitler‘s birthday.

But wait, you say, this is The Twenty-First Century! “Installing software” is sooooo last millennium! This is the era of Web 2.0! And sure, that’s mostly a meaningless buzzword, but dig down deep enough and we have web apps that don’t suck (as bad as they used to)! You can put the game on your website, and anyone in the world can come play it (assuming they have a reasonably modern browser)! Nothing to it!

And so what if you can’t program in Flash, since the only development tools available on Linux are fourth-rate? Flash is proprietary anyway; we can do this with open standards! SVG for graphics! JavaScript for client-side code! Whatever you want on the server! And bringing everything together, the crown jewel powering the Web 2.0 revolution, XMLHttpRequest!

The idea, the plan, the ideal was so glorious, I could not help but to pursue it. Was it but a pipe dream, or could I usher in a new age of gaming?

I sat down and put together a rough demo of the core of the client-side interface. JavaScript collected user input and told SVG how to draw the action. And lo, it worked! Sure, Firefox‘s JavaScript implementation only really handled one key pressed at a time, but that would be good enough!

And with that done, all I needed to demonstrate was near-real-time bi-directional communications between the browser and the server, and the technology would be proven! All that would be left is fleshing out the details!

But what treachery is this? XMLHttpRequest objects only handle a single request/response, not continuous bidirectional communications? The request gets sent all at once, and the object even explicitly disallows keepalive? Every time the player made a move, I would have to issue an entirely new HTTP request, each with a new TCP three-way handshake?

Oh, the latency! Oh, the bandwidth!

And woe, for security reasons browsers do not let JavaScript code open their own socket!

For want of a usable way to talk to the server, the demo was lost.

I suppose the game itself could be written as a Java applet, with everything else being all trendy Web 2.0 type stuff. But do browsers these days still come with a Java plugin by default?

No, seriously, does yours? What does about:plugins tell you if you put that into your browser (in case that link won’t work)? If a Java applet would actually work for people, that’d be the way to go, I guess.

Otherwise, since Flash development is pretty much out, the other option would be a standalone client. But if I can’t assume most people can do Java applets, can I assume they have a standalone Java or C# runtime, let alone Python or Perl? Or that someone would even know how to run such a program?

*sigh* Web 2.0, you fail.