Exhibiting was great for getting feedback, particularly from some of the intelligent and creative people knocking around at GameCity. Such as Martin Hollis and Karl Hilton; a couple of the creators behind Goldeneye on the N64. Alan Hazelden creator of Sokobond and the upcoming A Good Snowman Is Hard To Build and even the Guardian’s Keith Stuart.

Along with industry professionals there are children of all ages, happy to pick up the controller and give you candid feedback. It was great seeing families helping each other getting through the tougher puzzles. It’s the variation of people at GameCity which makes it such a wonderful place to get real people to playtest your game.

Although my personal favourite part of GameCity 9 wasn’t exhibiting, it was just getting to play games. Such a wonderful variety; Tap Happy Sabotage! a crazy physical multiplayer game, molecular puzzle game Tricone Lab and visual programming game Glitchspace to name a few.

So if you get a chance to exhibit something at GameCity next year, it’s definitely worth polishing up that demo and getting it in front of the public. See you there next year!

Following on from Posting Basic Data I’m going to talk about how I implemented a system to record users inputs, upload them to a webserver and replay them as needed. This was extremely helpful for designing the puzzles for Polyology, recreating bugs and testing fixes.

Determinism

An important base line for creating a consistent replay system a deterministic game engine. So if you do exactly the same thing, you get exactly the same output. Typically the only complication comes when we use random numbers to create interesting particle effects, or spawn objects at changing locations. Fortunately computers aren’t really random at all, and the randomness is typically generated based on the millisecond you called the random function as a seed. You can either record that seed, set it to a fixed number of use an existing library such as David Bau’s Seedrandom.

Now your engine is deterministic just need to record all external inputs so allow you to replay the game. Typically they include

User Input

Frametime

Random Seed

Which is fairly trivial to collect at runtime, bundle up and send to a webserver. However if you game is multi-threaded life is significantly more problematic as the OS can give you threads at different times but there are more extreme virtualization solutions out there.

Wrapping this information in xml, json or whatever you prefer and upload it to a webserver.

Personal I also included other information so allow me to search and sort the data such as

Users score

Current date and time

Length of replay

Replaying the data

Getting the replay to work is fairly simple, just step through the file, doing what you recorded. There are a few gotchas like disable current user input, handling remapping and any state that influences the same (e.g. if the player has the key to unlock that door) but nothing that can’t be overcome quickly and easily.

Proof of the Pudding

This proved an invaluable resource from a design perspective, allowing me to see what users are doing from a distance. So players that don’t give you any feedback when playing your game online still give you a huge amount of valuable data. Allow you to see where 60% of users stop, and what they were doing on that level, or letting you know that after someone emailed you feedback, they continued to play the game for another 2 hours and finish off every bit of content.

From a code side it was also useful, when users reported bugs I just watched the replays until they happened, then I could fix the code and verify it was fixed by running the new code against the replay.

A replay system is a wonderful tool to give you a huge amount of information, and as long as you spend the time and care to mine this information you’ll undoubtedly end up with a better product in the end.

If want to find out how to implement a quick telemetry system, or just want to me nosey about how I used Django to create a telemetry system for Polyology, then this post is for you.

Django

One of the various tag lines is “Django makes it easier to build better Web Apps more quickly and with less code.” which I can’t help but agree with. It does take some time to setup and learn but once you know Django you’ll be able to quickly create and extend your telemetry system. It has solid documentation and a lovely tutorial for getting you started on their website (disclaimer – This article was written using Django 1.4).

Uploading data from the game

Below is a small snippet of javascript code for uploading some bit of information, some thing like a player has loaded a level, restarted or quit your game. It ties in some situational information, the set and level, where the event occurred. Then it’s a fairly trivial matter of sprinkling your code with PostTelemetry calls in suitable places, and you can extend it with new telemetry without changing any web server code.

Django lets you define models, layouts of how information will be defined, this is a quick model for some generic telemetry. In this case it’s just a couple of short reference strings and an integer (and a cheeky increment function for later on).

Django will give you a admin site, setting you add, edit, delete telemetry as well as filtering and sorting.

Conclusion

So that’s it, that’s most of the code for the telemetry, and you can just add new post calls and everything is just handled. Every indie dev out there should have a simple, extensible web framework for telemetry. If you don’t have one, I’d try Django and see what you think.

Finally I’d like to thank Mark Tully for introducing me to Django in the first place.