Last time, I covered briefly how our playback system works within the game client – strictly speaking this is everything we need, and in the beginning it was everything we used. It did require our testers to take an active part in sending us the playback files though, besides being unreliable it put higher demands on our testers and forced them to tell us directly how much they had played – removing some of the advantage of letting them play on their own terms.
The system now works by sending the playback files directly to our server after every game. We send the files via HTTP and use ordinary POST – requests to transfer them – this allows us to use a normal webserver as a host and makes accessing the files no harder than downloading a webpage. If we were concerned about security we would pick something else, but the playbacks are just streams of input so we do not really care if someone else looks at them.
Most modern languages have classes to handle HTTP requests for you and finding a free library that does what you need should not be too hard, but in our case we only really need to do one thing and failure always means we bail, so we use sockets directly. If you want an introduction to low-level network programming, Beej’s Guide to Network Programming has been around for a while and shows you the basics. For an introduction to the HTTP protocol, James Marshall’s HTTP Made Really Easy is good – the guide contains a link to the HTTP spec but if you are like me and prefer learning from examples, Wireshark can show you the actual HTTP requests sent by your computer.
In addition to the playback file itself, we also send the hostname – sanitized to only include alphanumeric characters and be a maximum of 32 bytes. A server-side script collects the file and categorizes it by this hostname – due to our own backgrounds and the simplicity of the script, we use PHP for this. If the script manages to save the received file under the intended name, it gives a specific HTTP response – only if this response is received is the playback deleted from the playtester’s computer. This is repeated for every file in the playback folder – files that are unsent due to errors or player interruption simply remain and are sent the next time the game is started.
Like when the file is written, a visible warning needs to be presented to the player should the upload fail – in our case, this warning does not prevent the player from playing the game though. The playbacks are still there and can be uploaded the next time the player goes online – or sent manually if there is something wrong with the server.
Finally, connecting to the internet will trigger warnings with some virus protection applications and firewalls, so it is best to make the playtesters aware of this before they start the game. In our experience even a majority of people did not bother reading any instructions that had more than a couple of paragraphs though, so make sure the game itself does not require a lot of explanation.
… And that’s how we do it. We still have some hiccups with the process but when it works it is convenient to be able to send someone a build and have everything work automatically from there.