THE BUILDERS PROJECTS

GUIDE

TO

BUILDING II
***

THE DESIGN MANUAL

Version 0.05

TABLE OF CONTENTS
CHAPTER 1

BUILDING A MODULE............................................................................................................................................7

1.1

THE BUILDING ESSENTIALS .....................................................................................................................................................7

1.2

MODULE CATEGORIES .............................................................................................................................................................7

1.2.1

Story Oriented Module.......................................................................................................................................................7

1.2.2

Role-playing Oriented Module...........................................................................................................................................8

1.2.3

Combat Oriented Module...................................................................................................................................................8

1.2.4

Single Player Module.........................................................................................................................................................8

1.2.5

Multi-Player Module..........................................................................................................................................................8

1.2.6

Persistent World Module....................................................................................................................................................8

1.2.7

Combining Module Types ..................................................................................................................................................8

CHAPTER 2
2.1

GETTING ORGANIZED ..............................................................................................................................................................8

2.1.1
2.2

DESIGNING YOUR MODULE ................................................................................................................................8

Team of builders.................................................................................................................................................................9
TARGET AUDIENCE..................................................................................................................................................................9

2.2.1

Restriction on Player Characters.......................................................................................................................................9

2.2.2

Scope of the Story...............................................................................................................................................................9

2.3

CHARACTER PROGRESSION ...................................................................................................................................................10

2.3.1

Giving XP points ..............................................................................................................................................................11

2.3.2

Giving loot and other treasures .......................................................................................................................................11

2.4

ESTABLISHING THE RULES.....................................................................................................................................................12

2.4.1

Rule sets ...........................................................................................................................................................................12

2.4.2

Resting systems ................................................................................................................................................................12

2.4.3

Death and re-spawning systems.......................................................................................................................................12

2.5

USING CUSTOM CONTENT .....................................................................................................................................................13

CHAPTER 3
3.1

WRITING A STORY................................................................................................................................................13

SETTING OF YOUR STORY ......................................................................................................................................................14

3.1.1

Using an Existing Setting .................................................................................................................................................14

3.1.2

Creating a Unique Setting................................................................................................................................................14

3.2

GOOD, EVIL AND NEUTRALITY ..............................................................................................................................................14

3.2.1

On using Good .................................................................................................................................................................15

3.2.2

On using Evil....................................................................................................................................................................15

3.2.3

Neutral behaviour ............................................................................................................................................................15

3.2.4
3.3

Alignment summation.......................................................................................................................................................16
WRITING A SYNOPSIS .............................................................................................................................................................16

3.3.1

Broad Considerations In Writing.....................................................................................................................................17

3.3.2

Start the ideas flowing......................................................................................................................................................18

3.3.3

Boil it down to its base elements. .....................................................................................................................................18

3.3.4

Write a first draft..............................................................................................................................................................18

3.4

WRITING PLOTS AND QUESTS ................................................................................................................................................18

3.4.1

Writing the Plot................................................................................................................................................................18

3.4.2

Plots and quests ...............................................................................................................................................................19

3.4.3

A few plot and quest points to consider: ..........................................................................................................................19

3.4.4

Main/Sub Quests Methodology ........................................................................................................................................19

3.4.5

Side Quests.......................................................................................................................................................................20

3.5

TIPS ON WRITING THE STORY ................................................................................................................................................22

3.5.1

Retaining logic in the writing process..............................................................................................................................22

3.5.2

Give a tone to your story..................................................................................................................................................22

3.5.3

Establish the content rating and respect it.......................................................................................................................23

3.5.4

Avoid repetition................................................................................................................................................................23

3.5.5

Stay consistent with the choices you have made ..............................................................................................................24

3.5.6

Use of realism ..................................................................................................................................................................24

3.5.7

Linear / Non-Linear .........................................................................................................................................................24

CHAPTER 4

DESIGNING AREAS ...............................................................................................................................................25

4.1.1

Area Lighting and Sounds................................................................................................................................................26

4.1.2

Travel ...............................................................................................................................................................................27

CHAPTER 5

NON PLAYER CHARACTERS IN YOUR MODULE.........................................................................................27

5.1.1

Designing NPCs...............................................................................................................................................................27

5.1.2

Dialogue...........................................................................................................................................................................28

5.1.3

Appearance ......................................................................................................................................................................29

5.1.4

Henchmen ........................................................................................................................................................................29

5.1.5

The Villain........................................................................................................................................................................30

5.1.6

Villains motivations. .......................................................................................................................................................30

CHAPTER 6
6.1

USING THE JOURNAL...........................................................................................................................................32

NON-LINEAR QUESTS MADE EASY WITH JOURNAL ENTRIES .................................................................................................33

CHAPTER 7

USING SCRIPTS TO DESIGN EFFICIENTLY ...................................................................................................37

7.1

HOW TO KEEP TRACKS OF VARIABLES ..................................................................................................................................37

7.2

HOW TO USE JOURNAL VARIABLES .......................................................................................................................................38

7.3

USER DEFINED EVENTS .........................................................................................................................................................39

CHAPTER 8
8.1

ADDING LIFE TO YOUR MODULE ....................................................................................................................39

ADDING COLOR / FLAVOUR ...................................................................................................................................................39

8.2

FREQUENT NPC BEHAVIOUR (PICKPOCKET, GUARDS, COMPLEX ANIMATIONS) .....................................................................40

8.2.1

Ambient Animations Tutorial For NWN1!!!.....................................................................................................................40

8.3

CREATING ORIGINAL TRAPS ...................................................................................................................................................44

8.4

VISUAL EFFECTS, SOUNDS AND LIGHTING ..............................................................................................................................45

8.4.1

Making your important scenes more dramatic and exciting ............................................................................................45

CHAPTER 9

ADDING COMBAT ELEMENTS TO YOUR MODULE ....................................................................................46

9.1

ENCOUNTERS .........................................................................................................................................................................46

9.2

BALANCING COMBAT ............................................................................................................................................................47

9.3

DESIGNING LARGE BATTLES ..................................................................................................................................................47

CHAPTER 10

ADDING ROLE-PLAYING ELEMENTS TO YOUR MODULE...................................................................49

10.1

CONSEQUENCES OF PC ACTIONS............................................................................................................................................49

10.2

SKILL CHECKS AND OTHER RELATED PC STATISTICS.............................................................................................................50

10.3

ROMANCE ..............................................................................................................................................................................50

CHAPTER 11
11.1.1
11.2

DESIGNING A PUZZLE ....................................................................................................................................50

What is a Puzzle? ........................................................................................................................................................50

TYPES OF PUZZLES ................................................................................................................................................................51

11.2.1

Cryptogram .................................................................................................................................................................51

11.2.2

Riddle ..........................................................................................................................................................................51

11.2.3

Logic............................................................................................................................................................................51

11.2.4

Maze ............................................................................................................................................................................51

11.3

FORMULATING A PUZZLE.......................................................................................................................................................52

11.4

PLACEMENT OF PUZZLE .........................................................................................................................................................52

11.5

PUTTING THE PIECES TOGETHER ...........................................................................................................................................53

11.6

BUILDING THE PUZZLE ..........................................................................................................................................................53

CHAPTER 12

MODULE CATEGORY PARTICULARS ........................................................................................................54

12.1

ROLL PLAYING MODULES .....................................................................................................................................................54

12.2

BUILDING A HIGH-LEVEL MODULE .......................................................................................................................................54

12.3

BUILDING A PW ....................................................................................................................................................................55

12.4

BUILDING A MULTIPLAYER MODULE ......................................................................................................................................56

12.4.1
12.5

BUILDING A HACKN SLASH MODULE ...................................................................................................................................57

CHAPTER 13
13.1

How to make a module DM friendly and DM documentation.....................................................................................56

TESTING THE MODULE ..................................................................................................................................60

HOW TO BE A GOOD PLAYTESTER ..........................................................................................................................................60

13.1.1

PLAYTESTERS GUIDELINES....................................................................................................................................60

13.1.2

Playtesting Tips ...........................................................................................................................................................61

13.2

BALANCING ITEMS AND EFFECTS ..........................................................................................................................................62

13.3

WHEN THE PLOT GETS BROKEN ..............................................................................................................................................62

CHAPTER 14

GOING PUBLIC WITH THE MODULE..........................................................................................................63

14.1

READ ME FILE .......................................................................................................................................................................63

14.1.1

Recommended topics/subjects. ....................................................................................................................................63

14.1.2

Uninstallation Guide ...................................................................................................................................................65

14.2

ADVERTISING THE MODULE ...................................................................................................................................................65

CHAPTER 15

DICTIONARY OF COMMON TERMS AND ACRONYMS ..........................................................................66

15.1

DICTIONARY ..........................................................................................................................................................................66

15.2

COMMON ACRONYMS ............................................................................................................................................................68

15.2.1

General Online Communications ................................................................................................................................68

15.2.2

Gaming Specific Terms ...............................................................................................................................................69

CHAPTER 16

RESOURCES........................................................................................................................................................72

CHAPTER 17

CREDITS ..............................................................................................................................................................74

INTRODUCTION
Neverwinter Nights developed by BioWare and Neverwinter Nights 2 developed by Obsidian and distributed by
Atari (formerly Infogrammes), has become one of the leaders in end user adaptability. The main engine behind
this is the Toolset, which allows users to create their own modules. No longer are they limited to what was
created by the games developer originally.
What we can do with the toolset is mind-boggling. However, with so much that you can do, where on earth do
you start? That is where The Builders Project comes in. The Builders Project is a group of Neverwinter Nights
and/or Dungeons and Dragons enthusiasts who have dedicated themselves to a few simple objectives:
i)

To reach as many new module builders as possible and get them educated in the use of the
NWN and NWN2 Toolset. We want to do this within the framework of the membership, but we
see no reason to make any info published by the guild private in any way.

ii)

To provide a support system for module builders.

iii)

To gather, pool and make available any resources we encounter regarding module building,
with the intent of aiding our members and the community at large in the pursuit of module
building.

iv)

To provide a means of sharing knowledge and experience in module building, foster an

atmosphere of collective education, and further the purpose of making our membership
competent and capable builders.

To that end, the Builders Project has been collecting information on every aspect of module building and
keeping track of the questions frequently asked on the forums and the answers provided to these questions. All
this information is stored and edited in what we call The Guide To Building.
***

The Guide to Building will be released in several instalments, each covering an important aspect of module
building. The purpose of this second instalment, titled "The Design Manual", is to provide the builder with a set
of suggestions and guidelines to help build better, more complete and enjoyable modules. This manual should,
however not be viewed as an attempt to establish an authority over methods for designing and building
modules. The suggestions contained herein are just that suggestions. Not every topic has been thoroughly
explored here so there will be issues not fully addressed, or not addressed at all, due in large part to this being
a huge, and complex subject.
Designing and building NWN or NWN2 modules can be a difficult proposition for any builder; even a veteran
builder. Difficulties can develop for anyone. No one system of module creation is superior to another. Each
builder is a different person and their individual strengths and weaknesses will be different, therefore each and
every idea presented here in this guide should be seen as a tool to use to make your module what you want of
it not a gospel claiming to be The right way or even, The best way to make a module.
***
Any help or support related to this instalment of the Guide to Building may be obtained in our guilds forum at
the following address:
The Builders Projects Guild

CHAPTER 1

Building a Module

So you have finally decided to make your own module, congratulations!

There are a couple of key concepts that you will see used throughout this guide, these being that playing your
module should be fun for players and fun for you the builder. You should keep in mind this concept at every
step of your module building experience. Each time you make a design decision, you will have to determine
how it will affect your module, if it is logical in consideration of your story, etc. But your final questions should
always be: Will this make my module more fun for the player(s)?

1.1

The Building Essentials

There are a variety of skills and concepts that are commonly considered essential to creating a fun and
enjoyable NWN module. In the following sections of this guide we will try to help lead you through the process
of learning and understanding these concepts. Much of what will be discussed here is based on opinion; where
ever possible we will try to present more than one opinion. Please feel free to disagree with any or all of them.

1.2

Module Categories

Most modules made by our wonderful community can be broken up into a few general categories. You will find
it helpful to consider what category or categories you would like your module to fit in.
1.2.1

Story Oriented Module

Story oriented modules are all about telling a story. This type of module will have a beginning, middle and end.
There will be one or more protagonists (usually the PC(s)) villains, allies and plots. The basic structure of a
story oriented module can easily be compared to a novel or short story. It will usually contain all the elements
of traditional story telling.

1.2.2

Role-playing Oriented Module

This type of module often has much in common with the story oriented module. However in this case there is a
very definite focus on developing the personality and place of the PC(s) in the setting of the module. Often
there will be choices or options available to the player that will affect the outcome of the module or change the
way Non-Player Characters (NPCs) react to them. Many role-playing modules are designed with the intention
that they be run by a Dungeon Master (DM) using the DM client in order to add more to the role-playing
experience.
1.2.3

Combat Oriented Module

This type of module is all about the hacking and slashing (or blasting for spell casters) of enemies. This can be
both easier and more complex to design than other types of modules. Many consider it very challenging to
create a never ending series of combat encounters that can keep a player interested in the module.
1.2.4

Single Player Module

In this type of module the designer intends for only one player character to be involved. There are many
advantages to making single player modules. Many scripting and encounter balancing issues can be more
easily avoided or dealt with when you know that there wont be a party of characters present.
1.2.5

Multi-Player Module

The intent here is that several people play the module at the same time, usually online. This can be one of the
most challenging types of modules to create. Balancing encounters and creating scripts take on whole new
levels of complexity when you factor in the much larger number of possibilities involved with multiple players .
1.2.6

Persistent World Module

The persistent world is the biggest most complex type of module that can be built. Here you are taking on not
just a single story or a single player but whole groups of players simultaneously involved in multiple stories all
with the idea that they can leave and return later to pick up where they left off. Often the most difficult part of
designing a persistent world is the persistent part, creating the systems and other complexities that create the
illusion of a real living, breathing environment are not to be taken on lightly. Also do keep in mind that PW
modules are not being supported by BioWare, however many people have and continue to run successful PWs
to date.
1.2.7

Combining Module Types

It is of course possible to combine several of these types into one module. Examples might include the story
module with a focus on combat or the role-playing persistent world. Feel free to mix and match these ideas to
help define your project.

CHAPTER 2
2.1

Designing your Module

Getting Organized

Just as no building is constructed without a set of plans you should not begin building your module without a
good solid plan in place. It is far too easy to get sidetracked or discouraged when working in the toolset without
8

some kind of clear idea of what you want to accomplish. With this in mind you should do everything you can to
prepare for your module before opening the toolset.
2.1.1

Team of builders

Many modules are built by teams of builders working together. Teams allow builders to combine their strengths
and to cover for their weaknesses. Teams also require a great deal of organisation and cooperation as well.
When working as part of a team there should always be one person who is in charge. This person will
maintain the master module and organise the rest of the team members. They will help establish standards,
and more importantly, make sure that all the contributions meet the requirements of the project.
TIP
Naming conventions: when working with a team it is highly recommended that a system be
decided on in advance for naming all tags, blueprints, resrefs, scripts etc. This can help prevent
problems caused by mistakenly overwriting one persons work with anothers. A common
method for doing this is to have all contributors append their initials to all their work.

2.2

Target Audience

What audience(s) do you hope to engage? Role-players? Hack and Slash fans? Do you envision a linear
module or a non-linear module, or some combination to entice particular types of players? Do you want your
module to focus on storytelling, atmosphere, and NPCs? Determining who your module is aimed at can make
answering the many questions that will follow much easier.
2.2.1

Restriction on Player Characters

Restrictions can help a builder limit the amount of work required to build their module, knowing ahead of time
whether you need to balance for every class or make special considerations for one kind of gender versus
another are just the tip of the iceberg. The more time you have to devote to your plot, sub-plots, NPCs, setting
details (specially named weapons, unique books, etc.) often the better, restrictions offer up time resources for
these things; however, restrictions can have an adverse effect in that fewer people may want to play your
module due to your imposed restrictions. Builders need to think about what they want to achieve with their
module and make a decision on the matter of restrictions, attempt to stick to your vision but if you feel
modifying your vision through the use of restrictions will help then do so, if it hinders, then dont use
restrictions.
2.2.2

Scope of the Story

What is the scope of your story? Do you want to take a PC from a low level to a high level, or focus on a
specific level or two? Do you want to simulate the lifetime experiences of a PC, or just a little period of time in
their life? Is your planned module going to encompass many lands, towns, villages, cities, and kingdoms or just
a small geographic area? After you have decided the basic scope of your story, consider how best to
implement your story via the size of the module you are willing to build or whether several modules would be
better suited to the scope of your story.

If you only want to deal with a fairly small geographic area, over a short period of time, it makes sense
to stick with just one module, likely small overall, although it is possible to use a village or two, create
many houses, fill those houses with NPCs, and, in the process, create a comparably large module
just keep in mind that writing dialogue, making interesting NPCs, and providing content that will engage
and interest your player involves a fair amount of work, writing in particular but scripting as well.
9

The more complex your story is, the more demanding it will be to make the story workable in only one
module, consider breaking up your module into segments or chapters. A small series of modules telling
a story has some benefits over a single larger module telling essentially the same story. You can see a
finished product and get feedback on it sooner. Mistakes made in developing the first chapter in a
series can be corrected more easily, while correcting a huge module can involve so much work, or be
so complicated without starting over, that it precludes any fixing at all.

Stories involving populated settings are often very complex due to the amount of work involved in
creating a credible village, town, or city.

Remember the aim is to create situations within which the player is engaged with your world. Where the
player is having fun and they feel their time is well spent.

As a general rule of thumb it is always a better idea to start off smaller with your very first module, to
get acquainted with the toolset, scripting and the various options available that make up for a good
story. Once youve sank your teeth into a smaller module you will find that your next creation can take
on a much larger scope without getting overwhelmed by all that the toolset has to offer.

2.3

Character Progression

Character progression and experience awards are key factors in designing any module. The method of
awarding experience and the amount awarded need to be well thought out and integrated into the other
aspects of your module.

Combat experience, I.e. killing opponents for experience, is the default system for awarding experience
in NWN modules, thus combat experience is the most commonly used, and player expected,
experience system used by builders. Combat experience presents a number of problems for both
builders and players:
o

For builders, doling out experience over the course of a module or a series of modules becomes
highly subjective as different players chose to fight more or less then one another and different
character classes are better at fighting then other (this is a problem exacerbated by re-spawning
enemies)

For players, those character classes not best for fighting tend to die disproportionately in
modules not designed specifically for them which, is annoying to players of such characters.
People tend to like to see some progress made by their characters during their adventuring,
seeing experience earned during fighting very often feels right to players no matter what type
of character they are playing characters whose chief function is to fight specifically expect to
get experience for doing what they do best.

Quest based experience eliminates questions about level balance and one kind of class versus another
getting more or less experience, this system is excellent from a purely building perspective complete
control of how much experience is dished out and when. Players can get annoyed if they do not see
immediate gains and gratification for their hard fought battles, characters who are chiefly combat
oriented can be particularly annoyed that they have to do everything the hard way, slowly, fighting their
way through one danger after another and get little in the way of award for their effort. However, if a
module is engaging enough, players seem to not complain so much about quest-based experience.

Alignment experience, and / or role-play are both systems intended to encourage and reward certain
kinds of behaviour in a player. Some people love these kinds of reward systems, ascribing to them a
particular recognized way of playing a pre-defined behaviour makes them proper role-players; other
people despise these systems because they feel they are the best able to judge how and why their
10

characters do what they do a few people feel only a live Dungeon Master (Game Master) can make
proper alignment or role-playing decisions for their characters.

Skills and / or abilities checks, offering experience rewards, are often enjoyed by players as an extra
means to role-play their characters and use their characters strengths to their benefit.

Total experience systems designate a specific amount of experience that can be gained in the module,
area by area, and it does not matter how a player acquires experience (whether by combat, quests, skill
checks, or playing their characters role properly). Once an areas experience pool has been exhausted
there is no more experience to be had, often leaving an area where there still is experience to be had
will trigger a script to level up the character the rest of the way to keep the experience even. This
system can offer solutions to everyones problems unless a character spends a little too long in an area
fighting to soak up extra experience only to learn the well has run dry.

Combined experience systems attempt to use two or more experience systems to please fans of the
systems used, most often, combat experience and quest based experience systems. Combined
experience systems offer an advantage in that non-fighting specific classes can acquire experience in
ways that do not require combat, allowing them to progress, also, fighter specific classes get their
fighting experience, everyone gets a little experience for their combat effort which fulfills the need to
see a progression of character improvements after facing off against enemies. However, combined
experience systems tend to suffer from the same problems combat experience systems do, sometimes
even more so if combat oriented characters soak up both combat and quest experience in the module.

Remember the character levels your module is designed for, make sure during play testing that obstacles in
your module are fit for the class and level of the player, and their likely equipment.
2.3.1

Giving XP points

Keep track of when and how many experience points you give out to players during your module. It can be
worth a builders time to workout how much a player of a given class and level range will receive after
completing your module so that balancing encounters and planning for continuing series can progress from a
somewhat common ground. Adventures at low levels usually advance very quickly and high-level adventures
level very slowly. Use the experience slider while experimenting on how you want to dish out experience to
keep your experience pacing, or progression, to your liking.
Poorly balanced experience in modules can lead to over or under powered characters for your module with
resulting boredom during easy battles or frustration at having to reload because battles have become too
difficult let alone whether players get upset at the pace of levelling or not levelling. Excessive experience, in
particular, can undermine a modules internal logic; an adventurer ought not to be able to jump from a low level
to a high level in the space of a few hours unless there is a really good reason.
2.3.2

Giving loot and other treasures

