This tool lets me visualize and clean data from the eyetracker i built for my dissertation. 50,000,000 samples (collected in 50 sessions), with state transition flags synced with time along the x-axis. Green means game has started, red means game has stopped. The scrollbar at the top pages the data for a session so I can easily query/refresh it in chunks (defined by limit). Changing the limit changes the zoom, essentially.

You can toggle lines on/off with the show buttons.

lots of noise in the data due to blinks and/or momentary loss of track -- but this tool lets me quickly isolate the signal through the noise.

Anyway... fun fun...

Another piece of software in development... Shows a texture representing the concentration of saccades (eye movement samples) from my custom-built eyetracker that I use to study player eye movements in a 3D video game (an FPS for this experiment).

Built using QtJambi technology preview 3 (UI) and Java for data analysis. QtJambi is a really great UI tool for Java that is about to be released. I LOVE the fact that between QtJambi and Qt 4.2, I can develop high-quality user interfaces that are cross platform, fast, and still easy to style. I know I sound like an advert, but the Qt tools are really maturing quite nicely, in my opinion.

I also built a weather or heatmap style of visualization of my game levels so I could see how people move through my levels. This shows an aggregated view of all players replayed from the start of their game session forward.

This is just one screenshot, but I actually generate quicktime movies of these flows (which I'll post at a later date).

This helps me track player navigation behavior in a large video game level.

I just added a new widget to my GameTracker app to track the line of motion relative to the field of view. This is basically a calculation of the player's actual line of motion relative to where they were looking (the player-camera's yaw).

The rotation monitor in the upper right shows a diagnostic view on the yaw vs. pitch information about the player-camera.

The lower right-corner shows a caterpillar view on the player's movement through the game level. The big chart area shows the raw data, and the top-left has a list of the available sessions of data (that have already be cleaned/filtered of bad sessions).

Next, I'll be adding a bunch more statistics to the statistics view.... all of which will be output in a format that I can do post-processing in SPSS.

The major purpose of all this gadgetry is to allow me to tune and trust my calculated variables -- which will become critical when I begin to do statistical analysis on the video game player's navigational behavior.

Ongoing work... thought I would post an updated screenshot...

My latest update adds a grid analysis to the player navigation, so you can calculate stats about amount of the game map explored, hot-spots or areas of "camping," etc. It's also a precursor to doing flow analysis -- which looks a lot like a vector field. I'm not the first person to do this sort of analysis, but I have a few ideas up my sleeve for how to extend this approach into uncharted territory (pardon the pun).

Added:

• grid 'time in cell' histogram
• time vs. sample tally metrics on grid
• additional grid-based stats
• ability to export stats to CSV

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...

The MapFlows application I've been developing now has the option to generate quicktime movies of the heatmaps. These maps can either show or hide the background image of the level. For the purpose of analysis, I like to sometimes see the emergent structure of the level from the patterns of movement without having the map always in view. Below is an example of my "catwalk" map (using one of my experimental conditions) with and without the background map.

Without Background Map

With Background Map

One of the applications of this technology is to provide a visual/analog means of assessing level design, with data from real players.

For example, it can bring into high-relief when players are exploring a level in roughly the same manner, or if they appear to be wandering aimlessly. In both of the examples below, there was 1 fixed spawn point and roughly the same number of player-sessions of data. Each frame is 1 second of gameplay and the video plays at 12 frames per second.

Example 1 - Wandering Aimlessly

Example 2 - Highly-Patterned Flow Through the Level