Dungeon Designs

To clarify this week's blog title, this post is about my work on "dungeon" designs rather than any sort of structured lesson in dungeon designing. However, I do touch on my own feelings about dungeon designs and make various points that may be helpful to anybody wanting to learn about dungeon designs.

COMMENTS WELCOME: What is your favourite dungeon crawl experience to date and why?

I decided to take a break from writing conversations (and their notorious web of nodes) and turn my attention to filling in the details of some of The Scroll's dungeons instead. Thankfully, Ryan of Eguintir's Ecologies had already designed some interior layouts for me, so my focus was to start scripting events for these areas to my design ends. I take this opportunity to thank all the designers of the areas of this module (and modules to follow) for all their great effort in supplying me with designs that have sped up the release of this module - and helped to inspire me with game play. First, a little forethought...

Let's Begin Our Dungeon Descent

Dungeon Definition

While it's true that every aspect of module design has something to do with "designing a dungeon" (in the broadest sense), hopefully, both builders and players alike will know what I mean when I talk about creating (or designing) a dungeon in particular. And in case there is anyone who is not sure what I mean, I am referring to those areas where the PC is likely to feel out of their immediate comfort zone and in a position that pits them against such things as monsters, traps, puzzles and other such problems in the hope of receiving great rewards in the way of experience, feats, skills and especially treasure; from great new weapons and items, to the basic gems, jewellery and gold!

As the word implies, "dungeons" in a traditional sense are normally located underground. However, I recognise that the term "dungeon" may also refer to adventures that take place in above ground complexes such as castles or towers - and can even refer to locations in space or beyond any worldly material plane of existence! With that in mind, let us continue along the way with some "traditional" photos ...

The Obligatory Main Corridor

Dungeon Purpose

There is something both intrinsically exciting and mysterious about a dungeon of the type I speak. For while the player and PC may know a little about the area they are about to travel to, there should be an overriding air of the unknown. Indeed, some of the most exciting dungeons (in my own experience) have been those dungeons I have stumbled across by accident and know absolutely nothing about, nor have any inclination about what to expect. However, I have also played some games where I have stumbled across a dungeon and the whole experience has been rather dull. So what happened? What makes one dungeon exciting and another not?

The Mysterious Domed Chamber

When I have examined the works of other games and looked for those aspects which have excited me or bored me, I was surprised at what I found. As you can see from the photos I found on the internet and posted here, a key factor about many traditional style dungeons is that they can be quite sparse. I know this is not always necessarily the case, but compared with today's modern designs and habitats, the traditional dungeon is still normally considerably simpler in design. I have noticed that many game designs reflect this well, and more importantly, such sparseness of content is not necessarily one of those aspects that detracts from a good dungeon crawl. Indeed, I have found that it is how the dungeon may have changed from its original design and purpose (possibly simply due to the ravages of time) that holds some of its intrigue.

The Dreaded Cell

Dungeon Character

So, what is it about a "dungeon" in a fantasy role-playing game that really fascinates the player and then holds their interest? I think a large portion of the answer lies in the dungeon's history, or more specifically, the element that gives the dungeon its character! For while a dungeon's immediate purpose is very important for a game's logical flow and prime responses from the player, if there is nothing else to it, then it quickly becomes relegated to the pile of "tick box exercise" dungeons that is soon forgotten about. I have experienced this kind of thing in the RPG "Sacred 2", which while very colourful and vast in size, each "dungeon" I have discovered and played my way through is more tedious than the previous due to each dungeon having very little (or no) character.

Adding history or creating character for a dungeon is no easy accomplishment. If successful, a player should be left with a memorable experience, some uniqueness in the dungeon's design that helps it to be one of those reminisced over for years to come. The player may not remember all the details, but they will recall having an exciting experience when playing through / adventuring within the dungeon in question. For myself, I have such fond recollections with games such as Ultima Underworld, Baldur's Gate, and more recently, some of those "dungeons" from Fallout 3. From each of these games I mention, it should now be clear that when I talk of a "dungeon" experience, it can refer as much to a location far away from the ground as to beneath it ... and can be set in any time frame!

Now, I ought to take this moment to differentiate between an entire game experience and only an element of it, such as a "dungeon". In my own examples above, the entire Ultima Underworld game consisted of one large "dungeon crawl", and so, strictly speaking, I should not be counting it as a "dungeon" experience in the context of this blog. However, I wanted to include it in passing, as it is still a good example of a "dungeon" experience, even if it was the entire game in this example. Looking at one of the other examples, Fallout 3, however, I was suitably impressed by the unique feel of quite a few of its "dungeon" experiences.

The Dungeon's Nuts & Bolts

With the above comments in mind, this week I have started to design the remaining dungeons around the raw material area designs graciously given to me by my area designers. The dungeon purpose has always been known to me from the moment I conceived the plot. The dungeon character, however, is the part that takes time to reveal itself as I work with what I have before me. For further clarification about what I am trying to say about the goals for my dungeons I have in mind, note the following category goal differences:-

Dungeon Purpose Goals: Add Transitions, Add Monster Encounters, Add Loot. (Needs.)
Dungeon Character Goals: Type of Locks, Monster Ecology, Treasure Histories. (Reasons.)

When a player enters one of my dungeons (or at least the main ones), I want them to feel that the place has a character, learn that there is a history, and have a sense of difference about the place compared to other places they have explored earlier. Of course, there is no escaping those aspects that are found common to all dungeons, but I hope to pull off at least one or two aspects of uniqueness to each dungeon that will make the player sit up and take note. I hope to achieve this by adding some unique puzzles, background information, and perhaps some unique aspect that ties both purpose and character together. Whether I succeed in this, I can only hope.

Dungeon Designs: My Personal Pros & Cons

Having blogged on about how I would like to design my dungeons, my "Pros" are probably obvious (and thereby the "Cons" too), but here is my list of pros and cons design objectives/avoidances in the broadest sense (in no particular order):-

DUNGEON DESIGN PROS:

