Moving on ...

The next area in the scheme of things was named “Hall of the Mt. King” and included a snake, which barred the Player’s progress.  Recall, that Colossal Caverns was based on a real cave, so to be truly accurate, one would use ‘natural’ looking tile sets to represent these underground areas … but “Hall of the Mt. King” was just too suggestive to not go with it …

So … I decided to create a surreal area using the Ruins tile set, where the Player’s mind creates hewn walls and tiled floors from the natural environment.  Stalagmites become large urns and a prominent outcrop of rock becomes a huge statue of … the Mt. King. 

I substituted a (giant) spider for the snake for several reasons: 1) the spider just seemed more menacing than a snake; 2) I felt the method of circumventing the spider was a better fit (heh, no spoiler here); 3) I felt it worked well with the surreal effect (this spider is as big as a large dog); and 4) using a web to block the entrance and control the flow seemed very appropriate in this circumstance.  The spider spawns in when its web is disturbed.  It does not immediately attack; however it does guard the access to the room.  If the player attempts to enter the room, the spider will attack (and likely win).  Of course, there is a way to avoid this; but I’ll give the Player the opportunity to discover it on their own.

The scripts are “functional” (which is a polite way of saying they do what I want, but not necessarily to the standards I desire); so I’ll likely revisit this area later as I learn and discover more … perhaps a ‘cut-scene’ ….

Which brings up the last piece of ‘general’ scripting that had to be completed … what happens if the Player dies?  Simple … as in the text version, they are given an opportunity to respawn.   Should they choose that option they will be transported to the Bath House and will suffer a small penalty (15 points from their score).

Working on Behavior ...

After getting the wandering monster scripts to spawn the critters when and where I wanted, the next step was getting those critters to behave as respectable critters should. 

I am using ‘Experience Points’ (XP) to record the Player’s score as they progress through the game; mainly because it is convenient for both me and the Player.  So, I turned off the XP given for killing things to prevent folks from running around killing birds and deer and such in lieu of exploring the caves.  The wandering monsters (except for the goblins) all span in as “neutral” to the Player; and as long as the Player does not attack them, they should remain so.  The rats, badger and bear being ‘omnivores’ will become hostile toward the Player if they approach too closely.  I really wanted the animals to attempt to stay clear of the Player, much as animals in the wild tend to do, if they are given the opportunity.

This modification is really pretty easy in the toolset as Bioware has made it possible to execute custom OnEvent scripts for creatures by simply removing the “//” in front of one line of code in the OnSpawn script which triggers an event and directs the engine to look for any custom code for that event in the UserDefined slots.  This allows the default Bioware scripts for each of the events to run as normal, while also running any additional scripts the designer wanted to include.

For these animals, the Event of interest is the OnPercieved event, which will run when the animal first detects the presence of another.  We are only interested in doing something special if the creature detected is the Player, in which case we have the animal move away and then disappear (destroy it).  Yes, it is pretty basic, but remember. these wandering monsters are “add-ins” and not part of the original text adventure; so I don’t want them doing much other than add a bit of ‘realism’ as the Player explores the areas.

The Pirate required a bit more scripting though.  He was to appear next to the Player, steal any treasures the Player may have in their inventory and then run off.  Getting him in and running off with a bit of ‘dialog’ was easy enough … ‘stealing’ the treasures was a lot more effort than it should have been (often the case).  I started out by having the Pirate ‘take’ any treasures the Player had with the intention of then having him ‘give’ them to the Pirate Chest (where the Player can recover them later); but, in spite of the script running, the items were not getting removed.  I still don’t know why (but I suspect it has something to do with the Pirate’s Inventory).  So, I decided just to destroy the objects and create another copy of them in the chest.  This got rid of the objects, but object removed this way do not trigger their OnUnAquire scripts and I was depending on those scripts to track inventory as well as trigger states of other objects in the game.  After a bit of head scratching I realized I didn’t need the Pirate to take the items at all, I could just have the Pirate’s Chest take the items, adding them to its inventory (where I wanted them to be anyway) and be done with it, heh.  That worked like a charm.  J

