Episode 82: March Big Update!

If you have been following of late, you will have seen that The Scroll campaign has currently been withdrawn from downloading. Basically, I had to make some big decisions about where the campaign was heading with module two on the horizon, and how I was going to manage multiple modules moving forward. I concluded that I needed to make some big changes to some of the core files for the campaign and so rather than prolong the agony, I took the steps required. Hopefully, I will have the latest version of the campaign ready to download by the end of the month. It's still only the first module at this stage, but even that will come with a grand facelift with the changes made. Read on to hear about the big changes I have made ...

The Enhanced Is Dead! Long Live The New!

To mark these big changes, I made the decision to end the "Enhanced" version series of the campaign, and replace it with a new straightforward version system. (The enhancements will remain, of course, it's just the version tag that will be going.) Importantly, the new version system is now no longer limited to 100 iterations before having to move up its first digit. Now, it allows thousands of increments, allowing me to keep the primary digit to relate to the current module release. Therefore, I will start at v1.1, where the first digit before the period represents the modules currently available and supported, and the digit after the period is the campaign version release. When module two is released, for example, it may go to v2.162, if we are on the 162nd version of campaign updates by then.

This has also allowed me to start afresh with "backward compatibility" support, which the current version series had been covering games as far back as v1.50E (March 2022). A lot has changed in the last two years, alongside many fixes, and I believe the enhancements made are now in a far better place than when first released, and so I feel happy about starting the release version anew. This new series will only be guaranteed backward compatible with v1.41E and up to v2.60E, the last release number of the Enhanced edition. (Older versions will have varying results.) That said, this latest v1.1 does come with some module improvements too. They are minor and have less of an impact, but the cleanest experience would be starting afresh from v1.1.

Now, let me cover some of the major changes coming in v1.1, and how module two made an impact.

Even The Start Screens Have Been Updated!

DM Client Support Removed

When I first designed the campaign, I thought there would be a need for me (and others who played the campaign in a coop multiplayer style) to have to "do stuff" as the players made progress. The idea being that I could still play in the same fashion as we, as pen and paper players, had done in the past. However, the beauty of being able to script events meant that my role actually became less as a DM, whose only role was more about in-game fixing if need be. The monster AI was working well for our needs, and all I ended up doing was following the heroes around as an invisible side-kick. Put simply, the module design had no need for a DM. 

In fact, the campaign design has changed so much over the years since its first incarnation, that certain events, such as area transitions, are actually hampered by the presence of a DM. Trying to accommodate the presence of a DM, especially with the up and coming module two, that comes with more advanced events, became such a burden that I could not see any reason to continue to support the DM Client system. Instead, I decided to concentrate on making coop multiplayer a much more stable and protected way of playing. Once I pulled out the DM client code, I was able to improve the efficiency and stability of player clients joining the host's game. Furthermore, I added a number of "safety checks" to help players setup their game without running into connection issues due to joining timing errors.

Moving forward, I realised that I, (who once played as the DM), can now, instead, share their gaming experience by playing alongside them as a PC of the party too. I also recognised that it was easy enough to add a DM tool if I ever wanted to reacquire some of those gaming elements that the client once provided.

A final great benefit to this change was that it helped alleviate the multiplayer area transition times, which I appreciate, especially as module two comes with one or two slightly more involved areas than the first module. However, on the subject of loading times, it was the next update/fix that really helped here.

Database Handling Improved

I have had an "unknown" issue with the module sometimes crashing upon entering the second area after a module fresh start. This never happened on my computer, but always did on my wife's. I knew it had been related to the database somehow, but only recently did I figure out the problem. It seems that the game does not like to "destroy" a database and set one up shortly after, especially if using the same name. It turned out that somehow, this action upset the game, which then went on to cause the game to randomly crash on some computers. The solution was to, rather than destroy an existing database, to simply "reset" all the variables it contained by overwriting any existing. The end result amounts to the same as destroying and creating a new one, but the process does not cause the game to crash shortly afterwards. I was greatly relieved to have this issue (ever since first release) finally resolved.

UPDATE: The game WILL still crash shortly after the first time a new database is written. However, as the new database only happens at the start of the game, a player is encouraged to reload the auto-save made at the start of the game to prevent the risk of a crash. If the player is updating an existing database, then the game does not crash.

On the back of solving this issue, I looked closer at the way the database was handling data, and concluded that some of its operations were not required for multiplayer gaming, and so switched their operations off for such. It turned out this helped improve area transitions by a significant amount; around 3-8% for multiplayer gaming. The bottom line, when module two is finally out, it will be working from a fixed database system.

Fast Travel System Overhaul

I'm not sure how many people are aware of this system I implemented, but it's one that can be put to good use when it comes to moving around the World of Althéa. Whether your PC is encumbered or not, if you have a valid waypoint available (and you can set your own too), you can use the system to move rapidly to the waypoint you choose. No more slowly dragging your party back to a location to do something, as it's as simple as left-clicking on the map and selecting the way point to move to. It's the closest thing I can achieve to the likes of clicking on a map and have the party to move rapidly to that location.

There were some teething issues with the initial system, as sometimes the PC could be left in an unusually fast speed even after the fast travel had finished. However, I am hoping they have all been sorted now. If any others are discovered, they should be reasonably straightforward to fix now too.

However, one of the things I have wanted to address with it for some time now, was to incorporate the Fast Travel GUI into the area map GUI itself. The system prior this latest would open a second GUI that opened somewhere else on the screen, from which the player made their selection. However, this latest version now keeps the Map Pin selection incorporated into the Area Map GUI itself, making the whole system feel more natural and intuitive. Take a look at the image below. A player need only left click on the area map to bring out (or close) the list of waypoints, and then select a waypoint to move rapidly to it. The player can leave the pop-in panel open if they wish to (in case they change the current waypoint in mind), of left click on the area map again to close this pop-in to watch their PC icons move rapidly across the map to the waypoint in question. To cancel any rapid movement, the player simply closes the area map, either by clicking on the area map exit cross, or pressing escape. The rapid movement has been designed to auto-stop if required, such as a conversation starting, or combat encountered. Basically, play is unaffected apart from the speed at which the party moves to the selected location.

Area Map With Fast Travel Pop-In Open

Persistent Skill Bonus Fix

For some time now, as long as the Adventure Skills system has been in place, a bug has been lurking in plain sight, basically going unnoticed. Thankfully, its impact has been relatively "minor", albeit frustratingly unfair when required by the PC. The problem is associated with Skill Bonuses gained by items that sit in a PCs inventory, which fail to reinitiate their bonuses on a game reload if they had been stowed away in a container the PC carried, such as a Bounty Bag. As PCs had the potential to gain campaign feats that awarded such Skill Bonuses, which were then stowed in their Adventuring Skills Book, then it meant any such benefits would have disappeared on a reload, and likely gone unnoticed.

Addressing this particular bug has been one of the issues that has contributed to the longer delay of the campaign's next release.I wanted to make sure this bug was also made backward compatible, alongside the other final list of bug fixes for the Enhanced version releases. The upside to this latest fix, is that some good has come from it, in that I have improved the operation of party feats that can be acquired in the campaign, as well as fix the Skill Bonus container issue.

First and foremost, new campaign feats now alter skills in a permanent manner. They no longer rely on Adventure Skill pages. I could have still done it this way, but now wanted to reserve the Adventure Skills book to bonuses from items carried by the PC only. So, campaign feats with skill bonuses are handled via script rather than items, and are permanent alterations either way. The new fun changes come with the skill bonuses that are benefitted from items that sit in a PCs inventory. For now, the Adventure Skills Book keeps an overview of all the benefits gained from such items, and is the item that ensures these benefits are not lost between reloads. Importantly, these skill bonus items can now be stowed away in containers and their benefits will no longer be lost between reloads!

Now, whenever a PC acquires a skill bonus item that sits in their inventory to gain the benefit (as opposed to an item that can be equipped for such), the Adventure Skill Book tracks the benefit by adding it to its own list of beneficial skill properties, as well as keeping a page copy of the real benefitting item within its contents. So, if a player wanted to see what benefits they were gaining from items in their inventory, they need only check the Adventure Skills Book properties for a full list. If they wanted a breakdown of which items were providing these benefits, then they need only open the Adventure Skills Book and examine each page therein to learn where the benefit is coming from. This new approach actually gives the Adventure Skills Book a more active role for feedback in the game than previously. Take a look at the image below for a quick overview of the kind of thing I am talking about here.

• 1 - 3: These are the three real items collected by the PC that are giving them skill bonuses.
• 4: The Adventure Skills Book (ASB), the current description is up and showing all benefits.
• 5: The ASB contents. Each page can be clicked to see its own description instead of the ASB.
  

The New Adventure Skills Book Information

There's A Lot More!

The above differences are just some of the bigger ones that impact the campaign and module two moving forward. However, there are also a lot of other fixes and updates coming to address some niggly problems and gameplay from previous versions. From logical flow issues, combat activation (including auto-pause), creature issues, launder bench usage to name just a few. Take a look at the full list here.

TLK & UI Updated!

With all these updates, and being a NEW version, starting from v1.1, there will also come new TLK and UI folders that will need to replace any existing Althéa versions that you have. If starting afresh, you will also need to grab the latest module folder, which now also starts to be noted by release date rather than version number release. This is done to help prevent players downloading a newer module than campaign in error, which can lead to a broken game. There is also additional file checks in the new code to help prevent this, and a "silent" version number will be kept with any module upload to help maintain this. As far as the player is concerned though, the release date for the module folder should be the governing guideline for them now as to whether there is anything significant about its changes that affects them.

I recognise that this month's blog is a lot to take in, but I wanted to let you all know that I have been busy preparing the campaign for the second module, and this is the result. My wife is currently play-testing all these changes, and still helping to find any remaining bugs that can be fixed prior release, and as soon as she is done, I'll upload for all to benefit from.

Episode 73: Upping The Ante!

With a new module comes new challenges... It's a time to "up the ante", and to introduce new monsters and puzzles for the party of heroes to face and overcome. However, creating such new challenges for the player's band of heroes also translates into creating new obstacles for the builder to overcome. Let me explain ...

New Monsters!

It is said that there is actually "nothing new under the sun" (Ecclesiastes 1:9 KJV), which is something I happen to agree with. However, for each of us, there are certainly new things to experience, even if it has been around before in one format or another. I mean I believe it is safe to say that most of us know what a vampire is, and what to expect it to be like, but... It's true to say that not all vampires (and any creature for that matter) fall from the same mould. Yet, it is these small variations in the monster template that can make the encounter a bit more "exciting", or perhaps I should say "dangerous", upon encountering one such creature in a new campaign world.

This is because not every builder will include certain aspects of a creature's design in their specific version of the creature in question. Sometimes this is due to the limitations of the NWN game engine that we use, or more likely most of the time, due to lack of time to script in all those lovely AI updates we could employ for the various creatures. That said, when we have been able to add a slight nuance to a creature that may not have been experienced before, it can add another level of depth to the module being played in question. Therefore, with this in mind, I hope, on the odd occasion, to add just a little bit more to any new creatures encountered in module two. Let me be clear on this matter, it will only be the odd one or two, as some creature variants can be quite complex. One such creature to have undergone such treatment is in this week's screenshot (see below).

My normal approach when dealing with this sort of thing, is to gather as much information about the creature I have in mind to use as possible, and then create a version that supports as many of its known features as possible. This is where the "ante" builds up for me, as even adding just one unique property for a creature takes time. If a creature has two or three properties that differ from the original template provided, then it takes me longer to include them in the final build. The end result, however, is a more rounded adversary, which, I hope, will also "up the ante" for their encounter. Whether players will thank me for that, I'm not so sure. I guess time will tell.

New Puzzles!

I've reported on these before, but I would like to touch on them again. For The Althéa Campaign, puzzles range from simple mini-games to more complex situational puzzles. Those that have played my first module will be quite familiar with the mini-puzzles I refer to, and so hopefully, will feel quite a home with the new variants that come with Predestinated Days, my second module. These sorts of puzzles can occur multiple times through the adventure, and can normally be solved in various ways. That said, I am making a concerted effort with this second module to expand on the more elaborate situational puzzles.

Again, players of my first module will be familiar with the sort of thing I mean. However, when it comes to these "situational" puzzles, I have decided to try to "up the ante" in these too. By "situational" puzzle, I mean those that PCs can encounter in an area rather than on any one specific object. I consider them multi-object puzzles, which a player may need to take notes on, or, more importantly, consider a bigger picture when working with them. One such example from module one, was repairing the sewer units. Here, the player had to understand a process and consider the long term goal or what it was they were trying to achieve. It is this kind of "puzzle" or "task" I hope to take to a new level of interest or, from my perspective, presentation. It's currently an idea in progress, but I already have a couple of these task-like puzzles in place, and I think they play quite well ... I just hope players think the same.

More Challenging!

Basically, as to be expected for an experienced party, I guess, the next module is aiming to be more of a challenge for both the heroes and by default, the player too. That said, I aim to try to include the normal alternative ways of playing in place, to allow players a different approach if they struggle to progress, even if it means altering the game difficulty setting, or a frugal use of Life Essences at the right time.

Perhaps A Little Too Challenging, Alone?

Episode 58: Rotation Matching Puzzles

Time has flown past since my last report, and so I thought another quick update was due. Recently, I have found myself making use of the extremely powerful tool MDBConfig by rjshae. Basically, I have needed certain placeable objects slightly altered for my own needs, and this has been a really excellent tool to help me with the process. Read on to hear what I have done lately ...

Rotating Puzzles

As many of my regular readers will know, I enjoy interesting puzzles in my D&D games, and so I suppose it's obvious I wanted to include them in my own module. The first module comes with around half a dozen puzzles already and you may recall reading I have some new designs coming along in module two. However, I finally decided to also include some I had in mind that work by "moving objects". Think either the mirror puzzle in MotB or like those found in Skyrim.

In this case, I wanted to add puzzles where the player may discover a specific sequence, which can then be applied to a set of rotating objects to unlock a path to somewhere else. Thankfully, NWN2 already has some code related to this, but I adapted it (made clearer) to suit my own needs. I still need to add the code to check the sequence and return a result of some kind, but that should be the "easier" part for me. In my case, it was making the placeable objects I needed to be able to provide the clues and for the player to interact with in the first place that was the hardest. Check out this weeks screenshot from the toolset showing my latest puzzle object additions. I hope to make use of these in the second module moving forward.

Growing Conversations

This stage of module building is otherwise being taken up with writing the conversations ... again. One of the largest ones is growing close to 10,000 words! This conversation is not even finished! I would like to point out that this amount of words is not about a large text dump, but due to multiple paths through the conversation subject to player PC choices and situation ability rolls, or character trait. Furthermore, in this particular conversation, the text is also affected by the player's background, which continues from module one (if played), or of that chosen at the start of module two.

Multiple Paths

On the theme of multiple paths, I wanted to report that I have also been coding a new means the PCs can travel, which led to a potential logical flow issue where the player could approach the same quest from multiple angles. Don't get too excited, it's not full blown flying, nor animated swimming, (or anything like that), but is a new approach which will allow the player to choose a different travel path. The point is, however, is that this new means of potential travel involved quite a bit of planning on my part, and only now do I think I have covered all the angles.

For me, allowing the player to be able to approach a problem from more than one "literal" path (as well as a skill path) is what will tempt players to play the module more than once to see how it played via a different approach. i.e. Think pen and paper where players may discuss which way to approach the game before declaring their actions to the DM ... I hope to pull off a similar approach in this module too. It does require triple checking things, which all adds time, but I am pleased with the results to date.

That said, I don't want to put players off, by suggesting the module appeared too "open world". Far from it! Like module one, the second module follows a very clear cut main quest, but also leads the player to explore other areas they may also find interesting ... with some areas seemingly more involved with the main plot than others may first appear to offer.

Continued Testing

Finally, just a quick update to say module one is going through another final SP testing after I decided to make some more changes to the code. It was mostly to do with the container code again and improvements to the way items are collected. As soon as my wife has finished this play through, the latest version 1.50E of module 1 will be uploaded.

Elemental My Dear Friend!

Episode 55: The Snowball Effect

It seems to be a repeating theme of late: I have an idea for module two, which then snowballs into a campaign idea that I want to make available for module one too. This obviously refers to the game mechanics than any new plot device, but the point is, it ends up taking me longer than I first realise. Read on for the latest month's updates.

Efficiency & Polish

The problem is, whenever I see an issue with the existing code, no matter how small, I prefer to try to do something about it rather than let it ride. Sure, I could let it go and try to concentrate on new plot only, but when I then try to implement new material, it can then reveal the weaknesses of areas of the code that can do with an overhaul. This is what happened when I tried to play a MP game of my module. Some of the areas were taking too long to load and some conversations went awry. This forced me to redesign some of the areas and rework conversations, but the efficiency of area load times or logical flow were not the only things I felt obliged to address.

The Journal Tasks

The above issues aside, lately I have also found myself irritated by some journal notes spamming the window on an update. I knew exactly what was causing it: Sometimes my journal entries update information pertaining to items required for a specific task. For example, when collecting the prayer rods in module one, the journal title also updates with the number of rods collected for ease of reference. However, to do this, I have to remove the journal entry each time before I can update the TOKEN that refers to the new quantity information. The result is a journal update double spam to the chat window. So, I could either remove this additional information, or, as I decided to do, add a new TASK menu list. (See this weeks screen shot from the new module two below.)

Outside The Toothrot Tavern Showing The New (Empty) Task List

The idea is this new small Task List GUI window will now list all tasks that involve item collections for quick reference, rather than keep the information with the journal entry. The player has the option to open or close this Task List GUI as they like by a simple left click on a new small button. Furthermore, I added a simple right-click option to the same button for the player to change the background of the task list from this default shown in the image, to have a black smudge behind the text or just plain text list without any background. The button also highlights when a task list is available. It all works well, and now allows me to remove extra tokens used within the journal entries and avoid journal update spam messages. Sadly, it does not allow me to remove every TOKEN reference, and so some double entries will remain, but hopefully, they will be far fewer. I still have a little work left to finalize the Task List GUI, but hopefully will have that done by the next post. (i.e. Rewrite the code to update the GUI text rather than journal TOKENS.)

The Journal Updates

As I worked on the new task list GUI, I also looked at the way journal entries were delivered in general, looking at rewriting the system to improve its delivery. I have always liked the way games like The Witcher have presented them and so looked at designing a similar system. Shortly after this, Andgalf (at the Vault forums) posted a link to a similar idea I was working on, and this cemented my desire to polish this area of the campaign. The following image shows the new journal update style.

Opening Scene Showing New Journal Format

Other Game Mechanics

The journal was not the only area where I updated and polished the code this month. Other areas include:

(i) The inventory, where further improvements have been made to help alleviate a rare issue where a player may flick quickly between new items and confuse an item description. Now, clicking on an item will always update the description (unless paused). 

(ii) The action queue GUI has had its queue size increased, and for those that even want to stop their Main PC from retaliating when attacked, the small sword now acts as a button to toggle auto-retaliation on or off. WARNING: Unless you really want to, keep this on its default value to retaliate.

(iii) The Show Info GUI has undergone additional updates and polish, as well as the new Task List GUI button. It now also has another Broadcast command added: Attack Nearest. Like its two complementary broadcast buttons (Follow and Stand Ground), it removes the need for the player to do multiple clicks to reach the command buried in a right-click menu.

(iv) The follow AI logic has been improved, or corrected, depending upon your point of view. In particular, associates are now more correctly associated with their masters, but without compromising the overall Main PC orders where possible.

(v) Faster PC movement has been implemented from an area map (if the map can be opened in the first place). It has been improved to include keeping encumbered PCs up with the accelerated movement rates. Think open map and click on it to fast travel PCs to a point on the map. The only difference is that when the area map is clicked, a GUI with a list of waypoints is presented for the player to select the destination. NB: The player can add their own waypoints at their current location.

(vi) A door had to be fixed because it was missing a collision skeleton. My thanks to rjshae (at the Vault forums) for the fix! NB: This means the large hak had to be updated and will also require downloading again when I update the new v1.50E version of it.

(vii) Removed the ugly "chat" option from the menu presented when right-clicking in an area. Added new options for individual and group options for "Rally" (jumps controlled PCs to your side) and "AI" (to toggle AI on or off), alongside the existing portrait double right-click or brain icon options.

Showing New Right-Click Menus

The Final Snowball

The end result of all these updates and changes is that they have an impact on the way "libraries" of code are structured for the campaign. Functions that once worked in one library had to be move to another and recompiled to prevent any sort of conflicts from occurring. One library ended up being removed completely and amalgamated with another! This level of knock on effect means, as I have already stated, that previous module versions will NOT be compatible with the next release (v1.50E). However, players of the next version (onwards) will benefit from all these gaming improvements. Once MP and SP testing of these changes is complete, the new files will be uploaded for download. CAVEAT: You will be able to load a FINAL SAVE from any previous game you may have played. However, make sure the save is located in New Edgeton from where you can continue your adventure where you have the option to continue to module two.

Module Two

All these updates and changes are, of course, in anticipation of module two adventures that I am working on. The new adventures require specific conditions, which started the whole mishmash of changes ready for the player feedback. The end result, however, is that the campaign (all modules) once again all benefit (and are more polished) for it.

As for module two plot, it continues to have conversations written and journal entries updated, but of those, I cannot speak ..... ;)

