Choose Your Language

Tuesday, 30 June 2015

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.

Monday, 15 June 2015

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.

Tuesday, 26 May 2015

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?






Monday, 11 May 2015

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?

Wednesday, 29 April 2015

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!

Saturday, 18 April 2015

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?


Wednesday, 25 March 2015

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!

Monday, 9 March 2015

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.

Friday, 13 February 2015

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


Friday, 30 January 2015

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.

Monday, 19 January 2015

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!

Tuesday, 16 December 2014

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!

Monday, 8 December 2014

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 :)

Thursday, 20 November 2014

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!


Thursday, 6 November 2014

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.

Monday, 27 October 2014

Player Expectations

As the years have passed and I have continued to add material to my own campaign, one cannot help but notice the incredible strides in mainstream computer games in both the visual and sound, as well as gameplay and content. Don't misunderstand me, I always knew things could only "get better" as far as the games were concerned, simply because of the improvements made in computer hardware. However, credit must also be given to those designers like Bioware and Bethesda (to name just two of the many fine companies out there who make comparable games to the likes of my own goals), who have really done wonders with the software to take advantage of said hardware to make some truly great games.

My point being, when I first started this campaign, I believe a player's expectations from a fan-based module were not too far removed from what was delivered. However, is it possible that as the time has passed, player's expectations of what to expect from such a module have also grown? Now, I am aware that good gaming does not boil down to just visuals and sound. However, in all fairness, the games I am thinking about also contain reasonable/good content too. Can we (as builders) even be able to offer the players a reasonable gaming experience compared to what can be acquired nowadays? I am not saying we cannot do so, but what would make a player pick up a custom module and spend time playing it compared to picking up Skyrim, Dragon Age 3, or one of the many free MMO games and play that instead?

Now, I know there will be some players who have more time and can, perhaps, spend their time playing both types of game, but my question is, why would/do they? What is the attraction to playing a home-made module, which, even if it has some reasonable gameplay, is not going to be able to compare to a "retail" product which has had a professional design team and many more hours put behind it? I know I am probably asking the golden question that everybody would like to know the answer to .... i.e. What makes a good game? However, I ask it anyway, as such feedback is always good for the builder, and helps encourage them along the way.

So, why do you download and play a NWN/NWN2 module compared to any other game that is available? Is it because of the rules used? Multi-player functionality? You have played all the other games already and it was a last resort?

And when you have downloaded such a module, how much time do you give it? At what point do you give up on a game ... or don't you? Do you keep going regardless?




Thursday, 16 October 2014

Sorry For The Delay

There is no beating around the bush ... I am sorry that this is taking me so long to do, and I apologise for the delay. For while I knew it would take me some time to do, I still had no idea that I would not have finished by now, a good seven years later!

Such A Long Time!
Indeed, had I known the campaign was going to take me this long, my design goals would have been different from the start. And to think, this campaign was originally going to be released as three modules in one go!

There are also the normal excuses, like real life issues, especially health related, but even so, I had hoped to have had the first module released at least a year ago, with the two additional modules a year or two each after that.

On a positive note, I have almost finished all the areas for the first module now, including the new ones I had to design for the two additional side quests I had in mind to add recently. One of the side quests was more involved with the conversations than I first anticipated, which added a least a couple of months more work than I first planned. However, that is almost done now. The second side quest should be more straight forward, and now that I have the areas designed for it, it should be quicker to complete. However, considering I thought they would only take a couple of weeks to add, they ended up taking far more time, even months! Once they are done, I return to finishing off the main quest(s) and will then be ready for BETA testing. (Note, however, not all the time over the last six months has been work on these two side quests.)

If you have any comments or requests, please add them to the comments. As I have said many times before, having comments does help me to stay focussed at times.

Wednesday, 24 September 2014

Althea Campaign Interface

Another quick update just to report that things are still progressing along nicely. Alongside creating new material, I have been improving existing code and making everything work together more smoothly where possible. I took a pleasing step forward this week, by introducing the "extra buttons" that run inside the main hotbar specific to the Althéa Campaign, including ones for the Main Menu and combat procedures in particular, which I hope will make combat within the campaign both more controlled and enjoyable.

New hotbar buttons and Main Menu options!
The New Interface

To explain briefly, there will be (as it currently stands) six new buttons within the main hotbar that sit alongside (to the right of) the familiar camera angle buttons:

1) Main Menu Button: Basically does what is says, and brings up the Main Menu for the player, where they will have further in-game options. This menu is not available during combat.

2) Party Maps Button: When the player(s) acquire maps throughout the campaign, this button will open the Map Screen when pressed to allow viewing. In a MP game, the map opens for all players so that the map can be viewed and discussed by all players at the same time.

3) Turn Based Pause Button: One of the first combat buttons that player(s) can use. This is a global toggle setting, so it sets for all players in a MP game. When clicked, the game will pause every six seconds, which the player must un-pause. This auto-sets if "Pause on Attacked" is selected from the Main Menu, allowing a hybrid turn-based system to begin.

4) Toggle Player Group AI: The second combat button, which can also be used to simply immediately stop all companions in their tracks if need be, is the Group AI toggle. Note, a "group" is all PCs that a player controls. In an Althéa MP game, each player controls their own group of PCs, as opposed to a normal OC game where only the party leader player controls the added PCs. This AI button does *not* toggle AI for those creatures in the party that are not "created" by the player or added as "companions". e.g. Animal Companions and Familiars cannot have their AI turned off.

