Trending
Opinion: How will Project 2025 impact game developers?
The Heritage Foundation's manifesto for the possible next administration could do great harm to many, including large portions of the game development community.
The X-Files was designed with the intention of setting a new standard for full-motion videogames, integrating cinematic footage worthy of the television show itself with quality adventure gaming at its best. Game programmer Jason VandenBerghe discusses the rights and wrongs of the four year development project, and allows us to claim... that The Truth is In Here.
From its inception, The X-Files Game was expected to set a new standard for the full-motion video game genre. By addressing aesthetic and production-value issues generally neglected by FMV games-specifically the quality of the script, acting, and photography - as well as the technical compromises needed to have video play on a computer - The X-Files Game was to combine engaging gameplay with the narrative interest of an "interactive movie." With the genuine success of the X-Files television series, the game had a running start in achieving its ambitious goals. It already had a rich, fully-developed backstory to use, the same award-winning production company that shot the weekly episodes set to produce the game video, and a prospective audience that included not only gamers, but a much larger universe of people who both owned a computer and liked the X-Files.
The intended audience of The X-Files Game was - first and foremost - the fans of the show. Therefore, game design had to appeal to people who were not traditional gamers, and who would expect the same artistic quality that attracted them to the show to appear in the game. At the same time, we also wanted the game to engage the typical adventure gamer, and thus we had to be mindful of the need to include other aspects of traditional adventure games (combat sequences, interesting puzzles, explorable environments, etc). We essentially had to create two games in the same title: one that met both the standards of the fans of the show, and fans of adventure games.
FMV games, as a rule, are difficult to execute well. Traditionally, production standards for games have been mediocre to grindingly bad. As a result, the genre now suffers from an image problem. Many consumers avoid the concept of an exclusively FMV game simply because all previous examples have been so poor. Overcoming such ingrained market expectation was a daunting proposal, and convincing Fox Interactive of the wisdom of producing such a game was daunting in the extreme. Indeed, it's safe to say that it was primarily the X-Files' creator Chris Carter's interest in an FMV title, coupled with the strength of the license, that allowed the game to be made. HyperBole Studios had completed two FMV titles prior to The X-Files, Quantum Gate and The Vortex, so the company was well-suited to address particular needs of an FMV game.
Considerable effort was invested in creating a game that would be wholly consistent with the television show. Nearly a year of pre-production was spent in developing the story and writing the script; the central plot was developed by Carter himself, and the majority of the script written by Richard Dowdy, a writer from the show. The X-Files Game also melds relatively seamlessly into the greater X-Files mythology. The game was given its own "case number" (or episode number) - 3X99 - which placed the games' events, in X-Files dramatic time, somewhere between the end of the third and the beginning of the fourth television seasons.
Many hours were spent to ensure that the video for the game was on a par - aesthetically and technically - with an X-Files episode. No corners were cut in the production; crew, lighting, and even smoke machines were perfect down to the detail. Our association with Chris Carter's production company Ten-Thirteen allowed us the use of A-list technical and acting talent from the outset. Our Director of Photography had worked on several of the shows from the series. David Duchovny, Gillian Anderson, and the other actors from the show were secured for their appearances through Fox Interactive. Location shooting at realistic times of day was also made much easier by having a big-name production company on-board, and I think the results of shooting in actual warehouses or woods instead of on a sound stage speak for themselves. I feel confident in declaring the game footage equal to or better than that of most independent or mid-budget feature films.
But shooting on location was just the beginning. One of the largest technical hurdles was the creation of high-quality video that would both play well on a minimum-spec computer and fit on a reasonable number of CDs. Previous FMV games (such as Phantasmagoria and The 7th Guest) had been forced to significantly reduce image quality and frame rate to get playable video. The "postage stamp" phenomenon of a tiny video window surrounded by an immense border, or the "black-line" technique that interlaced active video lines with black, were both common solutions to the bandwidth problem. Everyone involved knew that the X-Files had to somehow achieve what no one had done before, which was to display full-frame, full-color video on a computer that real people actually owned. Anything less would undermine the quality of the game.
For the PC/Mac version of The X-Files, we concluded QuickTime was the best possible video playback format. We felt the tools this choice made available to our video team and its codecs would allow us the greatest hope of producing the first FMV game that made no sacrifices in image quality and gave the player a true cinematic experience. While we did letterbox the image, giving the player a cinematic and not a TV experience, that was the only concession made to bandwidth. In this pursuit of quality, we largely succeeded. If the player had a relatively new computer, we were able to provide video quality that was comparable to VHS. Players with older computers could achieve respectable video playback, as we provided a great deal of control over the image quality and video playback configuration. We correctly anticipated that players with older systems - or oddball BIOSes or video cards - would need to experiment to find settings that worked best for them. In this way, QuickTime also gave us many more options for dealing with nonstandard hardware than, say, AVI. As a result, we were able to achieve image quality that was simply the best we'd ever seen in an FMV game.
PSX video playback was also a challenge, as the Sony standard 16-bit video format didn't meet our quality standards. After several disappointing attempts, we had the good fortune of being introduced to Nick Pelling's FPQ library, a 24-bit video playback technology that gave us stunning results at a compression ratio that allowed us to stream off the CD at single-speed. We were the first title to use this new technology.
The interface for the game and the gameplay design were similarly refined over a long period, with much attention paid to finding the common ground between the seasoned gamer and the X-Phile. The game uses a proprietary in-house technology called VirtualCinema. VirtualCinema was designed to be an enabling technology for cinematic interaction that could be used to develop titles that were primarily composed of FMV sequences connected with video loops or static navigation views. Implemented as an authoring tool for directors, editors, and other end-users, VirtualCinema's intention was to allow developers to make sophisticated game worlds with minimal need for additional programming resources. VirtualCinema was also seen as being useful to education and WebTV, where it would allow teachers, advertisers or content creators to quickly make intricate, high-quality "interactive" story worlds.
The Team
The game was designed principally by Greg Roach, CEO and Creative Director of HyperBole Studios. Greg participated extensively in the writing of the script, directed the shoot, headed up the creative direction for the game, and worked directly with the development team to ensure that his vision was implemented. As director, he was responsible for numerous critical technology and procedural decisions that affected the workflow and scheduling of the entire project.
The producer for the PC/Mac version was Phil Peters, a long-time film industry veteran whose expertise as a production designer and as a film producer proved invaluable. He managed the project's day-to-day operations up to the middle of the Playstation port.
I was the producer for the Playstation port, and had been a programmer for the PC version. I took over the port after the PC/Mac version shipped.
The programming leads were Pete Isensee and Melanie McClaire, veterans of both The Vortex and Quantum Gate. They provided a solid, quiet leadership that inspired those around them to produce large amounts of quality code in a short time. They tolerated numerous setbacks and long working hours without complaint, even when the project was clearly taking a heavy toll on their personal lives and even mental health.
We had the good fortune to have a fine artist with a solid understanding of technical issues as a graphic lead. Cassandria Blackmore had been with HyperBole since Quantum Gate, and contributed to the game design and production plan of The X-Files. Much of the game's look and mood can be attributed to her vision and talent.
The video department went through several people before we found Kara Costa, a capable and conscientious editor who was able to gather a coterie of competent assistant editors that saw the video post-production through to the completion of the PC/Mac version. Derek Dexheimer eventually took over for the Playstation port.
Tools
The X-Files engine and all of the supporting tools were developed in C++, using Visual C++ 4.2 for the PC/Mac version, and the SN Systems tools for the Playstation. At the time, Microsoft still supported their cross-platform package for Mac development, and we used this to develop the PC and Mac versions concurrently. Many development teams at the time were converting to CodeWarrior, and it turned out this would have been good for us as well, but we had no way to know Microsoft would drop support for their cross-platform environment two-thirds of the way through our project. We developed our own low-level libraries for the engine.
We used SourceSafe 4.0 for our source control. It worked effectively as a code database, but was a less effective choice for a revision control system. It gave us one nasty shock during the PSX port: we lost all of our revision history due to being unable to move the revision database from one server volume to another (larger) one, but fortunately this didn't end up hurting the project much.
Video was shot on Digital Betacam, using a late pre-production model camera Sony had not yet put on the market. Sony loaned the camera (only one of two in North America at the time) to the production after our DP specifically requested it. The DigiBeta camera masters were simultaneously dubbed to BetaSP and digitized on a Media100 lx Macintosh. Finishing was done with Adobe Premiere and AfterEffects. Final compressed video was made with Media Cleaner Pro, with the FMV assets compressed using Cinepak Pro, and loops and navigation view assets compressed in Cinepak Pro and QuickTime's native Photo-JPEG. Final assets were assembled by the Asset Manager, who hooked them into the game logic and placed them on the CD.
What Went Right
1. QuickTime & FPQ
QuickTime is the most widely used method for video display on the PC and Macintosh, and for good reason. It is relatively flexible, reasonably well-documented, and Apple has done the most onerous coding for you. By using QuickTime we ensured the widest number of computers would be able to play the game video with minimal problems. Most importantly, using QuickTime allowed us to concentrate on core game engine and database issues, instead of spending precious resources trying to get the video to play or track down driver incompatibilities.
The same benefits were realized from using the FPQ video playback middleware from Pterodactyl Software: someone else stayed up late to get beyond the 16-bit video playback limitations of the Playstation. What we ended up with was simply stunning 24-bit full-screen video playback at single-speed compression, which allowed us to put 4 hours of gorgeous video on 4 discs, a significant feat for the Playstation.
In general, the technology decisions made by the developers were solid, and paid off well in generally trouble-free engine performance.
2. Professional Film Crew
The production professionals hired to shoot the film are the ones ultimately responsible for why the game looks as good as it does. A crew accustomed to high network standards will light, block and shoot a scene to those standards, and the results speak for themselves.
On the set, everyone held themselves to professional standards of behavior, and production followed accordingly. The shoot on the whole went smoothly, even with the added complexity of having a film crew that knew next to nothing about making interactive entertainment when they began. While their time was costly, there is no question that the investment paid off as it was intended to.
3. Strong Development Team Dynamics
The development team for this project came together exceptionally well. All concerned believed strongly in the idea of the game, and devoted themselves to doing their highest level of work. The team's standards of quality were very high, and no one was willing to settle for a hack when a real solution could be had in a reasonable time frame. Communication between team members and between departments was strong. Developers tried to anticipate problems before they arose and offer solutions, even in the darkest and most sleep-deprived hours.
There were a total of six programmers, three artists, and three editors at the height of development, each with varied backgrounds. Some had game experience, some did not, but all had a great enthusiasm for the project, and believed that we were working on something special.
4. Jettisoning Old Code
At a key juncture in the project, the team was faced with the difficult decision to throw out code that would present insurmountable problems in the future, but would basically invalidate a year's worth of development time. This was the code base created by a subcontractor who had come on to port the project to the Playstation. At this time, the PC/Mac version had already shipped, and members of that team had moved on to the port, and had discovered that the other side of the project was in a shambles.
The team did their best to develop with what they had inherited, but it quickly became clear that what had been produced wasn't tenable code. The engine was very unstable, and a close examination of the code revealed huge holes in the basic design assumptions that had been used. After much deliberation and verification that it was in fact unusable, the new team jettisoned the whole of the prior work, and started fresh.
In hindsight, this was the only reasonable choice. At several points in the development of the new port, it became clear that if we had used the existing engine we would have hit one impassable design wall after another. One of our developers said early on, "I've never regretted throwing away bad code," and that was certainly the case here.
5. The License
The X-Files is certainly a major phenomenon. It seems to be winding down, but in the summer of '98 it was huge. Participating in that sort of an immense event was both thrilling for the developers and beneficial for the product. A license like this doesn't come around often, and every member of the team, both at Fox and at HyperBole, did his or her best to use the hype to good advantage.
By good fortune, the PC/Mac version shipped just one month after The X-Files movie hit theaters. This turned out to be ideal, and it made the summer of 1998 an X-Files summer. We had also shown a viable demo at E3 that year, and arranging for Gillian Anderson to personally demonstrate the game at E3 was an unqualified hit. The next day, her face was on the cover of every newspaper in the country.
Not surprisingly, the game met with mixed reviews. Reviewers had a tendency to either love it or hate it, with very little middle ground. Even so, it sold well, and was on the top-10-bestseller lists in most territories it shipped to. Our strongest markets were Europe and Japan, where The X-Files is an even larger phenomenon than it is here in the states, reinforcing the power of the license.
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 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.
Conclusions
Given everything that happened over the three years I worked on The X-Files Game, I am profoundly proud when I see the final product. In general it is a well-designed game, fun to play and pleasing to look at. The video quality is phenomenal and far superior to anything seen before on the PC, Mac or Playstation. While hardcore gamers have tempered their enthusiasm, it delights "regular folk" who have little experience with games. Critical response has been mixed, but sales have been good, so it appears that The X-Files Game did manage to break the mold in one or two places. (And, my son likes it, and that's really the most important thing.)
In the end, what I will miss the most are the people. The relationships I developed over such an intense experience of several years will likely last a lifetime. When the Playstation port shipped, the remaining members of the PSX team packed their boxes and went to dust off their resumes. That was the last project HyperBole had in the hopper, and so we were all sent off to seek our fortunes elsewhere. HyperBole Studios may or may not make another game. Time will tell.
As a programmer on the PC/Mac project, I had the opportunity to watch mistakes made by leadership along the way, and to learn from them. I then had the opportunity to take what I had learned and test it out as producer on the Playstation port. From that experience, I concluded that some of the tenets of good leadership are discrimination, communication, and focused action. There are others, I am sure, but if you fail in any of these, your schedule will slip.
Discrimination simply means going over what you will need to do in detail, and deciding what will work and what will not. Discrimination is the opposite of optimism.
Communication means telling everyone on your team what the expectations are, and then listening to them if they tell you that those expectations are unreasonable. Communication is primarily the skill of listening.
Focused action means taking immediate action based on your current objectives and an evaluation of where you actually are. When it comes to tackling complex issues that stand in the way of production, sooner is better than later.
These principles are what The X-Files Game taught me. I feel honored to have participated in it.
Project Data
PC/Mac Team
Programming | 8 FT Programmers (never more than 5 at one time), 1 contractor |
Graphics: | 4 artists, with 2 for most of the project |
Video: | 4 editors / compression specialists, ~5 interns |
PSX Team | |
Programming: | 10 FT Programmers (never more than 5 at one time), 2 contractors |
Graphics: | 5 artists, with 2 for most of the project |
Video: | 2 editors / compression specialists |
General Project Information | |
Total Development time: | 4+ years |
Release date: | PC/Mac: 6/22/98Playstation: 10/13/99 |
Platforms: | PC, Mac, Playstation |
Hardware: | Typical workstation was a Dell PII 266, 96MB RAM, 6GB hard drive, no video card. Also used Macintosh 9600s with 64MB RAM and 6GB hard drives. |
Software used: | PC/Mac Only: Visual C++ 4.2 Cross-Platform EditionPSX Only: SN Systems C++ Compiler & DebuggerBoth: Adobe Premiere 4.0, Adobe AfterEffects 4.0, MediaCleaner Pro 2.0, Adobe Photoshop 4.0, DeBabelizer 4.5.1, SourceSafe 4.0 |
Essential Technologies: | Quicktime 3.0 (Mac/PC), FPQ Library from Pterodactyl Software (PSX) |
Jason VandenBerghe currently resides in Bothell, Washington. He is Founder & CEO of Corporation X, an independent games publisher dedicated to making opportunities for independent developers who want to bring their games to market. He can be reached at [email protected].
Read more about:
FeaturesYou May Also Like