Episode 53: Streamlining Gameplay

I have been slowly picking up the the pace again for module two as I rewrite some old scripts and conversations that were originally found in module one. I admit that this is not completely new material, in that the concepts are from the first module, but these are, however, new renditions of aspects of play that I hope will work better for players moving forward.For more information on what I am talking about, and other news, read on ...

The Sepia Images

I mentioned a few months back that I am starting to introduce the "sepia" image artwork into my modules as a DM information point, or, as I have now, a gaming aspect. Two such gameplay aspects that have now received this treatment (ignoring the informative area load screens), are the "Repair Bench" and the "Bookcase". Previously, players had to interact through some long-winded conversations and make some potentially confusing choices. Now, with the new artwork to support the actions taking place, I hope the player will be able to more easily accomplish what they are trying to do.

A) The Repair Bench

In the Althéa Campaign, some weapons are called "dead" weapons (as opposed to "living" ones), and can degrade over time. However, a PC with the correct skills can repair their weapons at one of these benches either for themselves or other party members. The beauty of the new interface is that managing this task is made much simpler. The moment a valid weapon is placed on the bench, the player is presented the new interface and options are simple. A repaired weapon in a matter of only a few clicks and a little cost in gold.

B) The Bookcase

Another gaming aspect to see a big improvement with ease of play is the bookcase. In the Althéa Campaign, a bookcase can often hide a valuable piece of written text for those who know what to look for. In the previous method to play this, a player had to switch between their PCs trying to work out which had the best chance of finding the text. Now, the player simply clicks through the shorter conversation lines and allows the game to put forward the PC most likely to find the treasure.

