Alpha Testing #2

Latest testing reached the point where I decided to restart my alpha-testing ... and so I am now on Alpha-Testing #2. Basically, I had a number of fixes to creature AI, journal updates, feats and general maintenance that made me decide a restart was required to ensure I had sorted these first issues. It also gave me the opportunity to start with a different class PC to try a few other ways of approaching the module.

Script Handling & AI

The main changes I made this time around were to do with the scripts that are attached to companions and creatures, especially as dictated by the NWN2_ScriptSets.2da. In the early days of my coding, I relied more on existing scripts and OC protocols, using variable holders to fire my "custom" scripts associated with creature event hooks, like OnSpawn and OnHeartbeat. However, as my scripts have grown, these two "older" systems have become more of a confusion and hindrance than simply rewriting my own and directly associating them using the SetCreatureScriptsToSet function pointing to the NWN2_ScriptSets.2da. After the issues I experienced in Alpha-Testing #1, I decided this change was sorely needed to allow me to sort through both companion and creature scripts more easily. This change helped a lot when it came to working with henchmen and other associate types that shared scriptsets in common, or I had manually edited to try to workaround the differences between them. This separation has helped streamline the code and tidy many of the discrepancies.

Journal Entries On Creature Death

Another change that determined a restart for me was after I encountered a failure with a "trigger" event to do with a journal entry update after I killed all creatures spawned from an encounter. In this case, a single trigger for an encounter would be simple enough. However, I had a series of encounter triggers that spawned creatures, which was only meant to update a journal entry when all creatures from all these spawned encounters (from shared triggers) were killed. My existing system relied upon another trigger involved in the setup, which simply did not work reliably. Therefore, it was a case of rewriting the scripts surrounding this journal update event for those quests that relied on such.

Other Fixes

There were some other issues that revealed themselves in the latest lot of testing, but they were straightforward to fix by comparison. There was a situation where two "Hunger" icons were displayed in certain circumstances, due to me not doing a correct condition check.

There was the reappearance of some erroneous "faith" related information, which pointed towards an error I had in setting a variable at the time of "losing faith". This also had an impact on clerics "resting" and the prayers they gained, which meant it was important to track down and fix.

"Out with the old and in with the new" is probably the saying I mostly used regarding script changes recently made, as I rewrote some of the oldest scripts I had previously written ... even amalgamating similar event scripts to reduce overhead. I believe I have addressed most of these older scripts now, and, hopefully, I will be able to make progress again.

Hopefully, I will have a bit more to say in a few weeks time. If you don't hear anything in the meanwhile, just assume I am focussing on another set of issues, and will update you when I have more to report.

Alpha Testing #1

I have finally reached what I would consider the alpha testing stage for my module. I know there are some that would say I should just jump straight to using beta testing, but due to the high amount of customization in both AI scripts and XML, this module needs this final stage of internal testing before I release it into the hands of beta testers. As it happens, it's a good job I did, as some of the latest changes I made did have quite a bad affect on the module. Here is just some of what I picked up in my recent testing:-

Companion and Henchmen AI

This was one of my biggest concerns in my initial testing, as I discovered both companions and their summoned creatures would fail to return combat after a first combat. This was a hard cookie to track down! In the end, it turned out to be due to a player AI toggle setting to do with my own AI master control between having PCs in AI Mode or Puppet Mode.