Builders should keep an eye on how much loot, items and treasure, they give out in their modules, as well as
how it is given out. Consider whether it makes sense that the amount and the nature and the location of loot
are being given out is excessive in terms of the level, story, and setting of their module. Some examples:
Should a first level character find a kings ransom in treasure in a small cave housing a handful of goblins?
Should gold and or extremely powerful and expensive magic items be in every placeable a higher level player
opens, anywhere, such as in a city slum or just about anywhere except, perhaps, for a wealthy kingdoms
treasury? If you want to avoid generic treasure in your module, or as little as possible, avoid leaving placeable
objects useable, disable BioWares generic treasure scripts and use specialized scripts to mimic proper
barrel/box/desk fodder.

11

2.4
2.4.1

Establishing the Rules

Rule sets

Whether to use the base rules or to use scripts to modify the base rules is an important decision best made as
soon as possible in the building process. Remember that the default rules are what the player already knows.
Altering things like the ability to rest or how the PC levels up can make certain play styles and character types
unusable and can turn many players away from your module. If you do feel the you absolutely must alter the
basic rules of the game keep in mind that there are a large number of alternate rules systems available from
Neverwinter Vault. Below are some major considerations to keep in mind when altering the games rules.

NWN is a computer game, not a PnP game; there is a significant difference between the two mediums.
In a PnP game, a DM can skip the waiting period between action and inaction, such as sleeping, or a
long road trip, maybe throw in a brief random encounter to spice up the situation or have pre-planned
something but in NWN, unless there is a live DM, there is nothing but the player, sitting in their chair,
waiting to begin playing. The point of playing both PnP D&D and playing NWN is to have fun, attempt
not to think about how using modified rules will some how force players to enjoy your module the way
you want them to, instead, attempt to think about whether you can create a happy medium between
what you want to achieve and players having a good time.

Real life involves a whole series of tedious activities, sleeping, traveling, regular eating and drinking,
and restroom breaks, and all of the other realities of life people often play games to avoid tedium, and
escape the real world not to embrace it in their spare time. If you feel the need to modify the base rules
of NWN you should avoid tedium inducing rules that may make the game less enjoyable to your
players.

Make sure that your custom rules make sense in the frame work of your world and setting.

2.4.2

Resting systems

Resting systems cover what happens when the PC rests as well as when and where they can rest. There are a
great many considerations that can affect how you want to handle resting. If your module has very little magical
healing then resting becomes a key factor in the ability of the PC to survive multiple combat encounters. You
should also keep in mind that spell casters only regain spells by resting; this means that resting restrictions can
have a big impact on the abilities of spell casters. You should also question where the PC can rest. Is it ok to
take a nap in the middle of the town square? Will camping in the forest run the risk of being woken by hungry
bears? Do the goblins patrol the tunnels in their cavernous home?
The default resting system for NWN allows the PC to completely recover all hit points and memorised spells.
By restricting when and where the PC can rest you can add another level of realism to your game. Keep in
mind though that overly restrictive rest systems can make the game unplayable for spell casting class and
more difficult for melee types without magical healing.
2.4.3

Death and re-spawning systems

The default NWN method for handling death is one of the most often altered systems in the game. When
deciding how you want to handle PC death it is important to decide whether you are making a single player
module or a multi-player module. Single player games offering no re-spawn means at best a saved game
reload, often accompanied by revisiting previously completed content, a tedious endeavour that if repeated can
lead to the player quitting the game. The default base rules has the player respawn at the exact spot where
they died, for most players this makes the game to easy. At the very least it is recommended that you employ a
respawn point system; causing the re-spawning PC to appear at some safe neutral location away from the
12

place they died. If you have a dead player re-spawn at a spot far from where they died, consider using short
cuts such as limited use items, porters, travel signs, etc., to allow options that transport a player close to where
they died so that the player can avoid wandering through areas they have been through before.
Another common consideration is whether or not there are penalties for re-spawning. Many players and
builders expect a small amount of gold and XP to be taken from the PC each time they re-spawn. Keep in mind
that this is a punishment to the player and if to excessive can take the fun out of the game especially in combat
heavy modules.

2.5

Using Custom Content

Think hard about whether your project actually needs a hak pack, if so, attempt to keep in mind the relative
value of the hak pack versus the download time for people, particularly people using a dial-up service. If you
feel the module you want to make requires many pieces of custom content then go for it, better to keep your
muse then loose it; however, if you have the time and inclination, consider making a hak pack light version of
your module.

If you are a new builder or a builder who does not have a strong, vocal, following, using hak packs can
definitely affect your modules reception, particularly peoples willingness to download your module.
Consider using a custom Hak that contains only the content you absolutely must have.

If you are going to use multiple hak packs in your module avoid combining the hak packs into one large
hak pack, many people who are willing to download hak pack modules already have a library of hak
packs and may have all of the content on their hard drive already, do not make these people waste
their time downloading the same content, in a new package, for no good reason.

If you feel the need to use one large hak pack, consider looking into the contents of the hak packs you
are combining and erasing those bits and pieces of the hak packs that you are not going to use to
reduce the size of your combined hak pack.

Two potential exceptions to these rules, the first being the Community Expansion Pack (CEP) which is
a combination hak pack of some of the best custom content the community has to offer combined into
one package. Although not supported directly by BioWare it is very commonly used amongst
community members and will cause less resistance to download than other large haks. The second
exception being a recently released hak pack by BioWare that contains tile sets that were not included
in any patches for reasons of size; it is again presumed that this will be widely downloaded by the
community and thus will not present an obstacle if used by builders, you can download it here:1.67
Content Downloads

The Winrar compression file program, available on the Internet for a free trial run, is a valuable tool for
reducing large hak packs into more manageable sizes for uploading and downloading.

CHAPTER 3 Writing a Story

For the purpose of this chapter, story and module are differentiated as such: A story is the basis on which a
Story Oriented Module is made, it is integral to a Story Oriented Module but it is not the actual module. The
story is the artistic part of a module while the module itself is the actual files and other resources used by the
game engine when NWN is played.

13

3.1

Setting of your Story

3.1.1

Using an Existing Setting

Forgotten Realms, Greyhawk, Spelljammer, Dragon Lance and D20 Modern are just a few examples of the
published settings available to choose from. An existing setting allows a builder to work with a world that is
already established, has a history, often plenty of background and even NPCs to pull into the module.
However, rules need to be followed if one of these or another existing setting is used, otherwise you will not
meet the players expectations. There will be players who are familiar with characters, events, places, etc., that
will give them an emotional reaction (could be good or bad depending on any given players biases) to the
module before even downloading the it; literally, a reason to download the module. Proper implementation of
an established setting can be a great deal of work, often the more detailed the setting the harder it is to do it
justice. There are those players that will complain that NPCs, events, locations, etc., are either incorrect, or not
implemented as the player envisions them that can lead to annoyed players and this potential needs to
balanced against the benefits of the established setting.
3.1.2

Creating a Unique Setting

There is great freedom and equal responsibility in creating your own unique setting. A unique setting allows a
builder to do what they want to do with no creative fetters attached, however, players will not have any
established attachment to or knowledge of your setting thus requiring you to make an extra effort to get the
player emotionally committed to your setting. This need for editional attention to detail can increase the amount
of planning and research that needs to be done considerably. However the benfits of giving yourself the
freedom to do whatever you want can often be worth the extra work. You will also need to take great care in
keeping your custom setting internally consistent. Where things are located, the customs and mores of the
people, the history should all make sense in its context.
There are a number of things you can do to help your players to gain knowledge and understanding of your
unique setting below are some examples:

Books that relate pieces of history and lore from your world are a good way to pass important
information about your unique setting to the player. Remember not to make them to long though or
your players may get bored and stop reading missing important context and clues.

Unique weapons, armour and other items with descriptions that give them a history in your world are a
great way to add depth and make the payer feel that their hard won loot is special.

Add tidbits of local lore and gossip to your NPC conversations that help to breath life into your setting.

3.2

Good, Evil and Neutrality

A story can be told many ways but, in the case of role-playing games, the player has in theory, a chance to
chose whether they are going to indulge in good, evil or neutral behaviour. However playing a computer game
takes a great deal of the potential choices a player may wish to indulge in away. The builder must decide if
they are going to be supportive of multiple, fundamental, behaviours and if so, what behaviours are to be
supported and to what degree those behaviours will be supported.
It is recommend that you think about your story, its internal logic, and how you feel about different kinds of
behaviour and then decide if you feel that one, or more, types of behaviour are suitable for what you want to do
in your story. You should consider the fact that attempting to include options for multiple kinds of behaviour will
increase your workload. If you do decided to use more then one behavioural norm, think about dialogue

14

options, sub-quests, and at least one alternative ending to support the added behaviour. See below for more
thoughts concerning good, evil, and neutrality in PC's.
If you do decide to implement good, evil, and neutrality in a meaningful way. Determine what constitutes good,
evil, and neutral (ambivalent in terms of choosing between being particularly good or evil) behaviours and
activities in your story. Whether you are supporting multiple behaviours in your module or not, it is useful to
consider the differences between good, evil, and neutrality as social tools as well as individual codes of
behaviour. This will help to maintain a sense of moral continuity in your design process and give the player a
kind or compass to help in deciding how they will play their character.
Take some time to consider what the words mean to you in the context of your story. Once you have an idea
what these behaviours mean to you, what the tone of your module will be, and what type of audience (and
content rating you are aiming at) you can better decide how to implement one, or more of these in your
module.
3.2.1

On using Good

You may want to give the PC only good options, perhaps even simplify all player/NPC interactions by
establishing clearly who are the good guys, who are the bad guys and what actions/dialogues/activities are
clearly Good. However, depending on the type of story you want to tell, you may want to avoid making good
actions, dialogue, and activities be so obvious that you end up eliciting groans of disbelief from your players.
Tip:
Consider designing player/NPC interactions in ways that raise moral questions, do not give
away obvious clues as to who is Evil and who is Good. There are a number of issues involving
being Good that can be very challenging to role players.
3.2.2

On using Evil

Providing options for evil behaviour has the potential for opening a serious can of worms depending on how
you handle the story. Just how far you are willing to allow the PC to take evil actions, and whether the PC(s)
could suffer equally from evil can have a dramatic effect on the very nature of your story. Some builders feel
allowing for the pc to kill everyone is a valid option, others to allow them to join the bad guys (even take over
the spot of the chief Evil of the story), simply be rude, require payment for services rather then serve the
common good, or allow for thievery. There are those that allow for far more graphic Evil in Evil PC behaviours
such as enslaving people, rape, torture for information and or for pleasure. These behaviours are at the least
mature in theme if not extreme. All of these behaviours have their place in stories but the builder has to decide
whether and how far to support such content.
Tip:
Most adults consider the majority of evil options listed above to constitute Mature content.
Make sure to keep this in mind when reconciling your decisions with your intended audience.
3.2.3

Neutral behaviour

In a sense this category of behaviour fits in between Good and Evil, slipping in and around them. Much of the
time it is easier to use dialogue options for neutral behaviour more then explicit good or evil. Neutral oriented
players may or may not wish to chose from available good/evil options. Some may switch from one to the other
frequently or avoid both whenever possible. Adding the option for the player to show indifference to the Good
15

or Evil consequences of their actions can give them a feeling of greater choice without necessarily requiring
alternate endings to your module.
3.2.4

Alignment summation

No matter where you stand on behaviours in a module, thinking through what types of behaviours you want to
support will make it much easier to plan your PC/NPC interactions, your plots, and avoid violating the internal
logic of your setting and story by setting potential quests, dialogues, and plot developments next to your story
and goals to see if there are any holes.
Some basic ideas to think about when considering using alignment in your module: does your setting demand
alignments, does your story demand alignments, if so, then consider how you can implement these into your
story.
Tip:
Consider having an in-game mechanism, like an alter or temple, that the player can give gold to
too adjust their alignment (or some other device as fits your own idea).
Think carefully about why and how you implement any alignment modifications to avoid judging
player intent. A player should not have to guess when an alignment modification will occur (it
should be self evident).
Alignment hits in multiplayer games affect everyone in a party.
Make sure to provide a Read Me document to explain your reasons and systems of alignment in
your module.

3.3

Writing a synopsis

The writing process varies between people due to differences in interests, perceptions, experiences, writing
traditions, use of imagination, desire for realism, etc.; there are, however, some basic ideas and techniques
that most people can benefit from using; while considering how to write up their story, how to use their talents
to their advantage, and how to make their story accessible to people.
Four basic tips: Write what your muse tells you to; write about what you know; write with a mind for simplicity;
and be willing to take constructive criticism for the purposes of rewriting and revising your initial writing.
1) A muse can come from anywhere and relate to anything when you are writing, either from
experience, research, dreams, or self induced hallucinations whatever you are taking what you
have absorbed and are attempting to give of yourself to your audience. Writing your muse is
important, it is your inspiration; if while writing you find yourself in a corner or getting blocked from
writing, take a break or do something that eases you, lets you think, gets your creative juices flowing
again, to bring your muse back to you. In all of the other tips below, remember it is your muse that is
most often the most important tip to follow.
2) Writing about what you know can be a very effective method for taking life experiences, knowledge,
skills, and interests of your own and adding these things, these elements of yourself, to what you are
writing about. Think of the things you have done in your life, your friends and family, your
acquaintances at work or school or your neighbours, the books you have read, the television shows
you have watched, the movies you have seen, games played, particularly your own imagination - all
of the things that make you, you, and understand that all of these things are what you know.
16

You may not be an expert on many subjects but there, again, most people only know a little bit of
any one, or a handful of things, therefore there is no shame in writing about what you know in terms
of yourself. When you write about what you know, you can use friends experiences to help you think
about how different people have dealt with different problems that you yourself have faced or their
experiences, thus enabling you to make NPCs in your story far more believable; you can use history
as a tool for determining how and why a fictional enemy has done what they have done; use the
stories and characters of mediums that interest you, all to further your own creative efforts. In
thinking about what you do know, you can even surprise yourself and that can be a good thing.
Writing about what you know may provide you with all the background that you need and, indeed, a
plot and characters and dialogue. Even if you feel that your knowledge is limited and dull, it is
possible, with a little imagination, to inject enough conflict and tension into a narrative that might
otherwise be considered flat and uninteresting. On the other hand, if you write only about what you
know, even with that dash of imagination added, that will not really stretch you. Writing about what
you dont know can lead you into exciting territory. You might consider that it will take you out of your
depth, but the more often you experiment with new themes and backgrounds and plots, the more
your powers of invention will increase. In terms of factual material, what you know can always be
increased by research
(Note: Some people see the advice of writing what you know as being counter productive as they
think it refers only to specific life activities such as what you do when you get up in the morning, restroom, bath-room, eating, drinking, work-school, etc., meaning nothing else in terms of who you are
or what you think which is misleading as shown above. These people tend, particularly, to be
variations of literal minded and or self-conscience, people who do not see the link between all of
what a person is, does, or thinks as being what they know or they, or their lives, are too boring to
count none of which is true.)
3) Write out what you want to achieve in simple terms, make sure what you have written makes sense
and can be followed easily. Seek anothers opinion on whether what you have written makes sense.
Your vision may be too clouded by insider information to see if your story actually makes sense to
other people. Whether you intend on having a complicated plot or series of plots (or a plot at all) it
can be good to work out the simple elements of what you intend to do first, then add other elements,
as you think them through, and determine whether they make sense in the writing phase to you and
others before you implement them into your story.
4) Once you have written out the story synopsis for your module, or even started work on your module,
seek opinions from others on what you have created. Attempt to formulate questions for people to
think about while checking out your work, but also ask for any other opinions they may have. Read
or listen to what these people have to give to you, weigh their opinions against your own, and make
any adjustments you feel are necessary to please both yourself and those who have given their
constructive criticism.
3.3.1

Broad Considerations In Writing

There are many "correct" things to write about any subject, but you need to narrow down your choices. For
example you may want to create a module for rogues only. At this point, you and your potential player ask
questions, such as why should you create this in any particular fashion, and why should anyone play it?

Do you want the player to feel what it is like to be an inexperienced rogue in a large city?

Do you want the player to know how rogues function in a guild?

Do you want the player to play a specific type of rogue, a gambler/card shark and a minor grifter?

17

3.3.2

Do not be afraid to ask yourself and others questions, questions can get you thinking about what you
are doing, how you are going to do it, and why one thing can be easier to do than another.
Start the ideas flowing

Brainstorm. Gather as many good and bad ideas, suggestions, examples, sentences, false starts, etc. as you
can. Perhaps some friends or other collaborators can join in. Write down everything that comes to mind,
including material you are sure you will throw out. Be ready to keep adding to the list at odd moments as ideas
continue to come to mind. A good way to do this is to get an old fashioned pencil and paper (gasp!) and sit
down in a quite place where there are few distraction and just start writing whatever comes to mind.
3.3.3

Boil it down to its base elements.

Write out your story/module idea in three or four sentences.

Diagram your major points.
Make a tree, outline, flow-chart or whatever helps you to create a schematic representation of your project.
You may discover the need for more or less material in some places to further clarify it in your story synopsis.
3.3.4

Write a first draft.

Then, if possible, put it away. Later, read it aloud or to yourself as if you were someone else. Watch especially
for the need to clarify or add more information.
You may find yourself jumping back and forth among these various strategies for telling your story or writing
your synopsis, do not be afraid to have several working schemes to see your vision of your story come to
fulfillment.

3.4
3.4.1

Writing Plots and Quests

Writing the Plot

A plot is a plan, a design, a scheme or a pattern of events in a story and further the organization of incident
and character in such a way as to induce curiosity and suspense in the spectator or reader. A module, using
plots, should have a plot hook or two that provides a motivation for the player to be engaged emotionally with
the module. A plot hook is something that catches a players attention, that gets the story going, piques our
interest, and makes us want to see what happens next. The plot hook may not be the main quest, or plot, of
the story but it must be something that keeps the player going ahead. For example: a thief steals the players
equipment; the player must seek the thief out to recover his/her possession(s). In this case the hook that gets
the player involved in the plot is the thief stealing their equipment, the plot is comprised of the events that
follow from this starting point.
A storys plot, without a hook or two, often develops in a slow or confused way for players. Players will wander
around, talking with NPCs, gathering background information, while performing an occasional odd job for
NPCs, but without any sense of purpose or motivation. These stories frequently lose the interest of their
players who give up before it begins. There are, however, some modules that specialize in this freeform style,
have identified how to peek players interests by exceptional PC/NPC interaction, and tend to have a whole
host of sub-plots to keep the player entertained until they manage to stumble onto the stories main plot.

18

3.4.2

Plots and quests

Plots and quests are not necessarily the same thing but most often are so closely linked that the plot of a
module is often referred to as the main quest, yet some modules do not have a specific main quest; these
types of modules are referred to as free form. Plots and quests, although not the same, are often intersecting,
interpenetrating concepts that nearly always require each other, for example: a simple plot to defeat a monster
is a type of quest, even more so if given to the player by some kind of authority figure. Whether a module has a
plot or not, it will tend to have quests, therefore acknowledging the potential of linkage between quests and
plots can further your module making skills.
Plots and quests can revolve around a number of principle issues: physical action; psychological exploration of
the mind, body, soul; individual(s) against institution(s) or society(ies); fantastical physiological alteration (i.e.,
go to sleep as a man, wake up as a woman); etc. It can be worthwhile to take a basic plot idea, often physical
in nature, and combine the plot with other plot elements to contribute atmosphere and depth to your story.
Remember all plots can essentially be turned around, for example the player as the hunter or the player as the
hunted; player as good, evil, or ambivalent; or turned into a parody/comedy if appropriate.
3.4.3

A few plot and quest points to consider:

Consider the dynamics of good pacing when working out the progress of your plot(s) and or quests in your
story. The ideal here is to maintain a balance between the action and the story telling. You want to pace the
action and the amount of information gained to keep the players excited and involved.

Does the story spend excessive time with no action or purpose to drive the player along?

Do you overwhelm the player with too many boring activities, repetitive fighting in particular?

Could your module use a few break-ups between bouts of action and if so, what kinds of breaks?
Humour? Friendly conversation? Serious conversation? Romance? Sex? Arguments?

3.4.4

Main/Sub Quests Methodology

Good and bad consequences:

The situations and effects of good and bad consequences as a method can vary considerably due to the
nature of making good and bad choices. A player could anger a drunk, get into a fight and kill the drunkard end
of story, however, that same drunk could have been the town mayor upset, drinking heavily, due to problems
facing the town. Killing the mayor precludes the player getting any rewards for the main quest of the module
and lands the player in jail, on trail for murder, and a geas laid on him by the Goddess of Judgment, to resolve
the towns problems for murdering the mayor or face divine punishment and execution.
Stand alone sub-plot:
A sub-plot that has an effect in the module but does not involve any other quest, particularly the main quest if
one is present in the module. Example: An adventurer has traveled to a foreign land seeking an item of power,
but has run out of money. A stranger approaches the adventurer offering treasure to defeat a local monster
that is terrorizing the villagers. Whether the adventurer agrees to defeat the monster, or not, has no direct
impact on the main plot of the story.
Branching, parallel plots:
Most often a plot or quest with opposing, parallel, plots, common to modules with both good and evil options.

19

Bait and switch plots:

This kind of plot involves starting the player off thinking they are doing one kind of plot, then turning something
around on them. For example, the players supposed ally turns out to be an enemy after being bought off by
the real bad guy who tricked the player into their first course of action. A player may have to decide who they
are actually going to try to ally with after having made an enemy out of their natural ally, lost their supposed
friend, and not even know the exact identity of their true enemy these kinds of plots with consequences often
are tricky mysteries and involve multiple factions.
Skipping sub-plots:
Related to one another or not, but one sub-plot never necessarily dependent on another in such away as to
further the module s main plot. Consider a plot progression that begins at A. and ends at F., the player can do
any combination of mini-quests between A. and F., most often with one mini-quest choice precluding another
choice, such as B + C = F. but no D. or E..
Independent quests:
Split the module up into a series of smaller mini-quests and then give the player a choice of how to (or even
whether to) perform each of those quests. If the solution to mini-quest D doesn't depend (too much) on how
you solved mini-quests A B and C then that makes it much simpler to handle all the possible combinations.
Several interlinking quests that can affect the outcome of each other:
If you are going to use interlinking quests in your module it is important to use consistency, believability and
immersion that the player's actions have believable and meaningful consequences. Stories using this method
are often very complicated, requiring a flow chart of the course of the various, interpenetrating, quests that
change each time a player chooses to take one direction or another, or attempts to navigate several paths
simultaneously.
Multiple story outcomes:
These are a completely different animal altogether. At the point the story splits your work increases
immensely on the module, although there will be some overlap you have to manage the overlap properly or the
modules various outcomes will not make much sense.
3.4.5

