How Does It Work?
WebGL is an experimental technology to bring 3D to browsers using OpenGL ES, a cut-down version of OpenGL designed for embedded uses (The iPhone uses OpenGL ES 2.0 for its 3D API for example). Both Firefox and WebKit/Chrome nightlies currently support WebGL, but it may be some time before this technology reaches a release-ready state (the specification is still in flux, a draft was issued in December 2009).
Another interesting HTML5 technology used is WebSockets. This gives the browser the ability to open a two-way TCP connection to a server for a communication channel. This is an improvement over AJAX, which is a synchronous request-response technology that has high latency, and much more robust than ‘Comet’, a hack to make AJAX behave more asynchronously. By using WebSockets, the web browser has the ability to channel data back and forth at high speeds and act more like a native application. In this case, GWTQuake uses WebSockets to provide networking between client and server so that GWTQuake can even be played multi-player! WebSockets, like WebGL are currently only supported on nightly versions of Safari/Chrome and Firefox.
Loading and saving of games in GWTQuake is done using HTML5’s Local Storage, it’s a key:value store for web apps to hold more data than what can be fitted into cookies. Google use this in their Mobile GMail web app for caching and offline access to data. Unlike cookies, the data is not sent to the server on each request and it persists after cookies are cleared. Therefore you don’t have to download or upload files to load and save your games in GWTQuake, you just open the URL and choose load from the menu!
How Can I Play It?
At the moment GWTQuake is only available by downloading and compiling the source code from the GWTQuake Google Code project site. Both the OGG Vorbis tools and Lame are required to convert the Quake2 data into OGG Video and MP3 audio for use in the browser.
There are numerous issues, depending on what platform you are, but I managed to cobble together the following instructions for Mac OS X from comments from others on Google’s instructions.
Install HomeBrew, to get Vorbis and Lame (and Mercurial) easily:
(Credit for these instructions goes to “64.brian”)
sudo chown -R $USER /usr/local curl -Lsf http://github.com/mxcl/homebrew/tarball/master | tar xvz -C/usr/local --strip 1 brew install vorbis-tools brew install lame #if you don’t have Mercurial… brew install pip && pip install mercurial
Checkout the GWTQuake source (requires Mercurial):
hg clone https://quake2-gwt-port.googlecode.com/hg/ quake2-gwt-port
You may need to “cd” into the quake2-gwt-port directory now.
Maven runs out of memory compiling on OS X, fix this by using this command:
(Credit for this instruction goes to “redchris”)
Compile, download the Quake2 demo, and run the server:
./build-dedicated-server ./install-resources cp -r maven-build/server/target/gwtquake/war/gwtquake war ./run-dedicated-server 8080
Play the game by opening http://localhost:8080/GwtQuake.html in your browser!
At this moment, GWTQuake will only work on a nightly version of WebKit or Chromium. Sorry, no Firefox support yet. Apparently it is missing some feature that is required (I know that Firefox supports WebGL, WebSockets and everything required in theory here, so I wouldn’t know precisely why it doesn’t work without debugging it myself).
Google’s browser compatibility page provides download links for WebKit, Chrome, and what command to run to enable WebGL (which is off by default in both browsers).
Additionally, Chrome has to be run without the sandboxing otherwise it is very slow due to time wasted copying the framebuffer between processes.
Another major issue is that on most screens the game appears very dark. This is because the original game did gamma adjustment on the textures as it loaded them and this was not ported as such to GWTQuake for efficiency reasons (see the FAQ page).
For the screenshots I’ve included in this article, I’ve forced my screen’s gamma to be 1.2 so that the screenshots are more visible.
How Does It Play?
Surprisingly well, considering it’s in a web browser! There are a number of bugs. When I loaded the game, there’s just a black screen in Chrome, and the console text overprints itself. Just press enter to bring up the game menu.
One rather cool aspect of the web-ness of the code is that the data loads asynchronously. As you start a game, the textures load into view much like images in a regular web page!
In WebKit, I found that the objects in the game (gun / enemies / other interactive objects) flickered. In Chrome I didn’t get any sound, but the flickering was gone.
In WebKit it was reporting about 7-10 FPS, though to be honest it felt significantly smoother than that (nearer to 20 FPS maybe). In Chrome, I was only seeing 1–2 FPS. Ray Cromwell reports that “On WebKit/Chrome I can get 20-25fps on a MacBook, and on my Mac Pro desktop, I get about 45fps. Joel reports that a Linux notebook gets up to 60fps”.
Aiming can be sent a bit skewiff if your mouse pointer falls out of the browser window, so full screen is a must if you have any intention of playing properly.
Of course it should be understood that this is a) highly experimental, and b) highly-unoptimised. The FAQ page notes that:
What Does This Mean?
It means that you should not assume that the web browser is just a document viewer, nor is it as slow as it used to be, and nor is it as incapable as it used to be.
However, none of the technologies in use here having left draft status. I would put it at around two years before this technology (and games using it) arrive in the hands of the public via mainstream releases of Safari, Chrome and Firefox. But those innovating will be ready to hit the ground running.
What this means for users in the long term is a great simplification and removal of many hurdles for users. This is a 3D game that you can play just by visiting a URL. No installation, nothing to download and install. You “install” the game by bookmarking it. As simple as that. URLs could even be constructed to point to specific rooms in multiplayer sessions, so that you could invite someone into a game in progress just by sending a URL through e-mail, IM or twitter and such!
There’s been a lot of debate about HTML5 vs. Flash, especially with the imminent release of the iPad (which despite complaints from some doesn’t seem to be having a problem getting some major users of Flash to jump ship to HTML5). Whilst HTML5 cannot fully replace Flash yet, the features are coming, and those features will even surpass what Flash can do. Mozilla have demoed WebGL running on a Nokia 900; they decided to disable Flash by default on Firefox Mobile stating “The Adobe Flash plugin used on many sites degraded the performance of the browser to the point where it didn’t meet our standards.”
Adobe have promised that Flash 10.1 will increase performance, but this won’t change the fact that neither the iPhone, nor the iPad include Flash. Once a web developer writes content in a standards based way to work on the iPhone / iPad, why would they choose not to serve the exact same content to desktop users, and redo it all again in Flash?
Quake II in HTML5 does not exist to somehow be a practical example of the technology. It is to inspire developers to push the boundaries of what’s assumed what browsers are capable of. Compelling, graphical games and experiences can be delivered to users with nothing more than a URL, with all the freedoms of distribution the web offers (compared to the App Store for example), across multiple OSes and multiple platforms and processors. It will take many years for the availability of this technology to trickle down to devices everywhere, and many more years for the development tools to become readily available to all levels of skill; but come they will, because the Internet is the new operating system.