SGV Artillery Game: Proof of Concept

Issue 173, for the week of 7/2/2006.

Toast Note: What with the site redesign (now complete), three concurrent jobs, and a bad summer cold, the Space Toast Page has been a bit neglected lately. Still, I have a treat for you this week. Thanks for waiting.

(If the above opens as plain text, save it to the desktop and drag the file onto your browser.)

This is a proof of concept for a tile-based artillery game using Scalable Vector Graphics (SVG) and JavaScript. SVG was meant to be an open, plugin-free alternative to Flash, but it was a relative failure. To date, only FireFox and Opera 9 fully support the SVG specifications, with Safari’s support still incomplete, and no native support in Internet Explorer. Adobe has released an SVG viewer plugin for most web browsers, but Adobe’s implementation is not fully compatible with standard SVG. Still, the Safari development team is making fast progress, and Google is reported to be working on a translator for Internet Explorer, so SVG may yet see a true dawn.

To date, the game has only been tested in FireFox 1.5 for Mac and Safari 2.0.4. It is buggy, but runs in FireFox. Safari will draw the initial game state, but does not loop.

The game runs at a resolution of 700×500 pixels. In a window smaller than that, FireFox creates scrollbars, which trap the arrow keys. I don’t know a way around this yet. It should be possible to make the game scale up or down to the size of the window automatically, as SVG is resolution-independent, but that may require redoing the artwork and JavaScript to use percentage measurements, rather than pixel measurements.

The game artwork was created in Inkscape, an open-source project which is making great strides toward creating an alternative to Adobe Illustrator. As of version 0.44, Inkscape is not suitable for directly editing graphics in an interactive SVG file. It has a tendency both to mangle JavaScript and to revert custom group names to generic ones. Additionally, Inkscape’s method of saving object attributes like color and stroke width is to bundle them into one long style element (i.e. style="fill:#574736;fill-opacity:1stroke-width:0;stroke-opacity:1") rather than splitting them into individual elements, which are easier to access with JavaScript. The Inkscape team’s progress remains impressive.

My biggest concern is speed. The game currently maintains its frame rate by idling for 10 milliseconds between loops, although I think I’ve come up with a better way to do it — please refer to the JavaScript’s comments. Although I doubt that FireFox’s SVG drawing routines are tuned for game speeds, my biggest worry is the speed of JavaScript execution. Some parts of the script store game data in JavaScript variables, others assign it to the game’s SVG objects — as whim desired, really. The latter seems to be considered more “correct,” in terms of modern programmers’ fetish for object-based programming, but I’m all but convinced it’s terminally slower than the former. Accessing elements (manipulating the DOM) is also an absolute pain in the ass in JavaScript. For both reasons, I suggest doing it as little as possible.

As near as I can tell, this is the most advanced SVG game anyone has written to date — which is sad, but telling. Owing to uneven support, sluggish speed and lack of an integrated development environment, I can’t see SVG supplanting Flash any time soon. Still, SVG is not without potential. Enjoy the game.

Further Reading:

With some previous JavaScript experience, it took me about a week of spare time to get this far. The following sources and examples were invaluable.

Leave a Reply

Your email address will not be published.