The problem turned out to be due to two issues: The first issue was because I had failed to NOT include henchmen (inc summons, familiars and animal companions) in the master AI toggle, which meant when the game switched automatically to turn-based combat, it turned the AI off on these creatures too, which it is not meant to do. The second issue was more difficult to track down, and turned out to be due to the main PC not using the conversation script attached to it until after the player had switched to at least one companion. Once I had addressed these two issues, the AI all worked again as it was meant to, with companions using AI or not (according to the player's AI toggle setting), and henchmen (etal) using AI as standard.

Indestructible Quest Items

When a PC returned a quest item to an NPC, the item is destroyed as normal. However, upon a reload, the quest item returns to the player. This problem was due to the database not being updated correctly due to the item being "destroyed" rather than "un-acquired", where the check is normally updated. In the end, I decided to have the database update as the player used the escape key to bring up the "Options" menu when saving or quitting the game. This turns out to be a better way of dealing with this code anyway, and it sits quite nicely alongside my "henchmen fix" code that uses the same XML. (The "henchmen fix" code removes henchmen prior to exiting the game, which normally makes the module crash on exit if not done.)

Conversations

As some may recall, I have made a list to double-check four things during this testing time, and conversations was one of them. In the testing, I discovered a few conversations that had illogical nodes due to where the PC was located according to the time of day. (A rare situation, but one that I have proven to be possible.) While this was not a drastic problem, it was the sort of thing I was keeping an eye open for and so it got fixed.

I also decided to add an option to allow a conversation to continue after a player chose to "shop" via an NPC. This was because I wanted the player to not miss out on any potential new nodes that may present themselves *after* having browsed the shop's goods. Works a treat!

I also noticed that if the area map was open when a cutscene conversation started, that sometimes, the map would still be visible over the cutscene conversation. I edited the cutscene.xml to ensure it closed the area map GUI as it started, which now does away with that potential issue.

Quest Completed!

I have a dedicated quest VFX and small tune that plays with some quests, which adds quite a nice sense of achievement. However, in my testing, I discovered that the method I was using to deploy the VFX (via a conversation) was not being reliably displayed, due to the way the conversation set the camera angle. Therefore, in the end, I opted to deliver this VFX outside of a conversation and just within the game itself. I had to alter the SEF slightly, but all now looks far better when presented.

Debug Feedback

And while the least of my problems, I discovered there were still one or two lines of debug code giving feedback, even though I was no longer testing the game in "Test Mode".

Additional New Code

The only new code I added was the implementation of Spell Resistance (SR) when wearing items that give SR. I decided to use the feat system to add a new feat (SR Via Item) whenever a PC wore an item that gave them a higher SR value than any natural benefits the may have had.

And Onwards ...

That's all I have found and fixed so far, but I will continue to go through the module at a reasonably swift pace, and in a fashion that I think may help to mimic the most common choices or path. (Beta testers will probably do better at finding the more unusual path for me.) That said, this first batch of alpha testing has had me restart about four or five times, mainly due to the AI bug, as that was difficult to track down. However, now I am underway again, and have the support once more, hopefully, I will make quicker progress and iron out any other final major issues prior to beta release.

I will report back further testing issues in the days that follow ....

Installing User Mods & Custom Content: READ THIS FIRST!

If you are new to installing users' modules or their custom content, then hopefully reading this will save you a lot of potential frustration and/or having to send emails back and forth with the authors asking them for help about getting something to work. Even if installing user material is not new to you, then maybe this article will help you be aware of any potential pitfalls you have not yet experienced.

NOTE: This article is intended for the player end-user of created material, as opposed to material created for builders to use within their own projects. It is assumed builders will already know most of what I am about to cover, although I would draw their attention to the ADVANCED section, which may help to avoid issues with accidental duplications of files.

Even if you think you understand the BASICS, please at least consider reading the ADVANCED section of this article, as that covers where most issues arise after an installation.

THE BASICS

BACKGROUND

The Neverwinter Nights PC game franchise comes with a toolset that allows users to build their own custom content for others to download, and then to install to use or play. User content can vary from relatively simple User Interface (UI) alterations (e.g. Making the "Game Paused" wording say something different when the game is paused), to building an entire module, with or without additional material. When installing user content, however, care is needed to make sure the files and folders that make up that content are placed into the correct NWN folders on your own computer.

NWN FOLDERS

From here on in, whenever I use NWN, I will be referring to the NWN2 game only, but some aspects of what I say can also be applied to the original NWN1. The main differences are that NWN2 has more places where user content files and folders can be placed.

The following also assumes a default installation on a computer running Windows 7. Please bear that in mind if you have changed the installation path or run a different operating system.

When you install NWN, the main game default installation path is:-

C:\Program Files (x86)\Atari\Neverwinter Nights 2

When installing USER CONTENT, there is NEVER any reason to alter any of the files or folders from those in the above folder. At the very most, only ever make copies of files from this installation directory, and work with the copies inside the folder mentioned next.

However, at the time of installation, a user folder for NWN is also set up here:-

C:\Users\UserName\Documents\Neverwinter Nights 2

When you are asked to install user content, it will be into the folders that are found in this folder. The most important folders to note are as follows (as found in alphabetical order):-

Campaigns
hak
modules
movies
music
override
tlk
ui

This article covers files (and/or folders) that are asked to be placed inside these folders. If you asked to place any other files into other folders in this path, then please follow the builder's instructions.

USER CONTENT PLACEMENT

When you download user content or a user module, then the builder should explain to you in a Readme.txt or similar instructions where to place the files you have downloaded. Some user content may only use one of these folders, whereas downloads (such as modules) are likely to use many or possibly most of these folders.

Hopefully, even if the builder does not give clear instructions where their files should be placed, the way they may have packed the files may help indicate where they should be placed. This is the way each folder should be used:-

Campaigns - Contains the "campaign" folder. i.e. The "global" files for one or more modules.
hak - Contains hak files: Material used to alter in-game visuals. (Primary 2da files are placed here too.)
modules - Contains a module file, or a module folder. (Differs according to builder tastes.)
movies - Contains user created movie files in bik format.
music - Contains user created music files in bmu format.
override - Contains different files or folders to help change the way a game plays.
tlk - Contains user created tlk file. Alters what text the player receives in a game. Can be original reworded or new text.
ui - Contains user altered or created primary UI XML files. (Can include supporting images & sounds.)

NB: This is a general structure. However, it is possible (and even likely in some instances) that many files (even XML or 2da format) can and will be placed in the Campaign folder. However, some primary XML and 2da files have to be treated differently and are placed elsewhere, as explained above.

ADVANCED

FAULT FINDING

If you have followed the builder's instructions on where to place their files and you have done so correctly, then all should work fine when you start the game. However, through no-one's deliberate fault, problems can occur and are often down to duplicated files. (NB: There is an exception to this: See Some Safety Steps To Follow #4 below.)

While any file duplication can be a problem, there are two specific types of file that are more prone to duplication and are the highest likely to cause problems with your game. The two file types I refer to are the 2da and XML file formats. These two are more likely to suffer from duplication due to the high amount of alteration and testing they go through at build time, and also due to the location they are finally placed when the content is released.

For example, a single XML file may have five clear different versions (but all with the same name), spread across four different folders, with each one making a difference, subject to where it is placed. I will give an example of this in a moment, but first need to explain something about "priority" with respect to files being read for the game.

FILE PRIORITY

As far as I am aware, there are up to four folders that can affect when file priority is involved. Here follows the priority of folders from which the NWN reads and finally executes a file:

HIGHEST PRIORITY
================
HAK (PRIORITY) (*)
HAK (NORMAL) (*)
OVERRIDE
CAMPAIGN
CUSTOM UI (+)
=================
LOWEST PRIORITY

(*) NB: A game can come with more than one hak file to place inside the hak directory. Hak files have their own order of priority, subject to how they are installed by the builder, and so if a file appears duplicated in multiple haks, then only the highest priority hak version will count.

(+) This folder does, however, take the priority when you launch NWN for the first time, which is why it is used by builders to set up fonts, typefaces, opening images, etc for their module. However, once the game is loaded, it becomes the lowest priority as other folders (with files) take precedence.

So, what I am saying is, if you had, for example, an official campaign XML file with the same name (but each slightly altered in some way) in each of these directories, then the one in the HAK (PRIORITY) would be the only one to fire. If the XML file was not in the HAK (PRIORITY), then it would look at the one of next priority in the list, HAK (NORMAL), and if it were not there, it would look inside the OVERRIDE folder and so on, until it had gone through all the potential user folders.

If, after going through all the USER folders it does not find anything, then (if an official version exists) it will default to the official game version, which is installed with the game. (i.e. The ones you should NEVER alter.)

NB: I have NOT included the "module" folder, as not all files placed inside this folder have an impact. E.g. An XML file placed here will not do anything (at least in my tests). However, for the purposes of including it in the list, and if it does have any impact anywhere, then it would come below CUSTOM UI and just before the official game files. E.g. Official scripts can be altered and saved to the module by the builder, which then take priority here.

The 2da files suffer from the same kind of duplication error, as they can often be found in many places. So, if you have an old version of a 2da sitting in your override folder, which is taking priority of the one that you downloaded and comes in a campaign folder, then errors will occur.

SOME FILE INFORMATION

XML FILES: These are the files that alter the way the UI works within the game. UI are the "user interface" such as character sheets, inventories, maps, etc. It also includes some things you may not expect, like the fonts used and individual components, like scrollbars. If a font is missing, or a UI does not look correct, then the fault is likely to be with an XML file.

2DA FILES: These are two-dimensional arrays (2DA). Basically, think of a table with columns and rows, where code calls for references held within this table according to a row or column reference. If you are seeing odd behaviour with respect to some wording or missing text, especially related to character information, then it is likely to be caused by a missing or corrupt (old version) of a 2da file.

OTHER FILE TYPES: The user folders will contain a great number of other files, from new models, tilesets, terrains, images, sounds, scripts, etc, etc. And, in principle, they can all suffer from the same "duplication priority error". E.g. An old tga image file sitting in a hak, when a game is trying to use the one that comes within its campaign folder, will cause problems. However, due to the way that many of these other file types are put together at build time, they are less likely to encounter this issue. HOWEVER, if you do experience unexpected results, then do a search for the file in question among all the sub-directories of the NWN user directory.

SOME SAFETY STEPS TO FOLLOW

Here is my advice to follow when installing custom content:-

1) KEEP THE OVERRIDE EMPTY: Most user content, if properly structured, should NEVER need to have anything placed within the "override" folder. The "override" folder is a quick and messy way to fix things, or, more normally, to test things. If you have downloaded custom content that uses the override, then chances are, if you have other custom content you use, then it is likely to break that. NB: Note, however, a duplicate file in an override (even if newer) will NOT take priority over the same named file in a HAK.

2) CARE WITH CUSTOM UI FOLDER: You should take careful note of files that are added to the CUSTOM UI folder. There is nothing wrong with files being placed here, but you should be aware that files placed in this directory have the potential to alter EVERY game you play while these files are present. However, sometimes, these files NEED to be present to ensure the custom content or module work as intended, and so one must not be afraid of following the instructions to place them there. Just be advised that it is best to work with only one custom folder at a time within the CUSTOM UI. Most builders will provide a folder with their CUSTOM UI content, so it is simply a case of temporarily removing this folder to the desktop (for instance) if you intend to play a different module.