The bottom line is, these two conversations have been replaced with the new sepia image types, an immediate indication to the player on what to expect in play. Take a look at the two images I am going to use for these two gaming aspects below. Hopefully, as I add more gaming aspects, I will continue to apply this approach to any other gaming aspects where this will work. Furthermore, these new images and aspects of gameplay will be made backward focussed with v1.50E of module one too!

The Repair Bench Sepia Image Upon Usage

The Bookcase Sepia Image Upon Usage

Area Redesigns

As in previous weeks, I have continued to spend some time redesigning areas to work better with multi-player gaming. With my latest understanding of area load times, I have been able to reduce many of the loading times to around 10-20 seconds for module one, with only around 3-4 ranging up to a minute. Module two is probably the hardest for me to streamline, as it has some larger, more involved areas that cannot be broken down without losing the atmosphere and strengths their current designs use. However, even these I have reduced (when applying the latest knowledge), and I am hoping that the largest will not be any more than 60 seconds, much like the largest areas in module one. Furthermore, these areas are designed in such a way that when you are within them, there is a lot to do anyway. A reminder: these load times only affect MP games.

On the back of streamlining these load times, I also added a load screen timer to keep the players informed on the time remaining until loaded. It sits just below the hint comment and keeps the players updated with every second remaining, helping to alleviate the "what's happening" feeling. Check out the screenshot below .... This is from one of the largest load time areas and the seconds colour changes as it gets closer to finishing.

