Replay back to the end of 1998. Y2K was going to eat all of our machines unless every programmer who knew what the acronym COBOL stood for was working on converting all databases to four-digit year formats. Most gamers who could not program were too busy to care because we were playing Starcraft and Half-Life to an obsessive degree. BioWare had just finished a game called Baldur's Gate, and we came back from our Christmas vacations in January 1999, slightly frazzled but assigned to another project: Neverwinter Nights.

Neverwinter Nights (NWN) was supposed to be the best multiplayer Dungeons and Dragons (D&D) role-playing game (RPG) ever made. Not only were we going to tell a story of our own creation, but we were going to enable others to tell their stories, on their own servers. Dungeon Masters (DMs) could log in to a server and help (or hinder) players to their heart's content. Designers could translate their D&D modules from pen and paper via a toolset that we provided for them. It sounded pretty cool to us -- then we realized that we had the task of making it! It really started to sink in when other developers where telling us that they couldn't wait to play it and that they were glad that they weren't developing it.

Although Baldur's Gate was a good single-player RPG, we did a number of things very poorly for the purpose of accomplishing the vast and ambitious goals of Neverwinter Nights. The major issues that we are going to address (both the good and the bad) are the design for user-created content, design limitations imposed by the multiplayer focus of the game, the staffing requirements required to fulfill this vision, developing the game for multiple platforms simultaneously, and reputation systems. It is our hope that you will be able to learn something from what we did right and the problems that we ran into.

User-Created Content

	Stuart Anderson's Adventure Construction Set

At the core of every game there are a few core requirements that dictate the form of the entire design. Sometimes these are dictated by technology, sometimes by user interface design and game play. In the case of Neverwinter Nights, it was the vision. The vision was to build a game where the user-created content was just as important as the content provided by the game creators. Somehow we needed to get a significant percentage of our users creating custom content. We were sure that the desire was there, it seemed that every fan we talked to had some old pen and paper Dungeons & Dragons modules scribbled onto graph paper collecting dust in their bookshelves. We just needed a system that allowed the fans to dust off those old modules and translate them into a format readable by Neverwinter Nights.

Neverwinter Nights certainly wasn't the first game to try this. Stuart Smith's Adventure Construction Set released by Electronic Arts in 1987 was the first commercial attempt at this. This was a complete RPG construction set. You had the ability to edit maps, created custom graphics, edit creatures and items and it even came with a pre-made mini adventure. The biggest problem with this product was that once you built an adventure you only had your limited circle of friends to share with. If you were lucky, you had a modem and had access to a bulletin board system where you could download a handful of files.

	SSI's AD&D Unlimited Adventures

Neverwinter Nights wasn't even the first attempt at RPG construction set for D&D. In 1993, SSI released Unlimited Adventures, using the classic engine and content from their Gold Box series of AD&D games. Like Adventure Construction Set, this was a classic case of an idea that was ahead of its time. It wasn't until the wide spread use of the Internet that a single user could have access to the entire pool of user-created adventures.

We knew that almost the entire user-created content for other games was created by a fraction of a percent of the user base. This presented a real problem. What we really wanted was a role-playing game creation toolset that "even your grandma could use."

When we were first considering the creation of Neverwinter Nights, there was a thriving mod (user modification) community for games such as Quake and later Halflife. While many of these mods were of professional quality, the numbers that were being created didn't justify the effort that creating a full RPG construction tool would entail. It seemed that many of the users that would have liked to built mods for Quake and Halflife just didn't have the technical skills required. On the other hand, games like Starcraft had a thriving custom map community. Some how we needed to take the ability to create 3D levels like in Quake, add to it all the tools needed to create a RPG adventure and still keep the system within the reach of users capable of creating maps in Starcraft.

After some experimentation with arbitrary mesh systems and height field manipulation, we decided to provide a system that used 3D tiles. The major advantage of the system was the simplicity of area creation. Users could simply select a terrain brush and paint rivers, bridges, corridors and roads. If you are expecting a large number of end users to use the tool, then they have to be able to see concrete results the first time that they try it or most of them will give up at that point.

Another advantage of using tiles was that the areas could be represented with only a minimum of data. This was also extremely important. One of the key game play features was hosting an adventure for other players to connect to. What we didn't want was a long delay while the newly connected client downloaded a massive file containing all the art for the area. With a tile system we could send a full area description with just a few kilobytes of data.

The major limitation of any tile system is that there are never enough tiles. There is always just one more special tile or combination of tiles that the end user wants. This is also true for creature and item models too. Since the creation of 3D art is beyond the skills of the majority of the toolset users, we did not include any direct ability for the users to modify the core art resources. We did realize that there would still be a few brave souls who would want to create custom 3D art and other types of game modifications.

Sometimes, the end users can be too clever for their own good (and ours too). When we released Throne of Bhaal, the expansion pack for Baldur's Gate II, there was a popular rule tweak modification in circulation. Unfortunately the creator of this modification released a version during the weeks between our gold candidate and the time it arrived on the store shelves. The problem was that our install package for the expansion pack did not overwrite files with newer time stamps. This caused the expansion pack install program to fail on every user that had that particular modification installed.

When we were designing Neverwinter Nights, we planned for a method of allowing end users to make significant modifications with out breaking the core game or causing the game to crash when non-modified clients tried to join a modified server. The result was the 'hak pak' file (remarkably named because the file extension is .hak). This file would contain all of the non-canonical files (whether introduced by the end-user or modified versions of our files) and would be associated with only specific adventure modules. If a client tried to connect to a server running a module that required a hak pak, the client would be informed and gracefully disconnected.

On the plus side, the hak pak system did accomplish all of these goals. The major problem with the hak pak system was in the way in which art resources are added into Neverwinter. To reduce network bandwidth, art assets were generally referenced by index numbers. For example, the appearance of a creature was dictated by its appearance id. This referred to a row in a table that contained all appearance-related data. This included the name of the 3D model, sound information, movement speed, personal space etc. To create a new custom creature model, a new entry had to be added this table. Storing a custom creature in a hak pak was not a problem since the hak pak also stored a modified version of the appearance table. Unfortunately, as we released more creature appearances or as users tried to merge hak paks together, conflicts in the table row numbers were created. In the end we had to release a hak pak merging utility to rectify this situation. If we could do it all over again, we would consider building a system where all information was encapsulated in a single info file and creatures store the name of the file instead of an index. The server could broadcast the correspondence of new creatures to indices as the initial area is being loaded so that each client would know how to link the hak pak resources to the server's indices.

Another consequence of officially supporting user created content was the amount of testing required. In a normal game you only have to test the content of the actual released game content. If you are officially supporting user created content, you now have the problem of an unlimited testing set. For example, since we needed the pathfinding information to be integrated into the tiles, we had to deal with the fact that not only are all of combinations of tiles too numerous to test, you also have to worry about the users placing objects over key pathfinding locations. In the case of Neverwinter Nights, there was also additional content and features that were not used in the official campaign that also needed significant testing.