Development Statistics for P.B. Winterbottom

February 2010

I've shipped my first game! Here are some development statistics for The Misadventures of P.B. Winterbottom.

Project Duration: 14 months

Lines of Code:

Total Code Only Comments Only Mixed Blank Non-Blank
C++ (Engine) 37,706 25,646 2,193 930 8,937 28,769
C# (Tools) 49,522 35,446 5,089 7 8,980 40,542
Lua (Content) 76,485 45,969 14,331 40 16,145 60,340
Lua (Generated) 113,275 113,275 - - - 113,275
Python 986 986 - - - 986
Php 14 14 - - - 14
Totals 277,988 221,336 21,613 977 34,062 243,926

You can see that Lua pretty much eclipsed the codebase. A lot of the Lua code that was written by hand was boilerplate state machine type stuff. Still, almost all of the game logic lived there.

The Lua code that was autogenerated was mostly initialization code. We never got around to replacing our initial quick-fix initialization pipeline. This code was doing things like creating game objects in C and setting their initial states. Certainly wasn't the most performance friendly way to do things but it got the job done. ;) Next time around most of this kind of code will be replaced by a better designed resource loading system.

Python and Php were used for our automated build system and associated web interface. This went up pretty early in the project and we didn't have to muck around with it too much after that. We'll probably be throwing this away and moving to something like CruiseControl.

The C++ code was your pretty standard component based game engine. Nothing really remarkable about it other than the fact that we succeeded in shipping with the 'game' part of it existing entirely in script. The number above is a little lower than reality because we used Luabind to bind Lua to C++. There's probably a couple thousand lines of template code that gets generated when we build that game that isn't getting counted.

The C# code is a combination of 3 tools. We had a tool wrapping Git and providing a GUI for our content creators, a level editor, and a deployment tool for packaging data and copying it to the consoles. I'd estimate that at least 1/3 of the work on the project went into our tools.


Executable size: 2.4MB
Art created (3d models, textures, versions...): 97.3GB
Art imported into game: 337MB
Art shipped: 215.7MB
Music: 48.3MB
Sound Effects: 2.99MB
Scripts: 14.7MB

It's interesting to see that the 97.3GB of data that the artists created got distilled down to 215.7MB of textures that we shipped the game with. You can also see that there's a little more than 100MB of textures that we imported into the game engine that we didn't end up using.

Art dominates the shipped game's size, followed by music, scripts, sound effects, and the executable itself.

Version Control (Git):

Repository size at project completion:                 6.08GB
Commit Count: 8,327
File Count: 24,890
Folder Count: 1,093

We used Git for our version control. You can see that we didn't have the artists check in their 100GB of data into the repository, only the art that was actually being used in the game was allowed in. Their files were protected using backups on our server.

The commit count may be a little low. I believe at some point in the project we remade the repository from scratch and dropped the old history. (Probably around the same time we decided that art shouldn't be checking everything into the repository. I recall hitting a 2GB limit on some file sizes.) Since we're using Git I'd estimate that well over 1/5 of those commits are merges because we didn't fully take advantage of the rebase command.

Bug Count: ~1,257

The bug count is also probably a little low. This is just the number of bugs we had from Alpha to Gold once QA started hammering on the builds. During production we didn't use bug tracking software. We certainly had bugs during production, but they were addressed as they came up or ignored if they were minor defects.

Daily Averages:

Lines of code (excluding autogenerated):    385.7 / day
Lines of code (including autogenerated): 651.0 / day
Art created: 0.23GB / day
Commits 19.5 / day

Nothing earth-shattering here. It's interesting to see that our tools were generating roughly 1/3 of the code a day for us.

Maybe I'll use this data to estimate our disk space needs for the next project and seeing how close I get.

two-thousand-twelve ce, all rights reserved