Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: DreamForge's Sanitarium
View All     RSS
June 22, 2021
arrowPress Releases
June 22, 2021
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Postmortem: DreamForge's Sanitarium

December 4, 1998 Article Start Previous Page 2 of 2

The Programmers' Tale

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.

The pain... the PAIN!!!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.

The Sweet

Sanitarium represented a significant success for DreamForge in several areas. Many of these have to do with our personal sense of accomplishment in making this game, but others are things we learned along the way.

1. BRING IT ON HOME. As a game that was designed in-house, an enormous amount of energy and personal pride went into Sanitarium. Remember that this project began as a few guys hanging out after work saying, "Wouldn't it be cool if we made the game that we would enjoy playing?" Even after months of work, we weren't sure if the game would ever reach the shelves. As the team's hard labor began to bear fruit, the whole company's energy and enthusiasm grew, sustaining us through the crunch periods. That sense of personal ownership in a product cannot be underestimated. It defined the experience of Sanitarium for us as developers.

Not only that, but our staff offered us an inexpensive focus group. Fairly early on in the project, the ideas we designers had been bouncing off one another seemed like stale old superballs. We needed more outside opinions to give the project perspective. We invited small clusters of DreamForge employees to join us in the design room. Like a nightmare ride at Disney World, we took these groups through the game puzzle by puzzle, plot twist by plot twist. Questions and comments gave us valuable information - what looked interesting and what seemed confusing.

As a result of those walkthroughs, it became painfully clear that Level 6 of our design just wasn't cutting it. It was as though Al Gore had walked into the room. People's eyes glazed over at that point in the walkthrough; yawns were abundant. We looked at each other and said, "This is not good." So we asked people, What would be clever, interesting, and creepy? Bugs seemed to be the answer. Based on staff input, the resulting Level 6 of Sanitarium is much stronger and enjoyable than our original design.

2. HOME MOVIES. From the very beginning of the development cycle, we wanted to give Sanitarium a dark, cinematic feel. In most games, the cut scenes are treated like a necessary evil or worse - a pageant of plug-ins du jour meant to dazzle viewers and draw their attention away from the game play. We were determined to establish a style for the cinematic cut scenes, to make them an integral part of the game. We especially wanted the flashback cut scenes to deliver an emotional impact to the viewer, because they dealt directly with Max's life, love, and suffering. To support that idea, we shot the scenes to mimic the letterbox look of movies. Our cinematic coordinator, Marty Stoltz, drew upon his filmmaking background to guide us in precise cinematic screen direction. Joe Skivolocke also lent his post-production expertise to the effects for all memory cinematics. A lot of work went into ensuring correct camera usage and post-production of cinematic scenes - especially for the flashback sequences, which were meant really to touch the player emotionally.

Bugs... why'd it have to be bugs?


