Those of you who have read our FAQ (or who are adept enough to monitor outgoing network traffic) may have noticed that Frogatto “phones home”; it sends data back to our servers. Unfortunately, a lot of people have unwarranted suspicion about this sort of thing, which is really a shame because benevolent usage of this is really a irreplaceable aid to game design.
What we’re doing (thus far), is we’re tracking the movement of players throughout the game; every time you play frogatto, it records where you move, and sends a record of this back to us.
Why do this, you ask? Why would this matter to us? Well, one of the biggest pitfalls in game design is, as a creator, making bad assumptions about what players can or can’t figure out – that, or forgetting that you know something (since you wrote the game, after all) that you forgot to tell the players, but which is crucial to solve some puzzle. At worst, you can sometimes make things that are supposed to be possible, downright impossible – or you overlook some game-breaking glitch simply because you never tried something a certain way. These can easily make the game impossible to finish, which is something we want to avoid at all cost.
We could try testing this with a few friends in real-life; we have, but it’s nowhere remotely near a representative sample size. Thankfully, we’re in the internet era, and we have a better option. This is a good thing, because we especially need something that takes the least amount of labor on our part, because we’re a tiny, independent crew, and we not a real company that would have a department full of employees dedicated to this. We’re not a AAA studio that can have QA folks watch players test the game from behind a one-way mirror. When we have problems like this, the guys who would otherwise be creating new stuff for the game have to take time away from doing that to fix them.
Technical Info:
When you are finished playing Frogatto, the game tries to send a small plain text file to our servers. This file is then appended to it’s match on the server, and we end up with a very long list of all the data. There are four types of data; where you moved to, where you loaded the level, where you died, and where you quit the game.
None of it is personally identifiable – have a look for yourself. Especially since we’re open-source, there are no privacy concerns, because you can see our actual code, and we can’t hide anything.
However, there are valid reasons to not want to send back the data, foremost among them being a metered internet connection. If you want to, you can run the game with –no-send-stats to stop sending us data. (eg, “frogatto.exe –no-send-stats” on Windows.)
History:
So, we’ve actually had this stat-tracking stuff in the game since a very early version (probably our alpha versions; I remember fixing a couple of broken/overly difficult jumps on the now-nonexistant “stonepipe flats” level, based on this data). The problem we had was that we were collecting the data just fine, but we really didn’t have a good way to visualize it. The editor was able to display it with a line corresponding to each player, but it was very hard to read when too many lines were in one place, and after we released the 1.0 version of the game, the amount of data we were getting was so big that any sort of realtime display brought the editor’s display routine to it’s knees. For a while, we actually disabled the feature, which was really a shame.
Fortunately, DDR just came through with a brand-new python script that renders this data as an image. This sort of image is called a “heat map”; it overlays all of the different paths that players have taken on top of each other; each of the single ones is very faint, but they make the drawing darker and darker where they overlap. The end result is a single picture where the darker something is, the more often the players have been there. (The reason these are called heat maps is that a common color scheme, not seen here, is to have the untouched areas in colder “blue->green” colors, and the heavily-touched areas in warm (yellow->red) tones.)
Running DDR’s script on the level “bug mining” gives the following picture:
This is useful in itself, but it’s really useful if you combine it with a tiny picture of the level (which we’ve added a feature to export), because that allows us to immediately see what parts of the actual level this corresponds to – especially, to see if there are places in the level players are supposed to be able to reach, but can’t – or vice versa. For a simple example, here’s what it looks like combined with a screenshot of the tutorial level “grassy path”:
This is a great example of the data this tool gives, because when I designed this level, I had actually set it up so that the ant nest near the end was inaccessible to the player. Changes in jump physics later made this area accessible, and looking at this picture makes it very clear that a lot of people are jumping up there (in this particular case, we decided this wasn’t really a problem per se, so we haven’t fixed it, but in many cases, this would be very helpful to know).
Comments are closed, due to abuse.