3) CAMPAIGN & MODULE FOLDERS: Files and folders can be placed into these folders without any real concern, unless, of course, somebody happened to use exactly the same name for a file or folder as you are about to copy. They can sit here indefinitely without causing any concern to any other game at all. The only caveat to be aware of, is if the builder updates their content, you may also need to update files in these folders too. (However, see THE PRIORITY HAK next.)

4) THE HAK FOLDER: Treat similar to the Campaign & Module folder. i.e. Files placed in this folder are not likely to interfere with any other module, unless they have the same name as another hak used for another module. NB: This may be important to know if you have downloaded two modules, and each uses the same hak, but the builder may have slightly altered the original hak and not renamed it. This is unlikely to happen, but may be worth noting if the builder forgot themselves.

THE PRIORITY HAK: More importantly, however, is this folder is the one that can contain what I call the "Patch Hak", which is basically a dedicated priority hak for a campaign or module. If your module comes with such a hak, then be sure to keep this hak up to date, as it contains all the latest fixes for the game in question, and any files it contains get priority over any older ones. In this case, this is where the file priority system works in our favour, as it uses (in theory) the most up to date version of the file in question, over  and above any other version found lower in the list of folder priorities. This is the one time when file duplication is expected for players who are "patching" their game. Using this method of file updating means a player does not have to restart a module, but can carry on from a saved game.

5) THE TLK FOLDER: This folder is where you place the builder's own tlk file. Once again, files placed in this folder are not likely to interfere with any other module, unless they have the same name as another tlk file used for another module. NB: The official campaign tlk file is called Dialog.tlk and is found in the installation directory. This file should NEVER be altered, and any user tlk files should use a different name and be placed in the tlk user folder.

NB: I am unaware of anybody editing the official Dialog.tlk file directly, but there would have to be good reasons for doing so. In theory, a good builder will rather supply an end user with edited 2da files and a new tlk file so that all original files are left unaltered.

6) MOVIES & MUSIC FOLDERS: Treat similar to the Campaign & Module folder. i.e. Files placed in this folder are not likely to interfere with any other module, unless they have the same name as another file used for another module.

FINAL COMMENTS

There is a great temptation for players to try to install all their favourite modifications for the many user modules available. This comes inherent with installation dangers! Often, a module contains hundreds, if not thousands of edited files. Unless you know where to look for potential file duplications, then any modification left within an override or added as another hak has huge potential to cause the game to fail. Even if you do find the clashing (duplicated files), trying to merge them without knowing the full implications, will also likely cause a broken game.

So, while the temptation may be great, I would recommend being prepared to make sure your environment is "clean" before you attempt any potential installation, and use only the files that come with the module.

Lastly, if you have done everything your end correctly, then at least you have a good understanding of what to explain to the builder with respect to the problem you are experiencing.

Light, Sound, Conversation & Monsters!

ATMOSPHERE

I have set myself a procedure to follow now as I go through my module area by area. First I go through an area checking the lighting and sounds, to make sure the ambience feels right and that the player can "see" relatively well, subject to their own visual capabilities or need of a light source. I make sure area sounds are balanced, and offer audible clues if need be.

At this stage, I also check to make sure the area and mini maps are set up and working correctly with respect to whether they are available in the first place, and to ensure they are not giving more information than they should be by revealing hidden rooms before they have been discovered.

If all looks good, I double check that I can reach every object I need to, and make sure transitions work as they should, at the time they should. Once I am satisfied that this all seems fine, I move onto stage two: conversations.

Evening fireflies and a cloudy sky

INTERACTION

Checking conversations is much more difficult to do due to them relying on variables being set. However, I check what I am able, and even alter some variables or leave access to certain links just to check other responses if need be. This testing stage is more to do with ensuring I have at least finished all the conversations in an area with respect to what I want the creatures or objects to be able to "say" in the first place. For instance, I have a number of placeholder conversations that have only partial comments and need finishing off. My goal now, is to ensure I finish all conversations in an area as I make my way through them on this final testing stage.

Store Interaction: This book looks interesting!

SURVIVAL

Once the conversations are completed for the area, I move onto the combat monsters that will be encountered in the area. This part requires a little more attention, as I want to make sure I have allowed a fair and reasonable environment in which the player can meet the challenge. This is all about game balancing, and player choices prior to encountering any monsters can make the difference in whether the player perceives the game as a fair challenge or not. That's not to say the design should make every encounter a breeze or nightmare simply based on statistics, but also recognise environmental factors that may alter factors for either the PC or monster in the first place. E.g. A place where a PC could never rest would eventually wear them down to the point where even a fight with a giant rat may be difficult.

