Gamasutra: The Art & Business of Making Gamesspacer
Nihilistic Software's Vampire: The Masquerade -- Redemption
View All     RSS
November 15, 2018
arrowPress Releases
November 15, 2018
Games Press
View All     RSS
  • Editor-In-Chief:
    Kris Graft
  • Editor:
    Alex Wawro
  • Contributors:
    Chris Kerr
    Alissa McAloon
    Emma Kidwell
    Bryant Francis
    Katherine Cross
  • Advertising:
    Libby Kruse






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


 

Nihilistic Software's Vampire: The Masquerade -- Redemption


August 2, 2000 Article Start Previous Page 2 of 3 Next
 

What Went Right

1. Letting the artists and designers pick their tools.
With such a small team and tight budget, boosting the team's efficiency was our primary focus. If bad tools or art paths slowed down progress in the art or level design departments, we would have no chance of hitting our milestones. When we started to map the development project, the programmers gravitated toward using a package such as 3D Studio Max for both art and level design. Our argument was that doing everything in a single package would increase portability of assets between levels and art, and save the company money by licensing a single, relatively inexpensive tool. Thankfully, however, our leads in these areas strongly objected to this plan. They argued for allowing each department to use the tools that allowed them to do their work most efficiently. This single decision probably accounted for more time saved than any other.

The level designers cited QERadiant as their tool of choice, since most of them had previously done work with id Software on Quake mission packs. id was generous in allowing us to license the QERadiant source code and modify it to make a tool customized to our 3D RPG environments. Because QERadiant was a finished, functional tool even before we wrote our own export module, the level designers were able to create levels for the game immediately, even before an engine existed. And since QERadiant stores its data in generic files that store brush positions, the levels were easily tweaked and re-exported as the engine began to take shape. If the level designers had spent the first six months of the project waiting for the programmers to create a level editing tool or learning how to create levels in a 3D art tool, we would not have been able to complete the more than 100 level environments in 24 months with just three designers.

Locations included both interior and exterior cityscapes, allowing dramatic situations such as this battle atop a clock tower in medieval Prague.

On the art side, lead artist Maarten Kraaijvanger lobbied hard for the adoption of Alias|Wavefront tools for 3D art. We tried to convince him that a less expensive tool would work just as well, but in the end we decided to allow the art department to use what they felt would be the most efficient tool for the job. Since Maya was just being released for Windows NT at that time, the costs of using that toolset were not as great as we feared, and it allowed the artists the produce an incredible number of 3D art assets for the project. During the 24 months of the project, an art department of four people produced nearly 1,500 textured models, a mind-boggling figure using any tool.

2. Small team, one project, one room.
When we started Nihilistic, we had a theory that a small number of highly experienced developers would be able to produce a title more efficiently than a larger team with fewer battle scars. In my experience, successfully delivering a game is less about what you do and more about what you choose not to do. Most games that ship late do so because the development team went down one or more "blind alleys" -- development ideas or strategies that for whatever reason didn't pan out, and the work done in that direction is lost. As a small team on a tight budget, we could not afford to lose valuable time on these diversions. Experienced team members have the wisdom to look down a particular path and recognize when it's a likely dead end.

Developers that have shipped commercial titles also know when "enough is enough," so to speak. There is a rampant problem in this industry of feature creep, when games end up trying to be all things to all people, and wind up taking four years to complete. Seasoned developers know that shipping a title is all about compromise. Any title that goes out the door could always be "just a little better" and developers, ever the perfectionists, are never fully satisfied with the box on the shelf. Creating a successful game that ships on time requires the discipline to draw that line and move on to the next challenge.

We also knew that we wanted an office environment where all the team members were in a single room without any walls, doors, or offices whatsoever. This didn't really seem like a radical decision -- many of us got our start working for teams that operated like this -- but it seems like these sorts of companies are becoming less and less common in today's industry. My first game job was working at Parallax (now Volition) software. We were eight people sitting along one wall of a narrow office space in Champaign, Ill. Even the original Dark Forces development team was sequestered in a one-room studio in a building separate from most of the other LucasArts teams. This type of environment doesn't just foster, but rather forces communication between all parts of the team. For instance, a programmer can overhear a discussion between two artists about how to proceed with something and be able to jump in with an answer that will save the project days or months of work. This sort of thing happens on a daily basis; artists correct missteps by the technology team before they are made, a level designer can immediately show a bug to a programmer, and so on. Each of these incidents represents hours or days of project time saved. In an office environment with walls and doors, most of these situations would go unnoticed or unaddressed.

3. Using Java as a scripting engine.
We knew from the start that allowing the user community to edit the game was an important part of the design. After working in the first-person action-game market, we saw the benefits of supporting the user community and wanted to carry this idea over into role-playing games, where it is not the norm. A built-in scripting system makes a game engine much more extendable by fans. In Jedi Knight, we created our own customized game language called COG. Creating COG took a lot of effort from the development team; several months of work went into creating the compiler, testing the generated code, and implementing the run-time kernel used to execute the scripts. The end result was worth it, but it cost a lot in terms of time and resources to pull it off (for more about COG, see my article, "Adding Languages to Game Engines," September 1997).

The ambitious design included parties of up to four 3D characters, each with interchangeable weapons and armor.

When starting Vampire, we looked for ways to incorporate a scripting engine more easily than creating our own from scratch yet again. There were several scripting systems we examined and tested. At about that time, another game development company, Rebel Boat Rocker software, was getting a lot of attention for its use of Java technology. After exchanging a few e-mails with lead programmer Billy Zelsnak, we decided to give Java a try. Up to this point I knew very little of Java, and had largely dismissed it as a language suitable only for making icons dance on a web page and the like.

