While I've been rather neglectful of this, my little corner of the internet, I have a good excuse....

E and I are re-settled in Chicago-area, have almost unpacked our new home, and all-in-all life is good.

I am enjoying a 1 year appointment as a Research Associate at Northwester University, which is granting me a lot of uninterrupted time to make progress on my dissertation. Things are moving along at an incredible clip... especially considering how slow it was while I was trying to do it part time for the last two years.

I will be posting updates on the software and findings as I have them...

Current tasks:
- prepare a submission for GDC '08
- run stats on my player nav data and write up results
- begin to circulate chapters of the paper to my committee
- begin design and planning for a new wave of subjects in my game player behavior study

I've made a bunch of updates to GameTracker in the last few weeks.

1 - Player Movement Replay -- the little green streak shows the last 100 frames of the player's position and the cone represents the player's field of view for a particular frame.

2 - Time in Cell Histogram -- you can also see a blue-ish chart in the bottom left of this image. This is a new histogram feature that shows the distribution of time spent in a particular cell. This is calculated as part of the grid analysis view, which is something I've been in the process of developing for some time (other shots of that, below).

3 - Performance of the Grid Analysis View -- The basics of this view have remained the same, but I have dramatically boosted performance by cleaning up the code and being slightly more careful about where and when the Qtjambi AbstractItemModel-based objects are initialized. The threading on this piece has also been spruced-up.

In the process of collecting data for my dissertation experiment, I amassed something like 200 sessions of game play, each about 5 minutes in duration. Each log file from these sessions had millisecond sampling of player position, camera pitch and yaw, and the player's health. This gives me millions of samples I can use to analyse my game level in a variety of ways.

However, managing that much data is tricky -- especially when the software development was (is) ongoing and there are inevitably bugs in the system that require re-processing of the raw log data.

In order to ensure data integrity and the ability to sort erroneous and/or invalid session logs from valid ones, I needed a dedicated utility application -- enter LogImporter.

It's not the sexiest piece of software I've ever seen, but it has proven IMMENSELY helpful in verifying my data and trusting that everything that should be in the database has actually reached the database successfully.

In the process of this development, I wrote a general-purpose HistogramWidget (in Java/QtJambi). The widget can take either a query string (e.g. "SELECT rowcount as valueField FROM tableFoo") or an existing TreeMap of data, and then it renders a histogram of the values in that resultset. The dark blue bar represents the bucket containing the mean, the darker purple box represents 1 standard deviation, the lighter blue represents 2 standard deviations, and the red bar indicates the currently selected log file (in the list on the left).

This means that when you select an existing log file, it will show you where that falls in the distribution compared to all the other sessions in the database. This is extremely handy when you're not sure if the session you're looking at is vastly outside the norm compared to its peers. While I am currently only using it to show the rowcount for each log file, new histograms can be added extremely easily (if there's some other thing you'd like to compare across log files).

I've also just completed an update of my MapFlows application, which shows a heatmap-style visualization of where players are over time in the game level. It averages all available samples within a specified "bucket" range, and then generates a color value for each pixel based on its distance from all sampled player positions. It basically treats the known (i.e. sampled) positions of players as forces on the pixel where the magnitude of the vector is inversely proportional to the straightline distance to the point.

The app saves the frame images, stats about the app performance (meaning how long it took to process), and you can also print contact sheets of the frames in order to represent the flow as a static series of images.

I will post little videos of these flow-maps in the next day or so...