mm’s workrate as expressed by svn revision number…

so, while waiting for dave to iron out a couple of final localisation issues on our TGS (tokyo game show) build, I decided to geek out. I wrote a small C program (I don’t know perl! sorry) that scans through our svn database (directly using the filesystem, ahem) and generates a graph (using gnuplot, yay!) of LittleBigPlanet’s revision number over time. For the non-codey types, that’s basically – every time somebody on the team, artist, designer or coder, works on our game, they beaver away on their computer until they’re happy to unleash their changes on the rest of the team. then they ‘commit’ a new ‘revision’. We’re up to about revision 9,500 now. But how fast have we been checking in? behold, the image of glory:

I could go on about this seemingly boring red line for hours. to me, it represents all the sleepless nights, lost weekends, and love that has gone into LBP, reduced to pure stats. There’s something gloriously useless about it, and yet, fascinating. If you look closely, you can see lumps for weekends where the graph flattens out for 2 days, mini crunches before big game shows where the graph spikes up a bit. And then there’s the broad scale changes – a slow start, when we were only a few people, generally working on big chunks of stuff locally and not checking in that much. then the long flat bit after greenlight – were we really that lazy, or did we go back to big private checkins? In fact I think it was mainly due to the fact we went into a long review/design phase at that stage, and spent a lot of time ‘refactoring’ – anyway the analysis could go on. And the temptation to expand the data I analyse is great – this graph doesn’t take into account how much changed with each revision – was it a single texture, or an entire code system? – who made the changes, or all sorts of other things. but I’ll stop here… surely there’s a trac plugin for such wastes of time :)