Showing posts with label SVG. Show all posts
Showing posts with label SVG. Show all posts

Wednesday, July 14, 2010

“Rotating Spiral” becomes a Google “Chrome Experiment”

My combination of Javascript and SVG that produces a rotating spiral graphic (“you are getting sleepy... very sleepy”) has been accepted by Google as an official “Chrome Experiment.” You can find the Chrome Experiments main page at http://www.chromeexperiments.com/, and my spiral experiment at http://www.chromeexperiments.com/detail/rotating-spiral/.

I’ve also submitted several other of my Javascript/SVG experiments. I thought the rotating spiral was the weakest of them, so I was surprised, but pleased, when it was accepted. Hopefully, some or all of the others will ultimately be accepted as well. And, for anyone who doesn’t want to wait, you can find all of my experiments on my Automatons page – with one notable exception: my MazeWars SVG game. Unfortunately, it can’t be run as a stand-alone application – it requires someone to setup a game server.

Sunday, January 17, 2010

Maze Wars SVG version 1.0b3 Released

Maze Wars SVG, version 1.0b3, has been released. This version began as a minor revision to eliminate an asymmetry between the rules applied to the bots and to the human players. Specifically, for lack of a check to prevent it, bots were able to move and turn at the same time, which human players could not do. Making the bots separate their move and turn operations seemed like it would be a simple change. Instead, it turned out to be a little snowball that started rolling downhill, getting bigger and bigger, until it wiped-out an entire alpine village.

The essence of the problem was that the bots had to go from simply moving directly to the next location they chose in their traversal of the maze, to deciding on the location to which they wanted to move, determining whether they would have to turn to face in a new direction in order to move to that location, turning (if necessary), then moving to the desired location. So, they went from having to decide merely what they would do next, to having to plan up to two steps in advance (or more steps, if they decided they needed to shoot at someone at any time during that process). That one-to-many change forced a complete rewrite of the bots.

Other changes were also made, like a general clean-up of the game engine, and some of those changes introduced interesting bugs that in some cases took a long time to notice, or to fix, or both. But now it's done. The code's cleaner, the bots play fair, and, basically, you won't notice much difference.

Version 1.0b3 Change History

  • The bots have been completely rewritten, and are now bound by exactly the same limits on motion (and everything else) as the human players.
  • The bots traverse the maze a little more efficiently than before, because they don't waste time traversing dead-end corridors. Instead, they just look down such corridors, shoot at anyone they see there, and move on.
  • A general-purpose bot engine has been created that, hopefully, will make it easy to implement bots employing new strategies in the future.
  • Various minor syntax errors in the Javascript (unterminated statements) have been corrected. The bugs had no operational impact.
  • A workaround for the Firefox bug that prevented each player from having a unique iris color has been implemented (and the bug has been reported to the Firefox developers).
  • Lots of redundant synchronization has been eliminated from the code.
  • Logging levels for many logging statements have been adjusted downward, because the information they provide has declined in importance.
  • Added to the game engine periodic checks for some bugs that were a problem during the development of version 1.0b3 (and just might have been present in earlier betas); those bugs have been corrected, but these checks will ensure that they aren't re-introduced in the future.
  • The order in which the final scores are displayed has been changed. Now, when players' scores (kills) are the same, those who died the least will be ranked above those who died more often. (Previously the relative order of players with the same score was undefined.)
  • Altered the SVG in "client.svg" such that the player marker arrow in the maze map swells to a slightly larger size. (Of course, this only applies to browsers that support SVG animation, which currently only seem to be the WebKit-based browsers, at least in this case.)
  • The "bullet list" is now cleared when a game ends, which should eliminate any possibility of additional points being earned in the moments immediately after a game ends, due to bullets already in-flight striking other players.
  • Players are not placed in the maze until they have actually entered the game; previously they were placed in the maze as soon as they registered their name.
  • Minor improvements have been made to the communications between clients and the server.
  • Various improvements and optimizations have been made to the server.
  • Bullet hit testing is now handled in a manner such that, if a player is struck by bullets from multiple players at the same time, all of those players receive a point.
  • The game engine's code has been cleaned-up and made more object-oriented.

Wednesday, December 23, 2009

Maze Wars SVG version 1.0b2 Released

Maze Wars SVG version 1.0b2 has been released. The closest thing to a functional change is the addition a partial work-around for a Firefox 3.5.x SVG rendering bug that made the eyeball on the game’s first web page render incorrectly. No code changes, other than the deletion of some old, commented-out material. No changes in game play.

