[Hey folks, the following is another guest post from my summer intern, Nicholas Brown. -Darius]
For the first piece of the summer Darius had me looking at two Javascript-based game libraries. Specifically I was tasked with looking at GameQuery to see if it was better than Akihabara, or at least to see what the differences are. The two libraries are very different from each other in a number of ways but they both have the same objective: use Javascript to make games.
GameQuery is a much more general-purpose library than Akihabara and is built on top of the jQuery libraries. The jQuery libraries are designed to streamline the interactions between Javascript and the HTML and Ajax on your page. These seem like quite solid libraries and if you’re a web developer I’d give em a look. I didn’t get that far into them while looking into GameQuery but I did at least get a glimpse.
The major difference between GameQuery and Akihabara is that GameQuery isn’t built on HTML 5 and doesn’t use the canvas element. GameQuery has something called the “playground” or at least that’s what it’s called in the tutorials. This is it:
<div id="playground" style="width: 800px; height: 600px; background: black;"> <div id="welcomeScreen" style="width: 700px; height: 250px; position: absolute; z-index: 100;"> <div style="position: absolute; top: 120px; width: 700px; color: white;"> <div id="loadingBar" style="position: relative; left: 100px; height: 15px; width: 0px; background: red;"></div><br /> <center><a style="cursor: pointer;" id="startbutton">click here to show the demo</a></center> </div> </div> </div>
Basically it’s just an HTML div with a black background. Not very sophisticated and more than a little hacky if you ask me. Compare this to Akihabara:
createCanvas:function(id,data) { this.deleteCanvas(id); this._canvas[id]=document.createElement("canvas"); this._canvas[id].setAttribute('height',(data&&data.h?data.h:this._screenh)); this._canvas[id].setAttribute('width',(data&&data.w?data.w:this._screenw)); }
This dynamically adds the HTML element through Javascript and lets you set the width and height at the time of creation. It also looks a lot more like actual code than the GameQuery div based mess.
The mix of HTML, CSS, and Javascript makes GameQuery a bit clunky to use and the provided tutorials aren’t terribly good. The API is pretty decent and better than Akihabara’s sparse documentation but the crucial omissions regarding the playground and the limited nature of the library compared to Akihabara both hurt GameQuery.
Oh and GameQuery lags. Rather badly too. HTML elements aren’t really meant to be moved around like game objects and it shows if you have more than a few tabs open in Firefox (and if you’re like me then you’ve got at least email open and perhaps Twitter, Facebook, and a few news or reference sites open) which means anything you’re running with GameQuery is going to be sluggish at best.
The one major point in GameQuery’s favor is that it’s compatible with non-HTML 5 compliant browsers. This includes all versions of IE up to 8 and older and current versions of the other major browsers as well. Akihabara on the other hand doesn’t work on IE at all (no canvas support) and they still have the majority of the browser market share. The one place Akihabara beats GameQuery on compatibility is the mobile market. It works on all the major mobile devices as far as I know and has library support for controls on the Android and all i-Platforms which is pretty cool since normally you need a plugin to do advanced games on these.
GameQuery is an interesting tech demo for what you can do with basic HTML, CSS, and Javascript and it would be interesting to create a few basic animations or toys with it but overall it’s just not competitive with Akihabara or Flash. Akihabara could use more generalized libraries and better documentation but since its libraries are both larger and growing faster than GameQuery’s and it doesn’t face the same technical limitations as GameQuery Akihibara is definitely the better library.
{ 4 comments }
All true, although I’d say that for contemporary products, games, or applications the HTML 5 dependency of Akihabara renders it completely useless. Nobody can afford to cut out 60% of all internet users by not supporting IE. Even looking a couple years down the road, when HTML 5 support will be standard across all modern browsers, many users, especially those who aren’t “techies,” won’t have bothered to make the switch. I think in many cases, older browser support is gonna trump all of Akihabara’s advantages.
Which is unfortunate.
Not for mobile devices, though. Android and Pre let you package an HTML5 “app” as an application.
Similarly, IE9 has Canvas support. I’d wager that in about a year 75% of desktop browsers (by install base) will support canvas.
Turns out I had my IE version numbers mixed up, and was thinking that 8 was still the latest one (and a bit surprised to learn that it didn’t support HTML 5!). I also hadn’t considered the mobile implications.
In short: Touche, on all accounts. I should perhaps spend more time double-checking the key facts of my point before blathering all over your blog.
Well, IE8 is the *current* version. IE9 is available as a preview, though. It should be out pretty soon.
Comments on this entry are closed.