In the real world, where a human plays against a human, “cheating” is relatively easy. A player can gain an advantage by subtly delaying their release just long enough to read their opponent’s body language and choose a winning gesture. For sake of argument, let’s ignore this and assume the players play fairly, where each is completely unaware of their opponent’s move.

In this case, optimal play between two players making truly random gestures ends in a tie (on average). The only way to repeatedly win is to somehow predict your opponent’s gesture, which is impossible if your opponent is truly random. Only if your opponent has a bias can statistics be used to potentially model and predict their gesture.

To demonstrate this, I implemented three simple prediction routines.

To play a round against each routine, just click a link representing the gesture you’d like to make. The routine will then calculate its own gesture (not looking at your current choice of course), and then display the result.

1. Conditional-0
All the opponent’s past gestures are counted, and these counts are used as weights when pseudo-randomly selecting a gesture. For example, if you’ve picked rock once, paper four times, and scissors five times, then there will be a 10% chance that the routine will choose paper, 40% for scissors, and 50% for rock.

2. Conditional-1
This method tracks the last two gestures made by the opponent, and counts the number of each transition. These counts are again used to weight the random selection of a gesture. This allows it to see simple sequential patterns where an opponent’s next gesture is dependent on their last gesture.

3. Conditional-2
Similar to the previous method, this one tracks a combination of the opponent’s last gesture, and its own next-to-last gesture. This allows it to see simple dependence between the opponent’s gesture and its own.

It’s a strange game in that the player with the most entropy wins in the long run. To see the code click here.

So the general pattern is:

from django.db import IntegrityError
import models
try:
    myNewRecord = models.MyTable(data=blah)
    myNewRecord.save()
except IntegrityError:
    pass

myOtherRecord = models.MyOtherTable(data=blah)
myOtherRecord.save() # Throws an error if an IntegrityError was previously thrown.

I’d been previously using MySQL, but after switching to PostgreSQL I started getting a strange error when I tried to do any model access after an IntegrityError had been thrown, even though this access was outside the try/except:

“ProgrammingError: current transaction is aborted, commands ignored until end of transaction block”

What I eventually discovered, with a little help, is that Django’s PostgreSQL wrapper has some unusual transaction handling, so that if an error occurs then the entire connection must be closed to actually close the transaction.

The simple fix was to add connection.close() to the my except clause:

from django.db import IntegrityError, connection
import models
try:
    myNewRecord = models.MyTable(data=blah)
    myNewRecord.save()
except IntegrityError:
    connection.close() # Required to clear PostgreSQL's failed transaction.

myOtherRecord = models.MyOtherTable(data=blah)
myOtherRecord.save() # Now works correctly.

The primary attraction for script’s like Steffen’s lies mostly in IE’s perceived lack of functionally. Most other browsers, like Firefox and Safari, natively support rounded elements with a simple CSS declaration. IE, perpetually behind the curve, effectively had no easy way to accomplish rounded corners until a rounding method was discovered that makes use of Microsoft’s own VML implementation. Drew Miller then went on to create a simple wrapper that let’s you easily apply the effect across multiple browsers. Why Microsoft’s own rounded howto still recommends using tables and GIF images is anyone’s guess.

For the drop shadow, I made use of Larry Stevens’ excellent jQuery plugin. It accomplishes the effect in basically the same manner as Steffen’s script, but does so in a convenient jQuery interface.

And finally, a demo.

The first step in developing any Flash game is coming up with an entertaining idea. Since this is my first game, I wanted the idea to be simple enough to quickly implement, but I still wanted it to be complex enough to be interesting. Tower Defense is a great example of a popular game that’s relatively simple to implement, but also has enough complexity to be fun.

I’m a fan of real time strategy games that shun micro-management and busy work. Granted, this isn’t always an easy task. If you remove too much work from the user through automation, they become bored. And if you require them to handle every minor detail, they become overwhelmed. The under-appreciated Globulation is an obscure but innovative approach to this problem. Most RTS games require the user to manually create, direct, and assign every sprite for some arbitrary task. Globulation instead automates most of these functions and lets the user focus on the big picture, like where your armies should be directed and what percentage of your resources should be devoted to various tasks. For example, if you wanted to attack your opponent, instead of selecting a group of soldiers, a target, and clicking “attack!”, you’d create an attack point near your target and give it a weight proportional to how many soldiers you want to invest. That proportion of your soldiers will then automatically start attacking. That is, if they’re not overworked, hungry, or suicidal. I made the novice mistake of directing all my soldiers to do too many things at once. Imagine my surprise when more than a few wandered out to the dessert to die. There’s a great managerial lesson in there somewhere.