This monster stage, is also the time I ensure the bestiary has been updated for the creature if required. The bestiary can give slightly more information about a creature, which sometimes gives extra clues about how to fight it. At the very least, it will help categorise the creature for the player.

Example: Animal selected from creature category.

Life Can Be Draining

Progress continues ... and once again, I find myself back into coding some AI related scripts. This time, however, these scripts deal with creature encounters and how they respond in certain opening situations rather than the actual combat responses thereafter. That is all rather deliberately vague, I know, but suffice to say, it all works as it should do now.

However, to be blunt, I have not done as much as I would have liked since I last blogged, simply because of real-life issues (including worse health again). I had hoped to have finished the dungeon I am currently working on by now, but this has simply not happened. Apart from the above AI scripting, however, I did manage to alter some existing spell code to rework the way life-draining creatures work with my Life Essence system. (Something I touched upon in my last post.)

I'll keep doing what I can as I can ... and obviously keep you all updated. In the meantime, here is another screenshot ...

The Beginning or End of a Mystery?

Lots of Little Updates

Things are still moving along ... gradually. I am getting closer to finishing the last part of an area that will then leave me with just a few odd jobs throughout the module ... and then ... perhaps a final alpha test by myself to ensure there are no glaring mistakes and then it goes to beta! But, let me slow down a bit and just take this one step at a time ... and speak about some of those points I have been doing lately.

TLK & 2DAs

Recently, I have been updating my custom tlk file and spells.2da to make spell descriptions read more logically. E.g. Some spells that have lesser or greater versions I have renamed them with the quality in brackets. E.g. Dispel Magic (Lesser). It's only small changes, but ones that I have always been meaning to make and so as I was rewriting the Restoration spells, I thought I would do this at the same time.

Life Essence Update

I rewrote the Restoration and Restoration (Greater) to require Life Essences per drained level if the target requires any level restoration. This fits into the general scheme I have in mind with respect to Life Essences as a whole in coming campaign developments. This system is the same that I will eventually use with respect to level draining creatures sapping "life" and gaining Life Essences for themselves. Think of vampires gaining extra life by sapping yours. While not a direct level to level swap, it does equate to a gain by the life-draining creature.

Other Stuff

I have also been adding to the item drops available when it comes to showing "placeable" objects rather than the generic loot bag. This required some extra work to fit in with some of my other systems and to make sure acquisition scripts still worked fine, including a new crafting option that uses some new runes specific to a particular area.

Anyway, just a quick screenshot to leave you with for now ....

What Is This Place?

Players' Expectations (A Personal Perspective)

A little while ago I spoke about Player Expectations with respect to free mods that they can download. Just recently, STEAM ventured into a project to allow Skyrim mods to be added to their listings for people to sell rather than be offered for free. (This idea was quickly quashed by the public after only a few days.)

All this interest in the mod gaming market got me thinking about NWN/NWN2 mods and comparative RPG games in general again and what it is exactly that motivates players' interest in certain styles of play within the RPG gaming environment. Everybody is different of course, and each will be motivated by different mods/games for different reasons.

Like most who read this blog, I have my fair share of likes and dislikes when it comes to certain styles of games, and I prefer to have them tick certain boxes as I play them. However, just recently, I was surprised to discover something about my own interests that sat at odds with a certain game design that I am currently playing ... and with everything else currently going on in the RPG world, I felt prompted to discuss this aspect of gaming again. (More about that in a moment.)

I like to think that I am a "fair" player, by which I mean I will put up with the odd bug (as long as it is not game-breaking), and can put up with a fair amount of frustration aspects (like some back-tracking). I will even accept older graphics in a game, if it is not one I have played and like the looks of it. For example, a short while ago I started to play the "Gothic" (2001) and "Divinity" (2002) series of games, because I had never played them and Steam had them on one of their good deals. Now these are both old games compared to today's standards of games, and both lack some of those "tick boxes" I like to have. However, to my surprise, they are both more enjoyable than another game I have recently started, called "Kingdoms of Amalur: Reckoning" (2012). (I tend to start more than one game than once for variety. As a slow player, it helps to give some variety.)

At the end of this analysis, I will compare my findings with how it relates to NWN2, and, hopefully, how it compares to The Scroll.

APPEAL ANALYSIS

This recognition of one game appealing more than another did not occur to me until after some time of playing these games. Let me start by showing which of these games scored best with reference to my own "tick box" requirements (in no particular order). Note, I have only finished "Divine Divinity" at this time of writing:-

1) STORY: Winner: Gothic: Had me hooked straightaway, and not just because it's premise reminded me of my own module. Even though I have not yet finished this game, I still like the overall appeal of how the game sets its pace and keeps me interested in the story. DD comes in second, with KoA coming in last. I felt the latter suffers from a diluted story due to its open-endedness.

2) CONVERSATIONS: Winner: DD: I felt that of the three systems, DD felt the most natural to me. Gothic and KoA were OK and certainly acceptable, but if I had to choose one, it would be DD. Interestingly, having "talking" during the conversations did not affect my choice at all, as I often found myself skipping talk anyway, especially with KoA, which just felt like a lot of superfluous drivel. NB: I know you can ignore all this in KoA by jumping straight to the "top" option, but I like to get involved in other dialogue if possible. This dialogue felt rather one sided though.

3) COMBAT: Winner: Gothic: Melee speaking, while Gothic has comparatively fewer weapon options than either of the other two games, this actually turned out to be more exciting to play than the myriad number of options that the other two games offered. On the other hand, as far a magic combat goes, DD had the most straightforward method of spell acquisition and usage, which made it more accessible and enjoyable to use, giving it second place.

4) PC DEVELOPMENT: Joint Winner: Gothic/DD: In fact, the only reason KoA actually loses out in this area is because of the inordinate amount of achievements that affect KoA outside of normal development. i.e. There are other aspects beyond the normal skill benefits that can affect the way you PC plays that you decide at level up.

5) MAPS: Winner: KoA: The map system in KoA is extremely well done. It has good map mechanics, including a mini-map. DD comes in a close second, with Gothic trailing in last due to a really clunky way one has to access them.

6) EXPLORATION: Winner: Gothic: This surprised me greatly, because I like exploring and I thought KoA would win hands down. However, I actually found Gothic the more interesting environment to explore because I felt it was more manageable. And for the same reason, DD came in second. KoA, by comparison, felt long winded.