The New Style Load screen v1.50E With MP Area Load Timer

Module One v1.50E News

Multi-player testing has helped me find a number of minor issues with some areas of the code. They are mostly (if not all) "minor", but are a significant number to make a difference. And while quite a few are MP related only, some also address SP issues, such as a trigger not clearing down if a player approaches an area from a certain direction. It keeps forcing a conversation, which while not game-breaking is frustrating. Also, I have spent a lot of time reworking the conversations, including adding lip-flappers and animations. I had to rework them for the SP/MP shift anyway, and while I was at it, I fixed a number of typos and some logical flow. All this is being tested before the next release. As another example of a minor fix, I noticed an item in inventory would not be "compared" with a shop item if it had not yet been looked at itself. It was an extremely rare event, but did happen to me as I had equipped a sling and was now trying to compare at a store. Now, a warning comes in to say click on the shop item again and it updates. As far as any release date for this, it all depends upon how well the MP testing proceeds .. and then some more SP testing. Hopefully, I will have some more information in my next blog.

Module Two Specific

As far as module two specifically, I have continued to work on some large areas (on the back of the area redesigns), where some of the later quests take place. My next step is to redress all the module two conversations that require the SP/MP fix. I had hoped to have this done by now, but some of these conversations are very large (due to the number of quest variations) and I need to be at my most focussed when doing them. Hopefully, now I have experienced doing them for module one (which as only two left to do - and need doing prior v1.50E release), I will be more confident to manage the larger conversations of module two. I have also seen a couple of new puzzle designs that I like the look of, and am toying with including. However, they will involve XML coding, and I have to be in the right frame of mind for that too!

Episode 51: Fast Area Map Travel

This is probably a silly question being asked here, but have you ever played the likes of Baldur's Gate (or more recently, Pillars of Eternity) and noticed the "map travel" facility that these games use? I am speaking about the way you can click on a location on a map and the heroes travel to that point. I bring it up now, as a player of my first module recently requested if I could include something like it in my next module. Thankfully, after some playing around, I believe I have achieved something that works just as well, and may even have an added benefit! I am even hoping to have it for module one, from v1.50E onwards! Read on for more info ... (Video demo further down page.)

Waypoints Travel

I took the premise that the main reason players liked to be able to click on a map directly to travel, was normally after they had explored it more slowly the first time it was encountered. This meant that by the time a player had explored an area, there were advantages to be able to click on the map to effectively travel faster to a known location without having to direct the movement by piecemeal environment clicks.

Therefore, with this in mind, I recognised that the only other hurdle to consider (for me at any rate) was to ensure no further gaming aspects could be broken by any system I devised. i.e. A system that simply jumped PCs across areas should be avoided, as such jumping could also jump over a builder's vital event trigger! NB: I do use such "jump" systems when I know they can be employed safely, and do so in a large outdoor area in my first module. However, the system I wanted to add was one that could help alleviate the constant mouse-click update within the gaming environment that would not compromise the game in any other way.

The answer was to become more reliant on waypoints; the small markers builders use to annotate an area map to give locations to the player. With such markers in place, and as long as a recognised format was employed, I could then setup a means to allow players to select the waypoints to which they could speed travel for their PCs to run towards.

