If one looks at comments made by players at Neverwinter Connections and other Neverwinter Nights (NWN) community sites, it shows that multiplayer sessions featuring a live DM regularly get outstanding feedback. While excellent single-player modules are out there, and not all multiplayer sessions are successes, people respond well to the ability to interact with other player characters (PCs) and have a DM shape the story around players’ actions. This adds a whole new dimension to the playing experience and can make even a basic module come alive in new and inventive ways.

This article is intended to give builders some ideas and tools to create modules that can be DM’d effectively (what we like to call “DM-friendly.”) In many ways, design principles for building a DM-friendly module are similar to ones for module building in general, just with the added perspective of planning for player-DM interaction. The principles and building techniques described below should work equally well for both traditional NWN modules and the new NWN2. We hope that exposure to DM-friendly building principles will help increase the number of modules created with the multiplayer/DM experience in mind. In addition, as a community service, the DMFI offers voluntary review and certification of modules, which are then included on NWVault‘s official DM-Friendly Module list.

Note: this article is not intended to be a full-fledged tutorial on DMing practices or the toolset; however, links to helpful resources are provided at the end of the article.

In its final state, a module’s documentation, in-game tools, and in-game feedback mechanisms allow it to be run effectively by a DM. However, integrating storytelling and scripting while allowing DMs to be flexible in running the module can be a complicated task. Where to start?

Documenting to yourself the module's organization and flow before and during its creation is essential. How does it start, and from there, where can the players be expected to go at each stage? Work out the key elements you want to include (some of them may be conditional) and then determine your plot locations, NPCs and objects. You have now created your module’s design document - which, with some minor modifications, can easily be turned into the module’s DM guide. Many builders prefer to do a full "outline" version of a module on paper so that the areas, major NPCs, and major events are all clearly defined before the toolset is even touched. The original outline of your module isn't necessarily set in stone, but should give you very good idea of the scope of the module and its required elements, thereby acting as a template for the building phase. For those who are looking for ideas on developing design documents/DM guides, the DMFI article on creating DM-friendly documentation may be of help.

When looking at your design document, we suggest trying to incorporate the DM’s perspective - think of how you would want to handle each scenario if you were the DM. Clear instructions for how the DM can advance the plot should flow naturally as you outline the module’s storyline. One technique is to start by using short bullet points (e.g. "after the party leaves the meeting with the wizard, teleport them to the edge of the Gray Waste") in your outline, which will end up being a full DM Guide by the time you’re done.

The major difference between single-player and DM’d multiplayer modules is the adaptability of the latter, which allows modules to be truly non-linear when played. When looking at plot situations, therefore, you can think of suggestions for how the DM could add to the default plot without breaking it, or respond to players who want to go in a different direction than a linear main plot. This type of planning will help leverage the abilities of a live DM, someone who does not necessarily have to follow a set outline of how the story must flow.

For the most part, DM-friendly modules are a subset of multiplayer modules. Most designs (including almost every official BioWare module) adhere to a model more appropriate for single-player modules, one that has a linear story structure with programming and conversations that are easier for the builder to test. However, in any multiplayer module, especially one intended for DM use, we suggest builders take some additional design elements into consideration when planning their module. For example, try to make the story so that it doesn't revolve around a single player's life or background. This isn't a necessity, but allows for more equal participation by all players. Also, to encourage role-playing, give players interesting choices and experiences which might bring out their differences. In other words, look for situations which will encourage party interaction and bring out the different PCs’ strengths and weaknesses.

The primary decision for a builder in making a DM-friendly module will be the level of scripting involved. Possibilities range from creating a fully scripted module that requires no DM intervention, a type which most builders are familiar with, to doing a DM-only module with minimal (if any) custom scripting. This decision will affect many subsequent choices, so a builder should get a clear idea of what he or she prefers early on. The module’s design document should help guide you, since it should include all major events and will indicate how they can/should be resolved, either via scripting or "live" DM action.

If you want your module to be playable in multiplayer without a DM, i.e. be fully scripted, but still have a DM be able to plug in easily, that is quite possible, but should be planned for from the beginning. Many multiplayer modules' plots will simply "break" if the DM tries to influence things in-game. We’ll discuss techniques later on for avoiding this.

