I actually finished up v0.2.0 of my
game tracker months ago, but I finally got some free time so I thought I’d write up what I have. I have probably forgotten a lot of the details at this point, but I’ll just soldier on. In this update I finished up adding in aggregation and filtering of play sessions to the display system (and did a little bug fixing).
Filtering
I wanted to be able to filter play sessions into specific time periods. Right now I start a new spreadsheet every year to keep track of the data in a manageable way, and I start a new set of tabs within each spreadsheet to track data for each month. I wanted to be able to replicate this in an ad hoc way, which would allow me to build a more informative and flexible way to look at the data.
 |
| A small view of my tracking spreadsheet. |
Additionally it’s nice to be able to include or exclude games or groups of games from the list. For example, how much time have I spent playing all the games in the Zelda franchise? I have no idea right now but filtering would make that a question I can ask easily.
As such, I added two types of filters for play sessions, one for games and one for dates. The filters work by finding all the play sessions that match and then showing only data from those sessions.
The game filter works by matching the (whole) name of a game. Multiple games can be added to the filter which then allows multiple games. So far, I don’t have any structure like a series or a genre, so I don’t have filters working for that, but that’s something to work on in the future. The filter provides a list of all play sessions that match the set of game names.
 |
| The two basic filters. |
The date filtering works by using date windows. Each window has a beginning and an end date and the filter allows through all play sessions that are between the two ends. If either of the two dates is unset then the filter allows all sessions to the beginning or end of time.
It took a little fiddling to make them work, in particular to make an empty filter allow everything (which is backwards to how the filters are designed, but extremely unintuitive to work with).
Aggregation
In my spreadsheet I keep a log of all games played for the year (including the date, the game name and the amount of time played). Then for each month I break out one pivot table that includes the total amount of time each game has been played for the month and a second table that breaks out the games played for each day so that I can produce the stacked bar-chart of the games. I needed the aggregation system to allow me to basically do that in the stand alone system.
 |
| January's games played chart. (See a better view in my January 2019 post). |
Aggregation was interesting because I wanted to make it as abstract as possible, but still needed to make it concrete enough to work in the command-line interface. I think I may need to take a second swing at it to make it really work smoothly.
The way it’s currently constructed aggregators take a set of play sessions (raw or filtered) and extracts a aggregate, which is a map organized by game name, the type of aggregate and the value (as a double). Aggregates can be merged to put together different stats about a set of play sessions.
 |
| The aggregated games in my test file (mostly from early 2018). |
As I said the system is a little messy and I think having now let some time pass I could do a better build solution.
Project Update
Compared to the first update, I did a better job of using the git workflow and breaking down my work into smaller chunks and updating regularly. This was helpful in the work I needed to do to finish my thesis project. I also tried to start teaching the workflow to my students this semester and I think generally the “do small things well” mantra has done me (and them?) well.
 |
| The current state of the Game Tracker |
It’s also been months and months since I finished the actual main work for this update. I did break some tests which ended up taking me a while to fix. Since then I’ve mostly been working on my PhD so I’ve had to backburner the whole thing.
The two big directions I’d like to take the project in next, are to produce a GUI version using JavaFX and to integrate a Google Doc back end storage. The first step I think is going to be the hook up Google sheets and then go on to the JavaFX front end.
My plan, as it stands, is to finish the next update including the Google Sheets connection (and some various fixes / reorganization) by June 1, 2019.