7) CRAFTING: Winner: DD: I like the idea of crafting, and think it can offer a lot to a game. However, I have found that the thing that stops me from using a crafting system more than anything else is how complex it is. Complexity can mean anything from the number of combinations to make a product to the difficulty in applying the skill in the first place. DD was as simple as finding single crafting items and having a skill to apply them to other items. Gothic felt items were too far and between to achieve, and in KoA I felt overwhelmed with the number of options.

8) MECHANICS: Winner: DD: To be fair, NONE of these games had "great" mechanics in my opinion. KoA would have won, had it not been for the lack of a decent "Inventory" access, which really got me down after playing some time. I was surprised at how much the "Inventory" GUI (out of all the GUIs) would have made such an impact on the game experience for me, but it did. I even had more sympathy for Gothic's poorly implemented inventory system compared to KoA in the end.

COMPARISONS & CONCLUSION

So, here's the crunch .... Take a relatively new RPG (KoA: Reckoning) and make comparisons to some older RPGs (Gothic and Divine Divinity), and the newest one, even with much slicker graphics and many more game options, comes in bottom (for me at any rate):-

WINNER: GOTHIC

For me, Gothic wins (and KoA loses) for a number of reasons:

Gothic, while it takes a bit of time to get used to its rather antiquated mechanics, has a good story and a "traditional" character development system, which probably will appeal to old school gamers like myself. Even though Gothic suffers from a lack of a decent mapping system, exploration around the game area feels more exciting than exploring the albeit larger regions that the other two games offer. And when you start to encounter enemies in the game world, your character skills, abilities and weapons all feel more important than the other two games. I have not done any crafting in Gothic yet (as it feels too much of an effort to achieve), and recognise that Divine Divinity has better gaming aspects in this region and overall general mechanics, which was the only game I felt crafting was simple enough to apply.

SECOND: DIVINE DIVINITY

DD comes in a second, being closer to Gothic than KoA as an overall result. DD scores higher than KoA due to having a better story and PC development than the latter (in my opinion), but starts to fall down with its similarities that made KoA come last, like innumerable number of items/weapon combinations that don't really mean a lot to me after a while. It also suffered from some large meandering regions, which just felt too tedious, and I was glad to get them done and move on. DD did, however, have better overall gaming mechanics than Gothic and a more straightforward crafting system, which gave it an element of interest above the others.

Loser: Kingdoms of Amalur: Reckoning

KoA, on the other hand, has plenty of place to explore compared to Gothic, but with "plenty" comes a lack of pace and direction (in my opinion). I agree that KoA has done well to tie together all the quests and updates the local and world maps accordingly (winner hands down there), but just because those quests are there to do and the world is there to explore, I feel as though my heart and reason to be motivated to do so are seriously lacking. But what about the greater number of weapon combinations and combos, etc. that KoA offers I may hear you ask? Well, to be honest, the combinations are too many and too vague to be of any real interest or motivation to do anything with. As long as I have a reasonable weapon and/or spell and have developed my PC relatively well, then I will generally be OK. I wouldn't really know if I had found something decent above what I already carried or not really, and after picking up the nth coloured item, I'm not sure if I even have the heart to carry it back to a shop to sell it, even if I could stuff another item into my already limited and difficult to manage inventory.

NWN COMPARED

Now we come to the point ... CRPGs come in many flavours with comparable gaming aspects, but with some things that arguably make the game good or bad. I will now take a look at the points raised above with respect to how NWN handles CRPGing, and hopefully, how my own module, The Scroll, will work upon its release.

WORLD VIEW: To begin with, NWN offers a superior (in my opinion) number of perspectives to the player to explore the gaming world compared to any other CRPG in the examples above. Gothic uses first person, DD uses fixed isometric, KoA uses a 3D over the shoulder third person. NWN, on the other hand, uses 3D isometric with additional options to make world interaction more flexible, especially when it comes to combat. For this reason, NWN is the superior game when it comes to tactical combat in a CRPG, which is traditionally a style enjoyed by D&D players and the style to employ to duplicate such a roleplaying environment.

GAME SYSTEM: Each of the games above uses it own system to allow players to develop their PCs. They all rely on gaining XP, and then selecting skills and/or attributes to increase as the PC develops. The problem with "new" systems, however, is they are never easy to quantify with respect to overall development. The myriad options available in games like KoA or DD do not leave the player with a satisfying knowledge of actually being all that much greater with what they have achieved or acquired. NWN, on the other hand, uses an established D&D system, which uses a D20 system, which any player can quickly learn to understand how an extra 1 on a roll makes a difference to their PC stats. NWN uses an established and recognisable system.

COMBAT: Closely tied to the GAME SYSTEM is how combat is handled. The problem with many games (especially the modern ones like KoA), is the mechanics behind combat is as much to do with the ability to click a mouse as it is to do with actual character development. In both of the older games, Gothic and DD, I still felt the difference as to what I could achieve in combat compared to the likes of KoA. Thankfully, in NWN, the robust D&D system means a player will be able to tell when they may or may not be up for a task. In many modern games, it's sometimes hard to tell if a certain creature is tougher than you simply because there is no common ground by which to understand the situation, be it due to the game system used, or because of a unique creature design. Importantly, it will not be dictated by the speed at which they can click a button!

WORLD EXPLORATION: NWN comes with very adequate mapping systems, which allow for world maps, area maps and mini-maps. And while they once lacked the Fog of War feature that gave games like DD a greater feel of exploration, my own Fog of War hak now removes that problem for those that implement it, which I have done for my own module. And while some may consider the "area by area" approach of NWN to be a "weakness" of its gaming platform, I have come to realise that it is actually a strength! Why? Because it gives a player a greater feeling of control and achievement while exploring. Unlocking an area, or moving to another outdoor area gives a feeling of progression that seamless exploration cannot give. I believe this is an important point, as this affects the pace of progression for a game. (Although, poorly designed area progression can also feel just as "tedious" as wide open-ended landscapes.) The point being, I believe there is less risk of potential "tedium" in the design of a game that uses separate areas compared to large open areas, like those of some modern CRPGs. The vistas of the latter may look far better, but it takes a great deal more expertise to make those same area interesting compared to area designs, which modders of NWN use. Hats off to Bethesda who do manage to make interesting areas most of the time.

NWN MECHANICS: NWN still, in my opinion, offers the best in the way of GUI interaction for the player to play the game and work with their PC compared to any other CRPG I have played to date. There are certainly some aspects I have seen in other games that I have liked, such as the ability to get a description of an item while in the inventory without having to right-click first, but thanks to NWN2 ability to edit XML, such an inventory GUI has been implemented by myself for The Scroll. Couple this with one or two other GUI alterations, such as adding a Bestiary and a Main Menu for other gaming options, and we have at our disposal one of the most versatile GUI systems for any CRPG. Modders of CRPGs have a great tool in NWN, which is not only customisable, but is fundamentally based to work on the well-established 3E D&D rule set.