Wondering about Wandering ...

Wandering monsters … you know, the ones that just sort of appear from time to time as you explore an area rather than sit around waiting for you to find them.  The original text game included dwarves and a pirate as random encounters (wandering monsters by another name); however, given the 3-D graphics and the plethora of things for the Player to “see” while exploring an area; I felt a better selection of random encounters would add to the gaming experience.

As it was my intention to retain the original game’s integrity as much as possible, the additional wandering monsters that I introduced are “neutral” to the Player – they will not attack (unless provoked); but rather give the areas a breath of life.

In the forest, I added crows, and deer; which the Player can encounter fairly often as they move through these areas.  I also included a badger and even a small chance to encounter a black bear.  The badger and bear will ignore the Player, as long as they keep their distance …

I broke the caverns up into two areas: the Upper Caverns include the areas from the entrance to the pit just beyond the bird chamber.  In these areas, the Player may encounter bats and rats.  Once the Player descends the pit into the Lower Caverns (Hall of Mists and beyond); the goblins (my substitution for the dwarves of the original game) and pirate are added to the mix as “special” encounters.

The very first “special encounter” will be the goblin that throws a knife and runs away.  This gives the Player the opportunity to have a weapon before encountering any more goblins, which will attack the Player on sight.

On each special encounter after the first, there is a 1 in 6 chance that it will be the pirate.  The pirate will only appear one time; after that, only goblins will be encountered (this has some impact on the final score, just as it did in the original text version of the game).  When the pirate appears, he will take any treasures the Player may be carrying (if any) and run away.  Any treasures stolen by the pirate may be found in his chest, deeper in the caverns.  There is a chance the pirate may never appear (random rolls you know) and there is also the chance that he will appear when the Player has no treasures to steal – in either case, the Player will miss out on a few points from recovering their treasure from the pirate.

After the first goblin, any special encounter that is not the pirate (meaning all special encounters after the pirate has appeared) will be goblins.  These goblins are equipped with bows (with reduced damage applied … low quality?).  These goblins will be hostile and will fight to the death … be it the Player’s or their own.

Finally, I included a “clean-up” script in the area’s OnExit event to remove any “non-special” creatures after the Player has left the area.  This was done for two reasons:

1)      I did not want to fill the areas up with wandering monsters that slowly accumulate as the Player revisits areas in the normal course of the game; and

2)      Each creature created in the game fires a heartbeat script every 6 seconds.  Over the course of the game, enough random creatures could be created to impact performance.

Basically, there was no real reason to keep these things around once the player had exited the area.

A Goblin in the Works

From here on out, the blog will largely deal with what I’m currently working on in the mod.  I am pretty much working through the areas sequentially and adding items and scripts as they become necessary.  As I’ve gone along I have been tweaking scripts here and there as I come across better ways of doing things – of course when one starts tampering with scripts one has to be careful and ensure that nothing got “broken” elsewhere in the mod.

I have created two types of goblins to replace the axe and knife throwing dwarves of the original text game.  I elected goblins because in NWN dwarves are an option for Players to use – and besides the goblins look meaner.

Goblin1 is the one the Player will encounter first.  Like the dwarf it replaces, it attacks the Player and then runs away, leaving a useable weapon behind for the Player.  In the text version of the game, the weapon is a throwing axe; I changed it to a dagger for a couple of reasons:

1)      Throwing axes cannot be used by every character class in NWN; daggers can.  This just makes it easier if a Player wants to play something other than a fighter.

2)      Ranged weapons are “use and lose” in NWN.  Yes, a script could be written to create a new weapon every time the Player used the one they had; but it would seem rather awkward as the character would have to actually run over to retrieve the weapon – after each attack (would be easier to just beat on them with your hands).  [In the text game, this was a simple command “get axe”; but in NWN, the Player would actually have to move over to the weapon, then collect it, and then attack again – and by this time they are likely right next to the goblin anyway.]

