Don Moar
Lead Programmer
Joined: 17 Oct 2001
From: BioWare
|
 Posted: Thursday, 27 May 2004 04:19AM
Hey,
First of all, the aerospace industry analogy as you describe, khazar-khum, is not quite accurate. You would never put a full compliment of 217 passengers on the Boeing 7E7 for its first flight. Similarly, you would not hand over untried / unreliable tools into the hands of artists and designers working on your project; they are _not_ test pilots. Their work is not testing the tools, it is using the tools to make the game. Just as passengers on airplanes have a reasonable expectation of safety and reliability so too, do the users of our tools.
Continuing with the aerospace analogy, there is another saying "Never marry an untried engine to an untried airframe." It is all well and good to build tools using game and graphics code that is more or less final. It is an _entirely_ different matter to be developing them simultaneously. This introduces not just one, but several additional layers of complexity that must be managed in order for development of the game to proceed as smoothly as possible.
The simple fact is, there is a (slightly) higher failure tolerance for the game than for the tools for most of the project. That is, when the game goes down, it's bad but not critical because you can always restart / reload without loss of work. When the tools (using the same game and graphics code as the... game) go down, you have now introduced negative work into the project. Ignoring the cost of finding the bug for now, the basic cost is that the content creator must now reimplement whatever work has just been lost. This means the content creator is no longer moving the project forward, he or she is trying to recover lost ground. Now imagine an entire team of artists or designers who can't work because of an unknown data corrupting or crash-inducing bug. Don't think it doesn't happen.
Let's actually look at the cost of finding that bug. If the bug occurs only in the game, you are losing time the game or graphics programmer could be polishing existing or adding new features to the game. This is bad because it impacts the product our customers are purchasing. If the bug occurs in the tools, the tools programmers are usually the first ones to begin the investigation. This means that the tools programmers are no longer polishing existing or adding new features to the tools. When you consider the value that a new tools feature could add to the project in terms of allowing the artists or designers to complete some task faster (and the corresponding ripple effect benefit that could have on the final product) this can quickly multiply into a huge loss.
Now, good testing and change management practices help to mitigate that risk, but when it's your work that's just been flushed, it doesn't make you feel any better that the tools programmers saved a little time by reusing that code. When a project is developing the game and graphics engine systems and tools simultaneously, any sharing of code should be considered very carefully because the "issues" that you avoid later may be outweighed by the "issues" that you face today.
Don M
|