1) Medium to large in size to allow a sense of exploration. (Map required.)
2) Hidden areas, using secrets and concealed objects. (Properly hidden unless skill found.)
3) Logically placed denizens, both historically and ecologically. (With appropriate AI.)
4) Lighting attention - including some completely dark to allow PC own light sources. (Atmosphere.)
5) Sound attention - ambient and possible item sounds. (Atmosphere.)
6) A unique aspect to the dungeon purpose. (Logical flow.)
7) Purposeful and useful dungeon history and/or character. (Scrolls, books, info, treasures, etc.)
8) New logical object interactions above any normal interaction. (New scripts for added uniqueness.)

DUNGEON DESIGN CONS:

1) Illogical rooms and general poor design. (Poor logical flow.)
2) Useable objects at all times, even when not currently available. (Poor meta-gaming clues.)
3a) Too many denizens for area design. (A monster in every room syndrome.)
3b) Poor AI for creatures used. (No creature variation due to poor AI. Meet, hit, die, next!)
4) Minimal attention to lighting or sound. (Areas look and feel the same. No real atmosphere!)
5a) All dungeon "purpose" design and no "character" design. (Cookie cutter designs. Boring.)
5b) Even "purpose" design meets only basic needs. (Lacks story depth - "FedEx" style design.)
6) Lack of any "deep interaction". (One dimensional as opposed to three dimensional design.)

Like with most things I say, there are provisos and exceptions to these pros and cons as well. For example, I would rather a "dungeon" consist of only a few rooms (be small) if there is no logical reason for it to be any bigger. However, I would rather see more "medium to large" dungeons to explore and "get my teeth into", as a preference. Also, I would not want to be inundated with "boring and superfluous history" of a place if it had no real useful bearing on my current events. Historical information that gave me some sort of immediate benefit or would do in the near future, is exciting to find as well as giving the dungeon background and character.

And, of course, once you escape the dungeon and are back into the wide open fresh air, there is always the next one to quest for ...

Escaping The Dungeon ... And So Onto The Next!

Crazy Daisy Fame!

When I went to pick the mail up this morning, I saw a picture of one of our rabbits staring up at me. It was "Daisy" and she had made it to the front cover of the UK magazine called "Rabbiting On" produced by the Rabbit Welfare Association, which my wife and I subscribe to. If you look close enough, Daisy is also the rabbit on the right in my blog's logo image. The small black bunny on the left is "Bud", her bonded mate.

This magazine only comes out four times a year and so to have Daisy's photo on the front cover is a real privilege for us, and she has done us proud. I took the photo in question in the spring 2008, just after we got her and is when she was going around the garden picking up all sorts of grass and using her own fur to make up a nest. So while this photo is on an autumn "feeding special" magazine, I can safely say she was gathering the grass for other reasons than to simply eat. It was this frenzied grass gathering exercise, however, that helped to solidify the "crazy" part of her nickname.

The Scroll Update

This is only a quick update this week as I am continuing to write conversations and so cannot say much without it being a "spoiler". However, I can say that I am still making progress, and that once these conversations are done, I will be left with only some "encounters", "treasure placements" and a couple of "dungeons" to finish. The end of this first module is definitely in sight ... and I am so eager to get it to Beta that it hurts.

Logical Flow & MP Conversations (Revisited) (POLL: MP Conversations)

As I was writing a conversation for one of the companions that a player can add to the party, it slowly dawned on me that there was more needed for this conversation than first realised, for two reasons:-

1) Surrounding events needed to make more sense than they currently did.
2) This conversation needed to be common to all players in a MP game.

The first problem was one concerning "logical flow". Without going into detail (through fear of spoilers), it soon became obvious that the event being discussed was too important to be isolated to this companion and the PCs. "Fixing" this "logic" required an additional number of "new" conversations for new NPCs, plus I had to make a number of edits to existing ones.

As I was finishing the templates required for the additional conversation, I also realised that this conversation needed to be seen by all players when considering a MP game, as it was also a pivotal plot conversation.

In this campaign (unlike the official campaigns), different players take control of their own PCs. So, if one player decides to go in one direction compared to another player, then the PCs they "own" stay under their control and follow them, or carry out whatever they were last commanded to do. I give players this degree of autonomy all the while they are in the same area, only requiring them to all move together when going to a new area. A problem arises, however, if there is a conversation requiring the entire party in an area (like the one above), and the players are spread apart when the conversation begins.

I then recalled that this was also an issue in the official campaign, in that all players in a MP game would have a MP conversation start for them even if they had not been the player to start the conversation and weren't near the speaker in question.

After giving it some thought, I am not sure there is any way around this particular style of delivery. Furthermore, as I have used the "MP" switch in a number of conversations, then this conversation delivery will occur for all players in a MP game from time to time. I have looked at adding some checks to ensure players will be in the same region of an area when a MP conversation starts if possible, but there are likely to remain some conversations that will not have such checks.

If anybody has any more builders tips about helping to reduce this issue, then please leave a comment advising.

So, my POLL this time around is to find out what players think about MP conversation considerations. Do conversations starting outside of your control offend you? Do you recognise they are necessary for a MP game? And so on ... Please leave a comment if I have not covered your option, or if you have anything more to add.

Party Helpers: Henchmen

It's been some time since I last wrote about the player's party, so I thought I would bring this blog up to date with some more information on the sidekick, the henchman. As The Scroll is designed for both multi-player and single-player, deciding upon whether to include any henchmen at all and if so, how many, have been in question for me. Note: The player already has the option to design their own party and/or complement the party with companions that are included in The Scroll. Therefore, henchmen may, at first thoughts, appear unrequired.

First, to remind the reader, in the post link above I define henchmen as those NPCs that the player can add to their party, but whom the player has limited access to ... or control of. Whereas the player can possess companions/cohorts, access their inventories and even control their development as they progress in levels, they cannot do so with henchmen. Therefore, at first glance, the henchman may appear to the player as the "poor mans" choice of party members. However, for some players (and especially at the lower levels), the henchman may be the preferred choice of party membership, and here is why:-

1) Henchmen will auto-level as the party increases in level: For players who like to have party support, but wish to avoid having to control their development, then the henchman is the perfect choice. Access to the main character screen for the party member will still be available to the main PC to monitor such changes in development.

