NWN2

Naming Conventions The following conventions will need to be used in naming creature blueprints to avoid any conflicts with other blueprints and to ensure that all content works properly with scripts:

Localized Name Creature names should not be revealed to players in-game, unless a sufficiently unique creature or equipment model does not exist for the creature being created. In such cases, choose a one or two word descriptive name, but be sure you reveal as little of the meta information about the creature as possible. Size based descriptive words are not necessary since creatues can be scaled in NWN2 to properly reflect their size.

Putting creature names inside {} will make them visible only to builders. This will help builders distinguish between multiple blueprints of the same type and convey important reference information at a glance without revealing any of the information to players in the game. Generally, a creatures name or race, social role or class, gender (if applicable), and challenge rating are useful characteristics to record within {}.

Ex: Larger Kobold {Chieftain CR1} or Male Human {Barbarian CR3}

Template ResRef/Resource Name/Tag The primary purpose of tag and resref naming conventions is to prevent any naming conflicts. A secondary purpose is to describe the creature in some way. All global creature blueprints must begin with the "abr_cr" prefix to designate them as global blueprints. Server specific blueprints should begin with a 3 digit server number in place of the "abr", so "001_cr" for example. For every subcategory, add a two letter acronym delimited with underscores followed lastly by a descriptive name for the creature itself. This helps to quickly locate blueprints when all we have is its resref. To illustrate, here are a few examples:

A global humanoid creature blueprint: abr_cr_hu_koboldchieftain A server NPC blueprint on server 01: 001_cr_np_zhents_fzoul

Comments To identify and track blueprint versions, it's best to write your name and the date you modified the blueprint in the comments area. Ex: Created By: John Doe, Date Modified: 2006/12/20

For global blueprints, you should also include a link to this wiki page so builders that are unfamiliar with conventions or configuration options can easily find them.

Setting Event Handlers The default basemod creatures should already have these handlers in place, so if you are copying an existing blueprint, you probably don't need to do anything here. To start off with, make sure the creature's event scripts are all set correctly. The default scripts are:

• acf_cre_onphysicallyattacked
• acf_cre_ondamaged
• acf_cre_ondeath
• acf_cre_onconversation
• acf_cre_oninventorydisturbed
• acf_cre_onendcombatround
• acf_cre_onheartbeat
• acf_cre_onblocked
• acf_cre_onperception
• acf_cre_onrested
• acf_cre_onspawnin
• acf_cre_onspellcastat
• acf_cre_onuserdefined

Creating the creature Assuming the creature does need to be created, go ahead and do so as you normally would in the toolset. A few things are different in ALFA, however. Most of this just applies to creatures which are statically spawned, but its probably a good read for any builder.

General Guidelines Creatures are expected to follow canon specifications as closely as the toolset allows. If you must deviate on the basis of game mechanics, play-testing should be used to make sure the altered creature's CR is set properly. Always post any deviations from canon specifications on our NWN2 tech forums so that others may comment or follow them for consistency's sake. When setting clerical domains and alignment, be sure to base things off of the most popular deity for the creature type. When setting spells and equipment, be sure and follow FR's lore and canon if at all possible. Our first priority is game balance, and then following FR lore.

Remember the lower-level creatures of a given race are always vastly more numerous than their higher-level bretheren. Make more versions of them, especially the level 1 warriors, with different sorts of appearances and equipment.

Descriptions A creature's description should be the PHYSICAL description in the creature's sourcebook entry, plus anything important a PC should notice specifically about the creature that isn't obvious by looking at it in-game.

Behavior, Tactics, Society Behavioral information for each creature should be present on the creature in the form of a non-droppable, non-pickpocketable blank scroll named after the creature or its race/organization. The tag and resref of the item should be abr_it_cd_{description}. Put as much information here as you can stand, but it should all come from canon sources. You'd typically only need one information scroll per race or organization (only one for goblins, one for kobolds, one for Zhentarim, etc), unless the creature is unique.

