Postmortem: SANITARIUM
By Chris Pasetto
Gamasutra
December 4, 1998
Vol. 2: Issue 47
Originally
Published in Game Developer Magazine, November 1998.
| Postmortem: SANITARIUM |
Introduction-
The Designers' Tale
The
Artists' Tale
The Programmers' Tale
The
Sweet
|
At first, we planned to convert an existing
adventure game engine. Initial prototyping showed that this was about
as likely as an Oscar nomination for Jackie Chan. So, we set out to create
a new engine, re-using existing source code wherever possible. By using
source code from earlier finished products, we avoided absolutely all
bug-hunting hassles. Ha ha. That's a bald-faced lie. But using proven
code did give us less to worry about - we knew it had worked at some point.
The basic engine was completed early in the project cycle, leaving us
plenty of time during the rest of the project to sprawl in great big chaise
lounges and sip tequila from fishbowls. Actually, that's not true either.
Once the basic engine was complete, most of our time was spent on level
building. A level scripting system based only on actions, flags, and flow
control simplified the work. The rest of our time (those hours normally
reserved for basic human functions such as sleep) was devoted to interaction
scripting and special case programming, including blow-up puzzles and
action areas. We had originally planned to create a blow-up puzzle editor,
but time did not allow it. Reaching into the wiry guts of the beast, we
hand-coded each blow-up puzzle instead.
Deciding
on a codec for cut scenes was like clipping a lion's toenails. The first
codec we looked at, True Motion, provided better visual quality but lacked
support and ease of implementation. The second codec, Smacker, had just
the opposite traits. We couldn't wait around for somebody to achieve the
balance of properties that we needed because: first, we didn't have time;
and second, we didn't know if anyone would get it right any time soon.
The final decision came late in the development process: support and ease
of implementation won out over visual quality.
For SANITARIUM's bug testing, we entirely divorced
ourselves from tracking bug reports on paper. Both our in-house testers
and the test team at ASC Games used FileMaker Pro 4.0 to generate, sort,
and track the status of all bugs. Because we were both using the same
software, we were able to trade databases with ease, do proper triage,
compare priorities, and eliminate duplication. SANITARIUM
was DreamForge's most thoroughly tested product to date.
But even with this extensive testing regimen, the game still shipped with
the infamous "lockout bug" on Level 2. If the player wandered around the
town long enough and fulfilled certain conditions, it became impossible
to enter any of the buildings. This was a big disappointment. In the countless
man-hours of testing between ASC Games and DreamForge, no one encountered
this bug. Herein lies a valuable lesson, grasshopper. There is simply
no test group more likely to find a crash bug than those tens of thousands
of initial buyers.