2) Henchmen follow basic commands only: For some players, not having to issue commands beyond the basic ones like "Attack Nearest" or "Stand Ground" may be a preference. That said, greater AI control is still available if the main PC "examines" the NPC and alters settings via the "Behaviour" tab.

3) Henchmen support is unconditional: Henchmen, generally, will not object to a player's actions like a companion/cohort might. E.g. A companion/cohort may prevent or advise against certain actions that are against the party alignment, whereas a henchmen is simply along for the ride.

4) Henchmen deaths are at party level only: Whereas companions or cohorts die when they reach zero hit points (unless observing a Life Essence rebirth choice), henchmen simply fall unconscious when they reach zero hit points. If anybody in the party survives the battle, then the henchman will regain consciousness with 1 hit point. As a player has limited interaction/control over a henchman, then this level of "death control" was a good alternative in my opinion.

To remind the reader: Some henchmen may require payment, some may be less trustworthy than others, but in all else the henchman will provide company as the player carries out their adventure. So, whether the player chooses to build the entire party using only cohorts, or find the support of companions who may have their own opinions, or add a few henchmen, then in all cases, the player can be far from alone ... even if only playing single player.

And just to have an excuse to add a few screenshots, here is where the player can meet at least one henchman to aid them in their adventure:-



Coming into New Edgeton on a cloudy and rainy evening.



The rain has not kept the locals from coming out.



The shops look like they are still open.

Lights, Camera, Action!

In 5 ... 4... 3 ... 2 ... 1 ... You're on!

I thought I would refocus the area of module development I am currently working on, and decided to start looking at some of the cutscenes I wanted to include. (Hopefully, that will be the only pun I use in this post.) As I have said in the past, my ability with cutscenes comes in a close second to area design when it comes to implementing them (i.e. poorly), but I appreciate the benefits they add. And as NWN2 has "camera objects" to help out the builder, I felt obligated to give it a go.

The Light Problem

One of the first problems I encountered was the "light object tag" problem. I have encountered this before, but during some cutscene testing, this problem raised its ugly head again: A "light object" can lose its tag in certain situations, normally on a reload or (as I recently discovered) when travelling between modules. So, basically, if you have any scripts that rely on acquiring a light object by its "tag", there are circumstances when the tag no longer exists and the light object is not "returned", even though it still exists in the area/module.

My solution was to apply a search for all light objects (that I might later need to reference) at the start of the game, and add a local variable to them which I could search for instead. Add to that a change in the way I searched for lights, using GetNearestObject for a LIGHT object rather than by its tag, and I believe I have now fixed all light references in my modules.

Setting The Camera

Once the lighting was sorted and in place, and knowing the scene I intended could now actually be seen in the right light, I worked on placing the cameras, which I decided would be called from a conversation. After all, I have found that using cameras via conversation to be a straightforward operation. However, what was not so easy, was having the conversation (with the camera views) start at the moment I needed it to, to allow the cutscene to work as I intended. There were added complications about what the player was doing when the cutscene was to play. I was designing some to start on an unusual encounter scene, and others if the PC triggered certain events. Having the cutscene start and allow the events to continue to act out as I intended required careful timing, which required experimentation to figure out. There was also the lowered "sound" issue one experiences when a PC is having a conversation. i.e. I have some effects that play sounds as they occur, which work fine outside of a conversation, but you can hardly hear the sounds when inside the conversation. I overcame this problem by adding some sound objects independent of the effect to play as required.

And Onto The Action!

Finally, after the experimentation and tweaking, I have ended up with some cutscene template scripts that cover most (if not all), of the situations where I hope to give the player the occasional cutscene moment. I am glad that it is something I managed to resolve in the end, because the final results are encouraging, and I hope are something that will help add towards the players enjoyment of the experience. It's true these scenes may come as their PCs are about to meet a grisly end, but that's action for you!

Cut! OK, that's a wrap!

In Game Help & Information

Things have settled down again here now, and I have had a little time and energy to attend to this blog ... which also means I have a little more information about the module. I have decided that some of my in-game interfaces may need more information for the player when encountered for the first time. Therefore, to this end, I decided to put together a single "Help and Information" script that is called from clicking on a button that these interfaces may have.

I have not yet decided on all the gaming elements that will include this system, but the way I am implementing it is very simple and flexible enough to include for any of those that beta-testers feel require a little more information for usage. A few lines of code can simply be added to each XML script that requires the extra button to link to the "help box", which in turn feeds the relevant help text to the new box that clicking the button brings up, all from a single script. Below is an example of the kind of thing I mean - this is an example of somebody reading about interacting with a "Combination Lock" for the first time:

Hovering over buttons brings basic information.

The player requires some extra information about potential interaction and so clicks the option.

The player can scroll to read all the extra information available.

From my own experience, I have found that some games do not give enough "instructions" for my liking and having a quick discrete button to additional information and help seemed to be the best solution as far as I could see.

I continue to chip away at the final stages to this module ...

Chipping Away

This is going to be one of the briefest posts I have ever made ... just to say that real life events have caused module building to be placed on hold for the time being (for the month of May). However, rest assured, if I get the opportunity, I will continue to chip away at it as and when I can. Sorry to have to report that.

Furthermore, unless that opportunity comes, it will also mean I may not have much more to add to this blog until next month. Hopefully, however, things should smooth out again by then.

However, now is the time to ask any questions you may have about the module/campaign ... and to make any requests. I should be able to respond to posts made OK still.

Alternative Lock Picking

I have had a little time to look at Kamal's latest module, "Crimmor" in the last week. Kamal never ceases to amaze me with his excellent area designs - and this time, I was also intrigued to see a new lock picking system in his work, courtesy of RWS. (And while I have not had as much time to actually play his module, first impressions look good.)

Followers of this blog will know how much I enjoy implementing mini-games for the player, and I already have a number of lock designs that the player can look forward to. However, inspired by the latest design I found in Kamal's module, I set about looking at adding another lock mini-game to my own module. To this end, I looked again at a released work by Little Baron. I had looked at Little Baron's work a while ago, but recognised it needed some script rewrites to work within my own module design, especially multiplayer gaming. However, inspired by what I had seen in Kamal's module, I decided to go ahead and adapt Little Baron's "Lock picking" system to work with my own. (I have not implemented the trap system at this stage, as I am not sure I will.)