Now then, there are no “throwing daggers” in generic NWN … so, my first goblin actually throws a dart, which looks pretty close to a dagger.

I suppose that now would be as good as time as any to discuss combat.  In the text version combat was easy: you threw your axe and picked it up again; if you missed, you did it again, until either you killed the dwarf or the dwarf killed you.  NWN allows for much broader forms of combat and of course it is animated.  Creatures can take damage, one hit does not mean an instant kill – I want to preserve this part of NWN in the Adventure mod.  The goblins will be easy, with little risk to a Player who has a weapon (I’ve made them tough to kill with bare hands).  Some of the other creatures will be nearly impossible to kill, even with a weapon – all in keeping with the original concept of the text game.

Now, back to that first goblin…  It was a bit of a challenge figuring out “where” to drop the dagger.  I really wanted the impression that the dagger “was” the object thrown by the goblin (i.e., it should appear near the area the PC was when the goblin attacked).  I am using the OnEndCombatRound event to trigger the goblin’s hasty retreat – to make sure it attacks before running away; but usually by then, the Player has closed the distance, and is no longer near the area where the dagger should have landed.  To get around this, I used the OnPerceived event to save the Player’s location when the goblin first detects them.  After the combat round, the dagger is created and placed at the saved location.  The real advantage of this is that by using a location the Player actually occupied, the chance of creating the dagger in a place where the Player cannot retrieve it is greatly diminished. 

My only real concern about the script as it stands, is that the game uses rounds of six (6) seconds each – so basically, the goblin doesn’t flee for 6 seconds after attacking – which is a long time ….  I may rethink the use of the EndCombatRound event and move everything into the OnSpawn Event with DelayCommands to synchronize everything.

Making It Work

The things that make the module “work” are the scripts; and scripting is probably the hardest (and least understood) of all the activities that go into creating a module.  There are some very, very good tutorials out there and Lilac Soul has created an amazing “Scripting Tool” that will actually allow a builder to create a working script by simply selecting options from a menu and filling in a few simple blanks – it is really that simple.  You won’t be able to create complex scripts with it, but you will be able to create just about anything you NEED to make your module work.

I don’t use that tool, as I am one who likes to get under the hood and get my hands dirty – I like to understand what everything is doing and how it all works; but that is just me.

I’ve already discussed some of the scripts that have been created for Adventure; but there are few others that I would like to mention.  One of the neat things about scripts is that in addition to the hundreds of functions that Bioware has provided as part of the Aurora Toolset, you can create your own functions and use them in other scripts.  This is done by using “includes”, which simply is a one line method of attaching one script to another.  By placing any functions that are used by several different scripts into one script (called “cc_inc_routines” for example); I can “include” that script with any others that make use of those functions.

I currently have two functions in cc_inc_routines.  The first is ccTeleportToObject, which is used to jump the Player from one location to another.  This function gets used a lot and including it as an “include” makes things a lot easier.

The other function is ccCheckChat.  This routine is used for the few places where the Player can “say” something and have something happen.  Presently it is only used for the ‘magic’ word “XYZZY”; which teleports the Player between two areas.  The original game had another word as well: “PLUGH”; however, I decided to do that one a bit differently as you may see later.

Then there is a whole slew of “housekeeping” chores such as the stripping the Player of everything including experience when they enter.  I also need to keep track of how many turns a Player has used (a “turn” being a movement from one area to another); and how many turns the Player has used his lantern (it won’t burn forever).  These are all handled by the area OnEnter script.

I think that is enough for now ….

What Have We Here?

As I was really trying to recapture the whole Adventure: Colossal Caves “experience”; I felt it was necessary to include as much of the text dialog that was part of the original game as I could.  I was originally considering using a conversation with a Narrator to provide the various descriptions, as it would keep things together (the conversation file would contain all the descriptions); but I really didn’t like the “Third Party” aspect that lent to the game.  So, I opted to use “Floating Text” above the Players toon to provide the various descriptions.