All cinematics came into the world as storyboards - carefully laid out in Adobe Premiere and passed on to the artists. The 3D staff worked from storyboards to create raw .AVIs. Our post-production team worked with these .AVIs, touching up the rough edges and applying special effects using Adobe Photoshop, Adobe After Effects, and Strata MediaPaint. Some of the raw .AVI material had to be thrown out in the end (because it didn't work, because something looked wrong, because one of the lighting crew members was eating a sandwich in the background). Still, our shooting ratio was about 3:1 (for every second of cinematic material that we used, 3 more seconds were tossed out) - that's pretty good when you consider that the average movie has a 20:1 shooting ratio. The polished cut scenes that went into the game were the best DreamForge had ever produced, anchored thematically by a unique and consistent vision.

3. MODULAR FURNITURE. We had all worked on other games and were familiar with the potential threat of cutting levels, puzzles, and whatever else seemed expendable when the crunch was on and no amount of Mountain Dew could keep us going. From the beginning of the design, we prepared for such eventualities by structuring the game in a modular fashion. We constructed the game in portions that would add to game play and advance the story, but wouldn't detract from the game overall if they were taken out. In the end, we were able to keep the amputations to a minimum. A big combat zone and some blow-up puzzles took a trip through the plumbing, but otherwise the cuts were fairly minor. Modular design at the start of the project ensured that the final game would remain true to its initial vision.

4. HEY, NICE ASSETS. As an experiment, lead programmer Chad Freeman implemented an asset management system utilizing a Paradox database, which centralized all of the game assets in one place. Tools developed in Delphi and Visual C++ accessed the assets from this database. This solution provided several benefits. For one thing, we could easily analyze the asset data and take appropriate actions when total asset size broke the budget for a level. We could also view filenames and descriptions of individual assets. The database system let us group assets by levels or by other criteria. A single game level had hundreds of art and sound files. Searching for a particular asset by the filename alone would have been the equivalent of finding the fat guy wearing the Star Trek shirt at a sci-fi convention. Naturally, the ability to sort through assets quickly saved time and energy.

Because this process was experimental, we weren't able to fully exploit the database system. For example, the programmers were the only ones who utilized the system during the level-creation process. However, Chad Freeman would eventually expand the system so that artists and sound technicians could add assets to the database and level creators could access them directly from there, eliminating redundant file storage. In addition, the system could also store level information, allowing these same types of reporting, sorting, and other benefits to be extended to the levels themselves. Overall, the development of Sanitarium never made full use of these database management tools. As game content grows larger and larger (DVD and beyond), using database tools for data storage will help developers more and more.

We also utilized Visual SourceSafe for the first time during Sanitarium's development. Historically, programmers have been beset with the extremely time-consuming and tedious job of hand-merging code. Never again. Like a divine beam of light shining into our otherwise dank and shadowy cubicles, SourceSafe made code merging far easier and more reliable. SourceSafe also has other benefits, including the ability to keep a precise revision history of your code, so that you can painlessly retreat from the inevitable "bad move" programming-wise.

We chose SourceSafe specifically because it allowed multiple check-outs; the structure of our C files prior to adopting SourceSafe was such that it was common for more than one person to be working on a single file at the same time. SourceSafe also allows a project to be branched off; letting one person work on a demo while another continues development of the game. The projects can later be re-merged, so that fixes in the demo can be integrated into the main source.

5. PROJECT MANAGEMENT FOR THE INSANE. Using Microsoft Project and his own devious tracking tables prepared in Microsoft Word, project manager Scot Noel would recalculate our progress every week to two weeks. This method accounted for the progress of every single game element, from blow-up puzzles to art fixes to code implementations. GANTT charts demonstrated the flow of work between departments and individuals. These enabled us to respond promptly to the most critical problems by showing how the late delivery of a particular asset might throw off the final ship date by days or weeks.

Critical paths were plotted using PERT charts in Microsoft Project. Upon seeing these Daedalean webs of near-infinite complexity, many of us felt that Scot had gone, finally and irrevocably, insane. But once we penetrated the mysteries of the PERT chart, we saw the value of tracking the sensitive interdependencies of tasks through critical paths. As different departments, or even particular individuals, caught up with one another or moved ahead of expected schedules, the critical path would change. Armed with this knowledge, Scot could walk up to any given programmer and say, "The critical path for this game is going right through you at the moment."

Such monitoring helped direct the pressure and motivate the right people, letting others go home and get a good night's sleep. As are all systems, the PERT charts were imperfect. Some people always seemed to be on the critical path, most notably Chad Freeman, the game's lead programmer. All of us here at DreamForge hope that Chad will be able to leave the hospital soon. We already have a respirator set up alongside his desk.

6. PUBLISHER BUY-IN. Our publisher, ASC Games, believed in what we were trying to accomplish and provided valuable input throughout development. They behaved as if they were buying into our vision rather than just purchasing it. For the most part, they took a hands-off approach, and only required changes that they were convinced would significantly improve the quality and salability of the game. Travis Williams, Sanitarium's executive producer, put a lot of heart into the project - not to mention all the cool prerelease games and toys he sent us. We were so grateful, we put his head in the game.

We were very pleased with ASC Games' strong commitment to marketing Sanitarium. The box is a work of art in itself, and the rule book has received praise for its strength and simplicity. The magazine ads are impressive and true to the spirit of our game. One simple act for which the team is eternally grateful: ASC Games' marketing department didn't give away the game plot on the box or in the manual. It's always a relief when you don't see the central mystery of your game printed in big red letters across the back of the game box.

The Sour

While Sanitarium represents a phenomenal success for us here at DreamForge (both professionally and personally), there were some unfortunate stumbling blocks along the way. We keep telling ourselves: that which did not kill us has made us stronger. Never mind the scar tissue.

1. ANIMATIONS. Due to the size of the game, each character had a limited number of animation frames. In many cases, this caused the movement to look stiff and unnatural. Looking back on it, we would have preferred smoother animations with more angles - especially for the main character, Max. If we had taken this into account earlier in the project, we might have had an opportunity to fix it. By the time we realized that eight angles looked a little stiff, it was too late. The limited angles also caused problems for players trying to navigate Max through the levels. He'd often get stuck on corners, then either walk in place like some demented mime or frustrate the player with a litany of, "Can't go that way."

Getting consistent lighting between the characters' standard animations (status quo, walk, use, and so on) and the specific animations requiring interaction with the environment (such as kicking in the school door) was another nightmare. Different artists did these animations months apart, and this was a constant battle from beginning to end. A huge amount of time was spent fixing things as opposed to advancing the project.

2. COMBAT ZONES. The action sequences needed more attention. They were important for guiding the pace of the story, but didn't have the feel that we were after in the end product. The original idea behind these areas was based on one of DreamForge's earlier titles, Veil Of Darkness. It had wonderful combat areas that helped break up the pacing between the puzzles. However, in Sanitarium, multiple factors forced us to water down the combat zones or in some cases cut them altogether. We had originally planned a large combat zone for the Hive level of the game. We'd hoped to make "Grimwall vs. the Hive" one of the most fun and integral combat areas, but it was cut from the game for various reasons.

3. STURM UND DRANG. When you have a company of forty to fifty people, it's impossible to do anything without rubbing someone the wrong way. Sanitarium was put together by a design team that in part came together naturally and in part was hand-picked by Chris Straka, our head of creative development. Individual employees (usually Chris) designed our previous titles. But we decided that team design would be the way to go. While team design has the potential to fracture the unified vision of a game, the various team members ultimately complement each other's interests and goals, lending more depth to the game. This is a nice way of saying, "The team argued a lot, but came up with better solutions as a group."

Difficulties didn't end there. Once Sanitarium became a full-time project, many staff members complained, "Why didn't I get a chance to be on the design team?" Quite a bit of friction was generated because people felt as though they'd been snubbed. Unfortunately, a design team reaches critical mass once it has more than six members. Design teams work in much the same way as clown cars. Too many people cramming themselves into the design would have certainly brought an already volatile process to a grinding halt. At the same time, Sanitarium's personnel power structure created inequalities between staff members that were never meant to happen.

DreamForge learned much about design teams from Sanitarium, and we're having great success with the design team setup in our current projects. We've taken steps to recognize people's desire and initiative, and have parceled out responsibilities to those individuals willing to take up leadership positions. Now, rather than saying, "Why wasn't I included?" everyone moans, "Why did I get into this?" It's great fun.

4. LOAD TIMES. While long level loading times were an accepted design limitation from the beginning of the project, a system that could better manage memory and allow for streaming of more data from the CD could have benefited the game. The tight schedule left such a system impossible to pursue. A more sophisticated memory-management scheme could have allowed for shorter initial loading times, larger levels, and so on.

5. NEW KIDS IN THE CUBE. Sanitarium is a huge game. A lot of people worked on it, meaning additional efforts had to be taken to coordinate and organize everyone's labor. Familiarizing people with the vision of the game from an artistic and design point of view was a real challenge. Sometimes, keeping everyone on the same page seemed to be a chore, especially as new people came onto the project.

A lot of time was spent getting people to understand the status of the project and the direction in which it was headed. A new artist would ask, "Why am I making this one-eyed guy?" and we'd say, "Didn't anyone tell you?" We made the mistake of projecting time schedules as if new hires, following a brief training period, would be as competent as our most experienced people. Some of those experienced people were performing administrative and training tasks, and thus weren't producing much art. Art delivered by our new people often had problems when it went to the programmers. This meant doing things twice, sometimes three times. Projections and flow charts slid downhill, taking into account the flow of asset delivery, identification of problems, correction of problems, and re-implementation of assets. Since art delays were slowing down programming, we tried to use temporary art. This didn't work out because creating useful temporary art for the programmers proved to be nearly as time-consuming as the real thing. And just to throw a little cherry on top of the three-layered cake of delays, we lost two artists during production.

Even though Sanitarium had a longer production time than any previous DreamForge project, there were still some things that we would have liked to tweak or add to make it better. As it was, we went through a lot of crunch periods in order to get things done on time. The sheer amount of artwork required for the game nearly overwhelmed us. Unfortunately, due to the nature of the game, delays in artwork had a snowball effect because the level implementers needed the actual artwork in order to set up their levels.


Article Start Previous Page 2 of 2

Related Jobs

SideFX — Toronto, Ontario, Canada

Senior Houdini Technical Artist (Games) - Updated
Remedy Entertainment
Remedy Entertainment — Espoo, Finland

Senior Software Project Manager
Remedy Entertainment
Remedy Entertainment — Espoo, Finland

Head of Project Management
Remedy Entertainment
Remedy Entertainment — Espoo, Finland

Outsourcing Manager

Loading Comments

loader image