Also, the beginnings of a web site for the game can now be found at http://mazewarssvg.sourceforge.net/.

And, last but certainly not least, I’ve had the pleasure of corresponding with Greg Thompson (thanks Bruce), one of the authors of the original Maze War game, and seem to have received his blessing. Nothing said was usable as an endorsement quote (darn it), but the tenor of the correspondence was entirely positive.

Thursday, December 17, 2009

Maze Wars SVG version 1.0b1 Released

Early this morning, Maze Wars SVG version 1.0b1 was released. This retro multi-player first-person shooter had a couple of the inevitable bugs that always seem to be discovered only after a product is announced to the world. But they were exceedingly minor bugs. And they're gone now.

Enjoy.

Wednesday, December 16, 2009

Maze Wars SVG Finally Released

I’ve re-created the classic, multi-player, first-person shooter game “Maze Wars” using modern web technologies (server-side: Java; client-side: XHTML, Javascript, Ajax, and Scalable Vector Graphics). Today, that re-creation has reached beta status, and I believe is ready for general use. It's available on SourceForge, where you can find not only the GPL source, but a pre-built WAR file just waiting to be deployed to your favorite Java web application server. (I’ve only tested it with Tomcat, however.)

Work on this project began sometime around July, 2008, and after going through several periods of dormancy, is finally clean enough and feature complete enough to merit public promotion. It is based on my recollections (and a few graphics files I held onto) of playing a version written for the original Macintosh, sometime around 1987. When the consulting phone wasn’t ringing, it brought productivity to a halt among our office Mac users for several weeks. Legend has it that it had exactly the same effect on a little corporation called Apple Computer.

I’m not talking about the commercial version that eventually appeared (MacroMind “Maze Wars+”). No, this implementation was something else, and earlier. If memory serves, it had the video RAM address of the original 128K Mac hard-coded into it. I remember patching the binary several times in subsequent years to keep it working (video RAM kept moving as Macs gained memory), but eventually Macs changed enough that keeping the game working was beyond mere binary hacking, and the game effectively died. I have no idea who wrote it (let me know if you do), but thanks to whoever was responsible. A lot of people had a lot of fun with it.

(Of course, profound thanks must also go to the creators of the original Maze War game in 1973: Steve Colley, Howard Palmer and Greg Thompson.)

All these years later, I found myself missing the Maze Wars game, and decided that with Scalable Vector Graphics (SVG) resurgent among modern browsers (Safari, Firefox, and now Chrome) I might be able to recreate it for the web. And it looks very much like I’ve succeeded.

You can get some idea of what the original Macintosh game looked like, and how it built its graphics, from the following files (originally in MacPaint format) that were a part of that game.

There were the eyeballs, of course. All the players were represented by eyeballs. As you can see, they were pre-rendered in parts that could be blitted together to form an eyeball at any of the supported sizes (9) and angles (4). If it’s not obvious, the “ball” portion of each eyeball was the same for every view at any given size. It was only the middle portion that changed, which is why there are renderings of the iris and sclera facing head-on, to the left, and to the right, next to each eyeball, and that’s also why the tail, which appears on the eyeballs by default, is carefully drawn such that it stays within that middle portion of the ball – blitting an iris/sclera section onto the eyeball would completely hide the tail. By blitting (or not) a new middle segment onto each ball, any eyeball view could be created very simply. (The four images occupying the right side of the file weren’t visible in the game. They seem to be the doodlings that led the artist to the final renderings on the left side.)

My eyeballs are a bit simpler, omitting the veins in the sclera, for instance, but they’ve gained things the originals didn’t have, like gradient shadings, and individually colored irises. Seen from behind, they retain the pointed tail, because it just wouldn’t have been the same without it, but, because it took me something like three hours to work out the spline curve definitions for drawing the tail, I decided to forgo including any portion of it in the side views.

The game’s screen looked like the top half of this graphic. The first-person maze view was on the left, on the right was the maze map showing the location of yourself and the teleport stations (the circles), and, if memory serves, in the empty space below the first-person maze view was a list of players and, presumably, their scores. The first-person maze view was, like the eyeballs, built by blitting together the pre-rendered elements in the bottom two squares. Wherever a corridor branched-off the one you were looking into, a vertical slice from the right hand square was blitted over the corresponding portion of the left hand square, and—presto!—the uninterrupted walls meeting at a distant vanishing point were now interrupted wherever necessary. No drawing, as such, was required, just a lot of clever blitting together of off-screen bitmaps.