Side Quests

In most stories, side quests are used to expand the story of the module by attempting to immerse the player
into aspects of the setting not precisely germane to the main plot. Side quests allow builders to show more of
their imaginary world and create the illusion that it exists. Sub-quests are part and parcel to player choice in
modules. No matter how sub-quests fit into your module, if you are using them, there are a number of
techniques that can help you fit sub-quests into your module effectively: choke points, plot bubbles, favours,
fed-ex quests, and optional faction building.

Choke points involve the main plot of the module coming to a complete stop unless a certain condition,
or series of conditions, are met. For example: The pc(s) must acquire the location of a dungeon from a
library belonging to a secret society. The pc(s) must first discover which NPCs are secret society
members, the PC(s) may attempt to join the secret society, break into the library after learning its
location, or other things to acquire the proper tome used to find the dungeon. Depending on how many
options the builder wants to build for the player to explore, there can be, as mentioned above, many
ways to get past the choke point, or just one. Each option represents the opportunity to create a subplot
of varying sophistication. A module could have several choke points or none depending on the nature

20

of the story being told. Remember players must be able to get past choke points in your module. Do not
require skills or talents or abilities not available to your player to get past your choke points.

A plot bubble is a self contained point in a module that may, or may not, be required to complete the
main quest, a plot bubble can be physically removed from the main plot or interpenetrating, the main
plot.

A physically removed plot bubble would involve the PC(s) encountering some event or situation or
information that takes them into an area or series of areas that they cannot escape from until the plot
bubble has been resolved. An interpenetrating plot bubble is a plot that has no effect on the main plot,
can be picked up or dropped at the pc(s) convenience; these plots can be as simple as a series of fedex quests (more on these later), or a more complex series of activities such as taking on a job that
brings with it certain responsibilities depending on where you are in the module imagine taking on the
responsibility of being a marshal and or a judge on the border of a kingdom, each town you visit may
require your intervention but not impact your search for your lost brother or the golden egg or whatever
else the main quest happens to be.

Fed-ex quests or components of fed-ex quests are nearly omnipresent to all quests that require the
player go somewhere and do something, often involving some item it is sprucing up the basic fed-ex
quest into an engaging quest that builders must put their efforts into. Try to muddle up fetching and
carrying by complicating things so a player never feels like they are being routed from key item to key
item. Give your quests common sense, setting based, considerations, for example: a low level
character may be willing to help guard a caravan or help shepherd animals from a rural village to the
market, agree to carry the villages postage while patrolling the roads between settlements from
bandits. Higher level players may have responsibilities to the rulers of realms or are requested by
powerful political figures to meet with them, exchanges of presents, social considerations such as
needing proper clothing fit to meet with a count/countess, duke/duchess, prince/princess, king or
queen, all of which can lead to a player running around attempting to get something for someone far
outside of the typical, get the magical doohickey to defeat the big baddy. (Not that getting magical
doohickeys and defeating big baddies is a bad thing to avoid, just use some different ideas when
developing fed-ex quests.)

Favours can be an interesting tool for promoting subplots, it can be as simple as having the PC, or
NPC, aid one another at one point in the module thus opening the potential to see said characters
interact as allies later in the module, more complicated favours can vary between agreeing to engage in
a fed-ex quest, an exchange of services, even agreeing to help each other out of financial or interpersonal problems (a player may not even require payment, or vice versa).

A builder can create optional faction(s) capable of aiding the player out at different points in the module,
whether this be information, items, funds, or combat allies or factions can be designed to become
enemies under certain circumstances. Creating a reputation system in the module could be used as a
tool to send one faction or another in favour of the player, or use more typical quests or payment for
services (common for thieves guilds). Factions can really add another dimension to a module as the
player storms a castle with an army of allies, or has to hideout from a pack of assassins on his or her
back after annoying the wrong faction.

Sub-quests can be useful in making a simple story into something quite a bit more then it started out as, but
they can be a great deal of work and often require considerable thinking about whether they are necessary. A
module with poorly designed sub-quests can leave players wondering why they are bothering with a module
that makes no sense, demeans their vision of their character, or otherwise annoys the player instead of
engaging the player.
Avoid using side quests to pad out your module. A builder may try to compensate for inadequacies in their plot
by filling the module up with multiple side quests. This can confuse the player and lead to frustration as they
are distracted from the main plot line.
21

Minor side quest complications and climaxes should avoid overshadowing the climax of the main quest. The
main quest should be the most intense, present complications and consequences to the player; it ought to hold
the majority of space and time in the module.
Side quests should avoid being disconnected from the main plot, be either intrusive or introduce contradictions.
A player dispatched to quickly save a noble from assassination should not be encourage to rescue a toy from
the sewer, or deliver some knickknack to that shopkeeper down the street, or, worse, have a powerful NPC
give the player the quest to save the important noble while the NPC just sits at the tavern waiting for you to
report back. These kinds of side quests are frequent problems in modules and often end up undermining the
main quest.
Often good side quests are ones that are parallel to and support the plot, often the main quest. The question to
ask yourself when considering whether or not to include something in a module is: does this add or detract
from the plot? Nothing should ever detract from the main quest
(See Sections on Dialogue, Plot, and Sub-Plot for more details on Consequences in Modules, Sections on
Factions, NPCs, and Internal Logic related.)

3.5
3.5.1

Tips on Writing the Story

Retaining logic in the writing process

Whatever the setting or type of module it should have its own internal logic. If the setting is Medieval Europe
then having lasers and high explosives will break the internal logic of the module.
A brief example: Lets say your setting is in medieval Europe, no magic but a belief in magic, and the story will
take place in a semi-isolated village populated by illiterate, peasants (serfs to The Church) whom still entertain
some pagan religious beliefs. The story is based on your character being male, a low level paladin or cleric
referred to as The Inquisitor. Sent by The Church to investigate the accusations of a priest, of there being
persistent witchcraft of the worst kind. The PC must determine whether the priest is telling the truth, and
condemn some people to death by drowning or discover some other reason for the events you find in the
village.
The story and setting logic suggests that you dont allow magic of any kind to exist in the module, no NPCs
with powers, no magic items, no magical creatures, no references to places outside the experience of these
poor, backward, people should be present. The player should be informed that only non-spell casting classes
are appropriate. The main character should have instructions as to what to do (perhaps in the form of a letter
given to them at the beginning of the module). The most numerous NPCs should be peasants working their
fields, poor people with little if any use for coinage (barter system). The NPCs with power and influence in this
setting will probably be churchmen and wealthy landowners.
Keeping persistent internal logic in your module can go a long way toward helping the player to have a more
immersive and enjoyable experience.
3.5.2

Give a tone to your story

What is the tone of your story, realistic, serious, or humorous? Neither a setting, a plot, or a story, necessarily,
requires a particular tone but most modules benefit from developing a tone, sometimes two or more tones
depending on the length, subject matter, and realism of the module, to propel the mood of the module. Think
about how you want to tell your story, what types of plot hooks you may want to use to keep your players
attention, then consider whether one, or more, tones are suitable for your module. A humorous parody module
will want situations, NPCs, dialogue options, and other features a bit different from other modules attempting to
achieve a different end. If you are thinking of using several tones, it could be worth your while to plot out when
22

different approaches are best to use, humour used at the wrong time can take players out of their immersion in
your module, ruining it for them. If a situation is humorous then turns deadly serious, it can be a shocking,
powerful, experience. Tone can be a powerful tool in a story if used properly.
Example: A talented bard, Tenali, is doing her routine in a village tavern, she sings, dances a little, tells a few
tales, and later, Tenali chats up your pc funny girl - yet she is expected at the village down the road for a
marriage ceremony so she leaves letting you know shed love to see you again tomorrow night. You find her
murdered on the road to the next town, evidence of a slow, brutal, end. (Then, again, you could be an evil
character and be wishing it had been you who had savaged Tenali, then murdered her.)
In the example we see a light conversational tone with some humour and romance that leads into a dark and
threatening tone. This is one way of blending tones to give emotional depth to your story telling. With some
carful thought you should be able to come up with your unique blendings that will give your player the kind of
emotional context that will make it stand out to them.
3.5.3

Establish the content rating and respect it

What Content Rating do you envision for your module? Do you want the module to be fit for anyone to play or
are you interested in a setting and a story that requires some kind of mature to adult sensibilities? If you are
aiming at mature to adult content in your module, do you hope to engross people in serious thought about the
subject matter, or humour them, or just provide quintessential elf-porn and the like? Content Rating Groups:

Everybody, for audiences of all ages, fit for children.

Teen, fit for audiences around twelve to fourteen years old and up.

Mature, fit for older teens and adults; may include some adult sexual themes, increased thresh-hold for
graphic violence.

Adult, fit only for adults starting around seventeen to eighteen years old and up; adult sexual themes
and content are present, possibly graphic in nature, increased thresh-hold for graphic violence.

Extreme, fit for adults starting around seventeen to eighteen years old and up; may include adult
content often graphic in nature and copious amounts of graphic violence, sexual subject matter, drug
use and other extreme content not suitable for all players.

3.5.4

Avoid repetition

Repetitive content can come in many forms, here are a few things to look for:

Combat encounters that resemble one another, no variation.

o

Travel, as mentioned both above and below this section, can be very repetitive if it involves the player
walking through areas they have been in before but without any new content for them to encounter.
o

Keep combat encounters diverse, as mentioned in the balancing section.

Travel problems can be addressed with methods described in section 4.1.2 Travel

Boring NPCs who add little value to the module, who are not engaging to the player, this is particularly
true of NPCs given no dialogue, animations, or other interesting behaviours.

23

3.5.5

Either remove unnecessary NPCs or make sure that they have at least some variety in their
behaviours and interactions with the PC. See the Chapter 7 Adding Life to your Module

Stay consistent with the choices you have made

Build with consistency in mind, avoid making a module that flitters between multiple styles of writing, excessive
periods of inaction followed by equally excessive periods of action common to many modules that introduce
a player to a population center, have a quest giver, and a dungeon or evil boss and his/her minions to defeat
that tends to suggest poor pacing in planning the modules plot and any other jarring break between what
people have come to expect of a module or that encourages players to become inured of the modules plot and
progression.
3.5.6

Use of realism

Realism can benefit a module by enhancing the storys interpersonal relationships, atmosphere and internal
logic by appealing to a players critical thinking and decision making skills; however, arbitrary realism, with no
point to it, can hurt a module by forcing uncalled for tedium on the player. Avoid situations in which realism
intrudes on player immersion in your modules by assuming players will choose to do something only if it
appears to benefit them with no negative consequences, unless the story, or principle plot elements, called for
it in your module. Players ought not to be drowned down in superfluous details.

To use, and even whether to use, realism in a module is a matter of personal taste and preference.
Builders can answer this in any fashion they choose, just define what you consider "reality" or "realism"
in the context of your module, what the setting calls for.

Consistency, often referred to in this discussion as internal logic, is critical for players to feel that events
unfolding around them are plausible or not, as inconsistency can quickly destroy the suspension of
disbelief of players in your module. As long as the setting feels like a living, breathing world instead of
something artificial, a builder can get away with almost anything, but "reality" makes it easier for the
players to identify themselves with your setting and interact with it.

Builders should consider breaking the internal logic of their modules only if they feel it is necessary to propel
their story or plot(s) along, however, breaking the rules of logic can have serious, negative consequences if
handled poorly (more so if it happens repeatedly) as players feel they can no longer trust the rules of the
game, the nature of the modules story they are in, or the builders good judgment. Breaking rules can be a
good thing, but just because there is a rule to break does not necessarily mean breaking it is a good thing to
do.
3.5.7

Linear / Non-Linear

Choice, particularly Player Character (PC) choice, has much in common with linearity over non-linearity in the
design of a module. Builders will often find themselves considering giving player(s) choices about how to
complete the main quest, sub-quests, dialogue options, etc. Sometimes builders decide against extra PC
options in their modules. One method of building is not superior to another, just that some stories are better
told with a minimum of clutter while others gain quite a bit from added content as well as reinforcing
collaborative builder/player dynamics in your module; the added content, however, always comes with extra
work for the builder. Think about added content in terms of costs to benefits:

Does the module gain anything from that extra content?

What is the point of the extra content?

24

Answers to these questions can vary quite a bit, you may want to provide possible alliances (henchmen or
NPC soldiers to aid in battles), extra loot to add fun spending sprees at NPC shops, exceptional weapons and
equipment not available through merchants, added experience, enhanced role-playing options for specific
classes, particular types of behaviours (good-evil-ambivalent), humour/parody, romance, and so on a builder
may even consider allowing multiple endings to their module based on many factors, including PC death,
slavery, or simple failure.
Providing choice in a module can be a good thing, however it can be a pain in the butt to build, only the
person(s) building can really make the decision whether it is worth their time if in doubt do not hesitate to
make a few posts or ask peoples opinions about the merit of a little extra content.

CHAPTER 4

Designing Areas

Area design has both technical and aesthetic issues requiring careful consideration. The appearance of an
area can have a large impact on the players experience. The size shape and ability to enter and exit an area
can also determine whether an area is a constructive expression of your vision or a fun killer. Some basic
technical point to keep in mind.

Areas larger than 12x12 or 144 total tiles add time to loading between transitions in the module itself on
some lower end computers taking the player out of the immersive experience and slowing their playing
down.

Large areas can bore the player as they wander around, pointlessly, in a large area that has little or no
content.

Keep your story flowing for your players; large areas bog a player down with extraneous traveling.

Large areas increase the size of downloads for the player.

Unless there is a very good reason for an area to be large, avoid making large areas and your players will
thank you for it.

Each area has a purpose. Attempt to avoid creating areas that do not serve the story and the plot(s) for
your module. Areas that serve no purpose waste players time and energy on the pointless task of
wandering around aimlessly, unless the builder is specifically using added areas for exploratory
purposes and that opens up another series of issues that themselves relate to those areas having a
purpose themselves.

Exploration. Some players enjoy wandering around a little bit to see the world you have created and
discover its richness, if you have included somewhat large or extraneous areas in your module include
something worth seeing or doing in those areas to engage your players desire both to explore your
module and have fun while doing so.

Use identifying map pins for those locations a player needs to know so they can locate them easily.

Be aware of what real buildings and areas of the sort you are making contain. Buildings, for example,
are expensive, study what goes into making a functional building, functional: why are those rooms
there, what for?

Also remember to keep the size of interior areas realistic in relation to the outside / exterior setting of
that area. A house in a city should never contain an 8x8 indoor area, a castle might and for a dungeon
this is not an issue.

25

4.1.1

Area Lighting and Sounds

One of the keys to creating interesting and memorable areas is to use the appropriate lighting and sounds. It
is a common mistake of many novice builders to neglect this detail so make sure to take some extra time to
add this important element to your areas. Here are some suggestions to help get you started.

Cheerful and happy - make the area bright with soft colors like yellows and greens use gentle soothing
sounds.

Evil or Ominous - try lighting it with dark reds and browns and throw in some low moaning sounds.

Environmental - things like streams or a windmill, make sure to place the appropriate sounds next to
them. If your in a forest try adding some insect noises and bird calls randomly throughout the area.

Remember you can change the music that is played in each area. You can do this in both the area
properties and through scripting.

Adjusting the general lighting colors can give a new look to any area, even one using a familiar tileset. The
custom color palette is easy to use. Make a simple area and spend some time just playing with the colors.
There's no substitute for using test module to pop in and out so that you can see how even very small color
tweaks can change the look of an area. Play with fog color and distance. Smoky bar? Clear, cold winter
scene? Sorcerous tower room? Where you set the fog distance and color make a lot of difference. But
remember, when using coloured lighting, light of a particular color will modify the colors of not just your tileset,
but your placeables. A bright green light will wash the most vivid green right out of a bright green tree.
Tip:
Add placed sounds that can only be heard at certain times of day. Example:
Day Only
Seagulls - They rarely cry out at night. Making them day only makes ports feel more alive during
the day.
Crowd Noises - Even if you want them all the time, make two versions, with the daytime one
being louder than the nightime one.
Night Only
Frogs - Place near a pond. They're much louder at night.
Owls - A little obvious perhaps.
Specific Hours
Bells - If placed by something that resembles a bell tower, have them play at 9am, 12am, 3pm,
6pm, and 9pm. They help inform the community of the time, and players will soon realise they
don't play all of the time.
Cockeral - Have this one play the same hour that your module has designated as morning.
This will add to the players immersion and aid their suspension of disbelief.

26

4.1.2

Travel

As has been mentioned above, travel can be a tedious exercise in modules, attempting to find a way to make
characters move around should be an entertaining activity, not a choir. Methods to reduce tedious travel
include: specialized dialogues and scripts to enable the player to move from one area to another; town portal
devices (with preferably limited functionality to avoid being abusive tools); porters; carriage systems; area
transfer signs; secret doors; caverns and sewer system dialogues (see a dark area that is usable and insert the
appropriate dialogue); teleportation devices; or NPC guides that jump the player to the next location.
This is especially important if your module contains a large number of areas or areas that are sequencial in
nature.

CHAPTER 5
5.1.1

Non Player Characters in your Module

Designing NPCs

In nearly all cases the story told in a module will be told in large part by the NPCs, and henchmen. They are
the spokes people for the story. Use NPCs to encourage your players to immerse themselves in your story.
When you place NPCs into the module, think about what they are doing there, what their roles are, and how to
use those roles to engage your players.
Start with your key NPCs, those NPCs who get the storys plot rolling, propel the story through quests given,
and otherwise interact most with the player. What are the personalities of your key NPCs, what are their
motivations, their occupations, their relationships with each other and the player, and will, or how will, these
relationships change over the course of the story? If you dont feel you have a firm grasp of your key NPCs,
write your answers down into NPC biographies. Try to develop those situations that would intersect the life of
the PC with those of your NPCs.
Consider what relationships, behaviours, activities, and interests draw people to one another:

Family, simple contact with family whether nuclear, extended, or foster.

Work, co-worker(s) or those who have common workplace experiences.

Common interests, sports, drinking, carousing, politics.

Getting something from someone, friendship, affection, gossip, etc.

Common activities, such as going to the market, traveling a route, conversing with a neighbour.

Taking advantage of someone, using someone to your advantage, little to no personal regard for that
someone.

Occupations, those you tend to have dealings with, guards, special authorities, etc., not those that are
co-workers or those who work in the same field unless rivals of yours.

Humour, brings all kinds of people together for different reasons.

Sexual, little need to explain that people tend to find sex and things sexual interesting on multiple
levels.

27

Once your key NPCs have been created, think about all of the other kinds of NPCs who ought to populate your
module, everything from those who offer side-quests, to amusing NPCs who entertain players due to
humorous dialogues or activities, to those NPCs who are simply going about their normal day-to-day activities.
Once you have thought about what types of NPCs your module requires, start to populate your world as need
and fancy takes you.
A word of caution about using guards, guards are some of the most commonly used NPCs in modules, often
ridiculous numbers of them crowd the halls of castles, they crawl all around barracks and roads with almost all
of them repeating the exact same dialogue or none at all; more often than not, these guards do not have a
single thing to contribute to the story. Consider attempting to figure out how to use guards to effect in your
module.
Merchants are important NPCs in nearly every module; merchants supply PCs with necessary equipment to
get through the modules challenges and can often act as minor, even major, quest givers. Builders should use
the appropriate kinds of merchants for their module. Small towns, for example, often do not have very many
merchants and their wares are often not the best when compared to the selection found in a large city. A useful
tool to keep merchants interesting and unique in a module is to customize the items they have for sale. Your
players will appreciate the effort you put into these small things and it can be fun to create special equipment
that can in turn help you think about your setting and story to fine tune it as you work. Always remember NPCs
are not merely there to be there, but to immerse your player into your module.
5.1.2

Dialogue

Builders are faced with a dilemma early in the building process, whether to acknowledge the PC(s) as distinct
voices or, largely, as one voice when typing up dialogues for the player in their interactions with NPCs. There
are stylistic considerations, whether to use first person or third person (a few builders even attempt to use
second person, or other, more esoteric choices). Use whichever style you feel most comfortable with when
building, particularly as far as writing styles go and stick with it. Randomly changing the writing style used in
your dialogue can be very disruptive to your setting.
The question of whether to use only one voice for PC(s) or multiple voices is another animal to consider, it
being that multiple dialogues often involve considerable work in comparison to the former. Builders ought to
consider whether they need to have multiple dialogues to achieve their storytelling aim.
Try asking yourself a few brief questions:

Do those extra dialogue options lead to different results or are all of those options ending on the same
bit of dialogue line?

How often are different kinds of dialogue really required to tell your story the way you want to?

How attached are you to having multiple dialogue options?

If dialogue options all end up at the same destination, they have no real effect on the story progression at all.
However, if you do allow for different ends for your dialogue options then they do have an effect on how the
story progresses. If you feel it is critical to allow players to feel like they are as immersed as you can practically
manage in your module then it is worth your while to keep multiple dialogue options.
Some very basic dialogue ideas to consider.

Rather then have every commoner say the same thing try giving them one or more random sayings.
NPCs of differing social classes or occupation should have different one liners. Such as:
o

having a noble woman say Your odour is intolerable, away with you
28

an old lady walking in the park I was once young like you, I tell you, young people

a man or woman shopping in the market Oh, I have no money to pay a porteroh you are no
porternice dayuh, bye;

a lost person in a city I should really have bought a map

You get the idea.