Here are some observations on the types of DM-friendly modules and their advantages/disadvantages:

Multiplayer/no DM required: gives the most flexibility to the end-user, since a party can go through it without needing a DM present. Requires the most scripting, including checking/error-trapping for multiple player interaction in every conversation and script affecting PCs. DM interaction in each encounter should be specifically addressed in the accompanying docs, so the DM won't break the plot. Having a DM "plot wand" or similar tool is usually crucial in order to enable the DM to control and reset plot variables as needed.

DM required, but partially scripted: the DM will need to plan to participate actively throughout the module, rather than just picking and choosing moments, but scripting can help handle more complicated events and encounters; at least some NPCs have scripted conversations.

DM-only "soundstage": in its pure form, the DM controls all NPC interaction and events. Can be a powerful experience and easily accomplished with smaller-scale modules, although it starts becoming difficult with more complicated events and a greater number of NPCs. A scripted DM "plot wand" could also be used in such a setup, in order to trigger events.

We suggest first seeing what you want to accomplish with the module and tailoring the scripting level to that. If you have very limited scripting ability, then plan for a DM-only module, but don't rule out employing third-party scripts from NWVault or using Lilac Soul's script generator to accomplish specific tasks. One of the great things about using the DMFI wand package in a module is that it can make even a bare-bones DM-only module rich with possibilities, due to all of the FX and other in-game manipulation abilities.

DM-Centric Design and DM-Only Modules

Before turning to scripted modules, it’s useful to examine the principles behind building DM-only modules, which by definition have a DM-centric design. With all of the action falling to the DM, these modules both feel and play more like published pen-and-paper modules. For those module creators who prefer to offer players the chance to run through a module without a DM by use of scripting, please note that most of what is discussed below also applies to how DMs can effectively operate in a scripted module.

Although multiple DMs (and parties) are possible in NWN, it's still best to plan the module’s “minimum specs” for the usual base requirement: a single DM working with a single party. One important design fundamental is that DM attention can only be focused in one area at a time, so the module author should not require the DM to deal with multiple actions occurring at the same time, particularly not in different areas. That said, with a DM in full control the plot is essentially unbreakable and the DM can adapt in-game events at will to player actions. This adaptability, along with the full interactivity possible with with DM’d NPCs, is what distinguishes DM-driven modules. When designing such a module, play to those strengths and keep in mind your ability to use non-linear plots and events, while keeping in mind the constraint of DMs not being able to be two places at once.

Builders’ tasks in these types of modules will be largely focused on creating areas, NPCs, and "props" available to the DM, rather than scripting:

Areas: Area design will be largely dependent on the module’s needs, rather than taking specific DM requirements into consideration. That said, for DM-only modules, keep in mind that an area may be re-used, perhaps in an unexpected way, so try to avoid having mandatory scripted effects fire off (for example in the area OnEnter event handler) unless you really need it. One thing you can use for unique descriptions in an area are "flavor text" triggers which fire on each PC only once; that avoids the area re-use problem but still adds smells, sounds, etc. to an area without the DM having to type out all the descriptions. Making each area "realistic" in terms of design and included NPCs and objects will increase re-use possibilities and avoid boxing the DM into a corner if the plot takes an unexpected turn. While this may seem like common sense, many scripted modules have very specialized areas reached in a linear fashion. Incorporating "transition" or "rest" type areas, where no plot events are supposed to happen, also helps play by giving the party a chance to discuss the plot and interact without immediate threats, while letting the DM set up things in-game for the next set of events. Having some areas generically named and built - “Forest,” “Road,” “Home Interior” and the like - will also greatly help the DM's flexibility, in case the party ventures off the beaten path.