Waypoint Format Matters

For the design I had in mind, the way I was to setup existing waypoints now mattered more than before. The game engine relies on many waypoints for various reasons, and now I wanted to add some of my own design into the mix. I also took the opportunity to allow different types (colour to represent transitions for example) to list similar groups together. So, as it turned out, general waypoints (for buildings) were given a green background, transitions a blue, and players own waypoints, a red background.

To clarify, yes you read that correctly. For those that may not yet be familiar with my area map system, players can annotate the area maps themselves. If they choose to do so, then their map pins will also show on the area map with a name label of their choosing.

Fail-safe Travelling

Pathfinding has never been great in the NWN games, and so I have taken steps to help alleviate any PCs getting stuck during their travels. However, this area of coding may change (improve) as time goes by. For now, however, I can report that testing to date has shown all destinations were reached, even in quite crowded locations. I have not yet tested all areas and conditions though. As a further aid, I have also effectively "doubled" the PCs default speed while travelling this way, so that areas are crossed that more quickly when using the system.

The system is also designed to break out of fast travelling should the party encounter a hostile or start a conversation. It can also manually be stopped by switching PCs while moving or simply closing the map (or related waypoint list). The system also stops if the PC encounters a door or gate that requires opening. As a small consequence of using the faster travel system, however, is that searches of nearby secrets and hidden objects will be ignored, as if the PCs were simply making all haste to return to a destination, without any concern for searching.

The Scroll Area Map Fast Travel System

UPDATED: Map Pin Fast Travel System 2025

 

Module Two Other News

Although slightly distracted by adding the fast way point system (which benefits all modules from v1.50E onwards), I have still been able to do some work in module two. It mostly involves new conversations, but recently involved a new creature too. (The creature is already available at the Vault, but it is "new" as far as an inclusion within my own campaign.) However, it was while working on this new creature that I discovered a few more minor issues with module one that also demanded my attention. 

My wife is currently testing some final alterations in her latest play through, but when the time comes, the next upload of module one (v1.50E) will have a large number of changes that require me to point out that earlier versions are no longer directly compatible. By that, I mean earlier versions will still play if updated using the latest campaign files, but are not fully supported, meaning latest updates such as the area map travel system will not work unless the module being played is also v1.50E or above. (NB: Replacing a module folder mid-game is NOT recommended. Better to restart the module completely.)

Another aspect that is not fully "compatible" is the new journal "By Group" option, which was another new design concept originally aimed at module two, but will be made backward compatible for module one v1.50E onwards. This new journal sort option basically now sorts journal entries by colour groups: Main Quests (green); sandy brown (essential side quests); pale green (non-essential side quests); blue (missions of mercy quests), and orange (gaming information). Furthermore, the old "Recommended" option has now been replaced with a new "By Order" option. The distinction being that the order is still a recommendation, but with more of a priority weighting. It's subtle.

I cannot stress how much I am looking forward to bringing you Predestinated Days! I have so many new different aspects of gameplay, that I am beginning to recognise the scale of this project. The new alterations to module one are just some of those that leak through.

As a final note, v1.50E also addresses some minor points that needed fixing in earlier versions, and now also takes extra care with respect to plot items when players may use the Party Gen GUI in a way I had not first considered.

Episode 46: The Easy Option! (Puzzle Auto Solve)

It's been a difficult couple of weeks for my module creation. Just as I thought I was about to do something straightforward, instead, I found myself travelling a long way down a rabbit hole without meeting anything cute! That's the nature of the beast when it comes to coding sometimes; even though I thought I had put this section of coding behind me! For the latest module two updates, please read on ...

Sorting Items On Entry

I am going to keep this as brief as possible, but need to report it for prosperity and a reminder to myself and others about an issue with the function GetObjectByTag. Basically, when a PC enters a module, any items they are carrying are not correctly picked up as valid objects by this function in a game until after the game has been saved and loaded again. I had a situation where I wanted to locate a single item within the new module, which is normally denoted by a unique tag. However, prior to this, I had stripped PCs of items that may have the same tag. The problem was, even though the items were stripped and destroyed, the function still detected them. My thanks goes to KevL for suggesting a quick fix to change the tag prior destruction, thereafter meaning any object falsely returning valid would at least not be found due to the altered tag.

However, on the back of diagnosing this "fault" with the function, I observed that it would also return other items valid, which were not actually present in the module: Those that were on creature blueprints associated with encounter triggers! While this may not be a huge problem if we carefully consider item possession, the very fact that items are still returned valid, but without a valid owner or location, can be confusing. I had two scripts that did module wide searches for tagged items, which would have also returned any items carried on creatures that at this stage had not even been spawned into the game!

Resolving the latter issue was reasonably straightforward: I simply rewrote the scripts to avoid returning items that had invalid locations and owners. However, the first issue was the rabbit hole that had many paths! My initial fix was to force a save and reload if required. However, as I allow players to import PCs with equipment, this was almost certainly going to happen for any new module I make. The solution worked, but I did not like the impact on gameplay or the player, so I decided to rewrite the code to bypass this need ... This, however, meant having to check every item on every PC of every player that entered the module at any time. This was further complicated by the fact I allow special containers that help with inventory control when finding certain items. E.g. Gems automatically get placed into a gem bag. I also remove invalid or duplicated items from potentially various PC types. Bottom line, I eventually resolved it, but it took me a lot longer than I thought it would. Hopefully, it is behind me again now, and after testing some MP aspects, I will consider this done and ready for v1.41E. Although it won't be fully utilised until my second module is released.

Faction Code Slimlining

Another issue from recent weeks has been surrounding creature factions. During another play-test, my wife observed one other potential faction issue: If Frank (at the barn) becomes damaged during the fight with the first two ants that appear, he can turn hostile to the party. Ideally, the heroes should beat the ants before Frank sees them. However, if the party are pushed back or the ants break through, Frank can become involved and things go awry. The problem was resolved by reloading the game and doing the fight again, avoiding Frank, but I wanted a permanent solution. To this end, I went through much of the creature spawning and faction initialisation code, replacing some older ANTIPARTY faction changes to simply HOSTILE. This maintains clearer faction distinction, which should avoid any such potential issues moving forward. The ANTIPARTY faction was designed and should be reserved for when the PCs attack something they should not in front of non HOSTILES. A rare and unlikely situation.

Lava Chamber Walk Mesh

Unfortunately, I spotted a bad walk mesh for the Lava Cavern in the first module, which required the movement of some creatures and a re-bake of the area. As it currently stands in v1.40E, the creature that is supposed to turn hostile is stuck in a position that prevents it from doing so. This is now fixed, as well as some other minor issues with the area, which will be available in v1.41E. Fortunately, it's a non-critical area and one that 90% of players would probably not find anyway, due to its difficult access.

Other Minor Updates

While working on module two, I noticed some other minor points that needed addressing, including fixing a seated talk animation and some timings for message feedback. All cosmetic, and again, will come along in v1.41E for module one as well.