CRAFTING & CREATION: The idea of crafting actually has its roots in item creation from D&D. Therefore, it is no wonder that of all the systems that have come about over time, crafting is one of the more esoteric and potentially more complicated ones to develop. Even NWN has multiple systems, which on the face of it, are quite convoluted and difficult to employ. However, having made the system simpler, I believe I have placed this skill back into the hands of the player who may like to take the time now to develop one or two items that are worthwhile creating. The main thing is, I am hoping that items will be worth taking the time to gather the ingredients to make now, and that process will be easier in the first place too. However, I am also trying to avoid the many combinations and multiple items that can be collected that can make the process too confusing to use in the first place. i.e. I don't want to make a huge list of different items like KoA has when trying to craft or make something.

A HOPEFUL FUTURE

So what does all this mean? Well, basically, I believe modders for NWN already have a massive head start over any and all current CRPGs with the tools/system they have to create their mods with NWN2. In every aspect of general gameplay, they already have a stable and established gaming system that meets the requirements of a CRPG gamer. The only aspect that is missing is the story. So, if the builder has a reasonable skill set, and the time to develop, then using NWN2 they should be able to create a reasonable game that stands up against many (if not all) CRPGs currently written.

With the added benefits of cameras for conversations and the ability to script certain events and actions, imagination really is the limit for modders using NWN2. And yet, while I point out all this, I must add one reality check .... A good mod does require a good story, with good pace and overall balanced progress. That takes time and experience to get right ... but hey, even the experts get it wrong in my opinion, as there are few games I would say that are definitely what I would call "good". Even the winner of the three above would only score an "adequate" in my opinion. Yet even games like Baldur's Gate (which was game-breaking and used D&D rules) still does not get a high result from me compared to some of those I have experienced in later years. (Maybe at the time it was one of the best, but times have changed.)

The point being, however, I have not yet seen any gaming platform for modders come close to NWN2 with respect to a well-established ruleset, an ability to cater for a CO-OP multi-player environment, an ability to customise and still hold its own after all these years. For this reason, I do believe that there is the potential for NWN2 modders to do something special compared to any other mod market out there. And that has to be a good thing!

Module Reaches 94% (BETA IS 95%)

Even though I have taken a break for a couple of weeks, I decided that the module has progressed enough to be considered 94% done. Considering BETA testing takes place at 95%, then this really marks the final stages before asking for BETA testers. However, this last 1% for me before requesting testers runs the same risks of "delays" as the rest of the project has had.

So, what have I been trying to sort out lately? Well, here is a small list of things I have been looking at since I last blogged:

1) Finishing atmosphere/conversations/encounters for an area.
2) Improving Encounter scripts in general.
3) Fixed "names" of dropped unidentified items (to prevent showing).
4) Reworked/Improved Secret Door code.

And here is my list of outstanding:-

1) About 1.5 areas, with related content and code.
2) More updating the Bestiary for this module.
3) Add any LORE that may be required.
4) A few related journal entries still need finishing (still).
5) More combat balancing.

At the moment, I am spending time trying to get the lighting and sound right for areas ... I still have one or two areas that need looking at again. At some point, I also hope to add the bestiary and lore articles, which simply amounts to adding text and images. Then there are some journal entries that still require a bit more work, but as they relate to one or two quests that I am currently working with, then I cannot easily finish these until I have defined some variables.

Anyway, here are a couple of screenshots as I sign off for now ...

How do I get up there?

A quiet spot to rest ... Perhaps?

Saving The Day!

There's not much I can report on this week, as it's mostly been about scripting and conversations. I'd be giving too much away. I can mention that I managed to "fix" a potential problem related to AUTO-SAVING a game, and post a couple of screen shots to show what I am currently working on, so that's what I'll do ...

AUTO-SAVING

Background: There's a function available for single-player games (DoSinglePlayerAutoSave), where a builder can force an auto-save for the player if they think one may be important (or required) to prevent the player from suddenly finding themselves "dead" without having saved for a while.

The auto-save facility also has a related "automatic" save every few minutes, which is often used in multi-player environments. The problem is, however, many players don't like the timed auto-save taking place when they are in the middle of a game and edit the nwn2player.ini to stop this "feature" of the game from working. However, when this feature is disabled within the ini file, it stops the single-player function mentioned above from working as well, as I found out from my own experience.

This caused me a potential problem because I needed to make sure a game is saved at the start due to some database coding. In The Scroll, if a player starts the module and leaves again without saving first, then they cannot start the game afresh with the same PC. i.e. They can only return to the game with the same PC from a saved position. Hence, I needed to make sure there was an AUTO-SAVE at the start of the game. And while a simple message may have been sufficient (and is still the way I do it in a multi-player game in this case), I wanted to ensure the game was saved in a single-player environment.

The bottom line is, I was able to work around a copy of the existing save game GUI and create my own AUTO-SAVE facility that bypasses the ini check ... and even allows me to NAME the saved game file. So now, when the player exits the GUI warning about the game needing to be saved, the game does an AUTO-SAVE in a single-player game using the name I specify. Players who usually have the AUTO-SAVE feature disabled need not worry, as this is currently the only place I use the facility. However, it is good to know that I have a facility to do an AUTO-SAVE if I need to now ... and one that can be used in single or multi player environment and can have the save file named.

THE SCREENSHOTS

Where the player saves the game's day play, the heroes simply save the day ... usually. And while nothing too special, I thought these two screenshots might be interesting to some players ... the first shows the RWS tielset in action and the second a personalised SEF in play. NB: The SEF has been edited to not give any major spoilers.

How Do We Get Over There?

Unlocking A Projection!

 

BONUS VIDEO - CAMPAIGN INTRO!

Checking The Logic

It's been a while since my last post, but that's because I have wanted to use the time and energy I have to keep this project moving forward. Health issues have hampered me as usual, but I am still managing to make progress ... slowly, but surely.

I have been continuing to work on a dungeon (a crypt), which the heroes have to explore. This dungeon, however, supports a theme I have been working on and involves quite a bit of thinking ahead on my part, to ensure the logical flow works for the player irrespective of the path they take. Part of that logic check involves deciding if the player already controls PCs that can or cannot perform certain tasks according to their abilities. (I know I am being vague, but I am trying to not give spoilers.) Then, subject to that, I am designing the dungeon to work according to events that have already occurred in the past ... or may be happening still. While sorting through that logic, I am writing scripts to ensure certain items become available at the correct time, and trying to make sure everything balances in terms of combat and skill checks.

It occurred to me as I was working through the process that this is probably one of the most time-consuming tasks I have to do ... plan and check the logic of events and tasks that can occur for a player. Most of this takes place in pencil and paper as I make notes about what I intend to do. Then, the writing of the script is the next stage, before finally adding the objects to the module to test.

QUESTION: How do the rest of you builders manage your dungeons?

Do you plan events as you go .... (or are your events more straightforward) ... or do you also find there are a number of events you have to consider that may affect the overall running of the dungeon? I recognise that most builders will have a selection of dungeons where some are more straightforward than others. However, it is the planning of the more complex dungeons I would be interested to hear how you plan.

This door does not open in the normal manner!

I have also had to work around a couple of glitches I found in a tileset (RWS Dark Ruins), which ended up requiring more time. However, the end result has ended up in a neat idea that I hope will keep the players on their toes!

Hopefully, this dungeon won't take much longer to get to a working stage, and then I will switch to finishing another I was working on. My campaign design requires a number of placeholders between dungeons, and I like to work on each placeholder as I do the internal testing. This means I do not necessarily complete one area before another, but complete areas as the story requirements develop.

Seriously, This Is My Laughing Face!

There's not too much I can say this week, as it has mostly been about writing conversations. As every module builder will tell you, there isn't a lot you can talk about, not without giving anything away anyway. During such times in the past, I have posted about the difficulties I have with writing them due to trying to cater for a MP environment, etc.

This time around in my writings, I learned that not all creatures have all the various "conversation animations" available to them. (E.g. It's not  possible to make a goblin laugh.) Therefore, including such an animation in a conversation to make the creature appear more "alive" is not possible. Instead, one is left with a deadpan faced creature and some descriptive text about what it is they are "doing" as well as "saying". While not a major problem, it was a bit of a disappointment to learn this was the case. On the bright side, it did explain why my earlier attempts to include animations in conversations with some creatures would often fail.

Anyway, I thought I would just post a few screenshots this week and invite people to ask questions about the campaign ... or anything really. Is there anything you want to discuss in this post or previous ones? So, without further banter, here are a few screen shots for the week ...

Storm Clouds Over New Edgeton Market

Using "People Finder" GUI To Show Merchants

Heading For The Tavern

AI AI .... Oh!

Old MacDonald may not have had many issues keeping his animals in check, but the beast known as the AI in NWN can certainly be a tricky issue to tame. In the last week or so, I have been looking at the AI (Artificial Intelligence) when it comes to NPCs using spells. While I was running a combat test, I noted that the spell casters would prefer to run into close melee combat rather than cast their spells. This was certainly not going to work for me, and so I decided to take a closer look and see if I could make my spell casters do what they should be doing best ... and cast their spells when entering combat.

There's Gonna Be A Fight!

Eventually, I managed to narrow down the problem to two areas of code, which with a little adjustment to my own code, managed to make the spell casters behave more intelligently, and cast their spells. The two adjustments included:-

1) Where possible, switch to using the function HenchDetermineCombatRound rather than using the ActionAttack function. I thought the latter function would have triggered the former, but this is not the case. (Obvious in hindsight.) Using the former function throws the NPC into immediately using its combat AI code, whereas the latter makes the NPC close to attack before thinking about it.

2) Update my own AI script (used for many other combat situations, including things like healing and weapon choice) to make reference to the older NWN function DetermineCombatRound if the NPC is a spell caster. This older function appears to give better results than the newer one (mentioned in 1 above). Therefore, while I use the newer HenchDetermineCombatRound to initiate the AI for the NPC, I actually re-direct the AI to use the older DetermineCombatRound function via my own AI script.

The end result of making these two adjustments is that my spell casters definitely use their spells before entering combat.

Combat Begins! The spell casters cast from the back!

Creatures Summoned! Now for their next trick!

Other Testing

While testing, I also discovered some other issues that needed fixing. (Some due to later updates I had made that affected the very early stuff.):-

1) Fixed creatures dropping their "creature items" due to a new ID system I had implemented.
2) Fixed a container found on a creature that was using an OC GUI that does not work.
3) Fixed creature auras that were clashing with my NPC detection aura system.
4) Fixed/Updated a Scroll GUI trigger system to use newer functions to allow more script calls.

There were a handful of other minor issues that I fixed along the way and which I encountered as I did another quick play test. In the coming weeks, I hope to carry on finishing conversations and finishing area scripts.

Back On Track Again

Time for another update ... and the first for this year. Probably like most NWN builders, I have a paper notebook in which I keep a list of all those bits and pieces I need to do. Items get added or removed from that list as I go about designing the module, make changes or mark things as completed. My goal for this year is to NOT add anything else to that list at all ... and to concentrate on finishing those final stages to get this module ready for BETA, and perhaps, even its release.

There always seems to be new obstacles at times trying to hamper progress, but while they may slow me down, I am still committed to finishing this module. At the risk of repeating myself, all the core code is now in place and it is just a matter of me adding content. However, I now have to add content with respect to my own systems as well. E.g. Monsters that may appear in the bestiary and spells need code adding to work with the various systems I have relating to spell usage.

As a whole, I only have four quests lines to finish and then I am done! Occasionally, I do still find I come across small problems like the flute animation issue I have posted about recently, but overall, I am still making progress. So, just to say, it's a new year and I am back on track again!

Not Much Further Now!

Rune Puzzles (Extra)

Regular readers of my blog will know that I like puzzles in my games, and will have already read about this rune puzzle. However, as it has been quite some time since I last posted about them, I thought I would make another post for the end of the year, as I begin to finish off this section of the module.

Scenario Specific

This area was always going to be one of the last parts I worked on for the module, as it involves quite a bit of custom code based around the theme of using runes. Note, some rune puzzles are not scenario specific and will appear throughout the campaign. However, this particular use of them is very much geared to this dungeon. Obviously, I won't go into detail, but it will be clear that the heroes will have to find runes throughout the dungeon to be able to continue their quest.

The hero finds a sturdy bag containing three runes!

Rune bag information displayed in the new inventory!

When the heroes discover an object where they can use the runes they have found, then an interface automatically updates according to the runes they have already acquired. Note, the runes they have found may be useable in different ways, and so tactical use of them with the different objects may be required.

Not enough runes carried to work with this object!