Some of the changes are fairly simple, in that only PCs with any points in the Lock Pick skill can attempt to pick the lock. I have also changed much of the way the system works with reference to results that can occur. In my own system, here are some differences:-

1) Lock DC's altered to fit with my on system values.
2) Lock difficulty alters chance of pick breakage compared to quality of picks used.
3) No "special" picks means additional chance of DC increase on worked lock.
4) Permanent fail simply means a revert to the normal NWN2 lock pick system. (No jam.)

Not all doors and locks will use the system, only some. Those that do use the system offer the PC with the ability a slight advantage in that they can attempt to pick locks normally slightly higher than their ability. Of course, if they fail badly at the mini-game, then the lock reverts to a standard NWN2 lock pick requirement.

Gameplay: A lock can have 2, 4 or 8 barrels, each requiring 1-3 successful "picks" to disable. The higher the lock DC, the more barrels there are, and the more likely each barrel requires more clicks to disable. Therefore, the lowest DC locks will require at least 2 successful "picks" in sequence, whereas the most difficult locks, with the highest DCs, can require up to 24 successful sequential "picks".

Check out the screenshots below for what it looks like in game:

Feedback welcome.

This PC does not have any ability to pick the lock.

This PC has the skill and starts the lock pick. Note all the extra in game feedback.

If the PC fails by a large margin, then the lock will reset and the sequence has to be restarted.

Each barrel (this one has two) requires 1-3 pick attempts (3 in this case) to be successfully unlocked.

Bashing Objects

Just a quick post this week, as I have had to sort out a few personal issues, which have taken some of my time and energy. Just to say that I have been continuing to write for conversations and quests when I can, but coding in this area is progressing slightly slower than hoped. I was held up for a short while when I discovered an issue when I made my PC bash an object. The screen froze for about a second before continuing. I had not been expecting that to happen, and it diverted what attention I had on conversations to sorting this problem out.

I had not noticed the problem when bashing an object before, and so wondered if it was due to me creating a large number of items on the object at time of being destroyed. (Treasure! - Yes, large treasures might happen!) Doing a few debug checks (complicated a little by the fact that I have coded hardness factors for objects), and rewriting the function didn't resolve the issue. However, when I tested the code in a different area, it worked fine. So, I broke the code down to fire bit by bit, and eventually discovered the problem occurred on a large area with many objects; I was closing in on the problem. Eventually, I tracked it down to a loop call that was not "breaking" out of itself when an object was beyond a certain distance from the destroyed object. So, in large areas, the loop was processing a lot of objects ... and, hence, being frozen "in thought" for a brief moment.

A very simple addition of a break in the code had me up and running once detected. Now, I need to get back to writing the conversations and quests .... :)

The End of the Beginning (Draws Near)

I decided to take a look over the first module and write down those things that I still want to do before releasing it for BETA testing ... and the list is finally starting to look smaller! In fact, I concluded that I could mark another couple of notches on the "Completion" figure to read 92% complete! To put that into perspective, I hope to start BETA testing at 97%, and release on the Vault at 99% ... (allowing 1% for patching and/or fixes after release). So, one could say that I am only 5% from "completion" in some ways.

Conversations

I can still see work required in at least six conversations. Here are three of the characters involved:-

The PC finally gets to meet the man in charge!

A sudden encounter with a beautiful naked woman?

Does this man control some power around here?

Encounters

I also still have work to do on at least half a dozen creatures affecting as many areas. i.e. Adjust statistics and address AI for them ... and then test for balance.

Quests

Every quest in the campaign journal (apart from those that extend to later modules) now have "completed" stages ticked, which means I have coded for at least one end point in every quest in the module. Note, I may still have one or two "complete" options still to code for here, but the vast majority are done.

There are also two quests that require "fleshing out" completely, and about 2-3 that still need some work. E.g. In the last picture above, even the area detail is a little sparse. This image also reflects the amount of work I feel still needs to be put into this particular quest.

All in all though, I do think I can see the very first stages of an end to this first module in sight. Subject to my health ... and inspiration, I believe the module can be completed in the coming months.

Instilling Life & Intelligence

I have been distracted by real life events in the past couple of weeks, but I have been able to tinker with some of the monster AI (Artificial Intelligence) and encounters that will be had in the first module. Thankfully, I had already set in place a generic AI script for creatures that already handles many of the basic responses such as healing themselves, or choosing to cast certain spells instead of using basic combat. I also designed this script to allow for the running of an additional script each round, which has now enabled me to add some other tactics used by certain creatures.

Shaughn of Risen Hero fame had produced some Giant Throwing Boulders scripts, which I was able to rewrite to work with my own AI script, and to good effect! I was able to produce results by adding one simple script via the additional script facility and the creatures now throw a number of boulders according to a variable on the creature, and will do so until they run out, or indefinitely if they are near a good supply.

I have also been looking closer at my own Waypoint System that I am using instead of the official campaign version, because I found in certain situations that my own system suffered from the same problems the official campaign version did. i.e. Creatures not always adhering to waypoints. I have now added additional checks that force the creature to keep trying to go to the waypoint in question until successful, adding a "get safe point" when required to prevent any creature "lock up". The routes taken by creatures and patrols now appear much more stable, and all work with waypoint scripting still.

Over the coming months, I am aiming to finish off the last few quests I have to add, and complete the monster encounters and check for balance. I don't think I have much more "original" material left to write or script, as the core ideas are now in place and unless I encounter any more issues, I will simply be filling out now. However, I won't shout too soon, as I did encounter a problem with my "speech" trigger script, which also took some debugging to fix, and so I may still have that kind of issue to consider as I bring the first module to a close. (That "speech" script is one of the more difficult ones to keep track of though.)

As always, your comments are welcome!

Some Campaign Information

At this stage of module creation, there is not a lot I can say that would not be considered too much of a spoiler. Suffice to say, I have been continuing with quests, conversations and journal entries, moving me ever closer to completion. However, I am a little reluctant to move the percentage figure forward at this point, as there are still one or two major conversations I want to address before I do that.