Always try to personalize your NPCs. Remember Dialogues are conversations. People dont tell their life
history to everyone they meet, also, not everyone speaks alike. Use alternate or slang spelling to convey
different dialects, give your NPCs a unique voice. Try picturing the dialogue of your NPCs as if they were part
of an actual conversation between real people. Would a real person talk that way? It is a good idea to come up
with a back-story to your NPCs to help you personalize the dialogue, even if you are not going to give it to the
player.
Dialogue can make or break a module, poor spelling and grammar can hurt a module, poor dialogue writing
can doom a module. If the writing elicits negative feelings in its players (whether it be from excessive profanity,
out of character references, flip-flopping between modern and ancient speech conventions, a well meaning
builder working outside their native language, or, worse, a native builder butchering their own language) then
the builder has a problem. Use spell check, and ask for help in proofreading your work either from friends or
testers. To this extend there is one very useful tool available on the NWVault, called NW Spellchecker, which
allows you to review spelling within your module.
Tip:
An easy way to add to your conversations is to take advantage of the Other Action tab to
include sounds and animations to go with the written words. With the right choices you can add
humour; like playing the horse whiny at the punch line of a joke, or dramatic tension. You can
also make the NPC seem more realistic by having them play appropriate animations to match
their words.
5.1.3

Appearance

Whenever possible use custom items and clothes for your NPCs, far too many builders make the mistake of
using cookie cutter NPC appearances. By changing the look of your NPCs you add to the realism of your
module. Also special clothing will make the key NPCs seem more memorable. In the real world special
devices, identification badges, weapons, and, particularly, clothes have a significant impact on how people
behave towards one another, borrow these real world behavioural tools to enhance PC/NPC interactions.
Remember appearance has a major effect on peoples impression of each other, appearances, if used
properly, can make your imaginary world, your module, far more interesting and interactive.
5.1.4

Henchmen

Henchmen have an added value in telling your story in that they can actually travel with the player, interact
much more often (with the right scripting and dialogue) with the player, creating more opportunities for the
player to develop an emotional attachment to both the henchman and by extension your module. When you
are designing your module, consider whether you have a place for henchmen in the module, determine
whether you want your henchmen to have personalities, if so, then carefully work out the henchmens
personalities, dialogue, and place in the story, particularly whether they are themselves key figures in your
story arch. Henchmen, like all other scripting and dialogue intensive endeavours, can be time consuming to
build. Keeping henchmen alive without them being too powerful, so as to overshadow the player, is another
29

challenge; unless the henchmen are supposed to be the more powerful entity in the module. Aim to develop
emotional attachments for your players in your henchmen.
5.1.5

The Villain

Villains come in all flavours but a quality villain is a figure that evokes an emotional response in your player, a
response that screams through their conscience that this person, this creature, must pay for their crimes. A
player will not find a villain particularly vile or evil if they are only told, in bland, none descriptive language, that
the villain is, evil. To evoke a powerful emotional response from your player you need to use powerful,
descriptive, language to paint the villain black. A builder should show the player how and why the villain is a
villain, show their Evil actions at work, show the results of their Evil actions, make the player suffer at the very
hands of the villains cruel and brutal behaviour. It is in the details of how your villain interacts with your player
and those NPCs your player has grown to care about that you will find the lever that raises the players
emotions.

5.1.6

One caveat for builders to consider, does your module have a villain at all? Perhaps the player is the
villain or the action of the module barely calls for such a designation. If you have some kind of
antagonist, individual or group, for the player to come up against it is not necessary to have one or
more of them be The Villain(s) but it can be worth your while to be descriptive and or illustrative of why
the player ought to care about dealing with them at the end of a sword beyond the action itself.
Villains motivations.

A villains motivation can run the gauntlet of all human desires, even those deviant desires that fester in the
dark places of the soul; hardly human animals that indulge in their dark-side. The Seven Deadly Sins, listed
below, are an excellent place to start looking for motivations behind villains actions. Regarding motive and
villainy, different people have different opinions on the nature of villainous behaviour. People can see some
behaviour as understandable and forgivable, even as necessary or not villainous at all under extenuating
circumstances such as war; consider the choice between murdering an innocent child now, in cold blood, or
face a prophecy coming to pass that a great many atrocities will occur, on to eventual destruction of the world,
unless the innocent is killed would you consider a person striking the innocent child dead a villain? What if
the prophecy turns out to be a false reading of the true prophecy and the world is brought to destruction
because the innocent child was murdered, after the fact? Remember some people keep their motives close to
their hearts while others are quite outspoken depending on their personality.
The Seven Deadly Sins comprise of:

Pride, is excessive belief in one's own abilities, pride is also known as vanity.

Envy, is the desire for others' traits, status, abilities, possessions, or situation.

Gluttony, is an inordinate desire to consume more than that which one requires.

Lust, is an inordinate craving for the pleasures of the body.

Anger, is manifested in the individual who spurns love and opts instead for fury. It is also known as
wrath.

Greed, is the desire for material wealth or gain, ignoring the realm of the spiritual. It is also called
avarice or covetousness.

Sloth, is the avoidance of physical or spiritual work.

30

The scale of a villains actions can vary. The scale of villain is dependent on the aptitude, authority, position,
ambition, situation, and luck of the villain in question. One villain could be a vicious murderer, rapist, cannibal
and thief while another villain could be a crusading warlord seeking to expand his nations position at the
expense of his neighbours, which results in the deaths of tens of thousands. Both are villains but of different
natures. The scale of a villain goes a long ways towards establishing the scope of a module, but not
necessarily; the scale of a story can vary considerably based on the purpose and imagination of the storyteller.
Present the villain(s) in an as believable and as interesting a way as you can manage within the scope of your
module. A believable villain may appear evil, or be evil, because of ideology or psychological flaws or just
because they want to be evil.
Villainous people of the past and present often do not believe themselves to be evil; they pursue what they
believed to be a righteous cause, and from their point of view what they do is the right and appropriate thing.
Making villain(s) interesting is a two-front effort. There is the villains motivation(s) and their personality and
character quirks. Motivation for villainous people has already been addressed in this section but motivation can
be used as a tool to establish a villains personality: Is the villain a braggart, a silent person, a sociopath, an
antisocial person, a bully, a sadist, an effete fop or a dandy, a curious person, a coward, or a humorous person
or even appear as a nice, sympathetic, person? Does the villain use gesticulation while speaking, get antsy,
fidgety or are they calm, cool, collected, and in control? Educated or not? Well spoken or not?
Villains may exhibit one or more personality traits, complexity and moral ambiguity, or lack there of, can be
good in a villain.

Villain by physiological predisposition. Some people are born, or suffer a brain-affecting injury, that
leaves them prone to hostility, violence, and lacking in empathy; these people may or may not be semifunctional. In real-life these people are often referred to as suffering from permutations of Antisocial
Personality Disorder (ASPD), not all people suffering from ASPD choose to indulge their propensity for
violence and therefore are not villains.

Villain by madness. Madness, or insanity, comes in many forms and severity; any of these maladies
can cause a person to lose their ability to distinguish proper behaviour from improper behaviour
opening the door to all kinds of villainy. Mental illness may or may not be easily observable in people
thus making it even harder to deal with madness; an ill person may even know they are ill and want to
avoid discovery. Anyone in a position of authority, who is mad, increases the ramifications of their
madness as it spreads out to encompass those under their dominion.

Villain by possession. Such villains can be tricky, is the entity the sole villain or is the possessed a
willing partner (at some point?), or is the possessed innocent? Non-human entities may or may not
understand any normal forms of morality or these entities may have an agenda desires - beyond
mortal comprehension thus their activities can appear very strange, even demented.

Villain by misinformation, such villains often are convinced somehow that they are going to be turned in
by those they trust and decide to strike first, or may be making decisions based on false or erroneous
information.

Villain by choice, wilful villainy, they may or may not revel in their status, such villains often have
reasons for their chosen way of life that relate to financial gain or emotional/physical gratification.

Villain by lack of loyalty. These villains have sold themselves out for one reason or another to the
enemies of their friends, family, or leaders. These villains may also be out for themselves, ruthless, and
willing to use their position to their advantage to commit criminal acts; such as an officer of the guard,
or military, taking bribes or ordering the local militia out to plunder an out-laying village for its uppity
insolence.

31

Villain by necessity, lack of choice due to an enemys action(s), or perceived action(s). People, when
faced with an intractable foe that uses every means to its ends, often resort to similar tactics to not be
overwhelmed and defeated. Often referred to fighting evil, with evil or an eye for an eye. Such villains
often do not see themselves as such, under normal circumstances they would not do such things, they
feel they have no choice. Economic necessity can also drive people to villainy, often poor people with
no options choose to become bandits, outlaws, and pirates when times are bad crime goes up as
people get desperate.

Villain by circumstance, often through situations beyond their control. These villains are most often
beholden to some higher, villainous, authority who demands their followers to commit heinous, criminal
acts; such villains do not want to be villains but are villains due to their choice to follow a villainous
leader.

Villain by way of miscalculation, particularly poor choices made leading to villainy beyond what was
planned or even intended. A person, particularly in a position of authority, can make one or more
mistakes that take on a life of their own, leading to atrocity. If such a person does not take immediate
action to rectify the emerging atrocity, they are in part to blame thus are in part a villain not by intention
so much as of initiating and not defusing the situation. Of course, once a situation takes on a life of its
own it can actually be far beyond the control of the author(s) of the situation.

Villain as fool. Foolish people can always contribute to bad situations by creating them or exacerbating
them. The authority of a fool can go a long way toward explaining the scale of their authority, a foolish
head of household can lead their family to destitution and ruin (a very small scale villainy, fuzzy in its
place in villainy) while a head of state can lead their nation to economic ruin, senseless war, or
destruction at the hands of its enemies.

Villain believes themselves or their actions as good, not necessarily self-righteous. These villains have
good intentions, are attempting to do what they believe is right but not driven by any dogma, just an
agenda to the problems they see in life, however, the consequences of their attempts to help led
directly to hell on earth.

Villain as self-righteous crusader; these villains are most often religious fanatics or have philosophical
and or political beliefs driving their villainy. Many of these villains are upstanding, law abiding, people in
their private life, although some may be ruthless, or none of the above.

Villain by accretion of power and abuse of that power. When anyone has power, no matter how
upstanding they may be, or not, that power can corrupt them; leaving these individuals bent with the
potential for serious villainy of the worst kind.

It can be worth a builders time to consider what Content Rating they intend to release when contemplating their
villain and those things in the module that pertain to the villain. Graphic depictions of villainy ought not to be
included in a module intended for Every-body, hence fit for children, but released as a Mature audience
module at the very least.

CHAPTER 6

Using the Journal

If your module includes any quests or has a plot of any kind it is critical that you make use of the Journal. The
Journal is the key place to store and give out plot hooks, hints and track the players progress in the module.
Most players take for granted that they can turn to their journal whenever they need to, without adequate and
relevant journal entries the player will most likely get confused or lose track of what they should be doing. A
journals uses can vary:

32

A simple tool to remind players of useful and or necessary information about the setting, the plot, and
various sub-plots (quests) in the module.

A diary-like device to give insight into the mindset of a pre-generated character.

A method to convey information not easily conveyed by dialogue, such as a brief recap of events not
shown to the player.

A hint device to help players along, specifically if the builder fears the player will get stuck in a
confusing, complex, part of a module.

6.1

Non-Linear Quests Made Easy with Journal entries

Quests are an important and entertaining part of many NWN mods. In the simplest form of a Quest, the PC
encounters an NPC character who enlists the PC's aid in resolving some situation. When the PC succeeds, he
typically gets a reward of some kind.
This is often managed by setting a local variable through the journal entries used on the PC, which is updated
as each stage of the quest is completed. When the final stage is complete, the PC gets a reward. Such a
quest, regardless of how many steps are involved, is called a linear quest since the variable is updated from
one level to the next in succession until the end.
Bioware has provided a Journaling facility which, when used in conjunction with a Quest, helps the PC
remember where he is in the Quest process, and perhaps what he should attempt next. This is particularly true
of linear quests, which have a well-defined progression from start to finish.
Note: The below might get a little technical for beginning builders or scripters, and might not
apply if you are in the process of building your first module. If such is the case or if you feel a bit
overwhelmed by the following, dont panic! What may seem incomprehensible now will make a
lot of sense once you dive into the building process; set it aside for now but keep in mind that a
relatively easy method exists that allows for non-linear quest building. Revisit this section once
you feel a bit more comfortable and things will seem much clearer to you.
It is possible to use the Journaling facility not only to document the progress of the Quests for the PC, but also
to provide the local variable control function for the quests. The process of adding a journal entry also updates
a PC based local variable related to the Quest id. A description of the AddJournalQuestEntry() command may
make this clearer:

33

// - szPlotID: the plot identifier used in the toolset's Journal Editor

// - nState: the state of the plot as seen in the toolset's Journal Editor
// - oCreature
// - bAllPartyMembers: If this is TRUE, the entry will show up in the journal of
// everyone in the party
// - bAllPlayers: If this is TRUE, the entry will show up in the journal of
// everyone in the world
// - bAllowOverrideHigher: If this is TRUE, you can set the state to a lower
// number than the one it is currently on
void AddJournalQuestEntry(string szPlotID, int nState, object oCreature, int
bAllPartyMembers=TRUE, int bAllPlayers=FALSE, int bAllowOverrideHigher=FALSE)
Each time such a command is executed, a state variable is set on the PC reflecting the state of the quest as
represented in the journal entry just created. If the szPlotId of the command is "MyQuest" then the variable
takes the form "NW_JOURNAL_ENTRYMyQuest" with the value set in accordance with the specified nState
value.
Used in this way, the AddJournalQuestEntry() command becomes the state variable manager for the Quest as
well as documenting the progress for the PC. By appropriate setting of the bAllowOverrideHigher parameter,
the state can be made to reflect either the most recent state value, or the highest value the variable has
achieved. The latter represents a strictly linear Quest, the former an unstructured quest of some form, perhaps
with no well-defined goal, used primarily to record journal entries for situations encountered and possibly
resolved.
The bottom line, though, is that linear quests can be managed quite nicely by just using the Journaling facility,
without resorting to outside items or variables to control the progress of the quest. As each quest goal is
achieved, a new Journal entry is created with the nState variable increased by one. This sets the local variable
on the PC to a testable value used to determine the state of the Quest.
Unfortunately, that is not the whole story. Some Quests, often the larger, more complex ones, are nonlinear.
This means that the individual goals within the quest, leading to the final conclusion of the Quest, may be
achieved in a fashion other than an orderly progression from goal1 to goal2 , etc to the end as they would in a
linear quest. Many different orders are possible, all resulting in the same ultimate result. Some goals may be
completely independent of each other, and may be achieved in any order. Others may have dependencies on
certain goals to be achieved before they are attempted, but be independent of others still.
From this it is clear that the simple state conditions provided by the AddJournalQuestEntry() command will not
be sufficient to handle our Quest. We must be able to test for any particular quest goal having been achieved
at any given time - a capability beyond that of the existing AddJournalQuestEntry() command which provides
only a single state value for its quest-related local variable at a time.
What we need for this is a variable which can carry the state of all goals at the same time, so any given goal
can be tested for at any given time. Bit-wise variables meet this requirement.
Instead of testing for the value "n" (which we put in the nState parameter) we will test for 2**(n-1) that is, 2 to
the n-1 power, which can be expressed in code as 1<<(n-1) (1 left-shifted n-1 bits). Thus the nState sequence
34

1 2 3 4 conforms to the bitwise variable values 1 2 4 8. Why do we do this? Because by "or"ing the bitwise
values together, we generate a set of discrete bits and retain ALL the states we have entered. These can be
retrieved again by "and"ing the required bitwise value with the bitwise variable. If the value had been put in with
the "or" operation the "and" operation would retrieve it. This is a fairly common programming trick.
To make this work, we write a special #include script containing a function to replace the
AddJournalQuestEntry() command. We will call it addJournalQuestEntry() (lower case leading "a") and it will
take all the same parameters. Here is what it will look like:
// Filename: bit_journal
void addJournalQuestEntry(string szPlotID, int nState, object oCreature
, int bAllPartyMembers=TRUE, int bAllPlayers=FALSE, int bAllowOverrideHigher=FALSE)
{
int nBitVar = GetLocalInt(oCreature, "Bit_"+szPlotID) | (1<<(nState-1));
SetLocalInt(oCreature, "Bit_"+szPlotID, nBitVar);
AddJournalQuestEntry(szPlotID, nState, oCreature, bAllPartyMembers
, bAllPlayers, bAllowOverrideHigher);
}
What we did was set the appropriate bitwise variable value, and continue with the normal journal entry. So
everywhere we are now calling AddJournalQuestEntry() we will change the first "A" to "a" and proceed (we will
have to put #include "bit_journal" at the start of every script that uses the new function as well). Here is an
example for a routine in the Caereena mod called "it_spherebab3_aq":
void main()
{
object oItem = GetObjectByTag("it_spherebab3");
object oPC = GetItemPossessor(oItem);
AddJournalQuestEntry("prelude", 4, oPC, TRUE, FALSE);
}
becomes

35

#include "bit_journal"
void main()
{
object oItem = GetObjectByTag("it_spherebab3");
object oPC = GetItemPossessor(oItem);
addJournalQuestEntry("prelude", 4, oPC, TRUE, FALSE);
}
That's half the solution. Next, we have to fix the scripts which test for the state. We will do that the simplest
way we can ...here is a suggested transformation for the script "sc_babjourn11", also in the Caereena mod:
int StartingConditional()
{
object oPC = GetPCSpeaker();
int nInt;
nInt = GetLocalInt(oPC, "NW_JOURNAL_ENTRYKoboldWar");
if (!(nInt == 11))
return FALSE;
return TRUE;
}
becomes

36

int StartingConditional()
{
object oPC = GetPCSpeaker();
int nInt;
nInt=GetLocalInt(oPC, "Bit_KoboldWar");
if (!(nInt & (1<<(11-1))))
return FALSE;
return TRUE;
}
Note the two things changed:
"NW_JOURNAL_ENTRYKoboldWar" became "Bit_KoboldWar"
nInt == 11 became nInt & (1<<(11-1))
Note the parentheses that were added - they are required by operator precedence rules.
Using this facility in this way, any particular state can be tested for at any particular time, making the control of
nonlinear Quests by Journal entry commands possible through the use of bitwise variables.

CHAPTER 7

Using Scripts to Design Efficiently

One of the primary challenges module builders face is trying to create a module as efficiently as possible. The
term efficiency in module building refers to the attempt to require as little CPU use as possible, during the
running of the game on client machines, minimizing module file size, and maintaining flexibility of script
systems in the module. Efficient design techniques will ultimately lead to improved game performance for
clients, smaller download sizes, and ease of building.
This chapter should serve to help the builder better understand basic practices that will lead to increased
design efficiency. Primarily, a discussion of the use of Variables, journal entries, and user defined events will
outline basic ideas that can drastically increase the efficiency of ones module building and play.

7.1

How to Keep Tracks of Variables

To begin this discussion, it is important that we have a thorough understanding of the meaning of the word
Variable. Variables are used to represent unknowns. Often we don't know the value of the Variable when
writing a procedure, but we rely on a calculation to determine the value. Variables are what allow us to perform
complex mathematical calculations, write multi-purpose functions, and do a large variety of things. For those
that are somewhat unfamiliar with programming jargon, the word function represents the ability to allow you to
create chunks of code(script) that perform a specific task. Bioware supplies a large library of functions in the
toolset. These built in functions are there to perform a number of actions that programmers in the community
expect to be part of the NWN programming language. Ultimately, Variables have changeable values that are
determined by the functions that assign their value.

37

The ability to assign a Variable is a very powerful tool for many tasks in module design. In fact, one of the most
common tasks that builders use to ensure efficient use of data storage (perhaps for quest state progress,
persistency, etc) involves the setting and reading of Variables. In basic practice, Variables can be declared and
initialized on the same line. Initializing a Variable ensures that it has a default value, thus keeping it from
returning a null value.
In terms of efficiency in scripting and building, Variables have nearly infinite usage. However, the more
Variables that are stored on items, objects, or even in a module or script, the more size the files will take when
saved and the more processing the game will take. A particular example for a place to take caution with the
storing of Variables would be the use of Variables stored on items in a Player Characters (PCs) inventory for
persistency of data. The greater number of Variables stored on a PCs item, the larger the .bic file becomes.
The .bic file is the actual saved file in your PC vault that represents all the data that makes up your PC. The
larger these files are, the longer it takes to load the player vault and that specific PC for future games and the
more data the client software must transfer around while running the module.
For Persistent Worlds, large .bic files will cause a very slow load of server and local vaults and this can be
quite frustrating for players. It would be most unwise to declare Variables that store the same data repeatedly
in various places and equally unwise to store many unneeded Variables as this will eat away at game
resources during play. Therefore the wise builder will be sure to assign Variables in such a way that any single
Variable can have as many uses as possible and in as many situations as possible, but avoid assigning any
given Variable value in more than one location.
A couple of possible solutions to maintaining Variables in a more universal way are to write them directly to a
database using campaign variables, storing them on items in the PCs inventory (so long as the item is non
transferable), or writing the variables to the module itself. Obviously the method of choice depends on the
function the data will serve in the future and the need for persistency of data.
Another issue concerning keeping track of Variables during the building process is that most of us can not
remember all the Variables we end up using in our building projects. Therefore, it is prudent to use a log of
Variables for any one module. One of the best ways to do this is to include a list of each Variable with
descriptions of its functionality and use in the module. This can be done with a text file or even in the module
itself by use of a commented script. Keeping track of all the Variables and how they are used is much easier if
documentation is kept during the building process!

7.2

How to Use Journal Variables

One of the most common uses of Variables in modules is for Journal Entries. Specifically, using variables to
add journal entries, remove them, move them to and from completed status, etc. This is done to keep track of
PC progress through various plot procedures and to keep track of quest status.
The main functions used for Journal Variable tracking are the AddJournalQuestEntry and
RemoveJournalQuestEntry functions. With these two functions, one can easily set journal entries for single
PCs, groups of PCs, or every player in the module.
Another common use of Journal Variables is to track conversation dialog options in NPC given quests.
Whenever a journal entry is set on a PC, a Local Integer is also set on the same PC with the name of
"NW_JOURNAL_ENTRY*" where * is the tag of the journal entry that has been added. The integer value that
is set, is the quest status number that is set with the journal entry; in other words the value of entry ID from
the function. The usefulness of the Local Integer is that you can use it to check for Text Appears When
situations in the NPC dialog. This allows you to make sure certain dialog options only show up after the PC has
completed the proper sections of the quest; thereby allowing the builder to control quest flow. You can also use
this to make sure that an NPC will not give the quest again once the quest is repeated by disallowing the quest
conversation to fire once the Local Integer is equal to the entry ID of the completed quest journal entry.

38

The most important things to remember when using Journal Variables are the following:

7.3

You must have a pre-written journal entry for each entry ID variable that you set and the tag of your
quest journal entries and the entry ID number must match that in the AddJournalQuestEntry
function.

You must be careful as to your decision whether or not to allow the Journal Quest Variables to be
overwritten by lower values, as this can lead to backtracking in quest conversations.

User Defined Events

User defined events are a very useful tool for creating special scripted conditions for behaviour of NPCs. The
user defined event is used in conjunction with the OnSpawn script of the NPC, which has commented functions
that will make calls to the user defined event if they are uncommented (commenting means adding // in front of
a line of code in NWN script, uncomment means removing these //). Typically the user defined event script is a
switch/case statement that does something different depending on the signal (numerical value) sent to it by an
event, (usually the OnSpawn event) which calls the script. The user defined event makes it very easy to retain
the default behaviour of an object while adding custom mannerisms of your own.
To make efficient use of this, variables can be used to ensure that a single OnSpawn event and corresponding
user defined event can handle all possible behaviours for all possible creatures in your module. The wise
builder would wish to minimize the number of scripts running in their module. The goal here is to minimize file
size of the module, minimize complexity of having many scripts to do simple tasks, minimize difficulty in
tracking down what script does what, and of course reducing time, searching through a ton of scripts to debug
code.
Using a singe OnSpawn event and a single user defined event for all NPCs will help with this. In order to use
only two scripts to control the behaviours of all your NPCs, your events will have to utilize if statements, if not
other scripting techniques, to call for the behaviour set matching your NPC type. The control here is best
assured by calling a local variable from the NPC itself and checking for that variable in the if statement
controlling the behaviour set in the user defined event.
For example, a builder could have a section of code in the user defined event that represents a perception
event for that NPC which is triggered by a switch statement in the OnSpawn event. The if statement could
check for the local string herbivore on the NPC calling it. Any NPC that has this string would then exhibit the
desired behaviour the builder has coded in. Successive sections of code checked by if statements for variables
on the NPCs could be set up in a similar fashion to control the behaviour of about any type of NPC the builder
desires. The beauty in this method is that all behaviour is handled from one script.
Of course, the more advanced scripter would likely prefer to set up an include function of their own and call to
the include file from within the user defined event to manage behaviour. This may be preferable to some
builders because a single include could have a separate function created for every behaviour type. This makes
changes to behaviour patterns for specific NPC types a bit more manageable because each behaviour will be
set in its own function code block.

CHAPTER 8
8.1

Adding Life to your Module

Adding Color / Flavour

Color (flavour) is a catchall term referring to elements in a module being colourful, in some way, so as to
entertain players. Color, thus, often refers to special NPCs who help engage the player, or specific items that
can provoke the player to think about the setting of the module, or brief messages sent to the player via
39

scripting adding flavour to an area. Color is similar in nature to detail but different in that color specifically refers
to entertaining the player as opposed to simply providing a more engrossing playing experience.
Detail, as mentioned just above, refers to immersing the player in the modules setting, whether by providing
NPC portraits, special descriptions for NPCs, items (such as unique books, weapons and armour with module
specific names and histories), placables, and appropriate lighting and sounds. Especially unique items with
special powers, and histories, often endear a module to role-play conscious players. Observant players will
notice and appreciate detail in a module and the extra effort and care a builder takes to add such content into
their module. Keep in mind, however, that some people will not particularly notice these small things. Consider
whether and how much detail is important to you in your module, also consider what type of audience(s) you
aim to appeal to for some guidance on how to use detail to its best effect for your module. Remember to
include sounds and lighting, even darkness, into those areas of your module that should have them, a dark,
dank, limestone cave sounding of bats and dripping or a loud bawdy tavern goes along way toward giving a
module proper atmosphere.

8.2
8.2.1

Frequent NPC behaviour (pickpocket, guards, complex animations)

Ambient Animations Tutorial For NWN1!!!

In the following we will walk readers through the process of creating some typical ambient NPCs, namely the
"stay-at-home" and the "townwalker" NPCs, and also the use of the tag NW_INTERACTIVE on peaceable
objects.
Let's begin by creating an NPC in his home:
Tell the wizard to create a new city interior area and make it tiny (2x2). To keep things simple, we use the
"Home Lower1" from the "groups" section. (Paint Terrain - groups - Home Lower1 2x2)
This nice, little home has a stove, a table with two chairs, a desk on which lies a book with the Bioware logo,
and a big comfortable chair next to a bookcase.
Now let's make an NPC to live here. For the purpose of this little walk-through I suggest using one of the
standard NPCs that you find in Paint Creatures - standard - human. "Commoner, male" will do nicely. Put him
midway between the dinner-table and the large chair. To give him a bit of personality, give him a new name. It
is also a good idea to make a unique tag for him at this point. You do this by right-clicking on him and choosing
"properties". This brings up his properties "basic" tab, where you can also change the appearance, and assign
or make a conversation for him.
Our next step is to give him the correct "Spawn In" condition, we do this by using variables (that way you don't
need to make a copy of the default OnSpawn script). To do so just right click on the NPC, select "Variables"
from the pop-up menu, put one of the following in the name field, X2_L_SPAWN_USE_AMBIENT_IMMOBILE
or, X2_L_SPAWN_USE_AMBIENT set type to int and value 1, and click the Add button.
We want our "stay-at-home" NPC to use "ambient animations". There are three kinds to choose from:
1) IMMOBILE.
2) MOBILE.
3) IMMOBILE/MOBILE CLOSE RANGE.
The first option (IMMOBILE) will make an NPC play random animations while staying rooted to the spot where
he was spawned. This is useful for guards and others who should never move anywhere.
40

