Why Can't Johnny Ship?
| Why Can't Johnny Ship? |
| Introduction |
 Page
1
Page
2
Page
3
|
| Conclusion |
By 1985 I had an artist working with me and people to play-test the game. Then musicians were added to the mix. Better platforms allowed for higher production quality and more ambitious titles. Soon the staff included videographers, actors, screenwriters, designers, storyboard artists, 3D artists, animators, sound designers, producers, associate producers, programmers, system engineers, caterers, and on and on.
It's hard to remember just how ad hoc the development process was in the early days. Often you would start with a vague idea of the kind of game you wanted, write some graphics code, build some art, and play the game. Then you'd go back and rewrite the code, rework graphics, and replay the game. When staffs were small and localized this iterative process yielded great results. It was fun, to boot.
It is this history of development on the fly that haunts us with incomplete designs, inaccurate schedules, and in-the-bargain-bin products. And as a result, the creative fun of developing interactive development has been replaced by a death march: ship or die. We suffer, our products suffer, and ultimately our profits suffer.
These problems haven't gone unnoticed by the rest of the world. To quote Steven L. Eskenazi, principal at the investment bank of Alex, Brown & Sons, "The problem with this business is that companies lack a disciplined approach to product development. Management allows techie developers to start programming without a finished script. Since this is a branched medium, every time a developer makes even a slight change, it causes a rippling effect on the entire title."