As I was writing some of the plot entries this week, I did think about giving the reader some statistics about the module, which I thought may interest them. Such as the number of quests, the number of areas, etc. However, after giving this more thought, I considered even that information may be too much information. Then I thought of another set of statistics I could offer as an indication of the module's scope: file additions and changes. I refer to XML and 2DA files in particular, as XML relates to new or altered official campaign GUIs (graphical user interfaces), and altered 2DA's can give an indication of altered game play in other aspects, like additional new items or new faiths.

Anyway, whether this information is interesting to you or not, I will let you decide. At the very least, you will be able to have an indication of the amount of "custom content" involved in this campaign ... and as I had already been keeping track of this information over the years, I thought I would share it with you now. NB: These alterations impact the whole campaign, and some alterations may not be seen until modules 2 and 3.

OFFICAL 2DA UPDATED

nx2_crafting.2da - Update Crafting.
nx2_enchanting.2da - Update Enchanting.
placeables.2da  - New placeables, including BCKII.
appearance.2da  - New monsters. PC Camera height to simulate FPS.
visualeffects.2da - New monsters effects. (E.g. Beholder)
wingmodel.2da - New monster effect.
des_crft_spells.2da - Prevent spells making certain potions. (E.g. Light)
des_crft_scroll.2da - SPELL FIXES
des_treas_magic.2da - Random treasure item descriptions made generic.
feat.2da  - Add Althea Feats (Menu etc)
skills.2da  - TLK correction for Craft Armour & Craft Trap description.
ranges.2da  - Increase spotting/attack range of creatures.
spells.2da  - MENU & feat systems & alter "named" spells.
nwn2_scriptsets.2da - Allow added PCs to control like companions.
baseitems.2da  - Allow larger Stacking of smaller objects like Life Essence.
iprp_spells.2da  - Correct CLW cost & alter "named" spells (E.g. Bigby spells.)
nwn2_icons.2da   - Adds new images required.
nwn2_deities  - Alters deities allowed in Althéa Campaign
backgrounds.2da - Removes background traits not in Althéa Campaign.
classes.2da  - Alters classes allowed in Althéa Campaign & Ensures cleric good or evil.
Classes Removed: 28, 37, 46, 47, 53, 54, 60 (Harper, Red Dragon Disc, Shadow thief Amn, Neverwinter Nine, Red Wizard, Arcane Scholar, Doomguide)
doortypes.2da - Blocker doors & BCKII & RWS.
metatiles.2da - RWS.
tilesets.2da - RWS.
tiles.2da - RWS.

COST ADJUSTMENT 2DA FILES

All the following 2DA files were mostly altered to make a much more controlled economy system:

baseitems  - Reduce items back to base level. (Were twice value.)
armorrulestats  - Mithral and armour prices.
Itempropdef: Contains a factor used in calculating costs.
Itemprops: To correct (remove) some invalid property entries from the toolset.
iprp_arcspell: To alter arcane failure costs. (5-50%)
iprp_bonuscost: To alter ability costs. (1-12)
iprp_bonushp: HP Costs.
iprp_chargecost: To alter costs related to number of uses and charges.
iprp_damagecost: Damage costs.
iprp_damagereduction: To alter damage reduction costs. (1-40)
iprp_damagetype: To alter factors involved with various damage types. (Cold etc.)
iprp_immuncost: To alter cost of immunity percentage. (5-100%)
iprp_immunity: To alter cost of a specific immunity. (Poison etc.)
iprp_meleecost: To alter enhancement value costs, including AC. (1-20)
iprp_monsterhit: Alter more OnHit property costs. (Poison etc.)
iprp_onhit: OnHit special costs.
iprp_onhitcost: OnHit Damage costs.
iprp_onhitspell: Spell hit reduction costs.
iprp_redcost: Special container costs.
iprp_resistcost: To alter damage resistance costs. (Resist 5/- to Resist 50/-)
iprp_saveelement: Save costs.
iprp_skillcost: To alter costs of skills (ranks). (1-40)
iprp_spellcstr: Caster level costs.(1-40)
iprp_spellvcost: To alter costs of spell level related benefits. (0-9)
iprp_spells: To alter spell costs. (A factor that can vary with other files.)
iprp_srcost: To alter spell resistance costs. (10-40)
iprp_trapcost: Trap type costs.
iprp_traps: Trap strength costs.
iprp_weightcost: To alter weight reduction costs. (1-80%)
skillvsitemcost: To reduce ID MAX factor cost.

OFFICIAL XML UPDATED

areamap.xml - My Fog of War mapping system.
barter.xml - Allow plot items to update. (May not be needed now. To check!)
characterscreen.xml - Fixes Temporary Hit Points Feedback when switching PCs.
container.xml - Allow limited capacity.
creatureexamine.xml - Examine and abandoned companion fix.
examine.xml  - Allows distance feedback in header.
inventoryscreen.xml - Inventory feedback fix.
journal.xml  - Large journal option.
loadgamescreenx2.xml - Henchman crash fix (for own death system).
minimap.xml - Allow bigger mini maps.
modebar.xml - Emergency Lighting.
optionsmenu.xml - Henchman crash fix.
partygen.xml - Makes newly created PCs follow the correct PC on entry.
playermenu_popup.xml - Added Statistics, Main Menu and Combat Autopause options.
quickchat.xml - Uses larger style conversation screen with NWN1 conv. (Party opt removed.)
splitstack.xml  - Split a stack fix.
store.xml  - New store system.
worldmap.xml - Allow Map Within Maps.
worldmapnx1.xml - Allow limited travel without food.
fontfamily.xml - Read Books Font.

NEW XML FILES

Dozens of new XML (user interfaces) to add to the game play, from readable books and scrolls and other information type GUIs, to choice panels, input panels and puzzles of all types.

One For Me & One For You (Variable Split Fix)

One of the things I have been looking at since I last wrote is what happens to variables on "stacked items" that are split up by the player to share among their PCs. I had to do this when I noticed one PC, after taking a potion, had less duration for the potion taken than another PC who took one from the same stack.

The problem was that when a player splits a stack of items that have a variable set on them, the variable would be lost on one of the split stacks. Consequently, any code that relied on that variable was affected. In my case, I have some potions that vary in effect level according to a local variable on them. So, to fix the problem, I had to edit the splitstack.xml and create a new script that was called from the xml script, which fixed any splits after they had taken place.