The second option (MOBILE) will make an NPC play random animations and wander about freely. We use this
on "town-walkers" who may also enter areas with TAVERN_ and SHOP_ waypoints. More of that later.
The next step is to put down some waypoints. Click the "Paint Waypoints" button on the extreme right in your
toolset and find the "Generic Stop Waypoint". Place one of these in the vicinity of the table, another near the
comfortable, big chair, and a third near the desk. He will now occasionally walk to one of these. We're
beginning to get some varied action already! Finally, put down the HOME waypoint wherever you please. It just
needs to be in the area. This waypoint does three things: It changes the animations played by the NPCs a little,
if the NPC was spawned with mobile animations it makes him leave his home during the day (though there's a
snag to this which we shall get back to later), and it makes him use the "x0_npc_homeconv" when he sees a
PC. The "x0_npc_homeconv"??? That's right, you don't have it. But you can make it yourself simply by writing
a one-liner conversation and giving it that name. What the NPC says when he sees a PC entering his home is
completely up to you.
When using a waypoint, there is also one additional variable that can be used to ensure that the NPC actually
faces the direction the waypoint is pointing in. This variable is called X2_L_WAYPOINT_SETFACING and
needs to be added as a variable to the waypoint, right click on the waypoint, select "Variables" from the pop-up
menu, put the following in the name field, X2_L_WAYPOINT_SETFACING set type to int and value 1, and click
the Add button.
Now we need some placeables. There are two chairs around the dinner-table which are unfortunately a little
too close to the table for us to do anything with. However, in "Paint Placeables - standard - miscellaneous
interior" there is a chair that looks exactly right. Place it near the table, and because it has the tag "Chair" the
NPC will occasionally decide to go and sit in it for a while. If you also want PCs to be able to sit in it you can
make it useable and open it's properties/scripts page, then scroll down the list of scripts in the OnUsed slot
until you find "x2_plc_used_sit".
We can also make the NPCs sit on the static chairs that came with the area by using an invisible chair. If you
are using CEP you will find it in "Paint placeable objects - Civilization interior - Furniture - Chairs & Stools".
Place it in front of the big chair near the bookcase, rotate until it faces the right way, and carefully slide it as
close to the chair as you can, without having it "jump" on top of it. It must remain in touch with the floor;
otherwise the person sitting in it will face east, which 3 out of 4 times is wrong. Now, change its name and tag
to "Chair", right-click on it and "Edit Copy" so that you can use it in other places in your module. Make it "static"
(properties/basic page) if you don't want PCs to use it. If you don't use CEP you can use the invisible object in
"Paint placeables - standard - miscellaneous" instead, but this will always make the sitter face to the east no
matter how you rotate it.
Time to make some NW_INTERACTIVE placables!
NW_INTERACTIVE divides all placeables into three groups:
1) Placeables with open/close animations that have inventories.
2) Placeables with open/close animations that don't have inventories.
3) Placeables with activate/deactivate animations.
Common to them all is that they must have the tag "NW_INTERACTIVE" and they must not be static. The first
group must also be useable, otherwise it won't have an inventory, the other two need only not be "static", but
can be useable if you wish. Right-clicking on the placeable and choosing "properties" will open the "basic" tab
where you can change these states. Group 2) also needs to have the "will save" set to 1. This group is fairly
small and you probably won't be using it much since it consists mainly of trap-doors and secret wall-doors.
Let's start by putting a standard armoire to the right of the desk. We open it's properties, and noticing that it
already has an inventory, we give it the tag NW_INTERACTIVE. That's all we need to do in order to make our
41

NPCs occasionally walk over and open it (or close it as the case may be). There is a small trick we can play on
it, though: If you uncheck the "useable" box and set it's will save to 1, it becomes a member of the second
group! Our NPCs will still open and close it, but players won't be able to do anything with it. The armoire won't
even light up when they cursor over it. Useful if you like to give the player something to wonder about!
Now you can place a trapdoor to the left of the stove. There are two different to choose from in the "Secret
Objects" section of the placeables menu, the topmost is the one best suited for this interior area. Opening its
properties we find that it is already set to non- "static", so we give it the tag (NW_INTERACTIVE) and set the
will-save to 1. Here, too, you can uncheck the "useable" slot so that only NPCs can interact with it. I don't
recommend leaving this trapdoor for players to find as they would probably be more aggravated than amused
at finding a "secret trapdoor" that does nothing.
Next we need some placeables from group three. This also consists of lighting placeables, and luckily CEP
placeables work fine with NW_INTERACTIVE, so there's several to choose from. Find the crystal ball in
"Trades& Academic & Farm" and place it on the little table next to the big chair. Don't place it right in the
middle of the table, though. It needs to be closer to the edge towards the room so that NPCs can reach it.
Open its properties as before, give it the tag, and uncheck the "static" box. When activated by an NPC it will
now begin to rotate. Unfortunately, if you make it "useable", nothing will happen if a PC uses it. Open its scripts
tab to find out why - there is no script in the OnUsed slot! Do you remember what we did with the chair to make
it possible for PCs to sit in it? Let's try the same here: scrolling down the list of possible scripts in OnUsed we
find "x2_plc_used_act", and voila! The crystal ball works!
The room needs a little more light, so why dont we put a candelabra somewhere. I'll leave you to decide where
you want it yourself. As before, we open its properties to give it the tag "NW_INTERACTIVE" and make sure it
isn't static. This too can be made useable for players, and this time we find that it already has a script in
OnUsed called "nw_02_onoff". Good thing, because we're getting tired of all that scrolling down the lists.
And that should be all except... there's a fourth group of placeables, isn't there? What about all those
placeables that dont have any animations? Well, we can give these too the tag NW_INTERACTIVE and
uncheck "static". The NPCs will then go up to it and play the GET_MID animation, but of course nothing further
will happen. I'll leave it to your own imagination to think of placeables to do this with, except for one: the
invisible object that you find in placeables/miscellaneous. Put it on the kitchen stove, give it the tag, and
uncheck "static". This will make your NPCs interact with something that normally can't be interacted with.
I should also mention NW_ALTAR, which is a tag you can put on things you want your NPCs to worship.
Normally that would be altars, of course, but you could also give that tag to an invisible object in front of the
king so that his people will show proper respect. Just don't spawn him with ambient animations, or he will start
worshipping too, which looks silly.
Another thing that needs mentioning is that you must uncomment line 141 in the OnSpawn script :
SetAnimationCondition( NW_ANIM_FLAG_IS_CIVILIZED);
if your NPC does not belong to one of the player or humanoid races (orcs and goblins are humanoids, demons
are not). Make sure you save the script under a different name if you do so, otherwise the toolset will ignore
the original OnSpawn script and use this one for all NPCs, add this new OnSpawn script in the events of the
non-humanoid NPC that you wish to use.
In case you're now thinking that NW_INTERACTIVE is the best thing since sliced bread, here are some
downsides:
Placeables don't play the sound they should. E.g.: a fountain doesn't make a running water sound and torches
can't be heard.
Lighting objects light up, but don't change the area lighting. This can look very silly in a "torch-lit only" area.
42

Tagging doors as NW_INTERACTIVE doesn't work.