These two games outline my main inspirations. I decided to make something slightly more complex than Tower Defense, but significantly simpler than Globulation. Both have autonomous critters as a common theme. In Tower Defense, this autonomy is limited to simply firing when the enemy is near, but gets much more complex with Globulation.

So here’s the basic idea. In my game, there are 5 types of critters that the user can buy and use to fight the opponent. Each critter has different strengths and weaknesses. Like Tower Defense, most critter types attack by firing projectiles. However, unlike Tower Defense, the critters can all move and pursue their own simple objectives independently of the user.

The user decides where to place critters on the screen, and can tell critters to gravitate towards a particular spot, but otherwise each critter acts completely on it’s own. They attack when an enemy’s detected. They retreat when injured. They wander around when bored. Killing enemy critters earn you money, which you can use to buy more critters. I purposefully kept the critter design very abstract, partially for aesthetics and also to speed up rendering time.

The five critter types are:

• Dragoon
  • Pros: Strong long-range attack.
  • Cons: Slow speed and weak shields.
• Mine-Layer
  • Pros: Creates a wide field of powerful mines. Strong shields.
  • Cons: Cannot directly attack.
• Puppet-Master
  • Pros: Can control an enemy critter from long range
    (except Wraith and other Puppet-Masters).
  • Cons: Cannot directly attack.
• Soldier
  • Pros: Strong weapons and shields. Decent speed. Good at close range attacks.
  • Cons: Prey to long range attacks.
• Wraith
  • Pros: Invisible when not attacking.
  • Cons: Weak shields.

It’s still rough around the edges. I’m still tweaking the game play and working on an in-game guided-walkthrough to lower the learning curve, but most of the features are there.

I used the AS3 port of Box2D for the physics simulation and PureMVC as the application framework.

Please feel free to try it out the Beta.

I recently found myself writing a custom Javascript API to integrate a Flash widget written by an external vendor. I was making the API object oriented, so it could be instantiated and controlled simply like:

var myWidget = new FlashWidget()
myWidget.doStuff()

Things were going well, until I realized I had overlooked a minor detail in the Flash widget. For several actions, the widget accepts functions names, which it will later evaluate and call when the actions complete. The detail I missed was that it only accepts function names visible in the global scope. Since all my methods are bound to myWidget, and not the global scope, the Flash widget won’t be able to directly call anything in my nice API. I had hoped it would be smart enough to accept a qualified name, like “myWidget.doStuffCallback”, and resolve it correctly but no such luck.

I Need Closure

Fortunately, I’m well acquainted with the concept of Javascript closures, so the solution turned out to be a few extra lines of code to expose my callbacks in a way that the Flash widget would accept. Essentially, I needed to create an anonymous function which would call the given method, remaining bound to the myWidget scope, and include any additional arguments the widget might pass over.

Some Javascript frameworks, like the well-known Prototype framework, have various helper functions to accomplish something like this, but they usually boil down to this simple bit of code:

function methodClosure(obj, funcName){
    return function(){
        return obj[funcName].apply(obj, arguments)
    }
}

With this, I can easily expose my callbacks simply like:

doStuffCallback = methodClosure(myWidget, 'onDoStuff')

I had an idea to make a personalized news feed reader. Basically, I’d register a bunch of feeds with the application, and rate a few stories as either “good” or “bad”. The application would then use my ratings and the article text to generate a statistical model, apply that model to future articles, and only recommend those it predicted I would rate as “good”. It sounded like a plausible idea. I decided to start a pet project.