The real disadvantage is that since the text is generated as needed, it is scattered all over the place in various scripts.  So, making changes is not as convenient (now, which script created that line?); however, for the most part the “text” was being taken from the original game, so the amount of editing at a later time should be minimal.

The area descriptions are probably the most important, and they often change to a shorter version if the Player has already been to that area before.  In the text game, it also listed any objects that were in the area; however, as the objects are readily seen, I felt that was no longer necessary.  I placed the area descriptions in the area’s OnEnter event slot.  As the first three characters of the area’s name were a unique 3 digit number, I was able to use that number in a “switch” statement to keep all the area descriptions and any code that needed to be executed upon entering an area in one script that although lengthy was easy to quickly located the area of interest as “case ###:”, where ### was the Area Number.

Within each “case ###:” statement was a simple check to see if the Player had been there before:  if not, they got the full description and a variable was set indicating they had been there; otherwise they got an abbreviated description, pretty much like in the original game.

As I continue to build and add to the module, using the “Floating Text” seems the correct way to do it.  Everything gets recorded in the chat log and it has a nice smooth, clean feel to it, with everything behaving in a similar fashion.

Next: Making it Work.

Adding "Things"

With the “outdoors” areas completed and connected via transitions, it was time to start working on the items that could be found and used in the game.  Most of these items “do” something so will need some scripts to make them behave as they were in the text version of the game.

The first four items are found in the building.  They are a lantern (needed to light the caverns and avoid a deadly fall); a set of keys (used to open various locks discovered later); a water bottle (initially full of water, but could carry other fluids as well); and some food.  Creating the items was an interesting exercise …

Initially, I wanted the objects to “look” somewhat like what they were when the player discovered them lying (or dropped them) on the ground.  The challenge was that in NWN and Project Q, many items (things that Players can pick up and put into their inventories) lack true models and use the default “loot bag” model.  I thought I could work around this by using “placeables” that have models but can’t be added to a Players inventory and then by some clever scripting, “swap” between the placeable and the item as the Player picked up or dropped the object.  This actually worked fairly well; but seemed sort of “clunky” with a lot of tracking of tags (the way the toolset identifies an object) and resrefs (blueprints used for creating an object).  After messing around with the bottle (empty, full of water, and full of oil); I could see that as the number of items increased this would become less appealing to me – and eventually I would encounter an object that just did not have a model (the ring of keys was already pushing the limits of my  imagination).

So, I settled on a much easier solution.  By placing the objects in containers, they would be easily recognized by their portraits.  If at a later time the Player dropped the item it would have its default loot bag model, but the Player would at least know what it was.  I am a big believer in “less is often more” when it comes to NWN mods; I prefer to add just enough details to suggest the image I am trying to create, and let the Player's imagination fill in the rest.  It keeps the game clean and simple; something that I like.

It was at this point, that my imagination was beginning to take over.  Why was there a package of food just sitting in building?  I thought it seemed rather artificial, so removed it; with the idea of substituting something else – say apples collected from a tree outside?  Yes, I liked that, gave a reason to do a bit of exploring outside as well.  I had also considered adding a fishing pole inside the building, with the idea being that it could be used to catch fish to serve the same purpose – but that seemed to be too much deviation from the original for my taste (perhaps in a later expansion …).  Another change I made was removing the water from the bottle.  You now find an empty bottle, which you can fill at the spring … again, I liked that and felt it was a nice, if subtle improvement.  And finally, just for fun (and perhaps offer a bit of a wake-up to those who are very familiar with the text version of the game), I decided to lock the door to the building and place the keys (the same ones found inside the building in the text game) under a rock near the doorstep – I thought this was in keeping with the spirit of the original game and would offer an early clue that things might be a bit different ….

One of the really neat things that was added to the NWN toolset coding, is the concept of “tag-based scripting”.  This allows a builder to easily attach scripts to objects by simply giving the script the same name as the object’s tag.  So, when an object is used or activated or even picked up or put down, the engine checks to see if a script has been attached to that object’s event and runs it if found.

To make the bottle work, I created three items that looked alike (a bottle, duh!) but had different names (and tags): Empty Bottle, Bottle of Water, and Bottle of Oil.  I also created an invisible object, making it usable, calling it a “Spring” and placing it inside the fountain.  The Player finds the empty bottle.  If the Player  “clicks” on the “Spring”, the mod checks to see if they have an Empty Bottle in their inventory; if so, it replaces it with a Bottle of Water.  The Bottle of Water is “usable” – it can be used on anything including the Player or even the ground (there are some puzzles in the caverns that require the use of water to solve).  When used, the Bottle of Water is replaced by an Empty Bottle.  For fun, if the Player uses the Bottle of Water on themselves they take a drink (including the animation).  The thought of using a bottle of oil on themselves called up images of Gladiators or “Grease Devils” who used oil/grease to make it more difficult for an opponent to grab them – this might find a use later in the caverns ….

I decided to give the apples a special property as well … you know the saying, “An apple a day, keeps the doctor away.”  I decided to give the apples a bit of healing power as the Player may take small amounts of damage from time to time and really, I don’t want to make resting “easy” while in the caverns.  The concern here is that the apples are needed to complete at least one of the puzzles, so I need to make sure they are always available; however the game has a built in mitigation – the Player can only have seven items in their inventory at any given time so it will require some traveling and doubtful that it will be exploitable to any degree.

The grate required a bit of scripting as well.  It is initially locked, and the keys found near the building open it using the normal Bioware script.  I had to create a simple script to see if the Player had unlocked it, and then move them from outside the grate to inside the caverns when they clicked on it.

Coming up: adding the descriptive text to the areas and handling some “housekeeping” routines to keep track of things …

Playing with Tiles

Each area of the module is created using “tilesets”, which it is a group of “tiles” based on a theme (Forest, Desert, Caverns, Rural, City, Interior, …) that can be placed and rotated within a rectangular grid, to create a very good facsimile of almost anything the builder would need.  The NWN toolset provides a very good variety of tilesets to choose from; and several very talented folks have even created more that may be freely downloaded and used in your module as “.haks”.  For this particular module, I am only interested in working with the basic tiles and those added by Project Q.

One of the keys to keeping a module ‘interesting’ is to use different tilesets to prevent all the areas from all looking alike.  For the purpose of Adventure, really, only two tilesets would be required: a Forest for the outdoor areas, and the Caverns for the interior; but that would get boring rather quickly as each area would start to look like the one before.  So, I introduced a few other tilesets where I could to provide visual interest as well as better approximate some of the features of the original text game.

As I had mentioned earlier, the Forest areas were made using the Castle Exterior, Rural tile sets.  I wanted all the forest areas to look similar, as real forests tend to do (that is why they are so easy to get lost in); but for the area where the stream disappears into the slit in the rocks, I wanted to place it into a more canyon-like setting, limiting the player’s choices of direction to either downstream (south) or upstream (north)

[Yes, I know the text game allows east/west movement from this area – but as I mentioned, it was beginning to get easier to make slight deviations from the original at this point.  As the NWN game requires one to actually ‘move’ their toon from one place to the next rather than simply typing “e” and jumping to the next area east; I felt the four forested areas to the north that allowed e/w movement was enough.]

So, I chose the original Bioware ‘Rural’ tileset for this area as it has cliffs that could easily provide the canyon effect I wanted.  Now a bit of head scratching … how to make the stream disappear into a slit in the rocks – no tile provides for that.

My first attempt was to simply end the stream and place a lot of boulders about to hide the banks and then spread about some gravel to continue the dry streambed to the south.  The effect was ‘ok’; but several things bothered me: 1) the gravel was the same elevation as the ground, so it looked more like a path than a streambed – only the fact that it continued from the end of the stream allowed one’s imagination to think of it as a streambed; and 2) all the gravel required a lot of overlapping placeables – and that often results in a bit of a shimmering effect as one moves about the area.  But, it was good enough, until … I discovered the placeable tile floors in the ‘Project Q’ stuff.  One of the floors looked like loose stone (as opposed to square tiles) and by continuing the stream south to the edge of the map, I was able to place the ‘floor’ at the same level as the water and viola, a dry streambed!  A few boulders to hide the ‘joint’ and a nice group of flat rocks to provide the slit under the water where it ended and I felt I had created a very good representation of what the text described – was very pleased with it actually.