There is no way to control how much or little an NPC will interact with NW_INTERACTIVE placeables. You can
wait around forever before they do it, or they can get completely stuck opening and closing the same thing over
and over again. I can tell you that they seem to prefer talking to other NPCs and sitting in chairs over using an
NW_INTERACTIVE, though.
Finally, George Zoeller has earlier mentioned in the Scripting Forum that NW_INTERACTIVE was made by
Floodgate for Shadows of Undrentide, and that it is not officially supported by Bioware. (So don't complain to
Bioware about it.)
End of walk-through for "stay-at-home" NPCs.
Now for some "townwalkers"!
We make these by making a new version of the default OnSpawn script nw_c2_default9, and uncommenting
line 119 which goes (I.e. remove the // in front of line 119 in the NWN script):
SetSpawnInCondition( NW_FLAG_AMBIENT_ANIMATIONS);
Once again: RENAME THE SCRIPT FIRST! Then put it in the OnSpawn slot of your townwalkers properties.
The NPC will now chat with fellow NPCs and wander randomly about, except... he isn't going to wander very
far. He needs to know where he is supposed to wander, and for that you must place some Generic Stop
Waypoints. Find them among the standard waypoints and put them in all places that you think he should visit.
The Stop waypoints can't be too far apart. In our experience 20 meters between is about right (One area tile is
10x10 meters).
You can of course give the NW_INTERACTIVE tag to outdoor placeables too. An example: Place a barrel
somewhere, change it's name to "Trashcan", remove the treasure-scripts from it and give it the
NW_INTERACTIVE tag. Another idea is to put invisible objects with the tag on top of terrain features like
fountains and wells. And if the NPCs get weary from all the walking about they can sit on benches and other
things with the tag "Chair".
The "townwalkers" will also enter areas that are adjacent to the one they were spawned in which have
TAVERN- or SHOP- waypoints. So if you have some of those in your city or village you'll want to place these
waypoints there. There is a nasty snag to this, however: they never come out again. The reason for this is that
the engine is saving CPU power by dropping the NPCs AI-level to very low when there are no PCs in the same
area as the NPC. This makes them "forget" to leave the area they are in (unless there's a PC there). There are
some ways around this, the easiest being to write this line in the OnSpawn script (The one you've already
renamed, NOT the default Bioware script!):
SetAILevel(OBJECT_SELF, AI_LEVEL_LOW);
This will force the engine to always treat the NPC as if there was a PC watching him. The problem is that the
NPC will now be a constant drain on the CPU, instead of only taxing it when there are PCs around. This is
something you should do as little as possible, especially if you are building a PW or very big single-player
module.
If a townwalker starts his life in an area with the HOME-waypoint he will leave it during the day and return to it
at night. This too suffers from the snag I just mentioned: if there's no PC around, nothing happens. The
solution is the same: SetAILevel.
In addition to luring townwalkers to their areas, TAVERN and SHOP waypoints make NPCs play other
animations than they would otherwise. (There's lots of drinking and laughing going on in taverns).
43

We have seen some posters express concern that NPCs could start walking through several areas to get to
TAVERN, SHOP or STOP waypoints far from their home, in our experience this does not happen.
End of walkthrough for "townwalkers".
One type of NPC you may have noticed in modules you have downloaded is the merchant who is at the
outdoor marketplace during the day but goes home at night. You can make your own by placing a POST_
waypoint and a NIGHT_ waypoint. If your merchant's tag is "merchant1" the tags of the waypoints should be
"POST_merchant1" and "NIGHT_merchant1". Here too you must make a special OnSpawn script, and this
time you "uncomment" line 95:
SetSpawnInCondition( NW_FLAG_DAY_NIGHT_POSTING);
Can you guess what happens if there is no PC in his home when it is time to go to work? That's right. I'm sure
you can guess the solution too! Are you wondering exactly how many NPCs you can have with their AI-level
set to low? Me too. I currently have 29 of them in my module which is at 31meg unzipped (growing very
slowly). It is still running smoothly, but that's all I can say.
Before finishing I'll just mention what I think is the easiest way to place ordinary waypoints for guards etc: Leftclick on the NPC, then right click on the spot where you want his waypoint to be. Create Waypoint. Right-click
again where the next waypoint should be. Repeat as often as you like.

8.3

Creating original traps

What deadly dungeon is complete with out a good set of fiendish traps to torment and befuddle the PC. Traps
can come in a variety of types. There are traps that hurt the PC, slow them, misdirect, or immobilize them. It is
important to remember that players expect to be able to disable or circumvent most traps with thought and
foresight.

Damaging Traps: These are the classic device used most often to wear down the PCs and cause them
to use up precious healing and curing resources. They can be deadly but that is usually reserved for
higher level settings. Most damaging traps use some sort of trigger to set them off, this trigger can
usually be avoided or disabled by rogue type characters. The NWN toolset includes a variety of premade damaging traps for your convenience.

Slowing Traps: This variety has two purposes. One is to slow the PCs progress in the game in general
while they try to deal with the trap, the other more common use is to slow the movement and attacks of
the PC during combat or ambushes. Here again the toolset comes with several pre-made traps that
have slowing effects of the second type. For slowing traps of the first type some scripting skill and
imagination are required. The idea being to occupy the PCs for some period time while they deal with
the trap.

Misdirecting Traps: The idea here is to confuse or mislead the PC temporarily. Often teleport devices,
hidden doors and moving walls or floors are used in this capacity. With some imagination and scripting
skill this category of trap can also mislead the PC regarding other facets of the area, module or story. It
is important to remember that the confusion is meant to be temporary, otherwise the player may just get
frustrated and quite playing your module, so you should always provide the opportunity to gain true
information and defeat the misdirecting trap.

Immobilising Traps: These may not be suitable for NWN or CRPGs in general but are traditional in PnP
games. They serve the purpose of confining and restricting the movement of the PC. Often a pit or
sealed room is used for this purpose. One classic immobilising trap is the door and pit. There is a door
that tempts the PC to open it. When the door is opened a trapdoor opens in front of the door dropping
anyone standing close into a pit. Another example is the sealing room, usually a small room with 2
44

doors, once the PC enters the room both doors close and lock sealing the pc in the room until one of
them can be opened again.
Combining the different types of traps is an excellent way to challenge your players.

Damaging and Slowing traps: A slow spell or similar effect combined with a damaging trap that could
otherwise be dodged or avoided works very well.

Slowing and Misdirecting traps: A teleport device that moves the PC into a maze can both confuse and
slow the players progress.

Immobilising and Damaging traps: It would be very simple to make that pit in the example above deep
enough so that the PC takes damage from the long fall or have the sealed room contain a dangerous
monster or slowly fill with noxious gases.

8.4

Visual effects, sounds and lighting

The ability to add special effects, sound and lighting to your module give you all the power of a Hollywood
movie producer to aid in telling your story. Practically every movie and T.V. show takes advantage of the
natural responses we all have to these. With the introduction of NWN2 it is now possible to create your own
custom effects as well. With the right bit of flash and bang an otherwise ordinary scene becomes dramatic and
exciting, that dull area takes on a life of its own. Is your final boss fight less than awe inspiring try adding some
special effects to the moment?

8.4.1

Making your important scenes more dramatic and exciting

This is it, the first appearance of you main villain! They could just walk into the room and give the obligatory
speech or they could enter with a flash of light and a thunder clap. Which do you think will make more of an
impression on you players? Whenever there is something important happening in your module there will be an
opportunity to enhance it with the right combination of effects and sounds
Special visual effects can be quite fun to play around with once you learn how to create them. However you
dont want to go overboard with them. The module doesn't need a flash at every bend and in every other area.
Don't over use them or they become a distraction and loose their dramatic impact. Don't put 10 of them into
one 2 second scene. They will overlap each other and the player will miss out on the flashy parts. Brief well
timed bit of flash and noise can be far more effective than a dozen things all happening at once.
If there is a caster or two in the players party they will see plenty of visuals along the way. The most effective
ones are the ones they aren't expecting. If you can make your module so the party casters create most of the
visuals and the creatures in the module hardly ever do, then when the PCs bump into that one NPC that fires
them off he will seem much more important to everyone (so make sure he is).
Remember when that movie Alien first came out? The glimpses you saw of the monster were so short that it
always left you wanting to see it again. It was a very effective visual...more so because it was so short than
because it was flashy. They should be as long as necessary to be displayed and make your point and as short
as possible to avoid forcing the players to sit thru them. The longer they are, the more boring they get. The
more frequent they are, the more annoying and uneventful they become.
Use the smaller ones as well as the larger ones and more often too. Many people are so impressed with the
big ones that they just stack up all their favourites and run them all at once, everywhere you go. Save the big
ones for when you want to make a special point in an important scene or battle or event. They will have more
impact that way.
45

Whatever you do, don't give your players the ability to fire off big visuals whenever they want to. It is a real
mood killer. That fireworks wand seems like a great idea at first, and then everybody gets one and ugh...
For some players and builders the level up effect is over done. If you are in a reasonably quiet area and a party
member levels, it kills the mood. After the big battles this can really come into play. You just spent a long time
battling something ferocious with all kinds of flashy spells and visuals going off and then when it's all
over...BAM three or four party members level up and the "winding down after the battle" mood is gone.
Tips:
Too much of a good thing; dont over use the effects it dilutes their impact.
Save the best visual effects for the most important scenes.
Avoid throwing visual effect into every common event in the game.
Make sure your special effects match the scene and are timed to match the action.
Visuals are great so use them, but use them sparingly. Play around with them ferociously during building until
you get bored with them, then start adding them to your module.

CHAPTER 9
9.1

Adding Combat Elements to your module

Encounters

Enemy re-spawning. There are a number of considerations involving re-spawning enemies, where they should
re-spawn, at what rate should they re-spawn, and whether certain boss enemies ought to re-emerge at a later
stage after it had seemed the player had defeated the villain (not too common in NWN modules we have seen
but certainly possible). The setting and the story can go a long way toward answering whether to use respawning scripts or fixed events, such as multiple villain models at different points in the plot progression.

A module taking place on a large battle field over the course of many days ought to have re-spawning
battles, modules set primarily in enemy territory such as dungeons, evil or haunted castles, graveyards,
wild lands, or in the Underdark all offer up excellent places to plant re-spawning enemies.

On the other hand, there are times when re-spawning enemies makes little to no sense, a small cave
turning up groups of goblins every few minutes, or a road always under attack by hoards of bandits
between two little farms, etc., after each area has been cleared there should not be that many goblins
or bandits in such small areas, such scenarios evoke ridicule from players.

Simply thinking about when and where it is appropriate to use enemy re-spawning can go a long way
toward eliminating it as a problem. The rate of enemy re-spawning can also be a problem, you want to
challenge a player but not overwhelm them play test your combat encounters with a few different
character classes if applicable, and watch whether the enemies re-spawn so quickly that before you
end your first battle , you are faced with a whole new group of enemies. Try to see if you can get
through the area or do what you need to do in the area, and not have encounters become
overwhelming or tedious.

Unless a player is being ambushed, proper spawn points are essential for virtually every decent module
design. Enemies spawning right on top of a player appears wrong to most players, taking them out of
their immersion in your module, also, those player characters requiring distance for casting spells,
setting traps, or using ranged weapons can be rendered ineffective by poorly planned spawn points.
46

Tip: When placing standard encounter triggers it is recommended that you place the spawn
points for the trigger around a corner, behind a door or otherwise out of the players line of sight
when they cross the trigger area. This will reduce the chance of the creatures spawning on top
of the PC(s).

9.2

And leading on from that, encounters should stay dead if there isn't a way for them to be replenished.
It's a bit jarring when you clear an encounter in a dead-end corridor and then come back a minute later
to find another set of monsters waiting for you when there was no way they could have got there
without coming through you.

Balancing Combat

The vast majority of NWN modules use combat at some point for one purpose or another. You need to think
about the purpose behind the encounters you set up, whether the player should be able to defeat a particular
encounter, and how difficult an encounter should be under the circumstances you envision.

Some builders want to challenge players in just about all combat situations and that is okay but
many players will be upset with having to reload time and again as they find themselves over
matched in battle, often these players will quit the module in frustration. If you are seeking to really
put your player through the ringer there are many techniques to enliven the combat in your module
(as explored below in this section).

There are other builders who want to design challenging battles that do not end with their players
regularly reloading or quitting their modules. These builders want a balance between a number of
interesting, challenging battles that offer stimulating combat situations such as using terrain to an
enemies advantage, combining traps with enemy forces, mixed groups of enemies (example:
enemies armed with different types of weapons; consistent with terrain backed up with specialized
allies or mini bosses such as an orc shaman leading five goblins and two wolves supported from
cover by another three goblins armed with bows and arrows) that compliment one another while
offering a minimum of logically, plausible, combinations of enemies (nominal example: having
chimeras, goblins, dire wolves, and giants all in the same small cave fighting against the player,
unless the story somehow calls for this combination of allies) also adding those few battles that
the player should recognize as beyond them and high-tail it out of the area before they get
themselves killed.

Balancing for level is another option using encounter palettes and scripting, however, balancing a
module for any level can create unintended consequences that just make no sense, such as seven
vampires taking the place of seven zombies right next to a little town of twenty people the
vampires would have sucked the town dry; or, a simple bug hunt in a basement ends up involving
the hive mother who would have overwhelmed the town.

Beta testing your module with the appropriate character classes, or getting other players to beta test your
module, are both excellent ways to try and determine if you have balancing problems in your module. Ask
around for beta testers on the NWN Forums and / or put your beta module up at NWNVault to elicit player
feedback, you may or may not get the feedback you are looking for but at least you will have tried.

9.3

Designing large battles

Taken from a forum post by George Zoeller senior Bioware designer.

Some things we used for the large battles in HotU:
Graphics/Level Design
47

Use only up to 7 different creature appearances, the less the better.

Use predefined appearances only instead of using creatures with customized appearances/outfits.

Use few placeables that have a walk mesh in the area the battle takes place. The fewer the better.

Never place placeable objects on tile seams.

Use well designed, small areas for the battle - in any case stay below 16x16, better below 10x10.

Switch off tile features like torches or smoke. Don't place smoke or fire placeables if not necessary.

Remove "persistent" effect spells (i.e. acid sheath) from the spell list of the creatures that participate
in the combat. Nothing kills the frame rate faster than a lot of fancy fire shields.

Minimize the use of weapons with particle effects (like flame arrows) in the battle.

Don't use "persistent corpses". Try to have no treasure on most creatures that get killed in the battle
- this prevents loot bags from being spawned.

Use open areas, the narrower the areas get, the higher the impact of path finding on the CPU.

Scripting

Remove most of the event scripts from all the creatures involved in the combat. Instead use "squad
leader" creatures that give commands to the other creatures (squad based AI).

The OnBlocked event fires for creatures blocking another creatures path - it makes a very nice spot
for a target selection routine.

Tweak the spell casters spell lists to include only few cpu intensive spells (usually missile storm or
area of effect spells) - they take too many CPU cycles when cast .

Use the module's script caching features. Tools like NWNX2 provide options to screen script usage
/ execution times and allow you to get a good picture which scripts should be cached - caching all
nw_c2_* scripts makes perfectly sense as do all the x2_pc_* scripts.

Some random ideas to make the battle look cool:

There are ballista bolt and arrow projectiles in spells.2da. Using ActionCastFakeSpellAtLocation
allows you to create swarms of arrows or incoming ballista bolts or rocks hurled by catapults for the
right battle feeling

Have creatures react to certain things (i.e. signal them an event if a player opens a gate or
approaches a catapult). This will make the battle feel more intense and add the illusion of intelligent
creatures.

lay down triggers that spawn random things like hails of arrows or monsters bursting through a gate.

48

CHAPTER 10 Adding Role-Playing Elements to your Module

10.1 Consequences of PC actions
Consequences in a module, a player who has an effect on the development of a modules plot will likely feel
that they have role-played their character by affecting change, by seeing their character develop due to
interaction with the world that is your module. Some modules go so far as to have multiple endings to enhance
the feeling that the player has taken the initiative to role-play, to have been consequential to the resolution of a
story, rather then partaken in a nominally linear, slightly interactive, electronic-book.

A builder may desire to allow players actions to have an effect on events portrayed in their module, I.e.
to have consequences. Consequences can range from making an NPC angry enough to attack the
player, cause merchants to raise or lower prices or giving away items to refusal of service. In a larger
context, completing quests in different orders, allowing for multiple endings to the module, choosing
one quest or faction (alliances) over another leading to the exclusion of other quests and / or faction
alignments such as common in modules allowing for completion by both good and evil player
characters.

Consequences in a module are not necessary for a module to be good but they can add a great deal of
fun for builders and players alike; however, consequences in modules almost always expand the
amount of work involved in the creation of a module, sometimes several fold depending on the extent
and nature of the consequences. Planning out how plot and quests interact in your module can help
reduce complications while building. To help determine what things affect other things consider whether
it is necessary or important that there are universal consequences to player actions; try to concentrate
on the things that are obviously connected.

Be aware that not everyone likes to suffer consequences, most often negative consequences but even
positive consequences if they close off any other quest options to their character, when playing fantasy
games. Furthermore, a builder can never please everyone even if they like consequences in their
games but do not like the consequences you have provided for them. Do what feels right and feels
good about your modules development; if you have doubts about using consequences consider
whether the payback is worth the effort (remember many people only play a module once) or posts
questions about how best to explore the use of consequences in your planned module.

Concepts: If you have a thing, use it; all things are possible if they are plausible; red herring, go with your gut
feeling:

If you have a thing, use it, the basis behind this idea is that if you introduce a subject matter you ought
to use it to full effect otherwise it is a wasted opportunity and that may have unnecessarily wasted your
players time.

All things are possible if they are plausible, the basis behind this idea is that you can get away with just
about anything if you can establish consistency and or internal logical reasons for what is going on in
your story. If you do not attempt to keep some form of consistency or internal logic to your story, people
may come to feel that they cannot count on facts as facts or much of anything else, because the floor of
reality necessary for suspension of disbelief commonly needed for all fictional medium - is pulled out
from under them, their expectations betrayed.

Red herring is an interesting yet false lead or direction in a plot, essentially the opposite of having a
thing, use it. People may come to feel mystified/stupefied by the events unfolding around them. Be
careful not to over use the red herring or it will lose its effect and cane frustrate your player.

49

Go with your gut feelings. No matter what advice you get or distractions that come along to keep you
from what you most want to do, go with your gut feelings if in doubt.

10.2 Skill Checks and other related PC statistics

Skills and skill checks can be a useful tool to encourage role-playing, alternative solutions to obstacles faced
by the player, and to enhance the enjoyment of the module, particularly for skills heavy class characters. Skills,
however, can introduce problems for players if they and their requisite checks are not used or balanced
properly in a module. Avoid including skill checks that are inappropriate for the kind of player characters who
are going to play your module, for examples: a module intended for fighters and barbarians should avoid using
locked placables unless those placables can be broken; traps that are not ubiquitous and lethal; spot checks;
checks for hidden doors; persuade, etc, instead, such a module should consider using strength and
constitution checks and the like. Skills and skill checks can be extremely troublesome if used as the sole tool
for a player to get past certain situations to advance sub-plots, or worse, the main plot of a module because
the player may not have the skill(s) necessary to complete such a module. If a builder insists on using skills as
show stoppers in their plot/sub-plot progression or otherwise use skills regularly so as to present annoyances
to those players without the requisite skill then the builder ought to identify the need for a player to have
whatever skill(s) necessary to play the module documented where people can see the requirement(s) before
they download the module to rightly avoid peoples unhappy complaints.
On the subject of gender and gender checks, remember that if you are using gender checks in modules it is
nice to remember that eliminating certain kinds of behaviours sex, romance, and rude to evil behaviour - from
one kind of gender can often reflect badly, on several levels, to you as a builder unless you establish a good
reason for your exclusive activities. Common example: prostitutes in modules, only female prostitutes, only for
male characters; why not make other kinds of NPCs to explore sexuality, for both genders, rather then have
only prostitutes (slightly sleazy but understandable; this is not a statement against prostitutes in modules
either), only for male characters? Whether you intend it or not, it looks sexist, it suggest females dont like or
think about sex or sexuality, and that the builder is not thinking about this subject in an objective fashion
meaning everyone should be having equal opportunities for sexual content. Often modules listed as teen to
extreme provide sex or sexual situations for only male player characters; it then becomes, essentially, a Male
Only content rated module not really fit for female player characters.

10.3 Romance
Romance is a common element in story telling and appears in many roll playing games. Including romance as
an element in your module can add a great many interesting and fun roll playing opportunities for your players.
There are as many different romance possibilities as there types of people.

CHAPTER 11 Designing a Puzzle

11.1.1

What is a Puzzle?

A puzzle is an intricate series of questions that need answers. When you solve a puzzle your reward is
completion of something in order to move on to new challenges. Computer Role-Playing Game (CRPG)
puzzles are used to bridge the gap between the life of intrigue in the city and the cutthroat life of adventuring.
They have also been successfully used as plot elements or diversions. The reason builders like to use puzzles
is to challenge the Player Character (PC) to answer a series of questions. Puzzles can require a PC to solve a
series of questions in a certain order or they could be freeform. Freeform puzzles are puzzles that allow the PC
to answer the questions in any order as long as they answer correctly.

50

The creator ruins puzzle in the original Neverwinter Nights official campaign is a perfect example of a
successful puzzle formula being re-used today. This puzzle is in itself a multi-part puzzle split into three
sections. A smoke section that requires the player to place several vials filled with different colors into a
dungeon brazier in the proper order. The player then needed to solve the sound section. This requires the
Player to sound the gongs in the proper order. Completing that task still doesnt completely solve this puzzle.
The player needed to solve the light section in order to finish the puzzle and move on to new challenges.
There are many more examples of puzzles. A CRPG without any puzzles simply wouldnt be as much fun.
These puzzles provide the player with some challenge beyond the scope of the CRPG itself. The puzzle adds
to the excitement or in some cases the frustration of finishing the entire game. They can be used as plot
devices, to entertain the player, or slow the progress of the PC in the game.
One thing to keep in mind when building coloured puzzles is that a large number of people (both in general and
playing NWN) are colour-blind; this does not imply that they cant differentiate colours but often have trouble
distinguishing between colours such as green and red; this is further increased in difficulty due to the use of
colours in a game with shadows and area lighting. Best practice is to still build your colour puzzle but to make
the colours useable and to add the name of the colour in the name of the item you are using so that they
become recognisable for all players. As a matter of fact, even Bioware has made this mistake once or twice in
the NWN games

11.2 Types of Puzzles

There are many types of puzzles which challenge PCs. Puzzles for CRPGs usually come in four different
categories.
11.2.1 Cryptogram
Cryptogram Puzzles are code based puzzles that require the PC to decipher the code in order to solve the
puzzle. Proper translation of this code allows for an easy solution to the puzzle. Cryptograms often require the
PC to acquire key information in order to break the code and solve the puzzle. Disinformation or information
that is not completely correct is used to prevent the PC from completing these types of puzzles
11.2.2 Riddle
Riddle type puzzles are an enigma. Riddles are the only type of puzzle that provides the player with the
solution at the beginning of the puzzle. They require the PC to solve the puzzle by figuring out or making a
guess at a solution based on the evidence presented to them. Riddles do not have to rhyme. The riddle is the
solution, but the puzzle is to figure out what the riddle is telling the player.
11.2.3 Logic
Logic puzzles require a systematic arrangement of the puzzle pieces in order to provide a proper solution.
Logic puzzles can be solved in many ways, but ultimately the solution is based on arranging the pieces in the
correct order. Logic is defined as proving the truth. Just because I say 2 plus 2 is 4 doesnt make it logically
correct. The application of proof makes 2 + 2 = 4. It is this proof which makes the logic puzzles the choice
amongst builders wishing to provide a plot based puzzle.
11.2.4 Maze
Maze puzzles are used to provide action. Pure and simple. There is no logic involved, no riddle to solve, no
code to unravel. Its just the PC and a series of correct guesses on which way to turn, or not to turn, that allows
51

the PC to move forward and solve the maze. Mazes are typically filled with all manner of bestiary and traps.
Outwardly, it would seem this is the easiest puzzle to design when in fact its one of the most difficult to build in
a way that challenges the player.
These different types of puzzles are often used together or in conjunction with one another to provide a more
immersive experience and a better puzzle. It is quite common to find a riddle based puzzle within a
cryptogram. Another common combination is to place a logic puzzle within a maze to provide further
entertainment or challenge for the players. The use of puzzles within a CRPG is dependent upon the purpose
they will serve. A puzzle without a purpose is like a plot without any actors. It just doesnt work.

11.3 Formulating a Puzzle

Building a puzzle is easy. Building a successful puzzle is the challenge. A successful puzzle should not only
entertain the player, but should challenge them as well. If a player can easily solve a puzzle, there is no
challenge and therefore no purpose for the puzzle. Conversely, if a puzzle is too challenging you may actually
discourage your target audience.
Builders formulate puzzles for many reasons, often they may build a puzzle to advance the plotline of their
game. These are typically plot based puzzles that do not solve the plot, but serve to enhance the plot or give
further clues to the solution of the plotline.
Another reason for formulating a puzzle is for pure entertainment. The builder is making a game which
hopefully others will enjoy playing. If a game has a lot of action or a tremendous amount of dialogue options, a
puzzle can serve to provide a break from the normal style of the game. When used for this purpose, a puzzle is
usually integrated into the plotline. This puzzle would provide more than clues, but would provide solutions to
certain plot elements upon successful completion of the puzzle.
The third reason builders place puzzles within their games is to slow down the PCs progress within the game.
Maze puzzles are typically used for these reasons. The maze provides a break from the plot, while at the same
time increasing the amount of time a player must play the game.
Sometimes a builder will combine all three of these elements and provide a puzzle which advances the
plotline, provides a break from the normal game style, and slows the PCs progress in the game. It is usually
the placement within a game that determines the purpose of the puzzle.

11.4 Placement of Puzzle

The location of a puzzle within a game is vital to whether it is successful or not. An ill placed puzzle is a recipe
for disaster no matter how well built it is. If you remove the PC from the puzzle and force out of character
(OOC) actions, you have defeated the purpose of the puzzle, destroyed your plot elements, and in the long
run, you have ruined the game for your players.
When choosing a location for your puzzle you should take just as much care and consideration as formulating
your major plotline for your module. The location of a puzzle is dependent on your plotlines. Builders choose
the location of their puzzles based on the objectives of the puzzle. If you do not wish the puzzle to interfere
with any plots, then the puzzles solution shouldnt bear on whether the PCs can solve your plotlines. If the
purpose is to enhance the plotlines or slow PC progress in those plotlines, then your puzzle should be
obtrusive to the plot elements. This will force the PC to solve your puzzle before they can solve the plotline.
Location isnt the only thing that will make a puzzle successful. Timing within the module is equally important. A
poorly timed puzzle can be as detrimental as an ill placed puzzle. Timing of a puzzle is strictly based on your
plotline. Timing in this context is how long it takes PCs from start to finish. If you place a puzzle early on, you
set precedence for the rest of your module. If you place a puzzle near the end of your module, you may
frustrate your players or remove their train of thought from the gaming world and your plotline. While both
52

these times can be appropriate the most successful puzzles are placed closest to the middle of your module. In
the beginning, you are spending time drawing your players into your plotline, while at the end you are wrapping
things up. A puzzle can sometimes muddle those factors.
Both location and timing are dependent upon what type of puzzle you are building and your target audience.
Your target audience is the player and the PC they play. Inevitably a puzzle should challenge not just the PC,
but also the player. If your module is a mature content type module, you would not want to create a puzzle with
childish riddles or immature logic. If your module is designed for Hack N Slash, you would not place a rogue
skill based puzzle. Your target audience is an important factor to consider when placing a puzzle in your
module.
Your target audience is just as important to the success of your puzzle as its timing and location are. When all
three of these factors are combined properly you can just about guarantee success.

11.5 Putting the Pieces Together

This is a very important step in the puzzle building process. It is vital that the builder maintains good notes
during the building process. Now that you have a defined purpose, a correct location, and the proper timing
within your game for your puzzle, before you can begin actual building you must put all the pieces together.
This will allow you to easily insert your puzzle and avoid having to make numerous corrections after you begin
to place your puzzle pieces.
There are four components to puzzle building. There are actors, key points, objects, and miscellaneous
operands. If you notice, these four components are very similar to what is used to put your plotlines together.
Puzzles are very similar to plotline builds.
For puzzles, the actors have three components. The first is the actor which starts the puzzle. The second is the
actor or actors that offer clues as to where you may find solutions to the puzzle. The third is the solution actor
which provides rewards upon successful completion of the puzzle.
The key points in a puzzle are those objects or insistences where a portion of the puzzle solution is revealed.
These are separate from the actors themselves in that these provide actual solutions and not just hints of
clues. You will find key points somewhere between the opening actor and the conclusion object. These are
important to the puzzle because they assist in making the PC progress notable to the player. Journal entries
are especially useful when presenting key points.
The objects in a puzzle are the actual puzzle pieces used. These can be any of the other components. An
actor is an object, a key point can be an object, and a miscellaneous operand can be an object. Puzzle objects
are tangible. They are visible to the PC and sometimes used by the PC to complete the puzzle. They can be
items given to the PC, placables manipulated by the PC to solve the puzzle, or other objects used to find info
about solutions to the puzzle.
Miscellaneous operands are those objects that arent visible to the PC. Like puzzle objects, misc. operands
can be any of the other components, they can even be objects, but are invisible to the PC. Listener invisible
objects are an example of misc. operand objects. Miscellaneous Operands are typically used to force the PC to
solve the puzzle. These can be in the form of encounter triggers that spawn when a puzzle reaches a certain
stage. Misc. Operands are not actual pieces to the puzzle itself, but are still an integral part of building a
successful puzzle.

11.6 Building the Puzzle

You should now know how to define a puzzle, the different types of puzzles available, the many purposes for
puzzles, and proper placement of puzzle elements. It is imperative for your building frame of mind (and to
avoid a lot of frustration during the process) that you carefully map out your puzzle before starting to work on it
53

in the Toolset (unless of course you are building a small puzzle with limited options). Regardless of the variant
you plan on using, puzzles have a tendency to become more complex as you start building them and start
catering for the various ways in which a PC can actually try to resolve them. If you are looking for inspiration in
building your puzzle, there are many puzzle websites that have readily available riddles, logical, mazes,
brainteasers and other variants of puzzles available which are easily adopted into a NWN environment.

CHAPTER 12 Module Category Particulars

Your module may include elements that are in different categories, but the more elements there are the more
likely you are to cater to the general public. If you are dead set on creating a module in one particular category
because you feel comfortable with this category, by all means go for it but as a general rule of thumb for new
builders it is easier to add some elements of all categories in your first module than it is to go category specific
(and this includes building a decent hack and slash module).

12.1 Roll Playing Modules

The role playing module comes from those days of pen and paper D&D. Where players were more interested
in being their character then slaying the dragon and getting 'phat lewt'. These role players have continued on in
the world and have come to NWN and other computer RPG's for their role-playing needs. So one might ask,
how do I make a role playing module? How can I appeal to this great audience? Well read on.
The obvious definitive thing that makes a role playing mod is, surprisingly, the ability for the PC to role-play. A
role-playing mod doesn't even need to include combat. In fact some of the best role-playing mods have only
two or more essential encounters, with many others possible depending on the players role that they play. The
mod is more expressed in its dialogue and the options that the PC is given through action or choices along the
way. Certain class specific mods really open themselves to role-playing, such as wizards and rogues or even
bards. In fact to make a really good role playing mod one must allow the PC to become emerged in their
character and the world around them. Having the PC know certain pieces of the lore of the world that a regular
person like them would know, or having high stats provide extra options with dialogue, small things that make
the player feel as though their character is real. An example of stats effecting behaviour would be how people
accused the PC of looking rough if they had low Charisma, or the PC talking like an idiot with low Intelligence
in the main campaign.
Of course, having no combat makes gaining levels difficult and, although levelling up isn't as important in a role
playing mod, many players feel a sense of pride and accomplishment when their character goes up a level.
Many DM's and builders have handled this situation well, by offering the PC experience for good role playing,
an example of this is in the Bioware Premium mod, The Witchs Wake. The PC is given the opportunity to
carve a message on a pillar and gain exp for what they write.
As a whole, making a role playing mod can be very easy or very difficult, depending on how you handle it.
Whether you narrow the focus by designing the mod for a specific player race or class, or leaving it open for
any alignment or any class and race. The degree of role playing can also determine how easy the mod is to
make.

12.2 Building a High-Level Module

Epic or high-level modules deal with powerful, experienced, player characters that have proven themselves
against many foes over the course of their adventures. Builders, thinking of or wanting, to build a high-level or
epic level module should consider a few things about how their modules design will be slightly more
demanding than normal module design: setting, location, and implications.

54

The setting of a module tends to be far more important in high-level modules due to the power of the player
character and the power of the villain(s) who oppose them.
A setting that uses tremendous, powerful, magic and items will present different challenges for different
character classes while those settings using little in the way of magic will be in turn quite different. A high
magic module also tends to demand that the builder attempt to introduce a number of specialized magical
items that are a step above and beyond what is most often found in any other module, increases builder
workload and may encourage the use of hak paks that allow for specialized items in modules that use them.
Differences in use of magic can effect location in a module, low magic setting will tend to not use teleportation,
involve regional areas, and avoid planar travel, etc.; while high magic setting may jump all over the world or
lead to planar adventures.
A setting may have only a handful of powerful, epic, characters in it, these characters can make or break
kingdoms and shake the very foundations of the world NPCs fear these characters, may treat them almost as
gods or at least honoured persons for fear of rousing their displeasure, or worse, wrath. In such a setting it
would make sense for players to be treated as important individuals, even rulers of realms, any character
known wide and far will attract those seeking advantage by alliance-proximity-persuasion; unless they have
avoided making their presence felt to the world at large.
A setting may have many powerful, epic, characters in it. In a setting chock full of powerful individuals no one
character is likely going to be able to threaten the world by him or herself, there will tend to be a shifting
balance of power as different powerful individuals alter their alliances to redress power imbalances. Special
organizations, private religions, or government(s), may spring up to counter balance different competing
groups or achieve agendas best dealt with by high-level characters. Armies, specialist forces, assassins, etc.,
will be better armed, armoured, and prepared for dealing with high-level and epic level characters. Planar
enemies and allies, even travel, may come into effect in these settings as many powerful beings use whatever
tools they have at their disposal to achieve their aims.
The location can matter quite a bit in a high-level or epic module. Characters who are well known, famous or
infamous, ought to draw attention from the public thus adding to the workload of drawing up proper dialogue
and behaviour from NPCs, unless the player is supposed be in disguise (forcing a player to play a game a
specific way can also cause it own kind of problems). Epic adventures are often epic in scope therefore often
take place in a multitude of locations, increasing the number of areas called for in a module, increasing the
workload of the builder. It may be that planar travel must also be dealt with depending on the story of the
module, with few tile-sets that really look planar to use in the NWN toolset, builders will be tempted to use
hak paks that bring in their own special problems.
The implications of the plot(s) and quest(s) are of considerable concern in developing plausibility in a high-level
module.

12.3 Building a PW
This is probably the most complex and difficult type of module to build. Planning is a key issue in constructing a
PW. Since there are so many more complicated systems that go into them there is a whole extra level of
planning different from prepping for any other type of mod.
Things you need to think about before building anything:

Death system, will you allow bleeding to incite player-by-player resurrection, send players to a death
realm, etc.

Spawn system, dont forget to clean up areas before spawning the next set of monsters, prevent
players from mining areas for XP, etc.

55

Persistent data storage (all those darn variables need to come back after a reset)

Any other world specific systems, like custom skills, feats, spells etc.

Factions, which factions will be used in the module as a whole, are you planning for alignment shifts,
etc. Adding or changing settings to the faction system automatically trigger a complete build of your
module, doing so after adding a lot of areas and / or creatures will take a considerable time away from
your building pleasure, as with hak paks, choose your factions wisely and choose them up front.

Rest systems, you also need to consider the benefits of using this system against the limitations it
poses for certain classes in the module (arcane / divine spell casters in particular). Whether your PW is
going to cater to RP or PvE or PvP should also be amongst the considerations for rest systems, roleplayers might love them for the added sense of realism (especially if you use a system with bedrolls
and campfires) whereas hard-core PvP-ers may feel the opposite.

Hak paks, you need to decide on these up front, changing hak paks halfway through development of
your PW is one of the hardest and most time consuming things to do.

Figure those things out first, then test them to make sure they work as intended, then start your actual building
cycle.
One other thing:
Most PW are built and run by teams of people. If you really want to do this you will probably want to recruit a
good solid team of DMs, and builders. One of the keys to making a really successful PW is having good DMs
to keep the game interesting otherwise it is just another MP mod. Even after completion you will want to keep
that team of builders together for updates and new content to keep the world fresh and interesting.
A 'true' PW is never 'complete', but you DO want to get the core systems like those mentioned above in, and
tested early.
Above all realise that building the PW is only part of the job, you have to maintain it, expand it, recruit players,
and deal with a wide number of 'human resource' issues. You need to deal with unhappy players,
disagreements between players and players, players and DMs, DMs and builders, etc.
Starting your own PW is to be viewed as a labour of love, time consuming but really rewarding if you plan well
ahead and are committed to it.

12.4 Building a multiplayer module

Multiplayer modules are meant to be played by two or more people usually online. There are many things to be
considered in building for a group of players that have already been covered in earlier chapters. Here we will
talk about something that makes the Multiplayer module truly unique, the Dungeon Master and the Dungeon
Master Client tools.
12.4.1 How to make a module DM friendly and DM documentation
Documentation can be the most important thing for DMing. Dungeon Masters need to know what happens
where and why.

Toolset documenting, as in where in the palettes important pieces are located is crucial.

Map the important areas.

56

Basically a module builder needs to explain in some detail just about every aspect of a module. You will also
want to explain the things you did not do. Maybe the dm can expand on those ideas.

Plot Description: Use "excellent" documentation, and "excellent" organization. Not just good, but way
over par. Plot notes should be well-written, easy to understand, and concise but descriptive. Have
someone proofread them for spelling, grammar, and clarity. Use an organized method to write them
out. A "story" is nice, but often a formatted outline can be easier to understand and follow.

NPC Description: For important NPCs, have well-written in-game notes about the NPC as an item
description on an item in the NPCs inventory. You can make an undroppable book or use one of the
"paper" icons to list things about the NPC. Create a unique item in the toolset, such as a book, and
name it after the NPC. Then paste the write-up into the item description, make the item undroppable
and put it in the NPCs inventory. Do this in the NPCs inventory in the palette, and make sure it is in the
inventory of any "placed" NPCs in the world. This makes things much easier for a DM to "get into
character" when possessing an NPC, and saves time that could be wasted if you had written a
description elsewhere. Some things you may want to include: a short description of the NPCs
appearance, background, and mannerisms, the NPCs role in the plot, relationships to other characters
in the story, and anything else that may prove relevant or help the DM understand the character well
enough to play the NPC. This is important to have in-game because it wastes time to alt-tab out of the
game, scroll through pages of description, or shuffle through papers on your desk.

Item Descriptions: Write descriptions for your custom items/placeables/creatures/etc! The more
information you provide your DMs and players with, the easier it is to become "immersed" in the game,
and the less time they have to spend "making stuff up" to cover up the module builder's lack of attention
to detail.

Custom Blueprints: Custom blueprints should be organized in the palette in a logical, neat fashion, and
a description of how they are organized should be provided for the DM. Again, it wastes valuable time
when you have to search for something you need in a hurry. It is probably not a good idea to use
custom-made palettes, because while they may be easier to organize in the toolset, they don't show up
in the DM Chooser.

Areas: Use logical area names and provide documentation on your areas. Maps are a good way to go,
since many people are visual learners. Some people prefer to have areas named a certain way:
Country: City/Region: Area or some variation thereof, because it makes it easier to see the
relationships between areas. Detail is a plus in DM-run modules, so think carefully about your area
names. "A Shop" is nowhere near as interesting as "Avengard's Fine Gems and Jewels".

Tools: If you plan on having DMs run your module, include the DMFI DM Wand Package. There is
really no equal out there to the sheer utility and variety of the tools included, and many DMs are already
familiar with and used to using them. If you include your own custom DM tools, be sure to provide a
clear description of how they work and what they do.

12.5 Building a Hackn Slash Module

A Hack N Slash module can be defined as an action or combat module. There can be some role play events
inserted and even a storyline involved but mostly the module is built to test the player characters mettle in
battle against a wide ranging selection of opponents. A good Hack N Slash module provides the player
character with combat situations that are both interesting and challenging. This does not mean that a good
Hack N Slash cant have a strong story line, in fact many players look for the story to give meaning to all the
combat.
A few pointers to building a Hack N Slash module:
57

Provide plenty of combat opportunity, but not the same combat opponents over and over again. Use a
variety of opponent types. This can be done by changing the weaponry, special abilities, classes, or
spells used by the opponents as well as the type of the creature. It is also a good idea to vary their
appearance as much as possible. You can do this by hand placing as well as using encounters. You
may want to build a few different resource references (resrefs) of these opponents so you can supply
them in your encounter triggers in addition to hand placing them.

Good area design goes hand-in-glove with good combat design. Think about how the terrain can affect
the combat and tactics of the PC and the NPCs. Creatures with ranged attacks in hard to reach areas
can make a very challenging battle for melee types or ranged characters could find tight, enclosed
areas a challenge. Trees and other terrain features can be used to create interesting ambushes and
provide cover for both sides.

Always have the XP slider set above zero. This will provide the Hack N Slash player character with XP
for killing. You want to provide XP for kills but not a tremendous amount or the PCs may gain levels to
rapidly. Remember you must balance your later areas and encounters in the module to compensate for
levels gained. A good setting is between 8%-25%. But you can go higher than this. Remember too that
you can manually adjust a creatures CR (and thus the experience given for killing it) in the toolset.
Experience given should also make sense for the difficulty of the combat.

If you are building a combat module with multiple quests and multiple opportunities to gather
information about those quests make sure to use the journal often. In a heavy combat module a player
may forget what it is their character is supposed to be doing. Use the journal as a notebook for the
player to reference so that they dont get lost or confused about any important story elements.

Healing; there are 2 schools of though on healing. One says that you should make sure to provide
plenty of healing potions and items that aid the player character to deal with the wide ranging amounts
of damage they are likely to suffer. In a combat centric module a potion of heal can be vital to keeping
the player character alive. The other believes that good heals should be difficult to come by, and that it
is always a good idea to make this sort of thing the responsibility of the player in some way. This can
add tension and increase immersion because the player actually has to interact with the world in some
way to ensure survival. It also makes them think about the combat a bit more, it becomes a bit more
tactical.

Provide opportunities for the player character to rest before major encounters or after a series of
encounters. This will make the Hack N Slash more enjoyable and provide the opportunity for the player
character to identify and switch out any treasure items they may find as well as heal and recover spells
and limited use abilities. You may want to provide players with a choice regarding rest. Allow them to
choose a number of options ranging from limited (time/place) to unlimited. If you want to spawn
creatures in occasionally while they are attempting to rest don't over-do it. Occasionally it's fun and a
challenge, too often and it becomes predictable and can reduce the players enjoyment of the module.

Treasure should be provided along the way towards the goal and plenty of it. This treasure should not
make the player character invincible but should assist the player character in staying alive or providing
more effective combat. Be careful when providing treasure that involves immunities and other powerful
magic. You do not want to unbalance the encounters and make the game too easy. Remember you are
challenging the combat strengths of the player character not making it so they can run over your
encounters. One-shot items specifically designed for a particular example of combat are also a very
good idea. It adds immersion for the thinking player. Adding a detailed description to such things also
adds immersion, especially if it simultaneously fits with the specific occasion and also somehow feeds
back into your main story. Items with limited charges or uses can also add to tension - will I use it or will
I save it?

58

Provide plenty of unique items to the player character. Combat might be central to a Hack N Slash
modules theme but unique treasure makes the module something special to the player character. Most
Hack N Slash players have held their fair share of loot in the game. Providing them with unique items is
one way you can turn a module with little scripting and minimal role play into a unique experience.

Death in a Hack N Slash module should usually involve gold and XP loss. This insures that there is a
consequence for dying beyond merely being forced to re-spawn. You may want to expand this into
taking an item from the PC depending on the level of difficulty and the situation. There is a school of
thought that believes that being beaten is a sort of consequence in and of itself. These players often
feel humiliated or insulted by death penalties being added to the failure of losing a fight. For these
types of players the experience of having to return to defeat foe is all the more rewarding for having
been beaten.

Re-spawning after death should not involve the player character being returned to the beginning of your
module or being re-spawned at the spot where they died. You should provide an opportunity for them to
quickly return to the place of death though. This will provide the player character with the opportunity to
continue their adventures without having them fight the same battles over or run through the same
areas again and again. Death can become common place in a heavy combat module so where you respawn the player character is important. Another good idea is to provide a couple of ways back i.e.
return to point of death and also the option to return to a bind stone or similar. Some spell casters in
particular may want to use the latter, and even melee types. It's important also that re-spawning in this
way does not somehow feel like a cheat.

Another good idea is to provide an option for at least some creatures to have a forced rest. This means
the combat will be just as tough the second time, a real challenge. If you do reset your encounters
when the player re-spawns you may want to reduce or eliminate the penalties associated with player
death to avoid having the player trapped in a downward spiral of defeat.

Treasure can be classified into two groupings. Earned and provided. Provided treasure is that random
treasure you find as you search. Class or non-class specific and value might vary throughout the
module but provided treasure should not outshine earned treasure. Earned treasure is treasure you
make the player characters work to acquire. A difficult near deadly or deadly encounter should provide
such treasure. This should not be limited to being earned after the encounter. Providing earned
treasure just before a battle where it might be needed to help the player character thus allowing them to
earn the right to continue using it. In any case it is assumed the player character will continue after this
encounter so even if the treasure becomes a trading piece it was still earned treasure.

Having good merchants which provide a wide ranging selection of powerful gear at expensive prices is
a good idea too. This will provide the player character with something to spend their gold on. Maybe
something not available in the encounters but not more powerful then some of the earned treasure.

Identifying treasure is important. You should provide a method for all player characters to identify their
treasures. Merchants should not be the only ones with that ability if the player chooses a character
incapable of innate identification or not having high appraisal skills.

You may want to get rid of random drops. Looting bodies of lesser foes is hardly heroic, and can get
boring. Limiting loot drops to boss types is a common solution to the excess of mundane item drops.
You can also reward the explorer types by hiding interesting items in unusual places.

An important factor in a higher level hack and slash is dealing with the more powerful feats and spells
that can instantly kill an opponent or otherwise make the combat to easy. Devastating critical, for
example, can be very unbalancing. If you provide creatures with really high fortitude saves then many
mages will be disadvantaged. On the other hand if you make their AC too high then many melee types

59

won't be able to hit them. The decisions you make to deal with these and other high powered abilities
can be very important
Tip: As noted, the most obvious ways around the devastating critical issue (high AC and/or
fortitude saves) aren't all ways appropriate, but perhaps a fix that gaoneng came up with for
Caereena 2 might serve.
What you do is set a boss critter, or whoever, as immortal until a set hit point threshold has
been reached and then remove it. This extremely elegant solution gets around the AC and
fortitude save issues, and also the usually applied semi-fix of making a critter immune to critical
hits (which takes out sneak attack too).
When a critter is immortal they are still susceptible to critical hits, sneak attack and all other
appropriate damage. They simply drop to a single hit point and you can't finish them off. If the
immortality flag is removed at, say, 5% hit points remaining however then a player can actually
finish them with a devastating hit or other damage.

CHAPTER 13 Testing the module

Testing is a crucial step in module building, you have no way to know without testing if your killer script system
actually works or if the last change you made broke your journal entries. There are a variety of ways to test
your module. For most novice builders they stop testing with their own run through of the module, unfortunately
this is one time when doing it yourself is not the best way. As the builder you know too much about how things
are put together to be truly thorough and objective. You will almost always get the best feedback from testers
that have little or no prior knowledge of your module. A really good playtester will give you fresh perspective
and insight to your project above and beyond reporting bugs.

13.1 How to be a good Playtester

Don't try to see if it works, try to break it. Try to think up things to do that are outside the obvious parts of the
design. If the design is trying to lead or force you down some path...resist. Go along with it halfway then try to
deviate as much as possible. See if you can go backwards down the path.
13.1.1 PLAYTESTERS GUIDELINES
1) Provide a detailed account of your availability. Try not to say "I can test it sometime." That's a little too
open ended. "I've got a few hours this week to test your module." would be a little more concise. You do
not need to tell the builder "I have exactly 4 hours and 20 minutes to test your module this week." That
would just be silly.
2) Provide an account of your testing skill. This will be variable for each person testing. However, it will
give a builder an idea of what to expect. Perhaps use a rating system like the following:
Level 1: I'll run through your module and give you a general idea of how I feel about it.
Level 2: I'll run through your module and point out good and bad points about its make-up.
Level 3: I'll go through your module and point out good and bad points as well as give
conversation feedback and balance suggestions.
Level 4: I'll walk through your module and give you as much info as I can.
60

