What
Went Wrong
1. Trouble
with the AI. If one thing could be called out as the reason Thief's
gameplay didn't come together until late in the process, it would be the
AI. The AI as a foil to the player is the central element of Thief,
and the AI we wanted wasn't ready until late in the spring of 1998. As
lead programmer and author of the final AI, I take full responsibility
for that.
The original
AI for Thief was designed by another programmer before the requirements
of the revised stealth design were fully specified. Six months after it
was begun, the project director and overseer of the system left the team,
and the most of the programming staff was temporarily reassigned to help
ship another game that was in trouble. During the following months, development
on that AI continued without any oversight and without a firm game design.
Soon after, the programmer working on the AI also left. While the core
pathfinding data structures and algorithms were basically sound, the code
that generated the pathfinding database was extremely buggy. The design
of the AI decision process was geared towards an action fighting game
requiring little designer customization, rather than a stealth game that
needed much more customization. Even worse, the high-level decision process
in the AI had drifted away from a rigorous design and the code was extremely
brittle. The whole situation was a disaster.
These
might not have been serious issues, except for one key mistake: I didn't
realize the depth of the problem quickly enough, and despite concerns
expressed by programmer/designer Doug Church, I didn't act fast enough.
I think highly of the programmer involved with the initial AI and wanted
to avoid the natural but often misguided programmer reaction within myself
that I should just rewrite it my way. So, I took the position that, while
buggy, the system as a whole was probably sound. Several months and many
sleepless nights later, I concluded that I had been sorely mistaken.
By November
1997, I had the basics of a new design and began working on it. But all
work had to stop in order to pull together an emergency proof-of-concept
demo by the end of December to quell outside concerns that the team lacked
a sound vision of the game. This turned into a mid-January demo, followed
by an early February publisher demo, followed by a late February make-or-break
demo. During this time the only option was to hack features as best we
could into the existing AI. While better than losing our funding, constructing
these demos was not good for the project.
In
the end, work on the new AI didn't begin until mid-March. Despite the
fact that our scheduled ship date was just six months away, we threw away
four-fifths of our existing AI code and started over. After a hair-raising
twelve-week stretch of grueling hours, the AI was ready for real testing.
Had I committed to a rewrite two months earlier the previous autumn, I
believe the AI would have been ready for real use three to five months
sooner.
2. An
uncertain renderer. The project was started because of the renderer,
rather than the reverse. The basic core of the renderer for Thief
was written in the fall of 1995 as an after-hours experiment by programmer
Sean Barrett. During the following year, the renderer and geometry-editing
tools were fleshed out, and with "Dark Camelot" supposed to ship some
time in 1997, it looked like we would have a pretty attractive game. Then,
at the end of 1996, Sean decided to leave Looking Glass. Although he periodically
contracted with us to add features, and we were able to add hardware support
and other minor additions, the renderer never received the attention it
needed to reach the state-of-the-art in 1998. The possibility that we
might not have a point programmer for the renderer weighed heavily on
the team. Fortunately, Sean remained available on a contract basis, and
other members of the team developed sufficient knowledge of the renderer
so that we shipped successfully. In the end, we shipped a renderer appropriate
for our gameplay, but not as attractive as other high-profile first-person
titles.
 |
One
of the featured weapons is the fire arrow. |
This may
prompt the question of why we didn't simply license a renderer. When the
project started a few months into 1996, the avalanche of Quake licenses
hadn't really begun and Unreal was still two years away. By the time licensing
was a viable choice, the game and the renderer were too tightly integrated
for us to consider changing.
3. Loss
of key personnel amid corporate angst beyond our control. Midway through
1997, Thief was just starting to gather momentum. We were fully
staffed and the stealth design was really starting to get fleshed out.
Unfortunately, Looking Glass's financial situation was bleak. Few emotions
can compare to the stress of heading to work not knowing who might be
laid off, including yourself, or whether the doors would be locked when
you got there. The company shed half of its staff in a span of six months,
and while the active teams tried to stay focused, it was hard when one
day the plants were gone, another day the coffee machine, then the water
cooler.
Some
of the Thief team couldn't continue under these conditions. We
lost two programmers, including the former lead programmer, and a designer.
When we were forced to close our Austin office, we lost our producer,
Warren Spector, as well as some programmers who made valuable technology
contributions to our engine. All of these individuals are now on Ion Storm's
Deus Ex team. Although it took some months to fully restore the spirit
of the rest of the team, we held together and the company eventually rebounded.
Perhaps it bestowed a stoicism that comes from knowing that however bad
things might seem, you've already seen worse.
4. Undervalued
editor. One of the boils never lanced on the project was our editor,
Dromed. Although it was sufficiently powerful and provided the essential
functionality we needed to ship the game, Dromed was a poorly documented
and sometimes disagreeable editor. Dromed was first developed as a demonstration
editor when the target platform of the game was DOS. As a demo, it never
received the kind of formal specifications and designs one would expect
for the central experience of the design team. As a DOS application, it
lacked the consistent and relatively easy-to-use user-interface tools
of Windows. An early mistake was our failure to step back and formally
evaluate the editor, and then rebuild it based on our experience constructing
the demo editor. We also should have designed a proper editor framework,
and hired a dedicated Windows user-interface programmer to support it
through development. In retrospect, the time lost cleaning up the editor
probably would have been saved on the back end of the project.
5. Inadequate
planning. Although it is a cliché in the software industry
to say our scheduling and budget planning were woefully inadequate, the
Thief project suffered greatly from this malady. There were several
elements to our deficient planning.
During "Dark
Camelot," and continuing through the first half of Thief, we staffed
the team before the design and technology was sufficiently mature. In
Thief, this led us to rush towards finishing the design, when we
didn't necessarily understand the design and technology. With insufficient
specifications of both the code systems and mission designs, we ended
up doing lots of content that was essentially wrong for the game we were
making. Code was written and spaces were built that weren't well directed
towards the goals of the project.
To make
matters worse, we failed to reassess core scheduling assumptions carefully
once the schedule began to slip. Captives of a series of unrealistic schedules,
we didn't leave enough time for the sort of experimentation, dialogue,
and prototyping a project like Thief needs. Late in the winter
of 1998, many of our scheduling mistakes had been corrected. Still, during
the remainder of the project, the legacy of our earlier missteps required
cutting missions that relied on technology we didn't have, and reworking
missions not focused on the core gameplay.