Below is the code from the two scripts that fixes the problem. This version of the fix relies on the builder having an original template of the "item" in question, so that the code can recreate the working object by referencing it. However, I believe it may be possible to make a more robust version of the fix (that does not rely on a template) by using both the CopyItem and CopyObject functions. I might look at that in the future if I ever need that level of fix, but mention it now in case other builders needed such.

The XML Script: splitstack.xml:

I have highlighted the only changes needed for this campaign original XML script.

As always, please be sure to only work on copies of any official campaign scripts, and place your edited copies into either a campaign or override folder, so they are referenced rather than the original.

The gui_splitfix script:

The script that handles the callback when the player clicks OK from the split GUI.

And here are the results:

Player is about to split a stack of ten potions (That have a variable set on them).

New confirmation feedback says what the player has just split.

Debug feedback shows the first stack has kept the variable of 2 when the potion is used.

Debug feedback also shows the second stack has kept the variable of 2 when the potion is used.

One thing that I discovered during this fix, is the way to have the object that the player is targeting made available to the coder via the use of the following function in the following manner:

object oTarget = GetPlayerCurrentTarget(oPlayer);

This will be useful to other coders who may wish to alter other aspects of GUI targeted objects.

Perseverance

This last couple of weeks has called for perseverance. The events of the last few weeks have taken their toll on me, and I have been rather unwell and on antibiotics. I'm not sure what I had, but it kept me even more poorly than usual, and just made me feel completely miserable. I believe I am past the worst now, but my appetite is still erratic, and I am still feeling solemn. Having M.E. appears to make me prone to fall ill physically when I suffer with any kind of stress, and the death of Honey hit me hard.

So, what have I managed? To be honest, very little. However, as the title of this post says, I intend to persevere with this project and continue as I can, especially now I seem to be over the worst of the illness.

In the last couple of days, I did manage to write a couple of conversations that related to each other, and altered them according to the order that the player encounters each NPC. As I wrote these conversations, I realised that this was one of those frustrating elements that I have tied myself into with this kind of design. Because I have made much of this first module very "open", it means I have to account for how and when the player may speak with one NPC with respect to another NPC later on down the line. This design doubles the amount of conversation lines I need to write for each NPC involved, and is something that I will address in later modules by redesigning the approach a player can make to such NPCs. I need to be strict about this, or else I simply won't be able to achieve what I hope to do in the future.

Achievements

Something I forgot to mention a few weeks ago that I can mention now to offer something to talk about, is that I introduced an "Achievement" system. It was added for a bit of fun really, as I know how satisfying it can be to be awarded a "certificate" for unlocking a part of the game that may even be just a small side event. At the moment, I have used it in a couple of feats that the PC can achieve through play. i.e. Bonus feats as opposed to those taken at level up. So, a player may suddenly find themselves being presented a certificate for achieving something that awards them a bonus feat.

It uses a generic template, based upon my scroll system, which is presented using visual and sound effects. A fanfare for the achievement! The scroll background artwork is done by Geoff Cordery (Quillmaster).

Picking Up The Pieces

Once again I have turned to the toolset to continue where I left off from last year. I have returned a little later than usual, and it has been hard to get into again since what happened at the end of last year when our pet rabbit Honey died. However, I am trying hard not to let negativity overtake me ... and to allow the healing that faith and time brings.

So, what have I been able to do regarding the toolset in the last day or so? Well, mainly, I have been trying to familiarise myself with an event surrounding one of the companions and to ensure logical flow regarding the area I am currently looking at:-

The PC taking a step into the unknown!

Furthermore, I am at a point where I am having to address a number of conversations at the same time due to the variables involved. The process feels a little nit-picky to me at the moment, but I hope it is something that I will see the benefits of in a short while, and then also start to enjoy more than I am at the moment. Grief is a stange monster.

I also discovered a couple of minor bugs after I placed some creatures into the area I am currently padding out: The first was a walkwaypoints bug, where a creature would stop walking their patrol path when a PC came within a certain range. It turned out to be related to some AI I have coded that allows NPCs to be a little more intelligent than the average monster. The second problem was also AI related, with a faction issue thrown in: An NPC was trying to enter a jail cell to attack their prisoner! A quick faction change made sure the NPC carried on their normal tasks.

Now that I have these recent bugs out of the way, it should be a case of just getting back to writing the conversations again and tying them into the story. I also still have to finish populating the module with creatures, and balancing them for combat. And I do still have some "decorating" of internal areas too, which may require some more scripting to bring the areas to life. However, as I say in the title, I am slowly, but surely, picking up the pieces again.

Another Treasure In Heaven

There are some times in life that are extremely difficult to cope with, and the death of a dear loved one has to be the hardest. It is with a very heavy heart that I am led to write one more blog before the end of this year, which I had not expected to have to write: Our dear beloved pet rabbit, "Honey", died Saturday 29th December.



Honey Having A Cuddly Moment With Me

Close Up Of The Cuddly Moment

For those who have been following this blog a number of years, you may even recall the blog I made when she came to live with us. I cannot stress enough how much she has filled our lives since that time. As I suffer with M.E. and do not get out much, Honey became a constant companion for me, because she lived upstairs where I used to rest or write when I could. In fact, apart from my wife, I would say I spent more time with Honey than anybody else in the last few years. And my wife and I would always sit with her in the evening watching TV or reading from around 6.00 p.m. until we went to bed. It's hard to express just how friendly and intelligent Honey was, but you always felt you were fully involved with each other's affections and truly bonded.

In the morning, she would run around the bed and get my wife up for breakfast, and then come over for love and attention before everybody was eventually up and she could then settle down in "her spot" until evening came around again.

I know it may be hard for some people to understand this relationship we had with her, but I hope there are some who recognise exactly what I am saying. For if you do, then you know the kind of love I am talking about, being expressed in such a way that only such a loving creature can.

While we are in much pain now, my wife, Jennifer and myself cling to our Lord, Jesus Christ, and His words of promise of the new earth in Revelation 21:

"And I saw a new heaven and a new earth: for the first heaven and the first earth were passed away; and there was no more sea. 21:2 And I John saw the holy city, new Jerusalem, coming down from God out of heaven, prepared as a bride adorned for her husband. 21:3 And I heard a great voice out of heaven saying, Behold, the tabernacle of God is with men, and he will dwell with them, and they shall be his people, and God himself shall be with them, and be their God. 21:4 And God shall wipe away all tears from their eyes; and there shall be no more death, neither sorrow, nor crying, neither shall there be any more pain: for the former things are passed away. 21:5 And he that sat upon the throne said, Behold, I make all things new. And he said unto me, Write: for these words are true and faithful. 21:6 And he said unto me, It is done. I am Alpha and Omega, the beginning and the end. I will give unto him that is athirst of the fountain of the water of life freely. 21:7 He that overcometh shall inherit all things; and I will be his God, and he shall be my son."



Honey Jumped On The Bed Looking For Us

The Scroll: An End of Year Round-Up

As another year draws to an end, I have to resign to the fact that The Scroll will not be released this year. However, God willing, I hope to finish this module in the coming months and if all goes to plan have it released before the end of next year.

For this week's post, I thought I would take a look at all those things I have been working on for the module since its beginning. So, when I say this is an "End of Year Round-Up", I actually mean a round-up of everything to date for the end of this year, as opposed to only those things I have done this year. Consider this an overview of The Scroll showing some of those things it will have to offer. And while I have taken the liberty to linking to some posts you may have already read, I hope to some people it may be fresh reading, while to others, a reminder of what they have been waiting for.

We All Have To Die: The Death System

Having come from a pen and paper (PnP) background of playing Dungeons and Dragons (D&D), I have always found the "death system" of many RPGs to be rather weak. Yet, I must immediately add that I can understand why; because dying in an RPG is so much easier and quicker than in a PnP game. With that in mind, I wanted to design a system that kept the immediate threat that death brings, and yet also make it easier to manage at the same time. Thankfully, my PnP campaign (prior to porting it over to the NWN game) was working towards a new era, and I had already in mind the makings of a new magik concept called the Life Essence. This turned out to be the link I needed to help bring about a unique death system to the world of Althéa. For with the new essence, the PC may not meet death as quickly as they could do without it.

Builder's Note: Designing this unique death system was one of my first goals, and it turned out to be much more difficult than I first imagined. Not only were there issues with timing how the Life Essence actually worked during combat, but also what to do if a companion died. The system became more complicated when I accounted for companions being removed from the party bar upon their death and not accessible again until raised from the dead. To enable the player to still be able to access equipment they may have been carrying, I had to introduce the "Tombstone System". Later complications included coding for a player potentially abandoning those fallen companions, and making sure plot items were never accidentally discarded.

Time To Rest: Vigour, Resting & Time

Another issue I wanted to address with the official setup was the passage of time and how often PCs could recover their spells. I found the official campaign's (OC) ease of spell recovery extremely unbalanced, and it seemed to rob the game of its original tactical and careful use of spells, potions and scrolls. For instance, the idea of Scribing Scrolls or Brewing Potions ahead of an adventure was part of the planning that a good player would consider to complement their spells. When time and resting were no longer an issue for any reason, including learning new spells, then it weakened these other aspects of the game as well. So, to help redress the effects of time, I introduced a couple of more ideas adapted from original D&D rules: The hunger and vigour System and an amorphous time system.

Builder's Note: This was another one of those first ideas that I had, which turned out to be more difficult to implement than I first hoped. The problem was complicated further because I wanted to use my world's own calendar system. Add to this the concept of overland travel and quick travels (which still assume the passage of time like on an overworld map) and you have many different alterations to time and all its impacts on the PC, including spell times! Furthermore, due to the nature of the way spells work in time compared to the game world time (i.e. 15 minutes real time equalling 1 hour game time), you can see why all aspects surrounding time had to be very carefully managed, and is why the gaming concept for The Scroll called Time Warped Spells was introduced.

What's An Adventure Without Travel: Maps

As you can probably tell by now, altering or improving gaming aspects of the NWN engine that helped to bring back the same feelings as a PnP game were top on my list of improvements for my campaign. Even from the very early days, maps and their management was one of the first things to be given an overhaul, including having the ability to link between overworld maps. But when the overland map was introduced with Storms of Zehir (SoZ), it introduced a great gaming tool for maps, but one that I needed to make work with my own time systems. Then, finally, as my knowledge of XML coding slowly improved, I was able to develop that golden grail of mapping, the fog of war system, which until this time had not been available to NWN2 - and a reasonable map pin system to complement them.

Builder's Note: I do love maps and the exploration of them. My only regret at this time is the inordinate amount of time it takes me to design an area, which limits my own world and the amount of areas currently available to it. Don't misunderstand me, there are certainly enough to explore, but I don't think I will be happy with the amount until the entire campaign is finished, which means finishing modules two and three. Working with the new SoZ overland maps turned out to be quite a difficult process too, mainly because of timing issues and making new GUIs work as they should. Furthermore, I had to consider attrition due to accelerated overland time travelling. What happened if a companion died while travelling on the area map due to starvation? Finally, I also edited many of the "goodies" and associated scripts and 2da's with the overland maps to make sure only the treasure drops and monster encounters fitted my world design. e.g. The updated crafting system for the World of Althéa uses different quantities of ore/planks/skins that can be found, etc.

New and Exciting: New Challenges, New GUIs

For me, being able to introduce the player to a puzzle or a new way of playing the game was one of my main goals. However, I wanted to make this integrated in such a way that a player could use or NOT use as much of the new material as they wanted to. For instance, when I played PnP D&D, some players enjoyed the puzzles, while others just wanted to simply pursue combats, or concentrate on crafting! Some enjoyed reading background from tomes they would find, while others wanted to pursue a little looting and perhaps capture a spellbook! However, with the ability to craft ones own GUIs in NWN2, a whole raft of events has been opened up to us. So, whether you only ever use the Main Menu, or do take up the challenge of a few puzzles, I hope you enjoy the new look and challenges all the same.