But, I have been making other progress too ... I have been adding an extra puzzle button to allow an AUTO SOLVE for players who really do not want to do any puzzles. I have a few different coded puzzles in the game, which players are encouraged to solve to move the game forward. Most allow for alternative play to circumvent the puzzle by using specific tools with them if the player prefers to avoid them. However, a handful did require the player to solve the puzzle themselves as a game mechanic. One of these puzzles has now had an AUTO SOLVE button added, but only when the player sets their game settings to below D&D CORE RULES setting, and only then if someone in their party meets the feat or intelligence ability requirement. Furthermore, using this new option does not reward the player's PC with XP, but does allow the plot to move forward when necessary.

There is one other puzzle that I hope to add this option to, but all other puzzles will remain unaltered as they can either be solved using other means (tool items or Life Essences) or are not plot critical, so the player does not have to do them anyway. This week's screenshot shows the new button (when available) for one of the updated puzzles.

New Auto Solve Button When Game Settings Lowered

... And The Other Puzzle With New Auto Solve Button!

Episode 45: That's Enough! (Polishing Play)

It's funny how you let things slide with certain aspects of a design until you notice something for the umpteenth time and then simply say to yourself, "No! That's enough!". I had a few experiences of this over the last two weeks, and so decided to deal with them all. From a couple of subtle area transition changes to GUI text layouts, it's been a hodgepodge of stuff. Couple that with working on another area that players will learn holds more secrets than when (likely) first discovered, and you have earned another blog post with two screenshots. Read on for more info ... 

IMPORTANT: Any updates mentioned in this post will not take effect in module one until the v1.41E update.

TRANSITION CHANGES

In the last couple of weeks, I decided to jump back to another area I am working on because it links one section of play to the next. As I say in the intro, it's a key area that players will eventually learn holds a secret. In the process of working with it, I had to look at an area transition and it was while working with this area of code I determined to deal with two niggling points I had seen in my own play testing ...

1. Weather Changes: When moving from an outdoor area to another area, I originally had the timing of the weather changes occur as the game faded to black. This could be noticed if the changes were more significant, and so with a small timing adjustment, these changes are now not seen.

2. Time Changes: Similar to above, but often more noticeable, were if a rest altered the time of day from night to day. The selection would apply the change as the player faded to black, which I was not happy with. Now, the game fades to black before applying the time changes, which means the sudden light changes are not noticeable.

3. NPC Locations: On the back of these two VFX changes, I also looked at the NPC control code, which determined where NPCs will be located as a PC entered a new area. This area of code goes back to some of my very first coding ("Real Life" System) and it had been patched together with various functions throughout the years, until it reached the stage it is today. However, while it currently works for module one, it "fails" for module two. It fails because module two has more areas than module one, and the way I was currently handling area loops was not efficient enough for the number of areas module two comes with. To cut along story short, I repackaged four inefficient functions into two, which use far more efficient loops, as well as now use functions to "hide" creatures if they are not actually encountered anywhere else, but are simply absent. One of these new functions now handles the "de-populating" of NPCs if required (as a PC enters or leaves an area), while the second handles the NPC location upon a PC entering an area. The latter function had been the main issue, as loops had to consider NPCs returning to the PC's current area from any area in the module! The new system is really good, and much simpler for me to keep track of what is happening from area to area now.

NEW INVENTORY GUI TEXT

Another niggling point that I have been meaning to address for as long as I can remember is what an item's text says about its properties. I found that the so-called "unique" properties to be some of the most confusing both to use and/or have attached to an item's description. To make things clearer both for me as a builder, and for players, I edited the 2da files (itempropdef, iprp_spells, iprp_chargecost and spells with new tlk entries) to alter how the text displays when describing item properties. Whether it was simply to remove ambiguous or superfluous text, or even correct an official 2da entry (compare iprp_spells 359 with spells 386), where "Activate Item (Short Range)" would have been more appropriate had there not been two potential options that varied according to a power level. I ended up removing one option completely and reworded three to keep to a standard that I hope players can relate to more easily.

I also found the following frustrating to handle: having an item to be "Single Use", but able to be retried if "first usage" failed, without having the item used and removed from the PC's inventory due to its "single usage" activation. You could either (a) use the "Single Use" property, but code in a check to recreate the "used" item for the PC if it was used "inappropriately", or (b) use the "Unlimited" property, which allowed multiple uses until success, but could give the wrong impression about an item's usage if not clearly explained in it's description that it is actually a single use item!

Anyway, during my 2da rewording exercise, I came across iprp_chargecost entry 7, "0_Charges/Use", which at first glance, is good for nothing! However, it has a similar effect as the "Unlimited_Use" entry with respect to costs, but importantly, its useless description can be edited (as I have done) to now report "(One Use)". i.e. Like the "(Single Use)" equivalent, I now have a version of a 2da entry that allows me to say an item is a single (or one) usage item while allowing the principle of "Unlimited" attempts of that "one usage" without the need to recreate the item due to inappropriate usage! This means, I can now have "One Use" as part of the property description and even on a fail, the item is NOT recreated, meaning such an item will not be lost from a quick slot (if used). This is something I can make better use of moving forward, but I have also edited many campaign items that module one also uses. Basically, items that once read "(Unlimited)", but were actually single use items, will now read "(One Use)". I decided to stick with a subtle difference in wording from repeating "Single Use", as item usage is (in this sense) still subtly different.

New Special Properties Text Example

MODULE TWO INFLUENCES

There were a couple of other minor updates to all campaign code due to the influence of module two:-

1. Spell Book Ownership: Upon testing module two, I noticed a wizard would think their spell book (named as theirs) was not belonging to them. It was a minor glitch due to variables being lost between module change overs, and could easily be "fixed" by the player having their PC read the book again. However, this is not meant to happen, and so I changed the code to detect ownership by the name already recorded with the book rather than check a variable. As names are carried between module, this was a better format to follow, and I made a mental note to watch for similar items.

2. Walk Waypoints: Another area that required a minor code tweak was when I noticed some NPCs of module two disappearing from the area upon a PC arrival - a good result proving that the new area transition NPC checking code mentioned above was working - but nevertheless, not a good result as far as what I needed these particular NPCs to do. It turned out that this was the first time I had used Waypoints for an NPC in a different area from where they are first encountered, which they move to after said initial encounter. It was an easy enough fix, which, as I do not employ area to area waypoints walking in this way, I decided to simply check via the current area the NPC was in and keep the checks separate instead.

NEW SEPIA IMAGES