I’ve used a very similar approach in my implementation—not with bitmaps, of course, but with a collection of pre-positioned SVG wall polygons and corridor rectangles which can effortlessly be made visible or invisible by altering their “style.display” properties—because it’s wonderfully simple and effective, and remarkably authentic. It also uncomplicates the implementation in a lot of subtle but important ways, and it even, I realized, creates a rendering bug in one case. I didn’t notice that bug until I’d implemented it myself, but I’m sure it must have been present (though a bit less obvious) in the original version. In practice, I think almost no one will notice it, so I’ll leave it for you to find – or not.

There are, of course, a number of differences between my first-person rendering and the original. For one thing, there’s gradient shading so that everything fades to black by the time it reaches the vanishing point. There’s a hint of color to the floor. Stretches of wall are not featureless; they are interrupted by vertical black lines where corridors would otherwise branch off. (That may enhance the sense of perspective, but I’d’ve preferred not to have those lines. Things just kind of inevitably turned-out that way, and I couldn’t find a good work-around, or an overwhelming reason for being displeased, so the lines remain.) Teleport discs are visible in the first-person view, and they’re a very obvious blue – matched by their representation in the maze map. And, by the way, the sky is black. I’m almost certain that real killer eyeballs only come out at night, so that was a detail that needed fixing.

Other differences: On-screen instructions as you enter the game! A new, random maze for every round of the game. (However, I’ve retained the original 33 X 46 dimensions of the maze. After some experimenting, the original size seemed just right - neither too big, nor too small, for good play.) Problems with clipping long player names due to bugs in the SVG implementations of Safari, Chrome and Firefox. Bonuses for killing campers. And, last (I think), but not least: Bots, so there’ll never be fewer than ten players in the game, even if you can’t get anyone else to play.

The results look something like this, but, being rendered using SVG, they are resolution independent. So, stretch out the game window to fill your screen and everything scales-up immaculately – giant killer eyeballs!

If you’re comfortable deploying Java web applications, and believe in using modern web browsers, give Maze Wars SVG a try, and please have fun.

Tuesday, July 7, 2009

Why Safari Ruins the Text in Some SVG

I recently had the opportunity to write a fun bit of software: an automatic organization chart generator that generates the chart using Scalable Vector Graphics (SVG).

Little did I know that, when I sent an example of the software's output to my boss, declaring it to be working, and rather nicely I thought, what he saw when he viewed it in Safari was a hideous mess – unrecognizably bad compared to how it looked in Safari on both of the Macs I use. For one thing, the text was incredibly ugly. Seemingly bit mapped. For another, the portions of the text that were supposed to be bold were rendered plain (and, again, incredibly ugly). To top it all off, the conformance of the text to the stated metrics was terrible. Had I known that my boss would see something so awful, I wouldn't have sent it.

It took some back and forth, but I finally figured out why the SVG looks so bad on most other people's Macs. It's a setting in the "Appearance" pane of "System Preferences"; the one at the bottom labelled "Turn off text smoothing for font sizes __ and smaller." I believe the default value is 12, though I changed the setting so long ago, I don't remember for sure. In any case, being a big believer in anti-aliased type, I always set that value to the smallest one possible, which is currently 4. In my org. charts, I was using a font size of 8 pixels. While I'm not sure how we're mapping pixels to points these days, the key was that the font size in the SVG fell beneath the system's "Turn off text smoothing" threshold. So, "unsmoothed" text was drawn, and, judging by how badly it scaled and how ghastly it looked, I think it actually reverted to a bit map.

Interestingly, Firefox ignores that setting and uses "smooth" fonts anyway. Also, Firefox, at least as of version 3.0.11 and Safari 4.0.1, draws the text much nicer (for lack of a more specific term) than Safari – even after you get Safari using "smooth" fonts. Usually I find that Safari's SVG support is better than Firefox's, but not in this case. Well done, Firefox developers.

An example organization chart is included below. It describes the structure of the U.T. Austin Computation Center in February, 1988.

A lot has changed since then. One change is that U.T. Austin no longer has a Computation Center, and is rapidly running out of people who remember when it did have one, which is a shame. Also, only a handful of the people in that chart still work for the University at all.

Sunday, September 21, 2008

Moon Illumination, A Perpetual Table

A perpetually current lunar illumination table, that always shows the lunar illuminations for the current month. All illuminations represent the state of the moon at local midnight, which is why the illumination images span day boundaries.

If you do not see a lunar illumination table here, your browser probably does not support the Scalable Vector Graphics (SVG) standard. Using the Safari or Firefox browser will solve that problem.