Level 5: I'll go through your module with more PC's than you can imagine.
3) Agree upon the form of transferral of information with the builder both for the module and for your
feedback.
4) Try to keep a detailed notebook of information on the test. Write down anything that stands out to you.
You can comment on both good and bad things... "I loved the way the bog felt. I was really drawn in by
the dancing lights and green fog." "I wasn't a big fan of the way the bog felt. The lights were good but
the green fog doesn't feel right." Also keep track of specifics such as: "When speaking with 'George' he
had a spelling error in his first conversation node."
5) Follow ALL directions provided by the builder. If he asks you to play as an Elf then you should play as
an Elf. There are usually reasons they want that specific race tested.
6) Track your PC's progress recording how much time you've spent playing, what the PCs starting (and
final) level was, what quests you completed (and left open).
7) If testing occurs over multiple days then send a summary to the builder after each testing period with;
Current time spent on the module, a list of completed quests, a list of quests that are still open, and any
PC information (i.e. Level progression).
8) Explore the areas you enter thoroughly. Don't rush from one area to the next trying to finish quests.
Open any containers you find. Beat, break, or cast spells at things that don't open. TRY to break things
that shouldn't be broken. (i.e. That lever that opens the only door to the boss.) Examine everything you
see. As per item 4 on this list keep a detailed record of things that stand out.
9) Complete as much of the module as time, or the module, will allow.
10) Provide as detailed an account of your experience in the module as you can. Try to be specific when
discussing flaws or problems. You can certainly give an overall feel of the module. However, the more
specific the information is the more helpful it will be to the builder.
If time permits try the following as well:
Check if the builder wants to do more testing after updates are done.
Test with the same PC as before to verify that the updates are done and correct.
With the updates verified repeat all the steps above with additional race/class combinations.
As with all things, these guidelines are changable as the need, or necessity, arises.
13.1.2 Playtesting Tips
1) Keep a notebook, or some paper, by you during the entire module and take as many notes as you
need. Remember that the spacebar pauses the game. No one that I know of (including me) can
remember everything, especially if its a rather long mod.
2) You can change your .ini file to record everything that gets entered on your Conversation Window. Find
the line ClientChatLogging=0 and set it to =1. This way you don't have to write down everything that
happens in conversation when talking to NPC's. Typically journal entries and rewards are marked in
here as well.

61

