Features

Postmortem: DreamForge's Sanitarium

Sanitarium is an original adventure game filled with madness, delusion, and personal anguish. The same can be said for the development cycle. Sanitarium was developed by DreamForge Intertainment Inc., set in the heart of Greensburg, Pennsylvania. DreamForge employs about 45 people working on three to four projects at a time. We had previously developed an adventure game entitled Chronomaster, and our staff has a strong background in the development of computer RPGs. Sanitarium was a landmark game for us, primarily because the project originated in-house, and we had so much of ourselves invested in it.

	Figure 1. The original Sanitarium design team: (left to right) Eric Rice, Jason Johnson, Mike Nicholson, Tracy Smith, Chad Freeman, Chris Straka, and Scot Noel. (The author is off to the side, chasing squirrels.)

To maintain a consistent flow of game play and story, Chris had to balance the amount of dialogue that occurred during any one non-player character interaction with how NPCs were distributed throughout the levels. During beta testing, testers complained that many of the dialogue interactions were too long and that the keyword-based interaction trees were sometimes too complex. In addition, characters could end up talking about subjects that seemed strangely out of order, jumping between disparate topics like a bad news segment. Since a lot of us here tend to work that way anyway, we didn't find it too confusing.

Travis Williams, our executive producer, insisted that we trim some of the encounters and link many keywords together to prevent confusion. A lot of the original dialogue was purely atmospheric and time-consuming for the player to wade through in search of real answers. The final version had an improved narrative flow and better pacing through a balance of dialogue and action.

We were constantly concerned that the emotional content of the game would be lost in the medium. Our goal was to give the player the creeps. We took the time to think out what we wanted the player to feel on each level, what message and mood we wanted to get across. Our efforts in creating a cohesive atmosphere included not just a good storyline, but an immersive audio experience as well.

Sanitarium was DreamForge's first product to utilize stereo sound. The point-sourced sound system made for very natural-sounding effects within each level. But technology alone couldn't make the sound great without the right people to take advantage of it. Steve Bennet, our music and sound effects composer for the project, did some awesome work with the soundtrack. Working from lists generated by the design team, Steve searched a huge sound CD library for the necessary effects. Then he processed the sounds using Cool Edit Pro and Sound Forge, sometimes working over a sound effect multiple times to match the atmosphere of the level. The moody music he added, entirely original compositions created on a Kurzweil keyboard, brought a definite style to the levels that enhanced the creepy atmosphere.

Nonetheless, the voice acting should have been better. It's difficult to compete with other developers who have access to name actors and meet everyone's expectations. This isn't an excuse, but a simple matter of economics. Would we have liked to have, say, James Earl Jones for the voice of Morgan? Of course. But with 80 NPCs and a limited budget for voice acting, big-name actors were an impossibility.

The final hurdle in the design process came from our publisher. Late in the project, during beta testing, ASC Games approached us with a significant design change. Dave Klein, the president of ASC Games, was wholeheartedly behind the project and loved our game. But... "Could you make it easier to play?" He explained that ASC Games wanted Sanitarium to have mass-market appeal and to be accessible to everyone, not just adventure game players.

Our faces turned Barney-purple with indignation. We felt that such a move would both compromise the game's sophistication and seriously jeopardize our completion of the project. We were a few weeks away from the final ship date and being asked to undergo a major revision of our basic approach to the game design. Also, we were stubborn.

Travis Williams came out to discuss what could be done and what couldn't be done in a reasonable amount of time. Our original approach to game play could be summed up as, "You're an adventure gamer. Figure it out." This new way of thinking forced us to ask hard questions, such as, "Where in the game is this information conveyed to the player?" In many cases, it simply wasn't. This led to a lot of easy fixes - having the main character utter a strategically placed bit of dialogue or even altering existing dialogue to help the player make puzzle connections. When this couldn't be done without a metric ton of contrivance, we adjusted the puzzles to be more user-friendly.

Admittedly, the changes made Sanitarium focus more on entertainment than frustration. Players aren't perpetually stuck on difficult puzzles, so they participate in the story at a consistent pace and are able to enjoy it. Even the hardcore adventure game players that we initially targeted were satisfied by the balance of puzzle difficulty and richness of story.

The Artists' Tale

For all the designers' concentration on Sanitarium's story, many of the game elements were conceived in artistic terms. We knew that the visual atmosphere of the game would be extremely important to the game play. The art conveyed the emotions that the player would feel, as well as the player character's state of mind. Because it's all about emotions and states of mind, Sanitarium is a very art-intensive game. Thus, early in the process, the design team spent a lot of time determining the correct look for each part of the game.

One of the first things that we did was to gather reference material. We went on field trips to cemeteries, took pictures of St. Vincent's Cathedral, and raided local libraries. Eric Rice even captured a picture of a haunted gravestone on one of our cemetery photo shoots.

Back in the office, the heavy-duty work was getting underway. From concept sketches to full 3D models to touched-up game art, we strove to maintain that disturbing, realistic visual style as much as possible.

One of the first hurdles was an accurate isometric camera view. Finding a way to render six by four screen widths of landscape from twenty-four viewpoints and seam the shots together without any perspective warping was daunting. Tracy Smith worked out the bugs on this one. The final solution was to pull the cameras back to what would be the equivalent of viewing a city block with the Hubble telescope.

The biggest bottleneck that occurred during Sanitarium's development came during the post-production of the art. We call the post-production department "5D," not because they exist on some H.P. Lovecraft penta-dimensional plane, but because they work on a combination of 3D and 2D art. Once materials such as screens, characters, and animations poured smoothly out of 3D like good scotch, they had to go through the 5D twelve-step program before they would be ready for programming.

For the game art, Jason Johnson coordinated DreamForge's art staff as they used 3D Studio MAX to make the designers' vision a reality. The artists retouched the 3D background in Photoshop, then generated a temporary palette. Still barriers were clipped in true color, then squeezed into the temporary palette; coordinates were determined. 3D animations underwent alterations, retouches, and special effects as necessary. The artists then composited the animations into the retouched background. A final palette was generated and applied to all artwork for any given level. It was tough to create a palette that could support the massive environments and all the NPCs. The enormous number of colors used in the game was a nightmare for our post-production team. Using DeBabelizer Pro, these guys had to reduce entire levels of true-color renders to less than 230 colors. At that point, the original artists would walk over and ask, "Hey, what did you do to my level?" or management would say, "Is it gonna look like that when it's done?"

The steps continued. Still barriers in the temporary palette were reformatted into the new palette. Animations were then clipped and coordinates determined. Free-walking NPCs were retouched and clipped. Cursors, icons, and inventory were retouched and clipped. The player characters were put into a 24-color palette, retouched, and clipped. This was mind-numbing work at times. Even as brains turned to protein-rich pudding and limbs lost all feeling, the game art was taking shape.

All of this took anywhere from 50 to 350 man-hours per level. It was a demanding set of tasks requiring not only technical skill but the experience of having worked on games before and knowing how to deliver game art to a programming team in a perfectly usable form. Problems arose mainly due to inexperience.

The final look and quality of the levels and animations in Sanitarium is a testament to some very determined artists who stayed late, worked weekends, and apologized when they were too sick to crawl to their desks.

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.

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.

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.

join | contact us | advertise | write | my profile
news | features | companies | jobs | resumes | education | product guide | projects | store



Copyright © 2003 CMP Media LLC

privacy policy | terms of service