I have made a couple of updates since my last post about this rune puzzle. One particular difference is that, as in many other areas of in-game puzzles, I have added a button that gives the player access to more detailed instructions if need be.

Player has access to detailed instructions for puzzle.

Anyway, it's that time of year when I seem to slow down even more than usual (lack of sun probably), and so will be taking things a little easier for a few weeks (as if I did not take things easy enough already). However, as I have explained before, as a Christian, I do not celebrate the upcoming season festivals, which have their background in pagan rituals and are a man-made addition to what God has instructed us regarding worshipping Him, and so will, hopefully, not be restricted to updates on the module on account of this.

Therefore, unless I have a sudden burst of creative energy leading me to something to report, I will probably not blog again until the new year. I will of course, however, answer any posts that arise between now and then. In that time, and for now:

I wish you all a Happy New Year!

Althéa Manual Goes BETA!

Don't go getting too excited ... I did say the "MANUAL". However, this is a reasonably good sign that I am relatively confident that the campaign systems to be released with the first module are now in place and stable.

DOWNLOAD THE BETA MANUAL HERE

I decided to release the manual now (as a BETA for anyone interested) so that players can make comments about anything they read, be it questions on any systems, comments to make things clearer, or simply to be able to provide initial feedback on any presentation. Also, for those who have followed my blog, to let me know if they feel I should have covered anything else in the manual that they recall reading from the blog.

The Althéa Manual Goes BETA!

There may be some areas I still need to cover in the manual, but will leave that to any BETA testers of the module itself to comment on. After all, the testers will be in the best position to comment after having access to both.

As far as the module itself is concerned, I have just started my first play through to polish any of the first areas and general code at the start. All is going relatively smoothly at the moment, but I know there are some later areas that still need a degree of work to finish before a final test. However, if the first few areas go well, then I will most likely release this for BETA testing after updating the final areas that need doing without replaying the whole thing myself.

Things updated over the last few weeks:-

1) Added last of the area music.
2) Completed adding Load screens.
3) Removal of debug feedback that was not of the "toggle" type. (Also removed all test objects.)
4) Fixed AMMO quantities in stores. (Amount increased to 50 at a time to allow better economy.)
5) Added some LORE entries.
6) Improved some early conversations to flow more smoothly. (As I have improved.)

Some things that still need doing:-

1) About 3 areas, with related content and code.
2) Finish updating the Bestiary for this module.
3) Finish adding any LORE that may be required.
4) A few related journal entries still need finishing.
5) More combat balancing.

MODULE ETA: 2015 :)

Balance: The Final Blow!

Balancing a game! ... What an issue this can be! After all, one persons tactics may make a game easier to play than somebody else's. Different classes have pros and cons that could affect the game from the very start. Then there is simple chance of course ... one battle may go badly simply because of a run of poor dice rolls ... or be a cakewalk with an opposite run of the dice. The big question is, just how much should we consider scripting a game (for difficulty) where a player is relatively free to move their party wherever they like?

While it is true that in a DM controlled environment ensuring balance is easier to maintain than relying on scripts to control the difficulty levels for PCs, the big question remains just how much tweaking should ever be applied? I guess there are two schools of thought:-

1) FIXED: Do not alter difficulties at all and allow the PCs to get what's coming to them, or ...
2) SCALED: Alter the difficulty to allow for character levels and abilities.

Of course, every builder knows that a good combination of "fixed" versus "scaled" difficulties is the best solution to the problem, but, where do we (or should we) draw the line?

So, guess what I've been up to over the last couple of weeks? Basically, looking at difficulty levels for the PCs according to the different ways they could explore the module. I, of course, know the best path to take that will keep the difficulty levels about right, but I am also acutely aware that there are one or two steps they could make that would place them in a very difficult predicament. My current concern is, I am not sure if this is a good thing or a bad thing? After all, while I am all for a "challenge", I am also aware that being "stuck" can be a quick way to frustrate a player (from personal experience).

So, my questions today, to keep in line with my current module updates is, what do you think?

1) Have you experienced a game (or module) that was simply too hard? (Example?)
2) Should a builder always (or never) scale difficulties?
3) What is your preferred style of play? (Relatively linear/guided path or completely open?)

From my own observations, a game that is more linear tends not to encounter these balancing issues, as the player should (in theory) be developing their character at the same rate as the difficulties increase. The "problem" only really comes to light when designing a more open world when the player ventures into a more dangerous region than another. However, what now takes precedence?

4) Should the game adjust to fit the player or should the player get the hint and back off?
5) However, what happens if the player cannot back off for whatever reason? Is the "game reload" an acceptable solution, or should the builder have considered another option for the player?

Too late to turn back ....

I think I took a wrong turning!

What's The Latest?

I often find myself going "two steps forward, and then one step backwards", but thankfully the net result is always a definite forward movement. This time it was to do with my own walk waypoint system. A long while ago, I discovered that the official system was not reliable enough: Creatures would often stall or simply jump a step when supposedly following waypoints. So, I decided I needed to write my own, and thankfully, succeeded. However, another recent update to the rest system in my campaign highlighted a fault with one of the calculations for the waypoint system and I had to spend some time fixing that this week. (At least tracking down the fault is what took the time rather than adding the 0.1 float value to the code that needed it.)

Fixing issues was not the only thing I did this week, however. I can add that I also finished a rather difficult conversation and improved my own encounter system by making better use of the ScriptHidden function.

I also played about fifteen minutes on one of the new areas, testing the creature AI and my combat system that can be switched between real-time and an auto-pause system at the push of a button. It was great fun having the game auto-pause on enemy sighted, switch weapons while paused and target a new enemy prior to un-pausing. After six seconds the game auto-paused again (as my option had requested) and allowed me to re-examine the combat situation to see what I would do next. The settings I was using reminded me of a style something akin to Dragon Age and/or Baldur's Gate. Not surprisingly I suppose, as these two games (along with NWN) have influenced my own preferences in style of combat play. Of course, the campaign also caters for those that prefer to stick to an all real-time experience, which is the default play style anyway.

I have also started to place more of the unusual treasures around the module now. I don't mean what I call the "main treasures", but what are more like "unusual/interest items" treasures. They generally aim to improve either character or equipment. Here is an example of a page of a book of one such unusual find that the PCs may be blessed enough to stumble across.


Books will contain information that will help the PCs in some way.

For players who may be interested in playing this campaign, please feel free to give feedback about any of the game systems posted here or on my blog (see signature)... or any other comments you want to raise ... or have any questions about the campaign.