This is an update to my hback memory game. You can always grab the latest version from hback-latest.tar.gz.

Based on feedback (kudos James and Joseph) I’ve refactored a lot of the code and added the following feature requests:

• Left and right arrows toggle the buttons on/off. Joseph’s suggestion worked fine, but on my setup it only highlighted the correct button. This seems a little counterintuitive to me since the API calls it an “activation”; my version looks for key events and automatically toggle the buttons.
• Game has a Pause mode which can be toggled on/off with 'p'
• Added some comments ;-)
• Added a score logger which I think would be cool for eventually analyzing lots of data (eg. pretty graphs of user improvement over time). This can be disabled with turnOffLogging=True in hback.hs, although I don’t see why you would want to: I’m not sending your data over the wire to analyze average IQs of Haskell hackers (yet).

I think the biggest changes are under the hood: I refactored the widgets and state data structures and, as a consequence, a lot of the remaining code. Hopefully the code is a little clearer on what it’s doing and why. Send in all your feedback and ideas! (I do try to get around to implementing them, eventually.)

Per user requests, here are some of the liberties I took with the original paper:

The number of graphics were chosen to be 9 different boxes (this is how I understood the paper’s description). I’ve been considering adding color variations (eg. with two colors, we would have 18 different graphics) – would this be a good idea?

The paper only stated alphabet letters were chosen for the sounds. This is consistent with what I learned about easy memory encodings in my psychology courses in college. ;-) What I am not sure about is the number of different sounds used. I decided to keep the number of unique sounds equal to the number of graphics (just to minimize unnecessary variations).

The pseudorandom generator was originally free-for-all, but I found the chance of a True Negative was unfairly high (especially at higher levels of play). In other words, with increasing levels of difficulty, it was much safer to guess that the stimuli did not repeat. Since the user could easily “win” the game by not doing anything, it clearly went against the primary objective of the game as defined in the paper: to keep the user challenged at all times. After several different iterations of pseudorandom generators, I settled on the current version: there is a 50% chance that the stimuli is in fact the same as n-th previous turn and a 50% chance it is one of the other stimuli (randomly generated with equal probabilities). I feel this most clearly follows in the spirit of the game, which is to ensure that game consistently keeps the user mentally challenged (too easy or too difficult means the user loses concentration and no learning takes place).

With the same primary goal, the next-level choice is decided: with a naive score currently calculated as ((true positive + true negative) / total), the game level difficulty will decrease at 35% or lower, increase at 75% or higher, and otherwise remain the same. These boundaries were arbitrarily chosen by me and I am waiting for feedback to find out if they do in fact deliver a “consistently challenging” environment.