5) Observe Condition (HP Bar): If the player acquires the ability and wish to use this facility, then HP bars for enemy creatures can be toggled on or off via this button. Note, it is a global setting, so all players would have this feature turned on or off in a MP game.

6) Statistics Panel: Lastly, their is a button that brings up a game statistics panel giving some information about the PCs in the party. e.g. Number of deaths (and type of revivals), best creature killed and number, etc.

Main Menu Updates

Lastly, just to mention a couple of new additions to the Main Menu:-

A) If a PC suffers a penalty to hit and damage due to hunger, they will now find it on the Main Menu.
B) A new toggle button to pause if a trap is triggered has been added.

Actually, I have made an improvement to Trap Detection as a whole. Now, by default (with or without the above option being switched), a PC will stop everybody in their tracks if a trap is detected. This is *not* using the pause facility, but simply a command to stop, which stops PCs from doing whatever they are doing. The pause option (as mentioned above) is a toggle that sets the pause if the trap is "triggered", when "stopping" is too late. At this point, the player can decide whether to quickly intercept the moment of pause for their PCs or not. (Hitting the AI toggle should do the job.)

I am hoping to move forward on finishing some more quest writing in the coming weeks, subject to some real life events that are occurring. I will try to keep you all updated all the same.

Tuesday, 16 September 2014

The Vigour Sytem (Revisited)

It has been over six years since I last spoke about the Vigour system in any detail, but my latest updates to the campaign have been dealing with polishing this system using the scripting knowledge I now have compared to back then. One update, the effects of vigour are now added to PCs as icons next to the portrait. That is one update that can be "seen", but a lot more has been updated "under the hood". Some news will be similar to before, but there are definitely a few changes for the better I believe. These changes had to be made to make the system fit better with long distance travel and make more sense in general.

THE VIGOUR CATEGORIES

First, I decided to re-align the descriptions and effects of my vigour categories so that the system was more straightforward in application. Here is the new outline of the vigour categories:-
New categories divide between REST and FOOD requirements
As you see from the chart above, the main difference between the old version and this new version is that the 100% is divided equally between REST requirement penalties (> 50%) and FOOD requirement penalties (0 - 50%). The key thing to remember is that eating FOOD will improve any vigour up to 50% and the PC would need to REST to improve the vigour to 100% to remove all penalties.

The campaign also dictate the following rules with respect to REST ....

1) A PC cannot REST without access to food, but they can WAIT.
2) A PC cannot REST until 8 hours has passed from their last rest (unless at an inn).

However, note that the above vigour penalties do NOT begin until it is time to REST after 8 game hours has passed anyway. Therefore, vigour penalties will only ever apply if the PC cannot rest (due to their environment) and/or does not have access to food.

Note, also that allowing time to pass using the WAIT option during a rest, will also impact on a PC's vigour depending upon the number of game hours waited, according to the table above. Therefore, it becomes important for PCs to have access to food if they WAIT for any periods of time.

Five new vigour state (I-V) icons that can appear on a PC
HUNGER

Hunger now attributes to the worst penalties if not maintained. As a guide, an iron ration improves vigour by 25% up to a maximum of 50% vigour score. Other sources of food improve the vigour score by more or less than 25% upon consumption, but always only to a maximum of 50%. Therefore, the game mechanics stop a PC from eating an iron ration (if the player tries) if their PC's vigour score is already 50% or higher. On the other hand, some other food items may be used and wasted if used inappropriately. If the PCs find the Arcaene Magik scroll, Create Food and Water, (and can use it) then suffering from hunger would not be a problem for them again.

If a PC becomes DEPLETED and they carry an iron ration within the player's group, then they will automatically eat it. This check to eat food is made earlier if the PC uses the WAIT command: The system checks if the PC has become FAMISHED during the WAIT time and makes the PC eat a ration if available to stop them from dropping below 20%. The player can obviously continue to use food items to bring their PCs up to 50% if available and need be.

LONG DISTANCE TRAVEL

Travelling on either an overland map or using a map to travel (both available from module 2 onwards) work slightly different with respect to vigour depletion and using iron rations:-

In the former (overland map travel), vigour drops rapidly as the player moves their party across the map, and the system automatically feeds the party with available rations when the leader drops to 65%, boosting them back to 90% unless the rations had to be shared, in which case they get only a proportion of the normal 25% boost. If the food runs out, then the vigour continues to drop to 0%, whereupon it continues to accumulate additional HUNGER damage in the way of penalties to attack and damage every hour, up to a maximum penalty of -5. Any penalties due to lack of vigour are applied to the party members when they leave the overland map and return to a "normal" area.

In the latter (clicking on a map to travel to a destination), the result will tell you if the party has enough provisions to reach the selected destination. Or, if the party could make the destination by sharing the provisions they have. If the party have sufficient provisions, then they make the journey without any impact to their vigour and simply pay the amount of provisions required. If the party have to share provisions, then they will arrive at their destination with vigour penalties for sharing. The maximum amount of sharing can leave the PCs with no less than 10-20% vigour (and associated penalties), subject to how much they had before starting their journey.

The vigour (rest and hunger) rules available in game!