[gameprogrammer] Re: My game
- From: Josh Stewart <aek@xxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Mon, 26 Sep 2005 17:55:20 +0800
Thanks for the reply :)
Kevin Jenkins wrote:
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.
At least you have a bug tracking system. We have email, and maybe a
spreadsheet somewhere on a network drive. Most bug tracking is formal
and requires 20 bits of paper and 40 signatures at each step, and
someone down the chain enters it into some ancient database. Thats what
you get when its a critical system, every bug fix has to be justified
and re-proven, regession tested and to insert that into a running
system, you need the engineering rigour behind changes to the
configuration (thats why bugs are cheaper when fixed earlier in
development)..
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.
I wonder if something like collabnet could proved a suitable 3rd party
method for sharing a bug tracking database between testers at the
publisher and developers, that would speed this process up? (or do you
already have this sort of thing?) Then it would be straight from tester
to developer (with maybe someone in the middle on each side to sort
through the noise and collate results back and forward, if the project
was big enough and time was critical).
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.
Yes this is true at my work also, and holding onto the original talent
is important, however you cant guarantee anything and if someone knows
they are critical they can ask for unrealistic pay rises because they
know they are invaluable. And if the employeer got into that situation,
employee's should make the most of it :)
I think the answer to this is to get middle managers to discard their
rustic belief that resuing legacy company IP/software/tools from 7 years
ago, will save the project time and money. The following rant is
entitled "Reuse should have a 'used by' date"
As you said it takes ages to get anything done because you have to try
and understand what some guru was trying to do years ago.. sometimes
with no comments or documentation. Perhaps its a weird optimisation that
is totally irrelevant these days? Perhaps its a library that was written
to fill some need and your better off downloading a new library off the
net instead of digging up some ancient library thats buggy, poorly
documented, feature poor and difficult to integrate because of poor
design methadologies employed back when the code was written. You might
be tempted to write a new library. But if your trying to get a title
out, you dont have time to do it properly. If you do write your own,
your hack up version will plague future generations at the company,
continuing the cycle.
These days it can better to look around and evaluate 3rd party tools and
components, or if the company is big enough have separate teams working
on in-house components and tools exclusively. Then the game programmer
for a title becomes the integrator, taking all the best components they
can find/afford and making them work together.
The integrator should be able to pick the best tools they can, and not
be told by some manager they need to reuse some ancient component to
save $1000, but its up to the developer to make them understand this.
This can keep the work interesting because you can use new technologies
and design methadologies in areas your interested in (the game engine
framework, or key new features of the game, or gameplay machanics), and
farm out the rest of the work to 3rd party components.
Finding components that integrate well is another challenge, and you
also need talented people that really know there stuff to put it
together, nothing just plugs and plays together. If someone has written
a physics engine before, they are gonna be great at integrating another
one with the engine.
People might worry about their job, if its too easy to plug these bits
on. That is silly because people still need to extend 3rd party
components and work on new components. If you have some 3D programming
prodigy, keep them employed and interested by letting them work on the
3D engine component.. when they are done, get them to make the next 3D
engine. If your game sucks you can still license the 3D engine to other
people.
An example was a assignment I just did for uni. I found a heap of maths
libraries, XML tools, model loaders, TGA file libraries, and sound
libraries.. I ended up using the XML SXP/expat DLL and got that
functionality working in a day, then got a milkshape loader and extended
it to load in extra info for the models (bounding boxes etc). The TGA
library worked out of the box and the maths libraries were horribly
complex, so I wrote my own one over a day. I spent $40 on Milkshape.
Other people are still trying to roll their own crappy TGA loader.. I
dont care about the TGA compression format, but I do need to know how to
use the image data it spits out in my engine.
Software is unique in that builders can decide to make their own bricks
or find used bricks of unknown quality at the rubbish tip instead of
driving to brickland.
Josh Stewart
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
Other related posts:
