RWA Scale Test Fixed

My thanks to R.C.H. who has pointed-out to me two bugs in my implementation of Bob Altemeyer’s RWA Scale. As always, I find bugs in my code embarrassing, and I’m grateful to R.C.H. for not only finding the bugs, but reporting them. Consequently, the code has now been fixed. So, for those who’ve answered “strongly disagree” (-3) to questions 7 or 8 in the past, if you retake the test, your answers will now be correctly scored. Until now, they’d been accidentally scored as “very strongly disagree” (-4).

Chalk up another victory for open source, and thanks again to R.C.H.

“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.

The RF Scale

I’ve automated another one of the surveys from Bob Altemeyer’s book The Authoritarians. (My first effort, the “RWA Scale” is discussed in a previous entry on this blog.) This time, it's the “RF Scale.” What it’s measuring will be pretty obvious, pretty quickly. Just in case there’s any doubt, I’ve included Altemeyer’s description of the purpose of the survey at the end of the page.

Because this survey works in the same way as the previous one, I’ll quote myself to save time:

Note that your score is computed entirely on your own computer – none of the data is transmitted or recorded anywhere, so nobody will ever see it but you. On the one hand, this seems like a bit of a shortcoming, because it’d be interesting to know how other people score, but, on the other hand, surveys whose participants are self-selecting are meaningless. Add to that the fact that an anonymous Internet survey has no reliable way of excluding trolls, or preventing people from submitting their preferred answers repeatedly to try to shift the results in whatever direction they like, and Internet surveys go past “meaningless” to end-up somewhere around “outright misleading.” So, let’s not even play that damn fool game.

If you’re curious, I score a 12 on this survey.

Once again, it’s food for thought. Happy thinking.

This survey, like the last one I created, is fully standards-compliant and therefore works correctly in modern web browsers like Safari, Firefox and Chrome. It might work with the latest versions of Internet Explorer (if not version 8, then 9), but as to other versions, previous experience says: probably not. The old joke about the phone company applies to Microsoft’s stance on standards compliance: “We don’t care. We don’t have to.” Microsoft’s stance has improved very recently, but having ignored web standards for around ten years, they have a lot of catching-up to do.

The RWA Scale – Investigating “public opinion concerning a variety of social issues”

A friend (thanks D.C.) brought an interesting book to my attention the other day, the cornerstone of which is a survey known as the “RWA Scale” developed by Bob Altemeyer of the University of Manitoba. The survey describes itself as “an investigation of general public opinion concerning a variety of social issues,” and saying anything more would probably be a mistake. Anyway, because the book and survey looked interesting, computing one’s survey score struck me as a bit tedious, and it gave me an opportunity to use Javascript (ugh) in a way that I hadn't used it before, I decided to automate the survey. Some quick googling turned-up one pre-existing online version of the survey, but only available to Facebook users, among whom I am not counted. However, given that the book from which the survey was taken was published in 2006, and the survey was in use for quite some time before then, there must be other online versions (perhaps you've already encountered lots of them), but I wanted to try my hand at automating it, and so I have.

I’d go into more detail about the book and the survey here, but it’s probably best to take the survey knowing as little as possible about it. So, if you’re still curious, take the survey.

Note that your score is computed entirely on your own computer – none of the data is transmitted or recorded anywhere, so nobody will ever see it but you. On the one hand, this seems like a bit of a shortcoming, because it’d be interesting to know how other people score, but, on the other hand, surveys whose participants are self-selecting are meaningless. Add to that the fact that an anonymous Internet survey has no reliable way of excluding trolls, or preventing people from submitting their preferred answers repeatedly to try to shift the results in whatever direction they like, and Internet surveys go past “meaningless” to end-up somewhere around “outright misleading.” So, let’s not even play that damn fool game.

I’ll just tell you that my score ranges from 27 to 33 depending on how I interpret some of the questions, while the author’s introductory psychology students average around 75, and their parents around 90. A 2005 survey of 1,000 Americans reportedly also showed an average score of 90. That’s all discussed after the survey, where you will also find a link to the entire book (available free online) from which the survey and associated text were taken. Admittedly, including that information on the same page as the survey might introduce some bias into the results, but I thought that anyone who’d just gone to the trouble to take the survey deserved some explanation and context.

It’s all just food for thought. Happy thinking.

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.

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.

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.

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.

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.