| david siems | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Development Statistics for P.B. WinterbottomFebruary 2010I've shipped my first game! Here are some development statistics for The Misadventures of P.B. Winterbottom.Project Duration: 14 monthsLines of Code:
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. Data:
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):
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,257The 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:
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-ten ce, all rights reserved | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||