NPCs: When placed in-game, suggest using "named" NPCs with unique clothing and items rather than generic ones wherever possible. Notes on their personality, motivations, and possible actions should be included in the DM guide; one variant, mostly used on persistent worlds, is to put a “no-drop” book item on NPCs containing their DM notes, so notes are accessible to all DMs in-game. Putting down just a few words describing the NPCs' uniqueness will allow a DM to slip into character easily. For DMs, this is easier to manage in-game than using generically-named "commoners" or the like, unless you're using a heavily populated area and prefer to use scripted commoner spawners to flesh it out. In addition to placed NPCs, think of some different types you might want to have available in the module palette, even if not central to the plot. If you don't want to name them beforehand, suggest you name them by category - "shopkeeper", "priest" etc. - then either give out their names via roleplay or use a SetName DM tool to give them names in-game. This practice can work very well when improvising introductions of new characters into the module; one might be a relative of someone the party has already met, for example, and then could be named accordingly.

"Props": These are any kind of items that enhance the setting or advance the plot. Sealed letters, official notices, a bloody scrap of fabric, an unusual gem - all of these kinds of things significantly add to the immersion factor of your module. Build items with custom names, appearances, and descriptions and work them into the module via placement in areas and with NPCs. You may also want to create a few generic items, such as "a note" or "a key", which can serve as basic props fleshed out by DM description in unexpected situations. While custom item creation should be driven by the plot, it's nice to throw in some additional items either as "red herrings" to distract players, or to enhance the perception of realism. Placeables fall into this category as well, especially signs and other information-sharing ones. The more you add, without going too crazy, the less generic your areas and NPCs will be.

There is something of a natural tension between scripting and DMing - scripting by definition takes control away from a live DM, although at the same time it can enhance their ability to manage a scenario. If a builder takes into account how a DM can operate within a scripted module from the beginning, this tension can be minimized. However, if you are planning a heavily-scripted module, or want to convert one to DM use that‘s already made, it may be worth doing a separate stripped-down version for DM‘s; it takes much less effort to delete features than to redo them. It’s possible to do a heavily-scripted module that is DM-friendly by incorporating tools like plot wands, which we will discuss below, but as the amount of scripted events and reactions goes up, the more unwieldy it becomes to factor a DM into the plot. If elaborate cutscenes and sophisticated programmed NPCs are a significant part of the player’s experience in the module, then a DM is going to have relatively little to do in any case. A stripped-down version of the module specifically intended for DM use, where most NPC conversations are left unscripted and a plot wand included to trigger key scripted events/effects, may be a better way to go.

Assume that in multiplayer you will be dealing with a single party that stays (for the most part) together. Most NPC conversations can then be scripted to set a variable flag on the NPC when they have been talked to by any party member, and check for this whenever the conversation is triggered again. This sounds like a simple procedure, but is not always implemented, and leaving it out can cause a lot of headaches if the same quest or rewards are given out multiple times as a result, not to mention breaking immersion. To minimize the work, you can word the conversation generically to seem logical with any party member. If you want to get fancier, also set a variable on each PC spoken with, and have a script check for that in the initial conversation node, to get a more detailed/realistic reaction. This makes conversations geometrically more complicated/labor-intensive, but may be worth it, depending on the NPC.

Always set plot variables on the module or into a database, rather than on individual PCs. This is important in multiplayer for a number of reasons - not least because an individual player may disappear for real life reasons - and also will allow for a DM "plot wand" to function easily. NPC conversations, where relevant, should always test for module plot state variables, as well as whether party members have been talked with previously.

We strongly suggest including a module-specific plot tool - “plot wand“ - for the DM, if you have multiple scripted events that advance the plot state. Such a wand (book, whatever item you like) should ideally be scripted to be usable only by a DM and placed automatically in any entering DM's inventory (via the OnModuleEnter event) if they don't already have it. The wand's conversation options should be structured to allow a DM to activate scripts that set (or reset) each plot state variable. If there are a lot of side quests in the module, it may not be necessary or desirable to put everything into the wand, although it shouldn't be too hard to structure the conversation to handle this. At minimum, a builder should put all of the central plot variable states into the wand options. This is the single most useful DM tool in a fully scripted module, because it allows a DM to possess any plot-relevant NPC, at any time; otherwise, breaking the plot could easily occur due to not having a plot-advancing scripted NPC conversation fire off. In contrast, having such a tool can open the module to the possibilities of full DM interaction. Technically, a DM could use the console interface to trigger scripts and set variables, but a plot wand is a much simpler and more useful tool to employ in-game.

