What Went Wrong
1. Project Management
Relations between the management team and the developers ran from camaraderie to bitter behind-closed-doors aggressiveness. Emotions ran very high on this project, higher than I had ever seen before in a development environment. This, combined with a clear top-down management and design approach, made maintaining morale among the developers a real challenge. (It's nearly impossible to remain productive when your coworker whom you respect and admire is being yelled at in their office.)
This "top-down" approach to management worked into project scheduling as well. Time and again, developers were told that the schedules they wrote for the project were unacceptable. The schedules that were eventually agreed upon were largely emotional compromises made to avoid more conflict. This unfortunate situation hurt everyone involved, since the success of both the team and the company depends on its schedule being as accurate as possible.
2. Overly Ambitious Project
The scale of the game design and the tools built to develop it was at a level of generalization quite a bit higher than what we could actually achieve with The X-Files Game. The technology was designed to anticipate a wider range of products than just one game, and was therefore generalized to solve a wide range of problems. Unfortunately, this extra effort cost development time that wasn't accounted for in the initial schedules, and the project as a whole suffered for it.
Designers not tackling the details of the game design up front exacerbated this problem. Difficult questions like how we were to implement a design concept were not present in the design document. When the developers got to the point of actually implementing a hastily sketched concept, it generally turned out to take much longer than was anticipated. This affected every department; video, graphics, and programming all found that they had much more to do than the design implied when they sat down to work it out.
There are several ways of handling such a problem. One would be to revise the design to reflect the current realities of time and established budgetary restrictions. Another might be to put in a period of intense research and design time to objectively determine how long the project would actually take, and then reevaluate the schedule once a solid schedule had been put together. Instead, our management chose:
3. The Death March
The most severe blow suffered by all teams was from accepting an unrealistic schedule. Despite endemic problems with producing finished video, the large amount of graphics to be created, and the sheer size of the programming task, the concept that was floated at the time was that it would be possible to adhere to the original schedule if everyone simply worked around the clock. Foolish and naïve, we bought it, and started pushing.
While a final push of a few weeks or even a few months is common toward the end of a technical project, the schedule of six to seven days a week of twelve- to twenty-hour days adopted by The X-Files team stretched on for eight months. Predictably, exhaustion began degrading the ability of people to produce quality work, not to mention the deeply straining effects it had personally on team members and their families.
In retrospect, the death march did little to speed the project's finish. There were several systems that were developed during this time that caused us no end of grief in development, largely because of the inability of the developers to make clear and rational design decisions from lack of sleep. For example, before we began this push, our code, although incomplete, was basically stable and well debugged. Three months into the push our code stability had drastically decreased, and we started patching engine problems with localized fixes that simply led to more problems elsewhere. Had we maintained a normal development load, we would have been able to make clearer and more efficient design decisions, and I believe we would have finished at or around the same time we ultimately did.
For me, the lesson here is that if the schedule begins to slip, the solution is not as simple as just applying more work to the problem. Pushing harder won't necessarily finish the project any sooner, and some of the damage done to the team under that much stress may be irreparable.
4. The Password Puzzle
One of the first puzzles that the user was confronted with in the game was the infamous password puzzle. The FBI computer that the player used in the game (as Craig Willmore, FBI agent) was password protected. To enter the computer, the player needed to discover the character's full name and his password. The password was 'Shiloh' (for those of you who intend on playing the game, write this down ;-), a famous civil-war battle. Willmore, being a civil war nut, had posted a map of the battle on the bulletin board of his office. The player was to learn that Willmore liked the civil war, see the map on the bulletin board, and thus make the connection with the password.
Players and reviewers both claimed that FBI agent Craig Willmore would know
his own password.
Players and reviewers alike complained that an FBI agent should know his own password. Issues of game logic aside, the puzzle was difficult at best, and in actual game-play it had the effect of shutting uninquisitive players out of their computer, and stumping players in the first sequence of the game. A week after the game's release, Fox Interactive had posted the password in big bold letters on their X-Files tech-support web page to help stem the tide of support calls they were getting about it.
There were many attempts made by several developers throughout development to get this puzzle removed from the game. These attempts were met with heavy resistance from the designers, and the decision was made to keep it in.
5. Porting Early
The Playstation port of the game was mired in huge problems for a great deal of its duration. Many of these problems stemmed from one initial difficulty: an outside developer made a low-bid to develop the port before the game design was even complete, and they were hired on the basis of that bid. This team came on approximately a year and a half before the PC/Mac version shipped, and from the outset they were underfunded and in trouble. Many of their developers wanted to be on other projects, and HyperBole was focusing almost exclusively on the PC/Mac version in order to get it shipped. The initial development environment for the port was plagued with systemic problems that were tackled by writing complex in-house tools that often acted as a band-aid rather than actually fixing the problem. Meetings were generally frustrating for all involved, and there seemed to be a lot of confusion about where the project actually stood. I have learned that this is generally a good indicator that things are not progressing well.
The PSX port went through three full staff turnovers during development. As previously described, the first two teams generated very little in terms of usable code or assets. The final team was assembled after the PC/Mac shipped, and was made up of members of the PC/Mac team and several new developers. (I came on as producer for the port at this time.) This team made the hard decision to simply start over. After another full year of development, the PSX port shipped, and it looked great, but getting there after inheriting such a huge mess was quite a challenge.
Again, the culprit here was optimistic scheduling. The first port teams operated under a largely mythical schedule with no real qualified goals or documented solutions to expected problems, and so the port floundered. Once a realistic assessment of what was actually required to ship the product was made, development proceeded fairly smoothly.