Builder's Note: Being able to code one's own GUIs must be one of the biggest additions to come with NWN2. Not only does it allow the builder to alter many of the OC GUIs to personalise the look, but it also allows the builder a way to introduce many of their own gaming ideas. For me, the way to make a NWN2 game look new and refreshing is to take advantage of this coding system and really make your module come to life in ways unexpected to the player. If you need a guide to know where to begin, then take a look at my own guide. Furthermore, if you like the look of some of these systems, some are already available to download from the Vault. Look at the left hand pane in this blog for further details. For other systems, you will just have to wait until I finish the module! :)

So, that's probably going to be the last post for this year, but I intend to keep doing what I can do to the module until I next write. As a Christian, I do not celebrate any of the seasonal festivals, and so there will not be any "delays" for that reason. And know that I always hope for the best for my readers no matter what the time or season my be!

Module 1 Reaches 90% Completion

The final two interior areas needed for module 1 of The Scroll have been handed over to me by Ryan of Eguintir's Ecologies. Thanks to him, and some conversations I have been working on, I would estimate that the module has now reached the 90% completion stage! And although it seems clear to me now that I will not manage to complete this first module this year, as I had hoped, I am reasonably certain next year looks positive for completion for this first module of three!

I won't deny that this has taken longer than I had first hoped it would. I knew it would take me longer than most, due to my ill-health, but I think my health and some life events have had a bigger impact than even I thought it would have. I think now of those parts that still need doing, and reckon (when I was in better health), that they would probably only take me a few weeks. Instead, they will take me a few more months yet - such is the impact of my health.

GAMEPLAY (The Witcher Review)

On a side note, I finally finished playing The Witcher (Enhanced Edition). I know most people probably finished this game years ago, but .... see above. The point being, however, I do like to take note of things in games I play that may also work in my own module. Here are my "good and bad" points I found with The Witcher (in no particular order):

THE GOOD:

1) Interesting story.
2) Amazing scenery / Excellent designed areas. (I liked the colours and textures used.)
3) Weather system. (Inspired my own weather system.)
4) User Interface system as a whole.
5) Interesting quests.

THE BAD:

1) Travelling became tedious.
2) Unusual mechanics. (I prefer d20 / D&D.)
3) Single player.
4) Alchemy system too complex.
5) Lack of other skills.
6) Lack of interesting items.
7) Use of strong bad language and "nude" scenes.

CONCLUSION:

Considering this game was built using the NWN Aurora game engine (with a couple of extras), I am simply astonished at the great areas and atmosphere the designers of this game have achieved. And while it may still suffer from missing a useful z-axis, I can say that I would be very happy if my own areas came out looking even half as decent as those found in The Witcher. The weather system I designed for my own module was inspired by this game. After seeing it in action here, I felt NWN was missing out on some atmosphere that a well built weather system could bring.

I found the user interface well implemented and especially enjoyed the map system part, which made use of "fog of war" (a favourite of mine in any RPG game). The journal kept good track of my quests, but I found I did not make use of some of the other information in that part of the interface as much as I thought I would. Having come from a "pen and pencil" background, I thought I would have found the extra information useful. However, (and perhaps this is the point), the extra information, while serving as background, it did not serve much in any other way. I think I would have preferred it if it had been presented as a brief introduction to an area, which I could then refer back to (if I really wanted to). The same can be said to some of the other sections here. The point being, I only ever made reference to them after the fact (and if I remembered to go and look), which felt like a missed opportunity to me.

The combat system was "OK" for me, but I missed the D&D system, with which I am comfortable. What really felt lacking to me was the use of spells, but I understand that is down to the design of the universe, and is something you either work with or don't. As I always felt driven to improve my "combat" skills, I felt my "spell" powers were always added as a secondary concern with "talents" I had left over and could not place on more "important" skills. This probably shows me lacking as a player with respect to this part of the game, but I would be interested to hear how other players managed the "spell" usage section of The Witcher. (I believe I only ever used the "wind" to clear some blocked passages and knock down an enemy, and the "fire" one to start a fire or try as an attack.)

I was looking forward to trying out the alchemy system, and while I did use it quite a bit (I guess you have to to play the game properly), I did so with minimal no planning. The problem was the huge number of ingredients and their potential yield, and what was actually required in each formula. It just became too complex to handle, and I found myself just creating the same few potions when I could, with the exception of looking out for a special ingredient every now and then.

I found the inventory system used interesting. It was divided into three sections (ignoring worn items): one section for plot items, one section for normal items and one section for alchemical items. This was quite a good idea, except I often found I "missed" items I had picked up because I did not realise where they had been placed. Occasionally, I would come across an item in one of these sections I did not realise I had picked up. This was especially annoying if the item was a "readable" object that offered more information. Of course, some of this could have been me being inattentive as much as anything to do with the interface. Furthermore, while some of the items I found were interesting, sadly mostly were "not". I say "not" because many of the items I picked up were "food", but just described in a different way, like "bread" or "berry". This was a little frustrating because most of these "foods" did the same thing (restore vitality), but each version took up a different slot in your inventory and could only stack to ten. Personally, I would have preferred just a single "food" item that took one slot and could stack to 100 or more. In this way, the game "appeared" to have more items than it actually had, and so felt lacking for me.

There were the same issues like those I find in a lot of games with respect to logical flow (could take stuff from anybody's home without consequence), and shops being full of "useless stuff" that makes visiting a store a little tedious and more of an exercise than a pleasure. There was even the occasional bug I encountered (a big monster near the end kept having the fight restart after a cutscene replayed), which required me to have to load an earlier saved position to get around. However, all these "problems" aside, the experience was a relatively fun one for me (Final Score), which I believe could have been better if the game was improved in the areas I have already mentioned, but also been coded to allow a co-op multi-player game as well. (My personal belief is that every RPG should allow players to play the game co-operatively.)

Story/Quests: 85%
Graphics/Area Design: 90% (Ignores limited z-axis.)
Sound/Voice Acting: 95%
User Interface: 85% (Presentation and ease of use.)
Stability: 90%
Gameplay Aspects (Personal Experience): 50%

Final Score/Fun: 70%

I am now starting to look at Fallout 3 (Game of the Year version), and from what I have seen so far, it ticks more boxes for me than The Witcher did. I am really enjoying Fallout 3 to date!