Equipment A few things should be kept in mind when creating a creature's equipment. The first thing is, what drops? Generally its best if a creature drops all of its non-armor equipment, for realism's sake if nothing else. However, in many cases its best not to drop armor with a creature, especially if that creature is going to be used as a static spawn. Armor is heavy and expensive, so it presents stronger PCs with ways of gaining income while preventing weaker PCs from doing so, creating a wealth gap. Furthermore, its price means it sometimes adds significantly to the wealth of a spawns drop, possibly making the spawn drop more wealth than it should. Also, its rather logical that killing a creature will damage its armor reasonably often. Finally, removing armor from a corpse would be a time-consuming afair, and carrying it would not be easy. This would not be something done often (unless the armor is especially valuable or magical, which it shouldn't be anyway in the case of a static spawn).

Now, about spawn drops. The good news is in most circumstances, you don't have to add loot to a creature for static spawns! If the value of the equipment the creature uses is reasonable, you probably don't have to think about loot at all. Loot is created automatically with scripts, based on many variables in an attempt to match up believable loot (if any) to your creature. The value of the loot is based off of the value of the creature's dropped equipment and its CR, so setting the CR correctly is vital. If the creature is a static spawn, please try to use this built-in loot system unless there is very good reason not to. If a spawn does not use this loot system, it may need to be updated if ALFA's wealth standards for static spawns change in the future.

To disable the loot system, set the ACR_LOOT_DISABLE local integer variable on the creature to a value of 1. If you want to modify the amount of loot droped, set the ACR_LOOT_CR_MOD local float variable to the desired value. This alters the creature's CR for the purposes of calculating loot drops (whether it is positive or negative). Setting it to 1.0 would produce loot as if the creature had a CR of 1 higher than it does, and setting it to -1.0 would produce the opposite effect, loot as if the creature was 1 CR point lower.

Always set "Leave Lootable Corpse" to true, and "No Permanent Death" to true. Set the corpse decay time to 7200000.

(For information on what local variables are, and how to use them, go here: Using Local Variables in the NWN2 Toolset)

Note that regardless of these settings, all creatures always drop the items in their inventory which are flagged droppable. The loot system never actually removes items from any creature.

Note that if the amount of wealth a creature drops (as set by the builder) exceeds the amount a static spawn of its CR should drop, a warning is printed out in the server's log file. Naturally if the creature isn't a static spawn, this can be ignored.

Challenge Rating Also known as "CR", this is vital. Fortunately NWN2 usually gets a creature's CR close to what it should be on its own. Sometimes it doesn't however, so be sure to understand the concept of CR before proceding further.

A creature's of a certain CR should roughly be as powerful as other creatures of the same CR included in ALFA's base creatures. Even if the creature is not spawned statically, the CR must be set correctly for DMs to be able to tell its relatively balance in a fight, and for XP to be awarded properly. If the creature is spawned statically, its loot will be generated based on its CR. If you don't think you know what a creatures CR should be, do some testing for yourself, or ask someone! A good way to test is to use some of your PCs (either controlled by their players or by yourself with their character files locally on your machine).

Do NOT lower a creatures CR because you want to prevent farming abuse, or to lower a PC's rewards for slaying it. If PCs are gaining too much from a spawn of some sort which has its CR set correctly, the problem is in the way the spawn is set up and not the creature itself. Artificially lowered CRs are not only a good way to under-reward PCs for risking their lives, but sometimes lead to accidental PC deaths if the DM spawning the creatures doesn't know the true strength of the creature (until his PCs are face down in their own blood).

Perception Range If the creature's perception range is less than the PC's (ie less than "long") by any meaningful margin, the exploitability of the spawn increases dramatically. For this reason, its generally best to set a creature's percept range to "long". The "long" range has been adjusted to be slightly less than a PC's, allowing the PC to react to the monster without the computer having an advantage in reaction time.

Behavior Types: If the creature is expected to fight at any point, determining how we expect the creature to behave in a fight is also important. Create a local string on the creature named ACR_CREATURE_BEHAVIOR, and set the value of that string to...
BEHAVIOR_TYPE_TANK if you wish your creature to move to the front line and try to hold it. In narrow passages, tanks will attempt to clog the passage. In open fields, tanks will fan out to try to keep as many enemies as possible "covered" as evenly as possible.
BEHAVIOR_TYPE_FLANK if you wish your creature to actively seek people who are fighting others, and to strike them in melee from behind.
BEHAVIOR_TYPE_SHOCK if you wish your creature to run in past the front line with reckless abandon, prioritizing "soft" enemy targets.
BEHAVIOR_TYPE_BUFFS if you wish your creature to focus on support magic for allies. Or, opportunistically, healing.
BEHAVIOR_TYPE_MEDIC if you wish your creature to focus on healing magic for allies. Or, opportunistically, support magic.
BEHAVIOR_TYPE_SKIRMISH if you wish your creature to fight at range until enemies close, and then switching to melee.
BEHAVIOR_TYPE_ARCHER if you wish your creature to only fight at range.
BEHAVIOR_TYPE_CONTROL if you wish your creature to focus on special powers that alter the battlefield, attempting to use things like grease, entangle, and summon monster to stop enemies from getting around.
BEHAVIOR_TYPE_NUKE if you wish your creature to use its strongest magical abilities to repeatedly hit the strongest enemy it can find.
BEHAVIOR_TYPE_MINDLESS if your creature is mindless, and fights fearlessly without strategy or concern for personal safety.
BEHAVIOR_TYPE_ANIMAL if your creature is an animal, and fights without strategy (but still doesn't want to die).
BEHAVIOR_TYPE_COWARD if your creature is a coward, and runs away from conflict.

Other considerations

• Set the creature's CR accurately.
• Unless there is a very good reason to, don't create static spawns with "save or die" spells or abilities. The most obvious of these are instant death spells or petrifications, but holdings, sleep spells, fear and confusion often qualify as well. ALFA has much slower advancement than the d20 rules were ment for, and with a 5% chance to fail any saving throw, "save or die" abilities can too-easily kill even powerful PCs with weak creatures.
• The above isn't so critical if static spawns with "save or die" abilities are avoidable. For example, basilisks can turn a creature to stone with a failed fort save. But they are also slow, lazy creatures, so often times anyone approaching within range of the basilisk's petrification attack is asking for it, and deserves no mercy.
• Unless there is good reason to, try not to make creatures who's power deviates too significantly from creatures of the same type in ALFA's standard pallet. Not only does this harm the believablity and immersion in the world, but it causes some disgruntled PC deaths ("looked like a normal kobold to me, but it had an AB of +12?").
• If you do make creatures with a significally different power level from others of their type, make sure they have some visual difference from their kin so as to not surprise that party of PC1s with those nasty +12 AB kobolds.
• Did I mention the CR must be set correctly?
• When in doubt, play test your creations! Its really all about play balance, and keeping the ALFA experience as consistant as possible between all our different builders with their own assumptions about how to build.
• For more tips on setting up static spawns, go here?.

Custom Scripting Most people can skip this. If you're not using the standard AI scripts ALFA uses on creatures, you'll need to make sure you include ALFA's code into your scripts. You do this by including the file "acr_cre_events_i", and calling a different function for each event type. These functions are:

• ACR_OnCreatureSpawn()
• ACR_OnCreatureSpellCastAt()
• ACR_OnCreaturePhysicalAttacked()
• ACR_OnCreatureDamaged()
• ACR_OnCreatureDeath()
• ACR_OnCreatureBlockedByDoor()
• ACR_OnCreatureCombatRoundEnd()
• ACR_OnCreatureConversation()
• ACR_OnCreatureDisturbed()
• ACR_OnCreatureHeartBeat()
• ACR_OnCreatureRested()
• ACR_OnCreaturePerception()
• ACR_OnCreatureUserDefined()

Its absolutely vital to the functioning of ALFA that these scripts are called on each of their events! So make sure they are in there.

Configuration Options These are the additional cofiguration options allowed by the ACR. They are edited by changing local variables on the creature's blueprint. (For information on what local variables are, and how to edit them, go here: Using Local Variables in the NWN2 Toolset)

ACR_LOOT_DISABLE (integer) If set to a nonzero value, the creature is not given any loot drops by the loot system at all. If unset, it is.

ACR_LOOT_CR_MOD (float) This value modifies the creatures CR for the purposes of calculating the amount of loot dropped. If positive, it adds to the CR and increases the value of the loot dropped. If negative, it substracts from the CR.

ACR_CRE_RANDOM_ABILITIES (integer) If set to a nonzero value, the creature is spawned with randomized ability scores. The blueprint is treated as the "average" for the resulting scores.

ACR_CRE_RANDOM_ALIGNMENT (integer) If set to a nonzero value, the creature is spawned with randomized alignment. The blueprint is treated as the "average" for this, and alignment will never differ from the blueprint by more than one step.

ACR_CRE_ISUNDEAD (integer) If set to a nonzero value, this creature will be considered undead for all scripting purposes. It will still need undead creature properties assigned.

ACR_CRE_SPAWN_DAMAGED (integer) If set to a nonzero value, the creature will not heal to full health upon spawn-in. This variable allows you to equip your monsters with creature items/equipment that provides health bonuses without them spawning harmed.

1. THIS PAGE IS SERIOUSLY OUT OF DATE REFER TO https://www.alandfaraway.info/wiki/Basic_Host_Requirements FOR MORE CURRENT INSTRUCTIONS
2. Download and extract the following NWNX4 files from the link below to a dedicated folder on your host machine (eg. C:\NWNX4):
3. 
   NWNX4_Controller.exe
   NWNX4_GUI.exe
   
   madCHook.dll
   NWNX4_Hook.dll
   xp_mysql.dll
   xp_time.dll
   
   nwnx.ini
   xp_mysql.ini
   
   http://nwnx.org/index.php?id=nwnx4
    
4. Copy the madCHook.dll file to your Neverwinter Nights 2 game folder (where the game installed itself).
    
5. You will need to configure nwnx.ini with your module and game information. The most important line is the parameters entry:
   
   parameters = -module "My Module" -servervault 1 -publicserver 1
   
   If you prefer to launch your module in directory mode, use the -moduledir paramater in place of -module.
    
6. You will need to configure xp_mysql.ini with the correct connection details for the remote database server. Please contact the IA, TA, or DMA for that information.
    
7. Once you have the file configured, you can launch your server using the NWNX4_GUI.exe program (NOT nwn2server.exe as you normally would). It will automatically launch nwn2server for you.
   
   Alternatively, you can install NWNX4 as a service on your host machine by issuing the following commands in your NWNX4 folder (only recommended for advanced users):
   
   NWNX4_Controller.exe -installservice
   NWNX4_Controller.exe -startservice
   
   NWNX4 will show up as a Windows service, which can be started and stopped like any other service on your machine (via Services in Administrative Tools). You can enable the nwn2server dialog window by navigating to the NWNX4 service, clicking on its properties, selecting the "Log On" tab, and checking the "Desktop Interaction" box.
   
   Other service commands you can issue using NWNX4_Controller.exe:
   
   -serviceno Specify service instance number
   -stopservice Stop the NWNX service
   -uninstallservice Uninstall the NWNX service
   -interactive Start in interactive mode
    
8. Note: NWNX logs are recorded in the nwnx.txt file, and MySQL logs are recorded in the xp_mysql.txt file in the install folder. These will help you identify any configuration or run time sql problems (like bad queries).

While the basemod contains every door listed in the DMG with appropriate settings, builders may wish to create their own doors. ALFA has scripts which provide a number of mechanics not ordinarily found in NWN, and every door has an extra set of options because of this.

As with creating new creatures, items, and so forth, the easiest way to make a new door is to copy/edit an existing one. For information on editing the settings of an existing door, skip the next section.

Creating a new door. If you aren't editing an existing door, you will have to configure a number of options. To start off with, you'll need to make sure all of the door's event scripts are set correctly. ALFA's event scripts for doors are as follows: // Update for longer NWN2 file names

• acf_door_onclosed
• acf_door_onconversation
• acf_door_ondamaged
• acf_door_ondeath
• acf_door_ondisarm
• acf_door_onheartbeat
• acf_door_onlock
• acf_door_onmeleeattacked
• acf_door_onopen
• acf_door_onspellcastat
• acf_door_ontraptriggered
• acf_door_onunlock
• acf_door_onused
• acf_door_onuserdefined
• acf_door_onclick
• acf_door_onfailtoopen

If you want to add custom event scripts to your doors, you can of course do so. Just make sure each event script includes the file acr_door_i, and calls the appropriate function for that event, listed here.

• ACR_DoorOnClosed()
• ACR_DoorOnConversation()
• ACR_DoorOnDamaged()
• ACR_DoorOnDeath()
• ACR_DoorOnDisarm()
• ACR_DoorOnHeartbeat()
• ACR_DoorOnLock()
• ACR_DoorOnMeleeAttacked()
• ACR_DoorOnOpen()
• ACR_DoorOnSpellCastAt()
• ACR_DoorOnTrapTriggered()
• ACR_DoorOnUnlock()
• ACR_DoorOnUsed()
• ACR_DoorOnUserDefined()
• ACR_DoorOnClick()
• ACR_DoorOnFailToOpen()

Again, the easiest way to do this is to edit an existing acr_door_* file and save it under a different name. Failure to properly call ALFA's door scripts can break multiple systems of the ACR. So make sure you've got them in there.

Editing a door's settings: Aside from the standard NWN options of doors, we've provided a few more to give PCs and builders more options. These options can be accessed by editing the door's local variables. They are as follows: (For information on what local variables are, and how to edit them, go here: Using Local Variables in the NWN2 Toolset)

ACR_DOOR_CLOSE_DELAY (float) The number of seconds a door will stay open before automatically closing itself. If set to zero or less than zero, the door will not close itself automatically.

ACR_DOOR_CLOSE_NEAR_PCS (integer) If set to 1, the door will auto-close regardless of any nearby PCs. If set to 0 (the default), the door will wait until PCs are out of visual range before closing itself.

ACR_DOOR_STUCK_DC (integer) If non-zero, the door is considered "stuck", and therefore cannot be opened unless forced. The value defined is the strength-check DC to "un-stick" the door. If someone tries to force a locked and stuck door open, the strength DC used is the higher of this value and ACR_DOOR_BREAK_DC. The default value is 0.

ACR_DOOR_BREAK_DC (integer) The DC to break open this door, as per DMG rules. Breaking open a door does not destroy it like doing damage to it would in NWN, but it does keep the door from being able to be locked again. If this value is zero, the door cannot be forced open. Valid values are from 0 to 255.

ACR_DOOR_FAIL_OPEN_MESSAGE (string) This is a custom message sent to PCs who try to open the door and fail. This can be used in conjunction with ACR_DOOR_UNLOCK_PASSWORD to setup doors that require a spoken password to access (even useful for door riddles).

ACR_DOOR_OPEN_MESSAGE (string) This message is "spoken" by the door when it is opened. It is usually used to give the PCs a description of the area beyond an AT, if any.

ACR_DOOR_UNLOCK_HOUR (integer) This is the time of day (in hours) the door unlocks itself. Generally used for shops and things which are only open during certain hours of the day. It will only unlock once, so if something else locks it afterwards, it will remain locked until either another creature unlocks it, or its next unlock time. Valid values are 0 to 23. If you don't wish the door locking or unlocking itself automatically, leave both this variable and ACR_DOOR_LOCK_HOUR set to 0 (the default value).

ACR_DOOR_LOCK_HOUR (integer) This is the time of day (in hours) the door locks itself. Generally used for shops and things which are only open during certain hours of the day. It will only lock once, so if something else unlocks it afterwards, it will remain unlocked until either another creature locks it, or its next lock time. Valid values are 0 to 23. If you don't wish the door locking or unlocking itself automatically, leave both this variable and ACR_DOOR_UNLOCK_HOUR set to 0 (the default value).

ACR_DOOR_UNLOCK_SPELLID (int) This is the Spell ID for doors that require a specific spell to unlock. This will only work for spell IDs greater than 0. Be sure to set the door's default lock status to locked.

ACR_DOOR_UNLOCK_PASSWORD (string) This is what a player must speak to gain access to a password protected door. Leave this empty to require no password. Otherwise, be sure to set the door's default lock status to locked.

ACR_DOOR_AUTO_LOCK (integer) If non-zero, the door will automatically lock itself each time it is shut.

ACR_DOOR_LISTEN_DC_MOD (integer) This modifier is applied to creatures trying to listen to conversations occuring behind a closed doors. The DMG lists this a +5 for every door, but some customization is allowed for different door types. If undefined or set to 0, the door cannot be listened through.

ACR_DOOR_KNOCK_IMMUNE (integer) If nonzero, this door is immune to the spell knock. If zero, it is not immune.

ACR_DOOR_UNMOVABLE (integer) If nonzero, the door cannot be opened or closed by a non-DM creature, even if unlocked. Scripts can still open or close it, however. This setting is often used to represent large doors which a PC could not realistically close on their own even if they were unlocked, like the huge gates on castles and other fortifications.

ACR_AT_SIZE (integer) If nonzero, this setting specifies the maximum sized creature which can fit through this doorway. Anything large will be given a message saying it is too large to fit inside. Valid values are as follows:

• 1 = Fine
• 2 = Diminutive
• 3 = Tiny
• 4 = Small
• 5 = Medium
• 6 = Large
• 7 = Huge
• 8 = Gargantuan
• 9 = Colossal

Note that currently, NWN2 does not support creature sizes of fine, diminutive, gargantuan or colossal. These values are provided here for future compatibility.

Note that if none of these variables are defined, they default to zero. So a door without them would never close or lock itself, wouldn't be stuck or barred at all, would not be able to be forced open, and wouldn't have any sort of a custom message printed if a PC failed to open it.

DM Bonus XP

Bonus XP operates outside of the context of criteria-based Quest XP. It takes the form of a small one-off rewards of 10 XP, and can be triggered by anything from a particularly clever idea, to a perfect piece of role-play representing a PC’s personality, to anything that significantly adds to the general enjoyment of the other players – and DMs. Bonus awards should be made sparingly, but often enough to provide general encouragement for players. Bonus awards are made via the ALFA XP Bonus Cookie Widget.

Combat XP

Combat XP is calculated from the CR of defeated creatures, adjusted by the relative strength of the combatants (the ‘Danger Factor’) and is handled entirely by the ACR. For information purposes, the calculation is as follows:

• XP = ( 20 * ( CR ^ 0.6 ) ) * DF

The ‘Danger Factor’ calculation is:

This table is presented for informational purposes only, as the awarding of combat XP is handled mechanically by the platform.

DM Quest XP

DM Quest XP awards take two main factors into account:

• the challenge faced by the PCs; and,
• the success of the PCs in overcoming that challenge.

The same quest can present a significantly different challenge to differently constituted parties. Cleric-heavy parties will find defeating undead a lot easier than others, while Rogue-heavy parties are a lot less susceptible to ambush and a lot more capable of overcoming trap-laden dungeons. PCs should not be over-rewarded for overcoming challenges that are inherently easy for them; but nor should they be penalized for facing challenges that they are necessarily unprepared for. PCs should also not be unduly penalized for being effective: if a particular tactic surprises a DM and neutralizes a significant part of the challenge that the players are facing, it may be appropriate to reduce the ‘Challenge’ element – but increase the ‘Success’ element for the overall quest. Effectively, when one or another element is significantly increased or decreased, it is appropriate to increase or decrease the level of the award by a single band.

Awards are made for fixed amounts, by selecting the correct option on the ALFA XP Wand.

• Easy (20 XP / RL hour):
  the PCs should be able to overcome the challenge without any difficulty;
  the PCs should be able to overcome the challenge using only their key strengths;
  there is no significant chance of death or other plot-related failure;
  significant outlay of resources is not required;
  the PCs should be able to proceed directly on to another immediately.
   
• Normal (40 XP / RL hour):
  the PCs should be able to overcome the challenge without significant difficulty;
  the PCs should be able to overcome the challenge using their key strengths;
  there is no significant chance of death or other plot-related failure;
  significant outlay of resources is not required;
  the PCs should be able to proceed directly on to another quest with minimal recovery.
   
• Serious (60 XP / RL hour):
   
  the PCs should have some difficulty in overcoming the challenge;
  the PCs should have to prepare and plan properly to overcome the challenge;
  the PCs will be required to use skills and abilities other than their key strengths in order to succeed;
  there is a chance of death, or other significant plot-related failure;
  some outlay of resources is required, including temporary items;
  some recovery and restocking will be necessary before the PCs can proceed further.
   
• Exceptional (80 XP / RL hour):
  failure is a realistic possibility;
  the PCs will have to prepare and plan thoroughly in order to overcome the challenge;
  the PCs will be required to use skills and abilities that are the opposite of their key strengths in order to succeed;
  death or other significant plot-related failure is a realistic possibility;
  significant outlay of resources is required, including temporary items;
  a significant period of recovery and restocking will be necessary before the PCs can proceed further.

Example: Our party spend several IG days planning their raid on an orc camp, including making some specific tactical purchases – a Wand of Sleep and a half-dozen Antidote Potions – to exploit the weakness of the orc barbarians and counter one of their strengths (poisoned weapons). Our party is a traditional Fighter/Fighter/Cleric/Wizard/Rogue combination, but in order to make their approach to the orc camp undetected, they are required to be as stealthy as possible – not a key strength for the fighters and clerics and available only for the wizard by magical means. Their plan works and they successfully raid the camp, their stealthy approach and Wand of Sleep allowing them to neutralise the outlying guards before they can sound the alarm. They free a human slave, although they have to use several Antidote Potions, various healing abilities and potions, and several charges on the Wand of Sleep. Our party has successfully overcome a significant challenge by good use of their abilities and good planning. This quest would be properly assessed as ‘Serious’.

Example: Situation as above, but our party consists of three Fighters and two Clerics and their approach is to buff and slaughter. They fail to neutralise the outlying guards and the camp is alerted to their presence. They narrowly succeed in winning the ensuing mass melee and freeing the human slave. Although the final result may be similar, their approach has been significantly less successful than our first example, so it could be properly assessed as ‘Normal’.

Example: Situation as above, but this time our party consists of three Rogues and two Rangers, and their approach is to use stealth. They carefully reconnoitre the orc camp and are able to sneak in, assassinate the orc leader and liberate the slave, whose escape they facilitate with a series of Potions of Invisibility. While they may have arguably been the most successful of the three parties, they have not been significantly challenged: they have made use of a single set of abilities, key to their classes, that the orcs have been unable to counter. Again, this quest could be properly assessed as of ‘Normal’ difficulty.