[gameprogrammer] Re: My game
- From: Kevin Jenkins <gameprogrammer@xxxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Sun, 25 Sep 2005 22:03:29 -0700
To put that in context, the largest system I have worked on was about
3.5 million lines of code, and that was the entire X Windows system. The
Windowing system used on UNIX and Linux machines.
Can you fill us in on the tools that were used to manage that code base?
how are changes managed, what is the build system, do you use automated
testing. What is the bug fixing/tracking system like?
Bob Pendleton
I should clarify what I said earlier since I'm giving the wrong
impression. By 50 people I mean 50 total people. Not programmers.
There are about 10 programmers working actively on this particular game
with some number more indirectly working on it. 20 million lines of
code is the number given by the lines of code counter and isn't what we
use day-to-day.
The 20 million includes things like the Maya exporter, the level editor,
scripting for this and older games, about 50 different tools (model
viewers, report generators, the bug database, exporters, importers,
memory size checkers, dialogue language utilities), shaders, 3 different
graphics engines, etc. I'm sure a very significant percentage of that
count are old unused projects as well.
Only a small fraction of the total code is in the game project. It's
disproportionate but the quality of your game is determined by the
quality of your tools.
To build the code we use Incredibuild. It's a utility that shares the
CPU power among other computers that also have it installed. With it, a
full rebuild for the first time that day takes 10-15 minutes.
The code base is in VSS. There is no check-in management or tracking
beyond what VSS does. Someone will do a bad check-in about once a week.
There's no automated testing but we do testing throughout the game
lifecycle. Early on there may be no testers other than the producers
playing the build submissions. In the middle of the last project we had
three full-time testers. Right now the publisher is also doing testing.
I'm not sure how many testers there are in total but now, during the
final testing phase of the project, I get about 20-30 bug reports a day,
most of which are duplicates.
Bug tracking is done through an automated system. We get a bug, mark it
fixed, which sends it to the testers again or we can reassign it to
others. Communication through this system is very slow and very
inaccurate. The slowness comes from the delay caused by each link in
the communication chain. If a bug has to go through 5 people, each
person takes 3 days to get to the bug, then 2 days to work on and
reassign it that is 5 weeks just to process one bug.
This can be used for good or evil. It's good because it makes a person
responsible for a bug. Some people will ignore bugs if you just email
it to them. But it's bad because it's very easy to pass the buck. If
you don't want to do a bug you can just mark it 'explain' or reassign it
to another and know you won't see it again for a week or more, if ever.
The hardest part of dealing with a large system is that nobody really
understands any of the code. There's too much of it, the things that
break tend to be things that nobody remembers. The company I'm at has
a turnover rate typical of most game companies. So it's usually the
case that no matter what code you are dealing with the author no longer
works there. The programmers are very self-reliant out of necessity.
The downside of this is that it takes 10X longer to do anything. In my
opinion if a company were just able to hold onto its original
programmers that company would be an order of magnitude more productive.
Congrats if you read all of this :)
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
Other related posts:
