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 …