I soon learned that this idea wasn’t original, and in fact had been attempted by quite a few companies. The first to seriously implement this idea was Findory, later followed by Thoof, Tiinker, Persai, and probably others I’m not aware of. As of this writing, only Persai is still in business. Apparently, personalized news feeds aren’t terribly profitable. Why they’re not a commercial hit is a whole article in itself, so I won’t go into it now. However, before I admitted to myself that this project was doomed to failure, I decided to implement a few components to get a better feel for how the system would work. This is a review of a few interesting things I learned along the way.

The Problem

Obviously, the first step to any would-be social news indexing service is to download the target webpages and extract their article text. After you read a lot of non-standard HTML, you start developing a bit of respect for web browser developers who have to make sense of this mess. Most webpages have a pretty low signal-to-noise ratio. There are banners, navigation links, side-bars, headers, footers, meta tags, related-story clips, unrelated story clips, and a lot of other junk we don’t care about. So how do we take this mess and extract not just the text, but the main article text? It’s pretty easy to look for all the <div> or <p> tags in an HTML document and extract their contents, but we’ll get a lot of this junk we don’t want.

Cleaning Up the Mess

In an ideal world, all webpages would be XML documents that could be easily validated and parsed. In the real world they’re a mess, but they’re close enough to XML where we can potentially clean them up and parse away. With the help of the excellent tool Tidy, this turns out to be surprisingly easy. With Tidy, I can take the ugliest webpage and turn it into something I can easily feed into an XML parser, which can then extract the document’s text, ignoring all the HTML markup, Javascript, and other useless information.

Enter the DOM

So now we have a clean document that we’ve fed to an XML parser to build a DOM and extracted all nodes that contain text. How do we distinguish the text used in the navigation bar/side-bar/footer from the main article text? It turns out we can make an assumption in 99% of the cases we’re interested in. This assumption is that the largest “clump” of text is usually the main article. What I mean by “clump” are nodes of text that are grouped together based on their relative position in the DOM.

For example, suppose we have a document whose body is something like:

<body>
    <div>
        <ul>
            <li><a href="/home">Home</a></li>
            <li><a href="/politics">Politics</a></li>
            <li><a href="/health">Health</a></li>
            <li><a href="/travel">Travel</a></li>
            <li><a href="/about">About</a></li>
        </ul>
    <div>
    <div>
        <div>
            <p><b>MIAMI, Florida (CNN) </b> -- Hurricane Ike weakened slightly...
            <p>Ike hit Turks and Caicos Islands Sunday morning, leaving a trail of...
            <p>"It pretty much looks like an episode of 'The Twilight Zone,' " said...
            <p>Aftwood estimates at least 90 percent of homes he saw on the island were...
            <p>The possibility of similar devastation prompted state and local officials...
            <p > "Let's hope it's all a false alarm," Louisiana Gov. Bobby Jindal said...
        </div>
        <div>
            <p>Some side-story that we don't really care about.</p>
            <p>Another paragraph for this story.</p>
        </div>
        <div>
            <p>Yet another semi-related side-story that we still don't care about.</p>
            <p>Another paragraph for this story.</p>
            <p>Another paragraph for this story.</p>
            <p>Yet another paragraph for this story.</p>
        </div>
    </div>
    <div>© 2008 Cable News Network.<div>
</body>

Clearly, we don’t care about the navigation link text, or the two side-stories. Let’s break it down based on DOM location. We have six <p> tags in the first <div> tag of the second <div> tag of the body. We’ll represent this location as a list of indexes, like (2,1,*). If we group all the text nodes in this fashion, and track how much text each group contains, we get a table like:

location = characters
(1,1,1,1) = 4
(1,1,2,1) = 8
(1,1,3,1) = 6
(1,1,4,1) = 6
(1,1,5,1) = 5
(2,1,*) = 500
(2,2,*) = 100
(2,3,*) = 250
(3) = 26

Using this, we can safetly assume either the main article text is located at position (2,1,*), or the document has more ads/spam/comments/side-stories/etc than actual content. Once we know where the main text is located, we strip it out and move on.

Conclusion

This method proved to be a fairly simple and robust way to extract text from webpages. The main exception I found were news aggregators like Digg/Reddit/Slashdot, where the text blurb may be overshadowed by hundreds of user comments.

I implemented a simple Django web app with a Javascript widget frontend to demo this method. Try it out for yourself by pasting a URL below.