The Value of Hindsight

Why was Trespasser designed as a software-only product when the industry was beginning to embrace hardware in a big way? Why did it enter full production with only a prose walkthrough for a design spec? Why did the AI system need a major shift in direction in the last few months of production, and why did physics code which is barely usable actually ship? The answer to all these questions is that Trespasser was a project with management problems at all levels.

The word "management" is almost a profanity to some developers with its connotations of hierarchy and structure, so at odds to the often anarchic side of game making. Some major companies abhor the notion so much they have even done away with titles altogether. However, after the Trespasser experience it has become clear that just as there are no successful anarchic world governments there can not be any successful development teams without management.

Trespasser was developed for a Hollywood company, and if there’s one thing Hollywood is good at it is wholeheartedly embracing the notion of hierarchical structures. However, this does not mean that Hollywood knows how to manage successfully. Instead it is famous for its tales of producers on power trips ruining projects and careers left and right as it pleases them. Perhaps Trespasser fell prey to this Hollywood curse. At the very least, it suffered from being an innovative, technologically ambitious project being developed at a company which had not yet gained institutional experience in game management by publishing significant less-ambitious projects.

The lack of skill and experience at the highest level meant that the Trespasser project itself was allowed to run almost entirely out of control. Many developers have had experiences with upper management taking too active of a hand in the production of individual products and frustrating teams with unworkable ideas and arbitrary demands, and being free of upper management interference is their dream. However, as it turned out for Trespasser, having no management influence above the producer level was just as much of a problem.

Pretty outdoor screen shot from Trespasser. [zoom]

Trespasser’s team management was largely made up of people who had not had specific experience with running complicated projects and large numbers of employees before, or who had not managed a game project before. Computer games are one of the most difficult project management tasks possible, consisting as they do of a careful balance between art and engineering, between the desire to innovate and the need to deliver a product in some sort of timely fashion. Managing the types of people who make computer games is also a tremendous test of interpersonal skills, especially when, as on the Trespasser team, many of them have never worked in the industry before and lack of familiarity with standard game development practices. All of Trespasser’s managers, from the top of the team on down, needed mentoring and support from above in order to develop into the kinds of people who could handle the many complexities of such a complicated project, but never received it.

One of the surest signs of management problems is a lack of communication, and Trespasser was rife with it. The design document is a principal example of this communication problem, as has been mentioned above.Also significant was a lack of regular and useful team meetings. Most projects bring all their members together on a regular basis in order to share information, air concerns, and generally improve the atmosphere of teamwork. Trespasser’s team meetings happened erratically at best, going from unnecessarily often - as frequently as three times a week - to weeks or even months with no meetings at all. When the meetings did happen, they often served more to demotivate rather than motivate , as the project was continuously behind and the team leadership was not particularly successful at being positive about the delays. Towards the end of the project, the team largely came to dread them rather than look forward to meetings of any kind, such that by the time the project finally entered beta, no attempt was even made to have team bug meetings, which greatly contributed to the stress and frustration in the final days.

The general awkwardness of team relations was exacerbated by having a key part of the whole project - the physics - written by the project leader. It used to be that it was possible to both run a project and contribute key work to it, but with a game as complicated and a team as large as Trespasser, it was not reasonable to expect that this would be possible. Beyond being a nigh-impossible task, it also put the department heads of the project, especially the lead programmer, in an unenviable and difficult position. When the physics code was continuously delayed and unsatisfactory, there was no easy way to take action to fix those problems. No lead programmer should be expected to tell their boss that he had better get his work done or take some drastic action to get the project back on schedule. Further complicating matters was the lack of upper management support - although on several occasions the team did attempt to go to higher levels to have the lack of progress addressed, the company’s higher-ups were by turns unable and unwilling to take the necessary steps. Perhaps worst of all were the personality conflicts which arose - after a while, it became impossible to even attempt to raise concerns about the physics code without in a constructive rather than confrontational manner. Many on the team began to go out of their way to avoid dealing with the issue at all, but this only allowed the problems to continue growing. By the end of the project, the team was faced with the difficult task of having to take what we had, no matter how unsatisfactory, and try to get it into a stable enough state to ship.

It is unfortunate that even though the Trespasser team was made of some of the most brilliant programmers, artists, and designers in the industry, the game we ended up shipping was at best a deeply flawed beta. In the end, when most of the team were fed up with the whole project and exhausted from what amounted to more than a year in ship mode, it became an issue of ship or possibly never ship. The only way Trespasser was going to become the game that we had promised to the world was to take dramatic steps to address the management issues which existed, and few companies in the industry would have had the commitment and vision to take those steps. With an immense amount of effort, the game did manage to meet its last possible ship date despite the difficult circumstances, but it is hard to imagine what we could have accomplished if we had been brought together and guided with a strong vision and strong plan.

It has been almost half a year since Trespasser shipped. In that time it has gone from a gigantic Christmas letdown to an occasionally-referenced joke. The team has mostly disintegrated, some quitting, some let go, and those remaining distributed across several different projects. The engine is effectively dead, with the new DWI motto being "licensed technology," probably a good idea for the company but pretty disheartening for the engineers who created last year’s most innovative, if not quite best, engine. A group of fans on the net have proclaimed themselves the Trespasser Hacking Society and have taken up the lunatic task of trying to figure out how to do a mod for an engine which was barely usable with its in-house tools.

That Trespasser shipped at all is a testament to the strength of the individual members of its team. In looking back at my own experience on Trespasser, I find that I have learned a lot about game development, and am already putting that knowledge to work. Although Trespasser the game does not fulfill the many high hopes I had for it or even my base expectations for a piece of shipped software, I am happy with the work I put into it. It is my sincere wish that every other person who contributed to the massive effort is equally proud of their work, and that sometime in the future we all have our chance to make a major project which succeeds where Trespasser failed.

Richard Wyckoff was a designer on Trespasser who has worked previously at Looking Glass Technologies in small roles on projects like Flight Unlimited and Terra Nova. He is currently applying what he learned from Trespasser on an unannounced project at Knowledge Adventure. He can be reached at richw@loonygames.com.