For the next area, rather than employ the same trick again (it had two very minor shortcomings: 1) the splashes still occurred when the player walked along the streambed; and 2) the players feet were located on the bottom of the streambed, so were under the rock floor), I opted to use the Desert tileset, which provides for a dry streambed.  This turned out even more advantageous as the end of the streambed is a small depression – just what is needed to match the description in the text game.  The only real problem with the desert tileset is the almost complete lack of vegetation – I did add quite a bit of greenery, but would really have liked a “grass” floor to cover most of the sand above the streambed.

For the caverns, the natural choice of a tileset is Mines and Caverns, but for variety I have also included the Underdark (very useful for the canyons as well as the larger areas especially when a chasm is required …) and again the Desert set for the Bird Chamber, which according the text has walls of flowing orange stone – a pretty good match I’m thinking.  I also repeated my tile floor trick to create the cobbles for the Cobble Crawl area – pretty amazing how different the tileset looks with a different floor texture.

Thus far, I have been rather pleased with the results – I feel as though the toolset has allowed for a pretty good representation of the areas .  There are a few other “underground” tilesets that will likely find some use in the mod as I continue building.

The Adventure Begins

One of my goals in creating this mod was to use the Project Q custom content (.haks) for NWN. I really prefer “Q” over the much more prevalent CEP (Custom Expansion Package) as it is much less “buggy” and does not contain nearly as much “filler” material or “fluff” (some folks like this – I don’t). The Project Q Team has spent A LOT of time making sure that everything included in their package looks as good as they can make it and more importantly works as it should. They are very receptive to feedback and any “bugs” that get uncovered are removed very quickly – customer support that rivals the best in the industry and they are volunteers. What a great group of folks; sharing their knowledge and time with the NWN community.

Building a “simple” module such as this is nice in that you can see progress from the very start. A lot of the scripting that is required to make the objects behave in the intended manner can be added as one gets to the area that contains the object. This also makes testing easier as things can be done one at a time and any bugs worked out before moving on to the next area.

One may wish to consider “naming conventions” for scripts and areas and items before getting too far along to save rework at a later time. Establishing and using naming conventions just makes things easier for the modder; and will pay off big dividends as your module grows in size. One of the first things I decided was to use the original area numbering system of the text version of the game to make it easier to locate areas and script movement between them (transitions). I decided to include a three digit number at the beginning of the name; thus the first area known as “road end” in the text game became “001 Road End” in my mod. Area transitions were set up using triggers and waypoints (see the tutorial or lexicon if you want to know more about these) which were tagged using the following convention:
Triggers: “att_A###@” where “att_” indicates it is an Area Transition Trigger; “A###” indicates the Area Number for the area (### being the three digit number of the area); and @ (optional) is used to differentiate among several transition triggers in the same area – usually the compass direction of its location within the area. So “att_A001N” would be the area transition trigger located in the north of area 1.
Similarly, waypoints (indicating destinations for the transition triggers) were named “wpt_A###@”. Note that the A###@ for the waypoint will be in reference to it’s location in the mod and will generally not match the transition trigger that uses it. Thus, the destination for “att_A001N” is “wpt_A002S” as moving north from Area 1 leads to the southern part of Area 2.

OK – with that out of the way, I was ready to start building. The first map contained the eight areas located outside the caverns (nine in my case as I split the Forest (area 5) into eastern and western sections to prevent the player from heading east from the road and later approaching the same road from the west without ever crossing it …).

