Framlag mitt til keppninar Þú átt orðið var tölvuleikurinn Orðavinda. Hann byggir á þekktri hugmynd og reyndar langri sögu orðaleikja. Það kom mér skemmtilega á óvart að leikurinn hreppti fyrstu verðlaun í keppninni og að því er virðist af viðbrögðunum hefur mér tekist að stöðva skrifstofuvinnu á Íslandi.

Leikurinn er búinn til í HTML og JavaScript en notar Flash til þess að spila hljóð fyrir þá sem hafa það. Þeim sem eru forvitnir um innviðina er bent á heimili leiksins á GitHub en leikurinn er útgefinn sem frjáls hugbúnaður undir skilmálum GPL hugbúnaðarleyfisins.

I have no idea why you would want to use it, but because I have this selector extension and nowhere to put it, here it is:

jQuery.expr[':'].target = function ( a, h ) {
  return (a.id && (h = document.location.hash) && h === '#' + a.id)
};

Updated 6. aug. 2009: Optimized by @maranomynet

So I found my old Sokoban game. Originally a Windows application, I though it could be fun to try to remake it in JavaScript. So that’s what I did.

I wrote the bulk of it in about an evening, and spent a few more evenings applying spit and polish until I was satisfied that it worked the way I wanted. The whole thing is about 300 lines of mostly uncommented code running on top of jQuery — well, actually as a jQuery plugin.

The interresting bits

There are a few characteristics that make this implementation interesting. The first is that the game uses progressive enhancement methodology. The script runs through marked items on the webpage and makes valid Sokoban levels playable. If you don’t have JavaScript you can still read the level codes, which are normally written in a standard like this:

####
# .#
#  ###
#*@  #
#  $ #
#  ###
####

The @ is the worker, # are walls, . are docks, $ are boxes, and so on…

The symbols are image-replaced with CSS when the level is live, but the whole thing works without CSS. You can disable the styles if you desire to play the levels in pure ASCII.

This also means that the game is printable. At any moment in gameplay you can grab a hardcopy of your status and frame it. I am hard pressed to think of other printable games. Copying the level onto the clipboard also works just as it would any other text. Not really useful features for a game, but interesting side-effects nonetheless.

Because parsing all the levels immediately as the game loads up — especially on level collections that have very many levels — is quite labour intensive, I am applying a recent jQuery plugin of mine, .processEach(), to prevent the browser from locking up. In short, it works like .each() but yields the process every iteration to allow the browser some time to do other things. It’s perhaps a subject of another entry.

Have fun

Have fun with the game and the source (which are released under the GPL v3). I suspect that it might one day be exactly what a Sokoban level blog is looking for, but for now it mostly remains a curiosity rather than a spectacular reproduction of the game,

You would expect javascript code to execute when you apply it to an attribute:

someNode.onclick = "alert('foo');";

And you expect this to work because this is exactly what you do in your HTML. And in some browsers it does. Some browsers.

I don’t know another way to say it, maybe there is someone who can fix my terminology but here’s the thing: Element attributes are different from node members.

I remember all to well the grief this caused me when I started working with DOMnodes in Javascript. Sooner or later, you will run into these inconsistencies. The browsers also try their best at blurring the difference between attributes and members. Which is helpful when you know how it works.

Consider this CSS:

input[type="text"][value=""] { background: teal; }

It colors an empty input field. But why doesn’t the field update when you type text in the box? theInput.value gives you whatever you typed in there.

This is because .value is a node member that contains what is displayed in the box, while the actual attribute contents are exposed on .defaultValue, which incidentally is what [value] is examining (and what is copied to .value should the inputs form be reset).

With onclick, the node has a .onclick member that is a reference to a function (or null). When the HTML is parsed into a DOM tree, any code in onclick attributes is turned into an anonymous function and a reference to it is placed on the onclick member of the node.

So why does the following code fail in MSIE?

someNode.onclick = "alert('foo');";

Because MSIE doesn’t evaluate the string as it is placed on the member. The onclick becomes a reference to a string and if the event occurs MSIE will complain because effectively we’ve just tried to do this:

"alert('foo');"();

Does this make any more sense, or did things suddenly get more complicated?

Given a cell in a HTML table, what is it’s column index?

This seems like it’s simple. You just count the cells preceding it. Fine. Works for 99% of cases. But what if the table looks like this?:

Suddenly things are very complicated again. The last row really only contains two cells and the browser reports cell indexes 0 and 1 on those, respectively. Not the 3 and 4 I was hoping for.

My first thought was simply adding up the number of cells preceding this one which had a greater row index + row span than the row index of my subject cell. This doesn’t work because of cells like #4 & #13.

Eventually I simply ended up with a brute force method that does the job. But is unfortunately neither fast nor elegant. But then, what code of mine is?

It’s presented here in case anyone else needs to solve the same annoying problem. Or if anyone can suggest a nicer (or preferably a faster) method of doing this.

View demo and code.