Hereís where some problems came in. First, it was too much for only a couple of engineers to tackle. In many ways the project was too ambitious. Second, the "GI. Joe vs. Cobra" concept was translated by our publisher to mean "Player vs. Megalomaniac." I believe they felt it was a little trite. I have to admit it is somewhat cliché. We figured it wouldnít matter if everything else worked as we expected. Third, another game appeared that made extensive use of scripted animations and presented friendly characters. Half-Life turned out to be a huge success which begged questions from our publisher about whether or not we could compete. Considering that at the time of Half-Lifeís release, we had tons of quality content and some great rendering features, but no actual game, I must assume that some worried that we could not. Without "the game," our talents in game-play design could never be effectively articulated or, better yet, proven to EA. Finally, some other games started appearing that were doing outdoor military combat. Delta Force, Spec. Ops and Tribes come to mind. I believe all of these games were reasonably successful and generally applauded.
Itís a funny thing. If youíre making a game that is similar to a weak seller, some publishers will assume your game will sell weak too (Golgotha vs. Battlezone, Uprising). If youíre making a game that is similar to a hit, some publishers will think your game will not be able to compete (Prax War vs. Tribes or Half-Life). Itís sort of a catch twenty-two.
"When will it be finished and how *big* will this game really be?"
Clearly, RBR didnít have the "when itís done" luxury. Unfortunately, we had come from 3D Realms so we were very much used to designing with that freedom. The philosophy understands that innovation is difficult to schedule, so why bother? Even at the end, our engineers considered much of what they were doing as an R&D project. This allowed them to create some miraculous things, but made it impossible to schedule. Our publisher was running a business that has a foundation around predictability of their development schedules. And, we had contractually committed to having the game completed near the end of last year to be on shelves sometime in February or March. Content development didnít have the same hurdles to overcome as engineering, so content was able to maintain the schedules it had developed with EA. This, at least, allows us some measure of predictability and earned us monthly milestone checks. But, while we had come to a new good faith agreement with our publisher to have the game ready near Q3 of 1999, it became obvious to all of us that it wasnít going to be enough time to accomplish everything technologically that the title required. I think EA called this "missing our technology window."
But, what we were building was BIG. Not just in terms of the scope of the game, but what impact the engine Billy was creating would have on the world. Even today, the level designers that worked on Prax War are feeling that, despite never having an executable game to build around, constructing worlds with arbitrary polygons is where the future of 3D level construction will be headed. We were building the world from within a tool that used a purely 3D perspective, which used the same rendering engine as the game. The tool we used that Billy wrote is a significant breakthrough and had a profound impact on all of our level designer types. The kind of advanced thinking it required will be of great value for us on whatever project we work with next, so even though most of our work will never be seen by the public, the experience in itself was worth quite a bit.
The other significant feature that was likely to leave a big imprint on the game industry was the Java-based game architecture. I have heard some speculation that perhaps our use of Java caused some of the problems. I do not think this is the case. Java was going to allow for many unique and valuable attributes for our game construction and for the end user. These are things like allowing multiple modifications to work simultaneously and the ability to add and remove modification or other game code attributes on the fly. Additionally, I understand that Java allowed the engineers to do quick prototyping of tools. The final advantage is that most of the best Java development kits are free to download from the Internet. End users need not purchase expensive development tools in order to create game code modifications.
In the end, however, many of the new innovations our engineers had to invent cost us the predictability our project required. One of the rules of business states that a new start-up should leave as little to chance as possible if it wishes to succeed. It was a lesson hard learned for RBR.
So, What Have We Learned?
We learned that ideology can sometimes hinder decision making in critical times. There were certainly several key moments for RBR where the lack of an ultimate authority over game content and engineering was a problem.
We learned that it doesnít really matter how sound we may think the game design is. Until a final game can be fairly judged, there will always be doubt and skepticism as well as fans and followers. The trick is to build enough of the game play early enough to prove the fun of the title to those that are footing the bill for its development.
We learned that it was insane to attempt to develop such radically new and advanced technology simultaneously to developing the game. We all had such faith in our engineers at the beginning that it didnít seem to be a problem. By the time we realized it was a problem, it was too late.
Finally, we learned that when people work together they can overcome incredible obstacles. We also learned the converse of that.
In some ways, RBR was an experiment. We were the first Dallas company to spawn since id Software that attempted to create our own technology for our flagship title. We were developing a title with a smaller budget than any of the other original POV development teams in Dallas. And we were being published by a new entry to the first person genre Ė giant EA.
In many ways, RBR was a success. It showed that a small team could get together, and use its experience, history, and talent to build a start-up and sign a relatively good publishing deal. It also showed that it could manage itself to create extremely high quality content and dramatic innovations in new technology.
In other ways, RBR was a failure. It could not accomplish its original goal of a completed game before 1999. And it could not ultimately satisfy the publisher that it could finish its technology (and, therefore, its game) within a profitable timeframe.
In any case, every person involved with Prax War, from our producers at Electronic Arts to our technology and content developers in Dallas, has learned an incredible amount from the experience. We went places with 3D development that many will not visit for years to come. We invented methods for doing things that will apply to the next few generations of technology. We explored game design concepts and innovations that are sure to sell the next titles any of us help ship. We went the distance and we are all better people for it. It was a rocky journey, but I wouldnít trade it for anything. It has made each of us a stronger developer. Just wait until you see what we all do next!
- Randy Pitchford was a designer on the now defunct Prax War for Rebel Boat Rocker.
|Credits: Guest Editorial logo illustrated and is © 1999 Dan Zalkus. This Guest Editorial is © 1999 Randy Pitchford. All other content is © 1999 loonyboi productions. Unauthorized reproduction is strictly prohibited and not nice.|