For the forest areas, I decided to use the Castle Exterior, Rural tileset. It is one of the newer ones and very nicely done; allowing for elevation changes without “cliffs” and using very nice models for the trees. These areas went together pretty fast as other than the transitions between them, they don’t contain much. Actually the toughest part was getting the elevations correct for the road and stream; I wanted “everything” to slope upwards in the direction of the hill, just for continuity. I changed the building from a “Well House” to a “Bath House” for the simple reason that the models used in NWN are more “medieval” in nature rather than modern and there are some neat animated fountains that could serve as a spring and bath area.

I wanted the Player to be stripped of everything and given some “adventurer” looking clothing. I originally used the OnClientEnter slot of the mod to do this; however, the Player’s gold was not being removed …. After a bit of head scratching I checked the Lexicon for the TakeGold function and sure enough the game is bugged so that it doesn’t work if called from an Area or Module Event. The Lexicon recommended using a trigger around the Player Start position to get around this, and that solved the problem. I then gave the Player 42 gold coins … because it is the answer to life, the universe, and everything ….

One of the reasons I enjoy working with the toolset is the exercise in creativity. The text version of the game has the small stream issuing FROM the well house. NWN does not have a model of a stream coming from a building; however it does include a model for a stream and several buildings as well as a very large selection of “placeables” that can be used to dress up and customize an area. I chose the small round stone house as my bath house and started the stream in the next tile to the south. I then took some stone wall blocks and placed them along the 3 banks at the start of the stream; hiding the dirt banks and leaving the south side open as the stream flowed south. By lowering the height of the blocks until they were at ground level, I was able to make it look like an improved spring. Placing a large pipe between the stream and the building gives the impression that perhaps the source of the stream is inside the building. I was quite pleased with the result.

Recreating Adventure in NWN

I’ve been tinkering around in the Neverwinter Nights (NWN) toolset; always wanting to create a module, but never quite getting to the end for various reasons. My most recent project involves recreating a very early text-based computer game known as Adventure (or Colossal Caves) written by Willie Crowther (and expanded upon by Don Woods) in the graphical format of NWN. Thus far, it has proven to be an interesting endeavor, so I decided to add another element that I’ve always wanted to work with … a blog to document my progress and capture some of those little tidbits of useful information for future reference.

Right. So, just to give some idea of my experience level: I’ve completed the Bioware Aurora Neverwinter Nights Toolset Module Construction Tutorial provided by Bioware. If you are inteterested in using the toolset to create your own games, it is a very useful reference and includes everything you need to build your own module – in fact, you create a module as you work through the guide.

Another invaluable tool for the budding modder is the NWN Lexicon put together by a very dedicated group of skilled scripters who wanted to compile and share their knowledge with the NWN community. It is a “must have” reference and will save you countless hours of head scratching in getting your scripts to actually do what you intend them to do (or explain why they won’t do what you want).

~~~~~

I chose as my “guide”, the 350 point version of Colossal Caves Adventure by Crowther and Woods. I grabbed a set of maps of the game showing how the various areas are inter-connected as well as a walk-thru to help me “get it right”. Admittedly, my original intention was to make it as close to the ‘original’ as the NWN toolset would allow me; however I quickly abandoned that idea when I realized that certain elements did not make much sense in the 3D world of NWN where the player has a compass so really can’t be fooled into wandering around the forest in circles thinking they are walking a straight line.

So, one of my early “changes” was to move the Hill located to the west of the End of the Road area in the original game to the north. This allowed me to have forest areas (where one could wander around in) both east and west of the road leading to the building. At this point it seemed more “practical” to start the player off from the northern most area of the road (assuming they are entering the park) rather than at the road’s end near the building (where you start in the original game) – I’d always found it a bit odd that I had gotten to the building with no idea of what the surrounding area was like in the original game. I did choose to keep the area number s the same as the original game – to the maximum extent possible. After these two changes gelled, the others became much easier.

What this means is that if the player is looking for a “true” reproduction of “Adventure” in a NWN format, they won’t find it here. However, any who have played the original game will certainly recognize most things as being largely unchanged (with the occasional change to a puzzle solution to let them scratch their heads a bit – just like the old days).