Something else I have been keen to include starting from module two are DM information sepia images. (I include one without any wording as a screenshot below.) It's something I have been looking at for a while, and being reminded of them after playing a little Pillars of Eternity (which I hasten to add reminds me a lot of my own module in some ways), worked an idea which now works flawlessly. I am considering using it in a couple of ways, subject to what opportunities arise: Firstly, and primarily, they will be used simply as a means of introducing an area or object on importance. The idea being to present the sepia image with text and a voice-over as a kind of introduction to the object in question. My first test area (image without text below) works well as it fades into play, has a voice over and then fades into gameplay again, all the while allowing a player to click out of the event if preferred, and drop out of the image and stop the voice over. It took a bit of experimentation, but I eventually managed to succeed in being able to pull off the event using the conversation facility in full cutscene mode. Secondly, as I was able to employ the conversation facility, it also means I can employ these kind of DM sepia images as interactive events like those I was reminded of in Pillars. It could (if somebody wanted to render more images) even allow the scenes to change like they do in Pillars, but that is not something I intend to do at this time of writing. I just thought it useful that should I ever wish to add player choice text, which altered both outcome (and potential images), then that was still possible too.

THE END RESULTS

All these latest changes have had quite a visual effect to overall gameplay, as well as improve its efficiency again. Thankfully, I was also able to finish my "special" area transition link that started me along this path in the first place, and it works like a charm. Of course, I cannot tell you much about it, as that would be a spoiler! However, I hope you have appreciated the work that went behind something as simple as this piece of module two update.

A Secret Way Opens Up!

New DM Information Sepia Images (Without spoiler text.)

Episode 28: You Can Count On Vampires!