3) Talk to EVERYONE. Also talk to everyone more than once. If they say the same thing twice then move
on. However, if they say something different then keep talking until you see it's random or until they say
the same thing twice.
4) If an NPC talks to you, act as you would were you playing the module and not testing it. Often people
will say something they normally wouldn't during testing so that they receive as many quests as
possible. Usually when builders test their own quests they make sure they receive the quest. However,
they frequently don't check the other conversation nodes to see what happens. This is where you're
going to find the most chances for corrections and improvement.
5) Look and listen. Look at the scenery. The placeables, lighting, and NPC's walking around. Look at the
way the NPC's act. Are they as life like as they can be? Probably not, are they passable? Hopefully so.
If the NPC's are doing more than just standing around I would say they're average. If they look, feel,
and sound lifelike then they are very well done. Watch for changes in lighting. Are the buildings lights
on? Is there light on the ground outside the windows? Are the lamps or torches lit? Is there light on the
ground near these? Does the lighting get gradually darker when you're moving away from a light
source? Do the sounds make sense for where you are and what's there? It's easy to make the mistake
of making whispers in a barn where the inhabitants will be killed. That would be fine, but if the whispers
are ambient they'll never go away.
6) Do the areas make sense together? Do you go from rolling empty plains to mountains without a hill type
area in between? Do you go from empty (no trees) plains to thick forest with nothing in between? Is
there a stream with no starting or stopping point, just a line of water that doesn't come from an edge or
lead out of an edge? Are there pits in your area that seem to have no purpose?
7) Combat balance. Are the battles balanced? Are they challenging? Are they impossible? You'll need to
be as descriptive as possible here. If you feel it is unbalanced, explain how you came to that
conclusion. Also, try to offer a solution if you can. Perhaps the builder has an encounter that is just too
difficult but they're not sure how to fix it.
8) Creativity. This is probably the most difficult one for people to test as it is rather subjective. Some things
to keep in mind. Are the situations believable? Do they grab your attention? Are they interesting? Are
they semi-unique? If you find a quest that's rather drab, then offer a suggestion to spice it up a little.
9) Quest Clarity. Are the quests easy to follow? Can you take one clue and locate the next? This doesn't
mean that it's a linear quest where you go from one clue to the next. It just means you can find one of
the next clues without feeling like you should drop the quest.
10) Continuity. Does the module maintain its theme throughout? Does it change it's concept from RolePlaying to Hack & Slash without notice? Does the module maintain its tempo (meaning does it go from
being exciting and fast past to slow and drawn out at some point)?

13.2 Balancing Items and Effects

try as many different scenarios and combinations as possible no matter how time consuming it may be. Look
for those exploits that give you the advantage nobody else will have.

13.3 When the plot gets broken

Try to break it even more. See how broken you can make it after the initial problem shows up.
In order to get the perfect fix, you must know about everything that is broken. This is virtually impossible to do.
Miss something and you will have another fix to make down the road sometime. Accept the fact that it will
always be that way. Record every anomaly you find or you WILL forget some of them. When you find a
62

problem, try to speculate how it will affect other subsystems. Then check them all out thoroughly to validate
your suspicions.
When you find something is broken, don't fix it. Write it down for future reference and continue testing to see
how it affects things. Try to use it to break other things.

CHAPTER 14 Going public with the module

It is important to continue supporting the product and listening very closely to community feedback. The
willingness of an author/team to respond, and respond quickly, to community bug finds and other feedback is
absolutely critical, especially in those first few weeks. It tells the players that their feelings and thoughts are
important, and you will quickly form a basis for a sound player base for your work that will be happy to
contribute ideas and testing.

14.1 Read Me file

Stick to plain text (txt) where possible. If you have lots of images, pages, links and formatting is required, use
html (html) or PDF (PDF). Other formats include rich text (rtf), help (chm), word (doc), etc. Make sure to name
your read me file with more than just ReadMe.txt. Most players have several mods downloaded and they all
use that same name so they get overwritten all the time. Instead use the name of your module so that the
player can tell what module it goes with. For example MyModNameReadMe.txt
Be concise and to the point. The reader obviously has already downloaded your module, and there is no need
to re-advertise and re-decorate with flowery words and descriptions. The reader obviously wants to be playing
the module, not reading your final year thesis. Document only what is needed.
A bad read me can result in a lot of frustration and possible negative votes and ill-feeling. No one wants to play
through a module only to realize halfway that there are no role-play opportunities for certain classes and
alignments. A good read me obviously can go a long way towards informing the player what to expect.
Use common sense for formatting. Make sure your read me is easy to read. Use lots of indentations, line
breaks, white spaces, highlights, bolds, italics, underlines. Do not use funny fonts. For plain text, lines should
be no more than 80 characters wide - avoid instructing readers to turn on Word Wrap. For moderate to long
documents, always supply a table of content and implement a system for quick-linking. For web pages and
PDF, this can be done easily with hyperlinks. For plain text, this can be done by using unique section labels i.e. the reader should be able to use search, type in the name of the section as described in the table of
content, and jump directly to that section. Alternatively, separate sections can be divided into individual
documents altogether - e.g. one for introduction to game play, one for installation and technicalities, one for
credits, one for faq's, and so on - and placed into one single "read me" folder.
14.1.1 Recommended topics/subjects.
These do not necessarily have to be individual sections. Merge or subdivide where needed.

System Requirements: Are the expansions needed? What is the minimum patch version?

Content: What are the files included in the download? List and document these precisely - actual file
names and extensions, etc. What do they do? Not everyone is comfortable with having unfamiliar file
types on their computers. Are other resources required? If so, this is a good place to include the urls to
all those required hak packs, movies and soundtracks.

63

Installation Guide: Always assume the reader is a first timer and detail exactly where all the files
needed for your module should go.

Description: Briefly reintroduce the module, so that the player will still have some clue on what the
download is six months later. Remember, no need to advertise your awesome spell pack or ultimate
crafting system here. What is the setting? What are the events that lead up to your story? Is this
module part of series? Who what when where why how?

Prerequisites: Who should play this module? Who shouldn't play this module? Do players need to
possess specific knowledge on Ravenloft or Dragonlance or Faerun or whatever before playing your
module? What are the supported levels, races, sexes, classes and alignments? What are the favoured
skills and feats?

Changes in fundamental game rules. Are there special gadgets and items? What do they do? How do
you use them? Do any of the spells and feats and skills work differently? If so, what changes did you
make? And why? Again, be concise - no need for flowery descriptions. For a good module, the reasons
for these changes should be embedded right within the module and presented to the player in a way
that naturally makes sense, and therefore should have no need for very detailed descriptions here. The
only things that you should be clear about right from the start are subjects that affect character creation,
such as multi-classing restrictions and new game rules (hardcore rules, new ranger tracking skill, new
wizard spellcraft etc). You are writing a read me, not a walkthrough, and the purpose of a read me is to
get the reader into the game as quickly and smoothly as possible. If you really want to document all
these fantastic widgets and systems you made, document them in a separate walkthrough or player
guide.

Miscellaneous Notes: Any other things the player must know before playing the game? Handicaps?
What should a player do if she is colorblind or hard of hearing or stupid, and your module is full of
puzzles and games that require those senses?

Known bugs and issues: Provide workarounds and F.A.Q.s. If any are required; also mention in case
of known bugs when you plan to resolve these (or not).

Acknowledgements: Did anyone help you with things you couldn't do yourself? Beta-testers? Bugfixers? Did you use any third party tools and references like script generators and tutorials? Anyone
else you want to offer special thanks to?

Credits: Did you use custom content created by other designers? Did you use scripts and systems
written by other scripters? Did you use sounds and music composed by other musicians? If so, you
must give proper credits by listing the full (real or nick) names of the authors, the titles of their
packages, as well as the urls to their download sites. Not giving proper credit is considered very bad
form in the community and can reflect poorly on you.

Version Histories: It is very unlikely your module is done and finalized on first release. Documenting
your changes can make it easy for previous players to know what to expect after any updates.

Team: Is your module a group project? Who are the members? Who did what?

Contact: How should people contact you? How can people find out more about you and your module?
Message boards, private messages, emails, guilds, websites? Are there other goodies people should
look out for?

64

14.1.2 Uninstallation Guide

Modules that come with a lot of files are hard to remove, especially if all the miscellaneous resources are not
labelled and named with proper and easy-to-identify tags. Are there lots of loose files in different folders? Did
you use any database functions? If so, the list of content above and this uninstallation guide are basic
courtesy.

14.2 Advertising the module

Advertising your module can be as simple as writing a good description to setting up your own website or blog.
This section will include several ideas of how and where to advertise your final module and we will try to break
it up into sections, from the easiest options to the more complex choices.
This is not a step-by-step technical document but a guideline with suggestions on how to achieve your goal;
any tools, utilities or programs that are mentioned by name are not being implied as the only option available,
they are free to download and use, and have been used successfully members of TBP.
13.2.1 Writing a good description
Writing a module description is the easiest form of advertising. You want to add this description in your Module
Properties of the toolset; so when a player goes to load your module, the description appears when your
module is selected. You will also need this description when you upload your module to the Neverwinter Vault
and it will also be used in some of the other sections below.
How do I write a good description? This will depend mainly on the time you invest in the project. Create a
description that introduces the player to your world and that possibly hints at the plot or storyline.
A brief history also helps put the player in the moment of time where your story begins, but remember, you
want to try to leave some unanswered questions to draw the player into the story and make them want to play
your module. A good example of this is in the preamble (consider using introduction, easier for non-English
speakers) of your favourite Sci-Fi or Fantasy book, by reading this you can get a basic idea of how to write and
structure a good description without giving away to much information.
Let people read your description and accept any constructive criticism, family and friends make good
proofreaders and the more that read it the better. If you belong to a guild your fellow guild members are a good
source of proofreaders and keep in mind that it is normal to go through several rough drafts before you get it
right.
13.2.2 Advertising on the forums
The forums are a good source for advertising and Bioware has a special forum just for this. Before advertising
on any forum, find and read the rules about posting and if advertising a module is not mentioned then send a
message to one of the moderators to find out what the boards policy is before posting. The same is true for the
guilds, getting your post pulled for not following the rules is not good advertising.
What do I post on the forums? The great description you wrote in the previous section, of course. Some forums
also want you to add a link to your modules download location and mention if any hak paks are needed. You
can also add links to a cut-scene movie you created, or your website or blog which we will discuss later.
It is also common practice to include links to your module in the signature section of your profile so that it will
show on any forum posts you may make.
13.2.3 Advertising with a cut-scene movie

65

We are now venturing into more advanced techniques, which are also more effective. Imagine a theatrical
trailer of your module highlighting the scenery of your best areas, custom creations and special effects; it is all
possible, and not that hard to accomplish. A cut-scene is just a short movie that you create with objects and
scripts that interact with each other in a predetermined manner. You have seen cut-scenes in the official
Bioware module and expansions and there are several tutorials available that give details on creating them.
A good knowledge of scripting is essential for creating cutescenes, as well as patience; timing is everything
when creating a cut-scene. You will also need a screen capture program to capture your cut-scene as an .avi
file. Once this file is created you may want to convert it to other movie formats like .mov for Mac users. See the
resources section of this guide for some helpful links to tools for creating movies.
Now that you have your cut-scene in a movie format you have to find a place to host it. You can upload it to the
Neverwinter Nights Vault. There are also several online options for this, from sites offering free hosting to those
that charge a monthly fee; you can do a search to find what works best for you and your budget. Most sites
have a bandwidth or downloading limit so choose carefully. Once you have a host for your movie you can add
links to it in the forums we discussed or place them in your own website or blog.
13.2.4 Websites and blogs
Advertising with a website can be the most time consuming and difficult method, and is not recommend for a
stand-alone project; but it is great for a series of modules or a persistent world setting. A basic knowledge of
html is helpful and many web-hosting sites have made that easier. Blogs have become a very popular method
of online communication and there are many places that offer blog services, check the resources section for
some links to these.
13.2.5 Advertising future modules
If you are reading this, we will assume that you have posted a module that is part of a series or your work is
starting to get a following. A good place to advertise your next module is on the download page of your last or
current module. On the Neverwinter Nights Vault you can post comments about a module or as the creator you
can answer questions or concerns of players who have downloaded your module. This is also a great place to
mention your upcoming module to an audience that has seen your work before.

CHAPTER 15 Dictionary of Common Terms and Acronyms

15.1 Dictionary
Blueprint ResRef - This is a label that identifies a particular design or setup of a creature, item or peaceable.
Similar to the blue print of a house, many houses may use the same blue print but each is unique. The
blueprint Resref is used in scripts that create objects and is unique to any creature, area, placeable, encounter,
etc in your module.
Creature - any non-stationary object, usually a monster or NPC.
Declared Function - Those functions which appear outside of the void main () body of the script and are
called into action within the main body of script. A declared function allows builders to create their own custom
functions, which may perform one or more actions.
DM - Dungeon Master, a player that has access to special tools used in telling or advancing the plot and story
of the game while playing. The Referee, final arbiter of all rules. Often the module designer.
DM Client - The specific mode of game play used by the DM
66

Effect - Any modification, either positive or negative, to one's abilities or appearance which is not permanently
stored on one's character file and which is not applied by equipping an item.
Examples include poisoned, diseased, slowed, ability increase etc.
NPC - Non Player Character, any creature not controlled by a player.
OBJECT - anything in the game or manipulated by scripting. NWScript is an OBJECT oriented language
(based on the C program language) That means that anything that is referred to or manipulated by the
scripting language is an OBJECT.
Plot Actors - Any object used within the confines of a plot to assign, advance, or complete the plot. see object
PC - Player Character, the character controlled by the player.
Server/Dedicated Server - Software used to make a module available for online play
Tag creatures / items / etc can all share common tags but if you need to identify a specific creature / item /
etc from a script you will need to assign a unique tag to the creature, unless you plan to apply what you are
scripting to either a range of objects or to the nearest object with that tag. Since tags can be changed at any
time (unlike resrefs) they are very frequently used in scripting; assigning a unique tag while creating the object
can save a lot of time later on in the building process.
Commenting / uncommenting in a script: In a script you will notice green coloured text with a number of // in
front of it (minimum two) or as sampled in the above script with /* and */ at the start and finish of the text. This
is commonly referred to as commented. When instructed to uncomment a script, the author means that you
need to remove the // in front of the text in question. Although not a rule, /* and */ are commonly accepted to
highlight information about a script rather than to comment a line of script.
VFX - a visual effect or "special effects" these are the flashes of light and puffs of smoke that make things look
dramatic and exciting. For a full list of VFX, try the script editor CONSTANTS look up feature.
Example:

67

/*
Delay Monster Creation
with Declared Functionality
*/
void DelayCreate(string sResref, location lLoc)
{
CreateObject(OBJECT_TYPE_CREATURE, sResref, lLoc);
}
void main ()
{
string sClay = "clay_mound"
location lLocation = GetLocation(OBJECT_SELF);
DelayCommand(7.0, DelayCreate("sClay", lLocation));
}

15.2 Common Acronyms

15.2.1 General Online Communications
Afaik - As far as I know
Afk - Away from keyboard
Asap - As soon as possible
Brb - Be right back
Bbiab - Be back in a bit
Bbl - Be back later
Btw - By the way
Fyi - For your information
IE - Internet Explorer/Infinity Engine/Infinity Explorer
Iirc(IIRC) - If I recall correctly
Imho - In my humble/honest opinion

68

ISP - Internet service provider

LARP - Live Action Role Playing
Lmao - Laughing my (expletive Deleted) off
Lol - Laughing out loud
Ltns - Long time no see
mIRC - Standalone IRC chat program used to reach SP chat rooms (setup instructions)
Nm - Never mind
Np - No problem
NS - Netscape
Omg - Oh my god
Otoh - On the other hand
Rotfl - Rolling on the floor laughing
Rotflmao - Rolling on the floor laughing my (expletive Deleted) off
Rtfm - Read the (expletive Deleted) manual
RTFM - Read the (expletive Deleted) Manual!
Rtffp - Read the (expletive Deleted) front page
Tmi - Too much information
Ttyl - Talk to you later
Ty - Thank You
Wb - Welcome back
what - What the (expletive Deleted)
Yw - You're Welcome
*eg* - Evil grin
*g* - Grin
15.2.2 Gaming Specific Terms
(A)D&D - (Advanced) Dungeons & Dragons, may be a reference to the first or second editions of the PnP
game NWN and NWN2 are based on
(C)RPG - (Computer) Role Playing Game

69

3e - Third Edition Dungeons & Dragons rules

AA: Arcane Archer (a PrC)
BG - Baldur's Gate
CEP: Community Expansion Pack: a compilation of popular hak paks cleaned up and compiled by members of
the NWN community, widely accepted by players.
CoT: Champion of Torm (a PrC)
D&D: Dungeons and Dragons
D&DO - Dungeons & Dragons Online
DA - Dragon Age
DD: Dwarven Defender (a PrC)
DM: Dungeon Master (someone who acts as referee and has administrative powers in D&D)
DSotSC - Dark Side of the Sword Coast (Baldur's Gate mod)
FR:DS - Forgotten Realms: Demon Stone
HCR Hard Core Rules
HotU - Hordes of the Underdark (NWN expansion #2)
HoW - Heart of Winter (Icewind Dale expansion)
HS: Harper Scout (a PrC)
IWD - Icewind Dale, usually refers to the computer game of that name but is also a location in the Forgoten
Realms campaign setting
MMORPG - Massively Multiplayer Online Role Playing Game
MP: Multi Player / Multi Player Module
NPC: Non-Player Character
NWN - Neverwinter Nights
NWN2 Neverwinter Nights 2
OC: Official Campaign (the story ("campaign") that ships with NWN)
P&P - Pen & Paper (old school gaming from that ancient time before computers)
PC: Personal Computer (usually non-Mac), or Player Character, depending on context
PM: Pale Master (a PrC); also private message
PnP: Pen and Paper (this refers to the way D&D is classically played, with pen, paper, dice and most
importantly, imagination)
70

PoR: RoMD - Pool of Radiance: Ruins of Myth Drannor

PrC: Prestige Class special character classes with advanced requirements
PS:T - Planescape: Torment
PvE: Player versus Environment (see PvM)
PvM: Player versus Monster (a style of play that emphasizes players fighting NPCs, usually in cooperation with
other players)
PvP: Player versus Player (a style of play that emphasizes players fighting other players)
PW: Persistent World
RDD: Red Dragon Disciple (a PrC)
RPG: Role-Playing Game (should be self-explanatory...)
SD: Shadowdancer (a PrC)
SoA - Shadows of Amn (Baldur's Gate 2)
SoU - Shadows of Undrentide (NWN expansion #1)
SP: Single Player / Single Player Module
SPM: Single Player Module
ToB - Throne of Bhaal (Baldur's Gate 2 expansion)
ToEE - (The) Temple of Elemental Evil
TotLM - Trials of the Luremaster (Heart of Winter free expansion)
TotSC - Tales of the Sword Coast (Baldur's Gate expansion)
TTV - Table Top Variant Rules
WM: Weapon Master (a PrC)
WotC: Wizards of the Coast, a subsidiary of Hasbro. They publish the D&D PnP games, which is what NWN
and NWN2 is based on.

71

CHAPTER 16 Resources
Neverwinter Nights Vault a resource for all manner of things related to Neverwinter Nights.
GestaltCamera Scripting System v2.0 by John "Gestalt" Bye. This is a very popular scripting resource for
creating cutescenes.
The DMFI The DM-Friendly Initiative (DMFI) is devoted to supporting DM-led gaming in Neverwinter Nights
(NWN) and its successor, NWN2. On the web.

DMFI Wand & Widget Package The Wand & Widget Package is a compilation of tools created to expand the
potential of the Neverwinter Nights DM client. DMs are given extensive new powers to manipulate the game,
such as "throwing" their voice, playing a sound effect, or making skill checks. The tools also enhance the
player experience by providing access to additional "emotes" and the ability to speak racial languages. The
DMFI Wand & Widget Package is maintained by Hahnsoo, who also originally compiled the package and is a
major contributor.
Camtasia by Techsmith a utility for creating AVI and other movie type files.
StillListener's Corner a free software site.
LiveJournal is a simple-to-use communication tool that lets you express yourself and connect with friends
online.
MySpace Join for free and blog and do other social things.
The Guide to Building The Toolset Manual looks at the toolset and the many options contained therein. The
Toolset Manual is a reference manual in which every object type, property, tool and functionality offered by the
Toolset is described in detail, along with many tips to help builders in the creation process.
Lilac Soul's NWN Script Generator V2.2 a script writing tool widely used by the community.
NWN Lexicon is a complete scripting reference for BioWare's Neverwinter Nights role playing game. It is
available as an up to date, online version at www.nwnlexicon.com, a downloadable Windows Compiled Help
(*.chm) file, and a pure downloadable HTML version The current version is November 2004.
The Hermit's Chalice by Firestarter. A mod-building tutorial
Custom Content Guide v3.0 it has everything you need to get started. The tutorial includes chapters on: Tools, Weapons, Portraits, Voice Sets, Items Without Models, Spells, Custom Armour, Creatures, Custom
Races, Visual Effects and a host of links to the more common tutorials on placeables, etc.). At the back is a
summary drawing together the URL's for all of the tools you need to create custom content and then some.
Custom Content Guide V3-1 Conversion on NWN wiki
NWN Wiki fan website
Sticky: HotU / 1.6x: New Scripting/Toolset Functionality explained a BioWare forum thread that explains some
of the new content introduced with the Hordes of the Undedark expansion.
Module Builder's Henchman Kit v2.3a Provides an intensive basis for the module builder to easily incorporate
henchmen into their module.

72

Guide to making HotU/SoU henchmen This is a guide to making SoU and HotU henchmen.
Programming Special Items Using Tag-Based Scripts
PW Helper persistent world helper scripts.
The Hitchhiker's Guide to Color Tokens This short write-up is an attempt to explain everything color token.
Upon reading this, you should be able to create, with next to zero effort, text strings of any color anywhere
(almost)
There are a huge number of other guides and tutorials available on the Bioware forums and on the Vault
Search Forums
Neverwinter Vault
For NWN2 specific information check these out.
Don't Panic: The Hitchhiker's Guide to First Opening the NWN2 Toolset
more NWN2 resources to be added later

73

CHAPTER 17 CREDITS
Project Managers: qworty, Akkei
Editor: Ghostdreamer
Special thanks to all the members of The Builders Project Guild and the Nerverwinter Nights community that
have contributed to this document.
Special contributions were provided by (in alphabetical order) . . .
Adaram, Akkei, Aristan, Bannor Bloodfist, baron of gateford, Beothul, bluekey88, CID-78, Dallo, galap,
Ghostdreamer, Jasperre, jlhannah64, Kosmous, Mermut, nereng, Rich of Forumite, Sharona Curves, Sheldon
Easterbrook, Shiek2005, Skyrmir, stacy_19201325, Thirdpres, VaeVictus X, Vuldrick Garrison.

74