A set of four interactive 3D head models at the bottom of the screen are skinned and animated in real time to give lifelike status for each party member.

After a crash course in Java, we did a few simple tests incorporating it into our game engine. It passed each one with flying colors. In a matter of a few weeks, we had solved the major challenges involved in interfacing a standard, freely distributable Java virtual machine to our 3D RPG engine. From that point on, the only maintenance required was to add new native functions to the scripting language, which we did whenever we added new engine functionality that we wanted exposed to the script writers. We also trained several designers in the use of the scripting language, and they started creating the hundreds of small scripts that would eventually drive the storyline of the game.

Ever since those initial tests, I kept waiting for the other shoe to drop, so to speak. I expected to come to work one day and find out that the Java thread was chewing up 100MB of RAM or eating 50 percent of the CPU time, but amazingly, the system was trouble-free throughout development and never became a significant resource drain. If for some reason we had hit a dead end with the Java system late in the project, it would have easily taken three to four months to get back on track using a different scripting technology. In the end, the gamble paid off. We saved months of programmer time that would have otherwise been devoted to creating a scripting environment, and the result was a system significantly more efficient and robust than any we could have created ourselves.

All of the more than 100 3D characters, such as Lucretia, a Setite priestess, were modeled and animated by hand by a team of four artists using Maya.

4. Storyteller mode.
Throughout the project, the design slowly took shape through a series of meetings that involved the entire staff. Each new design element was presented to the group and subjected to a (sometimes heated) discussion. This process of open discussion and free exchange of ideas resulted in a lot of the most interesting design aspects of the game.

It was in one of our earliest design meetings that we came up with the idea of developing the multiplayer aspect of the game not as a typical deathmatch or cooperative system, but rather to create a "storyteller" or "dungeon-master" system. The idea was inspired by the venerable text-based multi-user dungeon (MUD) games that date from a calmer time in the history of the Internet. Many of us at Nihilistic had played MUDs in college, often to the detriment of our studies. One thing that made MUDs so appealing was the ability for "wizards," high-ranking users of the MUDs, to manipulate the game environment and create virtual adventures for the players in real time. The Vampire license from White Wolf emphasizes the role of the "storyteller," or moderator, so we felt the time was right to take this style of play out of the college computer lab and into a commercial RPG.

Implementing the storyteller system turned out to be fairly simple from a technology standpoint. Most of the basic functionality for a storyteller game is identical to what would be required in a traditional client/server multiplayer game. The added cost was mostly in the area of design and the user interface. It took a bit of experimentation and redesign to arrive at an interface that was powerful enough to run games as a storyteller without being overly confusing to the novice player. The UI work included new interface panels with lists of objects, actors, and other resources, and a few buttons to manipulate the selected resources. Our overall design goal for the user interface was to ensure that important functionality was accessible using only the mouse, and all keyboard functionality represented only "advanced" controls such as hotkeys and shortcuts. Even though the storyteller system is something used primarily by advanced players, we wanted to preserve this design goal, which meant quite a bit of extra UI work to make a mouse-driven interface powerful enough to drive a storyteller game.

In the end, the storyteller feature ended up being one of the gems of the game design, and resonated with both the press and gamers alike. Activision made good use of the feature in their PR and marketing campaigns, and we hope the expandability and storyteller aspects of the game will give the game an increased shelf life.

5. Using experienced contractors.
One problem with our strategy of using a small core team is that we couldn't possibly cover all the aspects of designing a commercial game with just 12 people. Instead, we relied heavily on external contractors for certain key aspects of the game.

Sound was one area where we made use of external talent. Our colleagues from LucasArts referred Nick Peck to us, based on his excellent work on Tim Schafer's Grim Fandango. Nick ended up not only supplying us with sound effects, but also working on some of the additional voice recording and ambient loops. For our music, we teamed up with Kevin Manthei who scored the Dark Ages portion of the game, and with Youth Engine, a local duo, for the modern-day tracks.

Even in the conceptual stages, we used external artists to help us sketch and visualize the game. Peter Chan was the lead conceptual artist for Jedi Knight and had subsequently become an independent contractor. His work in the first months of the project was key in establishing the look of the game's environments. We also worked with Patrick Lambert for character concepts and he delivered incredibly detailed full-color drawings that really brought the characters to life for the modelers and animators.

Perhaps the most critical external relationship was with Oholoko, a small startup spun off from Cyclone Studios. We hired them to do our cinematic sequences that introduce the story and provide the endings. While starting the project, we met with several firms specializing in computer animation, but pretty much across the board their rates were well beyond our budgets for that part of the game. It seems that the high demand for computer animation from movies and television has driven the larger firms' prices beyond the reach of typical game budgets. By working with a smaller, less established company, we were able to get more bang for our buck in our cinematics, and the results proved to be of the highest quality.


Article Start Previous Page 2 of 3 Next

Related Jobs

Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States
[11.15.18]

Mid/Senior Multiplayer Programmer
YAGER Development GmbH
YAGER Development GmbH — Berlin, Germany
[11.15.18]

Senior Backend Engineer (f/m)
NEXON M
NEXON M — Emeryville, California, United States
[11.14.18]

Software Engineer
NEXON M
NEXON M — Emeryville, CA, California, United States
[11.14.18]

Data Engineer





Loading Comments

loader image