Jt/data capture client

[jnterry]

This is a fairly basic version of data capturing - client just writes some stats to a csv each time a key is pressed.

I'm not convinced this will be enough data to replay a game after it has happened, since we cant guarentee network latencies are the same, so intents may arrive at the server at different times causing different results and hence the game state of the replay to slowly diverge from that of the original play session.

Regardless, this data should allow us to answer questions like:

• What percentage of key presses were on beat?
• How many beats were missed?
• How many beats did the user try to move twice?
• etc

I think it would be useful to correlate the collected data with the user survey response, then we can plot reported game satisfaction against how well the player stayed on beat. @Codrin-Popa (I think you made the form) Any way we can add a file upload to the google docs form to upload the output csv? Alternativey the csv files are labelled with the datetime that the client was started, so could just add a box for us to fill in with that - but we'd need to get the children to only fill in their boxes and then us add the extra data.

Also, would it be useful to have slightly different windows within which the user can press the button (eg, 80ms, 100ms, 120ms, 140ms or something) then correlate stats from these data files like how well the player stayed on beat with those window sizes. Additionally we could correlate the subjective "how fun is this game" rating with the window size. If so we would need to add that to the google form as well.

[jnterry]

If we want to do the data correlation suggested in the PR description (which I think would look very good for the report) we need a concrete way of associating data files with players. If we run the game on the same user account the directory is going to get very cluttered with the csv's and it will be hard to tell whats going on.

Any ideas?

[AnthonyWharton]

Not sure if we'll have enough test data from the data to test that many different configurations of delta window size with the people and get any sort of meaningful data. I say we pick a shorter and longer delta and just call it there.

As for correlating it, I propose we somehow attach a timestamp to the file name or something to that effect, and then we can just work it out later based on which slot time vs which results. I think knowing averages for each slot as opposed to each individual player should suffice.