Pithyless is not dead

I've been on haitus from this website for a long time. I'm not dead and I'll try to keep a more consistent update in the near future.

Reviving hback

I received an email from a user recently (thanks Rob!) who was accidentally using an old, buggy version of hback. hback-0.0.3 is the newest release, but I never mentioned it on the website. In the future, I may still mention hback on the blog, but you're always guaranteed to be able to find the most recent versions on Hackage. The newest release of hback can always be found on Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hback If you prefer to keep up-to-date with changes, checkout the repo instead: darcs get --partial http://code.haskell.org/hback/ The darcs repo is most likely to see bug-fixes and updates (I'm far less likely to make an official release, unless there are significant changes).

hback 0.0.3

For release 0.0.3 there are three major changes (from the end-user's viewpoint):

1. Game now tries to accurately duplicate the protocol described in the original PNAS paper. If there are any deviations, please do let me know.
2. The game should now correctly build with all dependencies and correctly locate all data at runtime that was copied during installation. If there are any issues with this, it's a bug - please do report it.
3. The graphics are now rendered as SVG (which means the cairo lib installed on the system will need to support SVG).

hback future

The project lost most of it's traction last year and I have not touched it much after that. Nevertheless, the main task that would be nice to fix eventually is to add SDL support (or similar) to remove the mplayer dependency and then to make the hback code cross-portable. If anyone feels up to the challenge, I am open to patches (small or large) and will gladly help in any way I can. Additionally, if there are no contributors, but I do see that there are people out there still using this (via email, comments, ...), I may very likely be motivated to resurrect this project. Thanks to everyone who showed an interest in the program; and I especially am grateful for the psychology and gameplay aspects that were discussed in previous comment threads. (If you just stumbled across this page, do look back at previous posts tagged 'hback' - the discussion in the comment threads are worth a reading.)

Thanks to the generous folks at community.haskell.org, hback now has a public darcs repo! The hback googlecode page has been updated to reflect this. Google's SVN is no longer officially supported, so do update your sources. Checkout the source: darcs get --partial http://code.haskell.org/hback/ In other news, I'm still swamped with school work, but will be back to working on hback by the end of next week. Stay tuned! Also, if you haven't recently checked the comments from the original post, you really ought to! The readers have raised some questions and made quite a few good arguments about protocols and limitations of dual n-back tests.

It's a bit unofficial for now, but since people keep asking, I've started an hback project on google-code: http://code.google.com/p/hback/ The source checkout includes the latest development version of the game. Eventually, I would like to host a public darcs repo for the project, but for now this will have to do. If you are currently using or considering playing with hback, I highly recommend you checkout the latest trunk. It's a much-improved version over 0.0.2 since it duplicates the protocol as described in the paper. If you spot any deviations, please do let me know. As soon as the most important tickets are fixed, this will be the basis for the much-revised 0.0.3 version. Additionally, I would like to explore building a win32 executable based on this trunk. Do check out the code and post any tickets or comments! Better to fix them now than after the release :)

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.

hback-0.0.tar.gz Update: Released hback-0.0.2 Download Latest: hback-latest.tar.gz

Based on a recent research paper that claims fluid intelligence could be improved by training working memory, I wrote up a dual n-back test memory game in Haskell and gtk2hs. This is an alpha release: all comments are most welcome.

Gameplay

The n-back memory game tests whether the player can remember if the nth previous turn matches the current one. The dual n-back test will measure how well the player can remember both visual and graphic stimuli simultaneously.

Given a difficulty level n, the player is expected to remember on each turn whether the nth previous sound or graphic (or both) matches the current one, and toggle the appropriate button(s). The graphic flashes for 500ms and the player has another 2.5 seconds to answer.

The training game consists of b block iterations, where each block will present (20+n) visual and audio stimuli. After each iteration, the difficulty of the n-back test may increase or decrease, depending on the performance of the player: the goal is to constantly keep the player at peak concentration.

Installation

Download hback-latest.tar.gz

 % tar -xzf hback-0.0.tar.gz
 % cd hback-0.0

Game can be played without system-wide installation:

 % make trial
 % ./hback

If you like what you see, feel free to install it:

 % make build
 % make install    # you may need root privileges for this
 % rehash
 % hback

hback takes two optional arguments:

 % ./hback b n
     - b determines the number of block iterations (eg. try 20 for an effective daily workout)
     - n determines the initial level (defaults to 1)

Errata

• Playing sounds currently through mplayer. If mplayer is not installed or you prefer a different player (all the sound files are .wav), currently the user needs to edit hback.hs (function playSound :: Audio -> IO ()) and recompile. This will be fixed as soon as I think of a good cross-platform solution; any suggestions?