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.

3 Responses

  1. You could always use the classic standby of a hidden IFRAME, which would at least allow some browsers to use keepalive.

  2. I’m not up on all the web programming tricks, but that means using JavaScript to load the URL in a hidden IFRAME, instead of using XMLHttpRequest to fetch it, right? Since it’s technically not the JavaScript code itself issuing the request, the browser will allow keep-alive. I think.

    That just might work, assuming the browser can send the new request off before the user tries to issue the next one. On the plus side, I wouldn’t care what the response is, so the code doesn’t have to wait for one before sending the next request. It’s worth a try, I suppose.

  3. Upon further consideration, the semantics of the updates sent by the client are very much HTTP POSTs and not HTTP GETs, and I’m not aware of a good way to do a POST in JavaScript without using XMLHttpRequest. I suppose I could fill the IFRAME with an HTML form that does a POST and use JavaScript to fill out the fields and trigger the submission, but that’s starting to look very hackish.

    Plus, giving the server side of things some thought, a single persistent bidirectional connection with each client looks to be much cleaner and easier to implement than a bunch of HTTP requests flying back and forth.

    I’m increasingly inclined to think the applet or standalone app approach is more technologically feasible than a shiny buzzword-compliant Web 2.0 app. And the compatibility issue with a Java applet could be largely dealt with by pointing the user in the direction of where they can download the necessary plugin. I mean, that’s what everyone does with Flash so they can watch Homestar Runner and YouTube, right?

Comments are closed.