It's somewhat comical to me, posting anything here since its been nearly three years since my last ... I doubt anyone visits this rusting pile of bytes anymore so I'd expect if you're reading this it's through RSS.

We both think the game is pretty fun - lots of subtle strategy and a difficulty curve that we tweaked over months and months of development. This is also my first really big and complicated Objective-C project and did I ever learn a lot.

Give the game a go, and let me know what you think of it. We're pretty active on our Facebook page with game updates, tips & tricks, screen shots from upcoming releases, etc.

I'll leave you with this EPIC trailer we put together for the game. Enjoy!

As mentioned previously, the talk I gave on HTML5 was captured as what the kids refer to as a "moving picture". Here, I have embedded it in this interweb page so that you might view it at your convenience. I sincerely hope the irony of an HTML5 video being presented via Flash is not lost on you.

And with that, I have now made twice as many posts in 2010 as I did in 2009. That's right ... four. Can you handle this, internet!?

I'm putting together a rather lengthy talk on HTML5 for work (I'll post the slides next week, and with any luck the audio too) and thought some examples might be a nice thing to have on hand, specifically for canvas since I assume that will be a popular topic.

I looked through some of the older stuff on the site (which is pretty much everything now), and decided it'd be cool to do the old mouse patterns experiment in canvas, and fancy it up a bit.

I've spent the past few months working on the SocialThing for Websites client, which you can see in action on AOL's country music blog The Boot. Techcrunch didn't tear it apart, and the comments aren't as rabid as one might expect on an article about an AOL product, so I suppose it came out next-to-all-right.

The client itself was a lot of fun to work on, and there were a lot of interesting technical hurdles that we had to hitch our pants way up and leap over which kept things awfully interesting. More on those later, though.

For now, I wanted to point you towards the backbone of the SocialThing client, aimapi-core.js, now hosted on Google Code. This is a pared down, bare bones, just-what-you-need-and-nothing-else version of the original Web AIM Javascript API that AOL released back in November of 2006.

So, you ask - besides dropping all the UI stuff that you weren't particularly interested in the first release, what's so great about aimapi-core? Well...

Its only 44k (with white space and comments). The original is 80k and does less.

pushFeed - a means of pushing content into a user's buddyfeed/lifestream

reportSpim

and more!

Alternate means of listening for events. The original codebase used long polling via script nodes. Unfortunately this meant rapid polling in Firefox because of a bug in that browser that prevents more than one script from downloading at once. This rapid polling was both memory intensive and had the status bar constantly letting you know that it was "Waiting for 12.345.79.80..." which kinda sucked.

So how was this resolved?

If AIM.params.useSWFListener is true, the API uses swfobject to pull in swfsocket.swf which uses AS3's socket API to listen for host events (IMs, presence updates, etc). Many thanks to my pal Rick Gardner for writing this piece.

If swfsocket fails to initialize, the API falls back to scriptiframe.js, a clever work around that James Burke came up with that uses an iframe to long poll for events.

And if all that fails, it goes back to using dynamic script nodes to listen for host events.

And more! (...that I still need to write documentation for!)

So give it a look, and let me know what you think. Oh, and for those wondering - no, the SocialThing client is not a frame a' la the diggbar. Come on, give me a little credit.

I've been doing some work in AS3 of late and stumbled onto a bit of a gotcha last week that I thought I'd share since it caused me about 15 minutes of frustration.

The gotcha pertains to a significant difference in how Javascript and AS3 handle the match method of the String object when the global flag is passed. Consider the following Javascript snippet:

var r = /[a-z]/gvar s = "abc";var x = s.match(r);

This will return an Array with values "a,b,c" in both Javascript and in its AS3 equivalent.

Now, consider this code, replacing the value of s with something that will not match:

var r = /[a-z]/gvar s = "123";var x = s.match(r);

In Javascript, this will return null, but AS3 will return a zero length Array. Which means that this...

if(s.match(r)) { // do stuff...}

..would always be true in AS3, but false in Javascript. I spent about 10 minutes thinking there was something wrong with my regular expression, and another five thinking there was something wrong with AS3's regexp engine before I realized what was happening.

So who has it right? According to the ECMA 262 spec, AS3 does (see page 101-102). Of course, Mozilla's documentation claims that it will return an Array as well with no mention of null on that page, while Microsoft's JScript documentation admits it will return null if no match is found.