Keeping a party together is usually a useful goal and will also help ensure the plot does not break. In NWN2, the world map system should enable a party to all move together from area to area automatically. In NWN, if you want to force the entire party to move together between areas, the easy solution is to use a trigger which checks for the presence of all party members within a certain distance before a transition fires. (This is very similar to the old Baldur's Gate "you must assemble your party before venturing forth.") This guarantees that a party won't split over a transition into an important plot area, for example. The trigger can also move all of the party members at the same time, if desired. One example of such a system can be found on NWVault.

We’ll now move on to what builders are probably most interested in: additional proven techniques for making your module work better in a multiplayer/DM’d session. We’ll divide them up into Areas, NPCs, Objects, and Module Design/Scripting. Please note that these build on the suggestions given in the “DM-Centric Design” section above.

Add an out-of-character (OOC) start area for pre- and post-game discussion with players. This allows DMs and players to handle administrative matters and engage in general discussion, feedback, etc. without disrupting the game flow. An OOC “Starting Merchant” that is available for new characters can be very useful as well, allowing the builder to control what equipment is made available and also allowing for player-driven customization via their initial purchases; to help this customization, include different custom clothing, armor, etc. designs in the store’s inventory. A “Trash Chest” can also be useful, by letting PCs get rid of any useless inventory brought into the module.

Consider having at least one separate OOC DM-only area if you have multiple DMs (for meeting purposes) or if you want to place creatures in advance into the module for easy retrieval via the Chooser. This can allow DMs to more easily find and move creatures, as well as adjust faction reactions using DMFI or other wands. For the latter function, include in your area a copy of each creature with a custom faction. (The “DMFI Custom Encounter” area is included with the DMFI wand package.)

Reusability of areas is important and will be more so in NWN2, helping reduce module file and walkmesh size. Some generic encounters in the palette to use in reusable areas could also be helpful.

Keep in mind that each area can correspond to a “scene” and is not necessarily a fixed location. For example, if the PCs start in a village, that can be the default version of the area. If they later return to it during a festival populated by many more NPCs, that can be a second area. If they finally return to find it attacked and destroyed, that would be a third area. Including multiple area versions when necessary can save the DM a great deal of time doing scene-dressing.

Ensure any stores present in an area have inventories consistent with the module‘s desired balance of available items. The same principle applies to merchants purchasing items from players: make the buyback rate appropriate and limit merchant gold and types of items bought. (It makes little sense to have a typical barkeep with unlimited gold and hefty magic items for sale, for example.) One thing to keep in mind: if the module ends up providing too little reward for a DM’s taste, he or she can always provide more loot directly; however, if it gives too much and unbalances the scenario, players will generally get upset if a DM takes loot away.

Since you cannot easily create custom palette categories in NWN1 - which should change in NWN2 - keep creatures grouped in easy categories where a DM can quickly find them later. Include a list of the custom creatures/NPCs in the DM guide and their palette locations.

Give NPCs reasonable equipment based on their background, including gold/gems, mundane items, and magic items. The DM's life becomes a little easier if he/she doesn't have to create everything manually.

Give NPCs appropriate physical descriptions, which allows the DM to play off of unique characteristics that cannot otherwise be seen (missing fingers, a streak of color in the hair, etc.)

Name items and placeable objects in a descriptive way so that DMs can find them easily (e.g. “Letter from Elminster” rather than simply “Letter.“) and be sure to categorize them logically in the palette.

Consider creating two versions of important quest-related items in the palette: one that is deactivated (or only partially activated) with a description that shows only what can be seen when examining it, and another one that is fully activated and has a full description of item properties. This allows for plot-relevant action to occur around an item that otherwise would be nullified by a simple “Identify” spell. Once players achieve the necessary goals, the second item version can be provided by the DM and the first version removed. Make sure to describe such items in the DM guide as well.

Players appreciate custom descriptions of both items and placeable objects. Consider putting class or skill-dependent scripts on items to generate different “spoken” descriptions of them, and/or include information on them in the DM guide. Custom item descriptions that are mysterious or unclear also give more scope for DM interaction regarding the item.

In NWN2, placeables can be saved together as a single prefab object, helping DMs (and builders) lay down scenery quickly. For example, a complete campsite with campfire and tents and everything else you would like to include could be spawned at once.

When scripting, it is important to note that the GetIsPC() function returns true for DMs as well as player characters. Triggers that use GetIsPC to filter out creatures won't actually filter out DMs, so be sure to add a line with the GetIsDM() function (if true, return) to accomplish this where needed.

Put a short script in the OnConversation event of important NPCs that notifies the DM that [player name] is talking to [NPC name] in [area name]. This is very helpful in keeping track of who the PCs are talking to when the DM is distracted or if the party gets split up.

When possible, don't place encounters near area transitions. Players will appear at the transitions at different times, based on how fast their machine can load the area, and possibly before the DM, making things hard to handle.

If activating a plot script requires careful timing, consider creating a special widget for the trigger rather than using a plot wand conversation option. This allows the DM to put the item in the quickbar to quickly fire the script.

Create custom factions, including a faction that is neutral to everything (including itself). This will allow for DMs to better control PC-NPC relations, as well as avoiding well-known problems with NPCs being set to global common factions. Turn off the global faction setting, unless you work with custom factions and you need global faction changes to automatically occur.

While some of the differences in building with NWN2 are mentioned above, it’s worth highlighting some additional possibilities. NWN2 will include more quickslots with labels, which could be used in effect as "plot wands“ without having to create the item. This would mean including a pre-created DM avatar with the module that uses pre-saved quickslots; this has been done in NWN as well, although NWN has much more limited quickslot space. Using this option with NWN2 would mean being able to include pre-set “one-touch” encounters and other features in the quick bar.

Another interesting feature is the new graphical user interface (GUI) system for NWN2. For example, it could be a useful and powerful feature to have an area-specific GUI pop up for a DM, based on the various plot states. It could have a pre-typed selection of descriptions, information on area creature stats, etc. With the added potential of NWN2 toolset plugins, it should also be possible to generate some of this automatically, rather than having a builder enter the information manually. Conceptually, this has potential to make things simpler for the mod designer; for example, the builder could lay down triggers with descriptions in the comment fields, then an editor plugin could copy the message to a variable and set up an on-enter script to display the message.

We hope that the above discussion of DM-friendly design principles has given builders additional ideas, tools, and practices to take into consideration when creating new NWN/NWN2 modules. Adding the “human factor” by enabling DMs to effectively interact with players can enhance the play experience of almost any module. We encourage builders to realize their creative visions using whatever work practices are most effective for you. By reflecting some of the best practices from the builder/DM community to date, this article is intended to provide a starting point and guidelines for those seeking to make their modules more DM-friendly.

The following are some useful additional resources to look at if you are interested in building and DMing in NWN or NWN2:

DM-Friendly modules on NWVault - a wide variety of modules and documentation types are included, check them out to see how other builders have done it!

DMFI 101: So You Want To Be A DM - this entertaining self-teach module gives you the fundamental skills necessary to DM in Neverwinter Nights.

DMFI Wands and Widgets package - this set of DM tools is a major reason why scripting ability is not required for DMs to create an impressive NWN experience. Visual FX, sound FX, NPC commands, environmental controls, and much, much more are included.

Creating a Neverwinter Nights Campaign - this article goes deeper into what is needed to create effective campaigns in NWN from both building and DMing perspectives.

DMing in a Persistent World Environment - addresses the design and DM challenges faced in persistent worlds.

NWVault toolset tutorials - The viewlet tutorials are an entertaining way to get all the NWN toolset basics and there are many other useful tutorials available.

NWVault prefabs - the Area prefabs can help greatly in constructing a module, whether you want an entire city or perhaps just a village or a particular kind of area. You can make the prefab areas "your own" by modifying physical layout or by adding your own NPCs, placeables, and items.

NWN Lexicon - the Lexicon is the best NWN scripting reference available, easily searchable, and includes some wonderful tutorials on both scripting and toolset applications.