What a bit of a selection of things to tell you about in this blog! My efforts (for what they are) have been tested in a number of directions, as health permitted during this difficult time. There may be another word with "V" in it that we are all talking about of late, but for this blog, I am going to restrict its application for the monster, the vampire! (The other word was "Covid", but that's the first and last time I will mention it.) So, what's been happening ... read on ...

CLASSIC MONSTERS!

You may recall from a few months back that I managed to put together some scripts that will manage lycanthropy in my next module. Now, in a similar vein, I am trying to rework another horror classic: the vampire! However, none of my vampires will be "Count" like characters ... or at least, they will definitely not be like the caricatured beaten to death more times than even the hardiest of undead characters, "Dracula" if I can help it. I aim to have them simply be the monster that D&D has made them and try to escape the stereo-type portrayal if possible. But who am I kidding! I reckon the "Dracula" character is so embedded in our psyche that it will be impossible to escape some mental images of that persona.

New Visual Effects

So what's new? Well, I discovered that NWN2 did not support the gaseous form that we are familiar with when a vampire wants to avoid an untimely end. Therefore, I had to script a version of that. (See video link below for a demo.) On top of that, I was not happy with the way the vampire model relied on a spell to try to dominate its victim rather than use a gaze attack, so I updated that too.

I also applied some of my previously developed "undead" scripts to ensure level drains work alongside any Life Essences a PC may be carrying. In my modules, Life Essences can act as a barrier towards level draining, in that some undead will drain these from PCs before actual levels.

Other than that, most (if not all) other vampire aspects are covered, from needing magik weapons to hit, fast healing, blood (constitution) draining, damage and other resistances. They are quite a formidable foe, but one that can be overcome if the party of heroes go well prepared; normally with a cleric and accompanying spells.

In Development

I still have some scripting to do with respect to their coffins and stakes, but that is all going to tie in with other plot related stuff and so it will come together in time. And you can thank my wife for their inclusion, as she wanted me to write a story based upon the return of one of her favourite characters from The Scroll (module 1), and this is where it led to. I won't say who that character was, but some of you who have played module 1 already may well be able to guess. :)

GAME OPTIONS!

As most players will know, vampires have the power to dominate their victims. This led me to looking at the various effects that I would need to have the vampire employ, which in turn led to the game option function, GetScaledEffect. This function is basically called when some effects are used on a player to alter the overall effect according to the Game Difficulty settings. Unfortunately, this section of the NWN2 game appears a little buggy, and so I determined to look a little closer at this too, especially as vampires use the dominate effect.

I discovered a number of small issues, but enough differences to what I expected to make me decide it needed "fixing". It's still currently a work in progress, but I do now have a greater understanding of the various effects involved and hope to have an update to this section of the game not before too long. I may even consider releasing another update for module 1, subject to any requests for it or not. If no-one asks for it, then I may just leave it as an update if and when module 2 is released.

The Vampire Combat Video demonstrating new effects ....

Episode 25: Nice New Gameplay!

Writing continues on module two at a better rate than previous weeks as v1.12E of The Scroll has proven to be the most stable release of the campaign to date. (UPDATE: As of 03/03/20, we are now on v1.18E) As this version has continued to be fault free in my wife's own latest play through (since updating), it has meant I have not been diverted from writing new material to sort out any further issues. With nearly 15 hours under her belt of fault free play, then unless she discovers anything else, v1.12E v1.18E may well be the final release of the campaign until module two is done. Talking of module two ... Read on ...

BACKGROUND ROLE-PLAY

So what's new? Well, it's hard to talk about anything too specific again, as much of the latest material is just a continuation of simply writing the whole thing! This includes continuing conversations, journal entries, scripts, etc. However, more specifically, I can say that I am starting to find an efficient way to include more background conversation nodes for players who do end up choosing to role-play a PC background. E.g. Bully or Lady's Man, etc.

I have even altered the script now to allow a Main PC (who are the only PCs that can have such backgrounds) to interject with their background node option, even if the player had started the conversation with a companion. Knowing the conversation node options will always be an option to the player has encouraged me to make the best use of them where possible, and it has been fun doing so.  

UPDATE: As these backgrounds are simply added feats, then (in theory) any PC could have a background, including companions. Therefore, I have reverted to the PC speaking as the PC applying their background comment, with a caveat that if no background has been set (either by the builder as a feat on the companion or as a feat applied as a background trait by the player when creating a PC), then if the Main PC has one set, then that will be offered if there is none other available.

JOURNAL NOTE SYSTEM

Another aspect of play that I have been having fun making more use of since I have it working now, is the ability to add additional notes to the player's journal. This is in addition to the normal journal quest entries, and are added alongside the notes a player can also add to the journal note section. Just like any player added note, they can be deleted by the player at any time, but are added as useful bits of information that help highlight those aspects that may be important when it comes to playing. For example, those players playing module one already may have noticed a note is added if and when a PC learns how to manage weapon repairs at a Repair Bench. This is one of the few notes that module one adds, but module two will make much better usage of this game mechanic to highlight not just game mechanic notes, but possible plot notes too.

NEW AREA MUSIC

I am also playing around with some new music files that I found, which I have managed to convert and add to areas. My test addition worked, and it currently sits as the music for an area I am currently working on. It's a minor new addition, but I hope, along with those I mention above, will be some of those differences that will benefit the next module.

THE MEGA MECHANICS

If you may recall, I have mentioned in the past that there will (also) be a mega-dungeon design in module two, which I hope will be well received. I have taken time and effort to develop a system of new mechanics that complements the overall design of the mega-dungeon to give a completely new experience to sit alongside the normal NWN2 gameplay. i.e. In much the same way players can currently experience new GUIs for puzzles and gameplay in the first module, the new GUI arrangements for module two I believe offer a whole new variety of gameplay to experience!

This week I have also been scripting aspects of this new gaming design to ensure it runs as smoothly and intuitively as possible. One thing I learned during this time is that you cannot get the gold piece value of ammo (bullets, arrows and bolts) like you can with other items. This meant I had to improvise a new way of doing so, which while quite boring to do, does mean I now have the system in place ready to work with some more code. All in all, this whole side of the gaming mechanics is gradually coming together ... right alongside the additional Readable Books I have written to complement such systems in the game and to give the player greater depth to the story. I have found the writing quite rewarding as I have brought the overall campaign story arc together.

That's all for now, as there's not much more I can say without giving spoilers ... Dare I say, I was even reluctant to use this week's screenshot in case it spoiled anything .. but I decided I was just being over cautious, so here it is ....

We Have Found A Tomb!

Episode 24: Continued Development.

I write with mixed feelings today, as I have just discovered I introduced a module one game breaking bug back in v1.06E (27th December 2019), which I only just discovered while testing something else today. It is so frustrating when something like this happens, especially when I am doing so little with scripts that may affect that module now. (This has now been fixed in the latest version available.) On a more positive note, I have been making reasonable progress on module two of the campaign, including making another home-brew placeable that the PCs will discover. (Included as this week's screen shot, as it is only a minor spoiler at most.) Read on ...

SCRIPTS LOCKDOWN

From today, I am forcing myself to make sure I add another line of code to critical scripts to ensure I do not break existing code that module one relies upon. This should, in theory, mean there should be no further "breaking" of module one. I know I have said this kind of thing before, but sometimes I thought the change I was making was insignificant. How wrong I can be! As a lesson learned, adding any new code to existing scripts will now be properly segregated from module one.

AREA DEVELOPMENT

Much of the last fortnight has been to do with continued area building for the module two, especially for those areas related to the main quest. It was during this time when I discovered an issue with "rope" in the game. Rope is used for some situations and so has extra associated scripts. However, it also has an "item placeable" object associated with it, which means a new placeable is created when it is dropped. The problem was, however, is that once dropped, I could no longer pick it up. This led me to a fix for v1.10E. When I went to test the rope fix in module one, that is when I discovered the On Area Enter issue ... which led to the essential update I speak of in the introduction.

It was during this time that I also discovered playing more than one sound at the same time could potentially cause an issue by only playing one of the sounds. This was also fixed in the latest campaign release.

NEW PLACEABLE BOARD

During my area building, I was reminded of some games that show a profile map of an environment, where the different vertical levels of said environment are shown in relationship to one another. I think of games System Shock 2 and more lately, Prey. As the layout of the environment I am currently working on is a bit different to the standard "one level directly on top of another", I thought I would also provide a map showing the unusual vertical layout for the player.

My first attempt was to use the "painting" model, which I am familiar with already. However, the model was too small to present the picture I had prepared. Therefore, I decided to look for another existing model that was bigger to do the job. I eventually opted for the arcane chalk board, but transferring my image to that turned out to be more tricky than I thought it would be.

On my first attempt, the image wrapped around so that it did not show correctly. Eventually, I was able to see that the original image did the same, and that if I wanted to present an image unwrapped, then it needed some alterations, which finally worked after some experimentation. However, this led to a second issue ... the text was mirrored and on the wrong side. Thankfully, simply inverting all the images related to the arcane board and the text in my own image sorted the issue. The screen shot of the final result is this weeks screen shot.

PC BACKGROUND CONVERSATION NODES

I also worked on more conversations, and was reminded how each main PC in a game could potentially come with a character background feat/trait. For example, you have the bully, or the lady's man, etc. Not every player may select one, but for those that did, I thought it would be good to try to include some conversation options that helped to reflect their PC background choice. These conversation options would sit alongside any others that the conversation required and I hope would add flavour and encourage the player to play their role-play their PC character background role more. I ended up having to write a new script for the conversation node checks, and discovered the farmer trait to be incorrectly present in the official nwscript file. It has been fixed with my own script that simply uses basic number integers.

A Profile Map of the Citadel

Episode 22: May The Force Field Not Stop You!

With the toolset issues behind me, I am now able to push forward with the creation of module two of The Scroll with more ease. Especially in the department of working with sounds and VFXs. I am not an expert in this area at all, but find I am able to rework some of those VFXs that others have made or come with the toolset already. To this end, when I found myself in need of another VFX for the latest dungeon I am working on, I was pleased to find I was able to make the VFX I needed. Read on ...

FORCE FIELD VFX

So if you had not guessed from the title already, the new effect was a Force Field. I don't think I give any spoilers by mentioning it, because I have not yet decided just how "menacing" the final encounter with it shall be. Suffice to say, the effect turned out as I hoped, with the only caveat being that I had to separate the sound part of the effect from its visual effect. This was because the sound of the VFX could not be easily managed in scripting if I did not. It was going to be this week's screenshot, but as the full impact could not be easily portrayed in a soundless 2d image, I am treating readers to a small six second video link to take a look instead.

AREA BUILDING

I also managed to start building another interior area to support one of the exterior areas I am currently working on with respect to the main quest. It's one of a few interior areas I knew I was going to have to build, and as I have just updated the HAK folder for the campaign, it gave me the opportunity to check one of the yet unused tile sets: Cellars by rjshae. This week's screenshot is from that interior area in it's early design.

CONVERSATIONS

I have also started to add templates for more conversations that are needed for the mega-dungeon section I am working on. These conversations are reasonably straightforward ones, but like anything to do with the "mega" status, I simply need more to accommodate the dungeon size. And while on the subject of the mega-dungeon, I can add that I have also continued to work on its various areas too.

SCRIPTING

Thankfully, writing scripts is one of the less taxing aspects for me, which I have been able to keep reasonably well up to date as required. On the subject of scripting, I have also decided to move all scripts, including altered official campaign ones, to the root directory of the campaign folder. This is because if they are stored within their own sub-directory (like they had been), they were not checked when using the "compile all scripts" option. While this may not be an issue much of the time, there are some circumstances when missing these scripts during a compile check may have an impact in future, because I often forget what these scripts refer to. So basically, it's a precaution moving forward from v1.08E (next release) of module one. As an example, the "invisibility" scripts required recompiling after I removed a function they referred to. Thankfully, the removal made no impact to the spells at all in any past releases, but I won't be taking the same risks moving forward.

BACKSTORY & QUESTS

I have also been taking time to put together back story in my Readable Books format (*) and develop some more side quests. The latest book written has over 2 x 6 pages! It is designed to answer some of the questions the player may have been wondering about, but they can choose to read or simply skip through. Either way, the game will continue regardless of how much detail the player chooses to read ... but I hope they are encouraged enough to want to know more of the story anyway. (*) Latest version in The Scroll campaign files only.

As I have stated previously, my aim is to try to provide some side quests that will complement the main quest more naturally than in the previous module. It's more of a subtle change, but one that I hope may make gameplay feel more natural ... perhaps. They take the shape of "while you are at it" approach, as opposed to "here is something else".

The Cellar is Cold, Dark and Dank!