Choose Your Language

Saturday, 3 July 2021

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!


Monday, 21 June 2021

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


Tuesday, 8 June 2021

Episode 44: Two For One!

Things have been settling down for me at our new house, and I have been able to make some good progress. Not only have I been moving to yet another couple of areas to work on, but new material (in the form of a Readable Book) supporting one of the new creatures that can be encountered has been in the making. Read on for a full update ...

STICKY OOZES

You just think you have delivered the decisive blow, only to discover you simply have split the ooze monster into two! Now you have twice the problem! Yes, I hinted at them in module one, and even had the code in place, but module two, Predestinated Days will have them full blown and ready for combat! Not only are these critters dangerous in their ability to divide, but their acidic quality will soon have unarmed combatants wincing in pain, and even some running away to help protect their equipment from any acidic backlash. Be sure to pick up the book, entitled "If It Splits, So Should You!" from the nearest store when you come across one. Seriously, you will want to know more about this particularly enemy and how best to defend yourself from them.

IMPROVED TB UPDATE

And if you are the type of player who likes to use TB Combat, then rest assured that an update to the Target GUI has been implemented to allow a player to click an unpause button from the GUI interface using the mouse instead of having to click the space bar. Surprisingly, this can be quite useful if you are sitting back from the desk and prefer the use of the mouse in such situations.

MAP ENCOUNTERS

Yes, Predestinated Days will be coming with an overland map ... the type you can explore and meet encounters. However, for those that later learn the quick paths for travelling, then the older style "click on a map" to travel to a location will also be employed. That is, two systems in one, switchable to the style you prefer. Of course, taking down encounters along the way will also reward you with experience, loot, and the thing my wife has been requesting, some specific crafting materials that you may need.

IMPROVED SCRIPTS

Both module one, The First Day and module two, Predestinated Days, gain these benefits from v1.41E onwards. Basically, as I have been working through the new areas for module two, it has given me the opportunity to go over and fine tune some of the less used scripts, including those for certain trap switches and detection, potential party mayhem (murders), house looting scripts and a general overhaul to areas of player feedback where I felt it may be of help.

Basically, everything over the last week or so has been general progression as I focus on a couple of new areas that move the players from one area of the module, via map travel, to another area of the module where the plot thickens! There is still much more to it than this, but being able to get the framework in place, where I can move between areas is a big step towards getting things done in general. This and preparing conversations holders are a pain to get ready, but once in place, simply editing and retesting from a saved game becomes very simple and a pleasure to do. I am getting closer to the easier parts with each week that passes!

And as this blog post appears to be about "two for one" in certain aspects, I will also do two screenshots instead of the usual one this week...

A View From Above ...

... And A View From Below!


Saturday, 29 May 2021

Episode 43: Permits Permitting!

I know it's been a while, but I am finally back in a position where I can now safely start producing more material for the module, Predestinated Days, the second part of the campaign. The once ever-present brick dust in our house has finally been eradicated, and both myself and the computer can now breathe more easily, allowing me to get back to production without any fear of a breakdown. Note, however, I have not been completely absent from the task, but simply hampered. This blog is to announce a return to a more structured pace and a little info on what has transpired since I last posted ...

MORE QUESTS!

Since my last post, I decided to change the area(s) I was working on ... which actually involved around half a dozen or so areas in the end. Since these are areas that will be found towards the end of the module, and are quite involved, I decided to start working on some of the earlier areas instead. Here I was able to introduce some new quests, which I hope will have an impact on the later areas anyway. In the latest area(s) I am working with, I was able to introduce three new quests, and add a lot of new conversations and characters that I hope will add flavour to the story as a whole.

MORE CONVERSATIONS!

From there, I was also able to manage a number of new conversations that will play according to the various PC backgrounds. As I continue to develop these areas, I have found that I have been able to make more and more usage of the new conversation options, which should add for some interesting outcomes, subject to which PC the player decides to allow to comment and according to the different background personalities they have.

MORE MONSTERS!

This latest area I am working on is also the area where I will be adding a new creature type. I won't say anything about it, except this link could be considered a small spoiler. However, true to my own style and tradition in such situations, there is more material I need to add regarding such, including bestiary information and even potential readable texts. i.e. I try to give more background to certain monsters where possible, to give greater immersion and potential gameplay options. With this, however, comes potential complexity that may clash with some other ideas I have in mind, and so I will need to work through this particular creature type with care.

AND ANOTHER SCREENSHOT!

I don't know if I have shown a screenshot from this area before, but as it is from the current area I am working on, I decided this was the one for now. Please note, like all my screenshots, the main PC speaker (and other potential party members) are NOT properly dressed, as they are test PCs only. Therefore, please do not let the lack of dress put you off ... I leave that for the player to apply when the time comes.

Things Are Never Straightforward!


Monday, 5 April 2021

Episode 42: All In A Day's Work!

Work at our property feels like it's taking ages - more like a campaign length project than a module! Hopefully, from tomorrow, we enter the final stages and I am hoping normality should return soon. Thankfully, this latest bank holiday has also given me a brief respite from the hubbub to be able to write this blog and give an update on some things I have managed over the last few weeks. Read on ...

Increasing The Spec!

Whether it was the brick dust floating around or simply its time, my wife's 10-15 years old computer (subject to various part changes) died a few weeks back. At first it looked like a GPU issue, but even after replacing that with an old card I had, it still failed to boot into Windows. Only later, after sorting out a replacement PC and rearranging the hardware did I also discover the OS had corrupted. So, whether the old PC is now fixed (and would boot from the reinstalled OS), I have left as an unknown, because I do not wish to risk corruption of the OS again on some potentially dodgy hardware.

The bottom line, I gave my wife the PC I have been using and acquired a new computer for myself with better spec to help with the module building process. (Moving forward, it will also benefit the odd newer game here or there of course.) My old PC is certainly good for my wife's needs and we are now both able to get on with our hobbies again. For the new PC, I switched to an AMD Ryzen 5600x CPU this time around, as opposed to using an Intel (my normal preference), so it will be interesting to see the results. I was also able to get a reasonable price on an Asus RTX 3070 in the build. At the moment, I am not noticing a great deal of difference (same drives being used from the older PC), but I imagine file compression and such applications will be quicker as I continue to build the module.

Frustrating Delays

Having to cope with our current situation is, without doubt, placing a strain on me. This limits me to what I can do even more than normal, causing frustrating delays. Rather than lose the thread completely, I have tried to load the toolset at least once a week to add the odd conversation update, or plot addition, but I confess that it has been so disturbed that it cannot amount to more than a few days work in total. So instead, I have also been trying to help out a little on the forum posts where I can, simply to keep my mind involved in "module" mode.

I did manage to fix a few issues with my module one and upload the latest v1.38E, which is now at the most stable it has ever been with respect to any issues, mechanics or plot. My wife helped to find the broken uploaded v1.36E after she wanted to play it again. This had been one of the most frustrating discoveries to date, as v1.36E never needed to have been broken, and had gone unreported for a couple of months. I'm just glad that is now replaced.

Module Two Actual Progress

Since the last blog episode I have shifted focus to an area where a key part of some action will take place. It involves a couple of cutscenes, some involved conversations as well as a fair amount of player interaction. It brings together a lot of those things I have learned from making module one, including animations, walk ways, spawning, as well as a multiple path conversation to cater from various playing styles both SP or MP.

This section also allowed me to use some code I had developed in module one, but never (until now) had a reason to employ. It involves my Read Language scroll, which allows its caster to be able to read a foreign or magic language while active. 

It was while testing this latest spell addition when I noticed some VFX I had been using were no longer supported in NWN2, and so I went through the lists looking for ones that worked better for the various places I had used them. Changes included the VFX_DUR_SPELL_PREMONITION, which is used in the cocoon spell I have designed. For the record, this update is not available until v1.39E release, but I will also be keeping an eye open for any other failed VFX constants used between now and then.

So once again I have to apologise for the lack of news, but, hopefully, things will begin to improve in the not too distant future. For the time being, here is a screenshot from one conversation I have been working on.

All In A Day's Work!


Monday, 15 February 2021

Episode 41: Moving Forward?

As I write this, a hammer drill echoes through the house as workmen sort an issue for my wife and I. Furthermore, this noise and distraction may last some time, meaning all production of the module will be compromised. Don't worry, once the house work is complete, I hope to regain my pace, but for now, progress may be slower, and this will also be reflected in fewer blogs until things are back to normal. Read on for latest ...

Latest Area

Recently, I have been writing conversations which handle a number of key quests surrounding a location, which the players will encounter nearer the end of the module. I have now sorted much of the initial stages of these quests, but am now working on one of the areas where the action takes place. Progress is slow, simply because I find area design difficult. Also, I have the added consideration of balancing some new game mechanics that take place in this area. It's hard to explain exactly what I mean, but this part of the module plays with some added game mechanics, which require careful application while designing the areas that use them. It all takes time.

The Journal Notes

Another gaming aspect I have been making good use of of late is my Journal Note System, which I first wrote about around this time last year. It has become a very useful tool, not only to help give players a gentle reminder of certain gaming points, but is also useful when keeping track of what players should know at any given time. It acts as a dynamic notebook, with updated notes that players may or may not act upon, but also allows me to observe different variable states that these journal notes may represent. As an example, a player may have a conversation with an NPC and learn of a clue about something the NPC mentions. This will update the journal note system, allowing the player to refer to it, to remind them of some useful piece of information, without incrementing a quest stage. It is also useful for me to observe in testing various variables.

There is not much else to report at this stage, and so leave you with another screenshot from the area I am working on. It may be a little while before I write Episode 42, but hopefully, by the time I do, I will have more to report.

 

Unusual Objects!




Tuesday, 26 January 2021

Episode 40: The Big Picture!

I know it's a cliché of a title, but as we have reached Episode 40, I think it's also appropriate for a round up of the campaign so far. Another cliché they often say is that "life begins at forty". Believe it or not, I was around that age when I started building with NWN2, which came out in 2006. Since that time, I have released The Scroll: The First Day (module 1) in 2016, and am still currently writing the follow up module. The question is, if it took me ten years to write the first module, how long will it take for me to finish the second one? And isn't there supposed to be a third module? Read on for more info on the bigger picture ...

Getting To Know you

The D&D game is nearly as old as I am, and if you include wargaming as a general pastime, the hobby is far older than me. However, when I was first introduced to the "game" in 1981, little did I know back then that it would play a big role in my life. For those interested, I wrote three articles about the changing face of D&D and my personal experiences with the game in the early pen and paper years: Part 1, Part 2, and Part 3. The bottom line, The World of Althéa campaign is my second campaign from my days of pen and paper gaming, and it was born of a growing understanding of gaming rules, imagination, and the love of telling a story. But, and here is a key point, that story has grown with me as I have grown. It's as if the story has revealed itself more and more to me as time has gone by. Don't misunderstand me: the core elements to the plot were in place (mostly), but the details were always vague to me until I put pen to paper ... or more lately, fingers to keyboard. So, it occurred to me, this story actually feels like it carries a correlation to my own life, and much about its telling carries aspects of my own past, as the story to come will be of my future. There is a humbling realisation that once the story has been finally completed (God willing), then the story ... and that large part of my life ... will be over, and both the end of the story and the fuller part of knowledge of myself will be known.

Isn't It Just A Story?

I suppose it is just a story - after all, it's reckoned we all have a story inside of us, waiting to be told. Although, it begs the question, why do we tell stories? Why does the bard pick up a pen and write a play to be acted by performers to entertain others? I want to emphasise that I am strongly distinguishing a story from a historical article here, or from any factual account for that matter. However, stories are still written and published, but from where does their source come? What is our imagination truly? I have my own beliefs about such, but I ask you to ponder over these matters yourself, and recognise that we all, for some reason, have desires to "hear" or "play" a story, even from a young age. Why is it that we like to escape to another place in our imaginations? That escapism is very much a real aspect of life, even if the story itself is just a result of the imagination ... whatever that may actually be?

Back To Althéa

Enough philosophising ... Latest news: I have been making progress with Predestinated Days, the second module in the series. And in case readers may be concerned that these modules stop at a cliff-hanger point (as part of a series), rest assured that I have designed them in such a way that I hope a player can play them individually to a satisfied end point in the story line with each module. So, if you want to make a start, then you can play module one to a satisfying "end", and keep your saved game, or any exported PCs to be able to either carry on playing with module two, or import and do the same. There will also be the option to simply start playing from each module's beginning regardless.

At the moment, I am in the process of sorting no less than four quests. I am taking time to write surrounding conversations in such a way that logical flow works no matter which way the player picks up the quest. All four quests are to do with the section towards the end of module two, and are some of the hardest ones to prepare to work well. Part of the issue with these quests, however, is that there are a number of new items and placeables that need work around their application too. i.e. I need to build new items, which need to be added via a 2da, which in turn are acquired via specific placeables, which are then referred to in conversations and the quests.

I still have a major section to finish that I have already started, which the players encounter earlier on in the module. There are at least three areas that I have not yet even started to work on from a perspective of player interaction - although the areas themselves have been finished. All in all, however, I am hoping the process will go more smoothly than the first module, simply because core functions are already in place. Although, the latest module also has much new content, including monster AI surrounding vampires and werewolves, as well as a unique gaming system to do with a campaign story line. It all adds up to some interesting gameplay ahead ... I hope!

How Long?

Trust me when I say that if I could have released this second module now, I would. My wife, who catches glimpses or hears sounds of me testing it, has often asked me the same question, eager to play the second part. She has even made a list of some crafting items that she would like to see that would help her with some higher level crafting when the time comes. (You would have to see the appropriate craft books to see what I mean.)

I can only answer in this manner: The first module took me ten years to build, but was done with less knowledge than I have today. Furthermore, much of the core code for module two is already in place, which means I am simply adding content. On the flip side, my concentration has become worse with each passing year, definitely slowing progress. This module also has more areas than the first one, and as I do not like giving players areas without something significant about them, I need to allow the area to "mature" and develop with each aspect I am currently working on, which also adds time.

The official SP release date for The Scroll: The First Day, was 04 May 2016. (This is ten years after I first started working in it in 2006.) From that time, I continued to work on patching and updating this first module as I also laid some ground work for module two. However, I did not start MP testing for the first module until 17 November 2018, which came to an end after 31 episodes on 02 March 2019. These current episodes that you are reading, detailing the building of the second module, Predestinated Days, then began on 03 May 2019.

We also need to consider that much of the area design of the second module (much like the third module) has already had major work done. (Although I have found myself needing to add new areas for the second module, which I hope is now finished.) Therefore, although difficult to pin down an exact date of when I started to focus on building module 2, taking all things into account, I believe we can fairly say that I can use a start date of around January 2018. Strictly speaking, work started a long time before this date, but allowing for all those varying factors above, if I had been starting this module afresh, I believe it would have taken around three years to reach my current point, at my current speed and knowledge.

I am not sure how much that helps us though? Simply because it is hard for me to know how I am going to fare from day to day. It is so frustrating having to pace myself due to my condition, but if I do not do so, then I would suffer. Also, there remains one or two areas that I have not currently focussed on at all, which means they are an unknown entity when it comes to time involved.

Speaking optimistically (and recognising potential health impacts), I would like to say this module will take me five years from start to finish, which would mean a target end date of January 2023. That is, I believe I am probably just over the half way point. But, like always, only time will tell. For instance, it may be that things fall into place much quicker and I could be finished by the end of this year! But, life events are unpredictable, and we must bear these in mind too. As for the third module, and to use another famous saying, "it will be done when it is done!" (And maybe I can report on that after this one!)

The Scroll: The First Day

Regarding module one, version 1.36E was recently released after my wife finished playing it yet again! She genuinely likes it! I encourage her to play some of the classic RPGs, which she does, but nevertheless comes away saying she wants to play my own module again to see if she can improve on her earlier accomplishments - she is into the new crafting system a lot! While v1.36E is the current release, I do have another version in the pipeline, which fixes stacked wand (and other item) usage. However, as this is a minor issue, I will wait for a while longer to see if anything else should reveal itself from any other reports.

This report also marks another aspect of module two: It has reached its 100th backup! To mark this, I will post some bonus screen shots ...

An Ancient History!

Viewing Ahead With Darkvision!

Cornered By Zombies!

Waterways!

Monday, 11 January 2021

Episode 39: The Path Opens Before You!

It's a good feeling when plans start to come together, and the results of the last few days have helped a great deal with that feeling for me. At last, I am starting to move towards conversations that open more paths for the player to follow, which in turn, allow me to start to write more conversations and update journal entries. Read on ...

Opening Up The Pathways

My favourite kind of RPG is one where I can easily switch between the various tasks a module may offer and pursue them in various ways. i.e. I am not forced along a specific linear pathway because that is the way the story goes. Don't get me wrong, I am all up for a very strong and engaging story in an RPG, but how that story develops or unfolds, I like very much to be in the hands of the player. Achieving this, however, is not as straightforward as one may think

The key is to minimise choke points, which are basically those events that do force the player to have to pass a certain point in the game, and which the module designer uses to ensure the player's party is at a certain stage in the overall game. As an example, requiring a key could be designed as a choke point. If not handled well, however, a player with a rogue who can pick locks, or a wizard that can cast Knock, or even a fighter that can normally bash through walls will not be pleased about such from the perspective of player agency. Such points have to be carefully considered, and implemented in such a way that do not spoil the experience, and the builder must do as much as they can to have such choke points appear most logical under the circumstances.

A linear game basically consists of choke points at every stage of the game, and leaves little in the way of choice of direction for the player. Conversely, if used sparingly, such choke points will be conveniently "disguised" among the many other options the player is considering. The downside to designing such a game is that it requires a lot more time to make work, as followers of my bog will have already witnessed. As an example, I have a trigger that a player could activate in one of four states, subject to the path they have taken, with each response varying according to the party makeup. And this is just a small notification trigger that can either update a journal note or a journal quest stage.

The latest news, however, is that I have just passed through another such design aspect and am now able to progress with the main quest and various sub-tasks available beyond this latest choke point. From a design perspective, it allows the builder a little more breathing space to be more creative again. The only problem to remember with such, however, is that all these new paths need to be brought back together before the next choke point! This is less of an issue for side-tasks, but certainly important for the main quest.

The pathways now open again for me, I have already started work on two new quests and a continuation of a third. This involves a few more conversations and new area events, which should all be most fun for me to prepare and interesting to the player too!

Improved Code

Again, thanks to the latest feedback from my wife (who is playing yet another play-through of module one), I have been able to focus on those areas of coding that can go under the radar unless certain playing criteria are met. For example, the efficiency of "loops" in certain areas of code is one huge aspect I have concentrated on since she has been playing with a party size of 10- to 12 members. Other areas include the code around hard-core death, as she in playing another run through that way. Also what happens to certain NPCs who have a neutral faction and have been subject to monster attacks at inadvertent times. All such pointers from such play testing have now been addressed, and serve to make for much more efficient coding, and make the experience more enjoyable.

Most of all, however, being able to apply all the benefits of my knowledge of building module one to module two have been of great benefit. And having a huge library of module one functions to draw upon has made the whole process so much easier ... and fun! There is a definite shift in time spent debugging compared to time spent creating.

As a side note, I intend to release module one v1.36E after my wife has finished pay testing this time around, as there are a number of very useful fixes. 

Finally, here is an screenshot from a stage after moving on from the last choke point!

Never Ignore A Gut Feeling!


Saturday, 26 December 2020

Episode 38: Coding Monsters!

Let me say straight from the start that this post is not about actually scripting monster AI, or even a tutorial about how to design a monster in a toolset. In this case, I am simply referring to those technical "monsters" builders face when trying to produce their modules. From applying animations to writing scripts, they all seem to come at various levels of difficulty, just like those "real" monsters we face in the game itself. So while some such encounters may occasionally appear as "simple" as a goblin to beat, others feel like dragons! Even builders skills can be thought of as in classes and levels themselves, so what may appear simple to one builder becomes a real challenge to another ... and haunt them for years! Read on for my latest XP gains in building ... 

The Patrolling Guard

A couple of posts back, I described how I had been wrestling with some animations and how they may or may not work within conversations. Recently, however, the issue with animations has extended into the area of walk paths for me. In the past, the official WalkWayPoints function (and accompanying scripts) had always been a bit hit and miss for me, and so a few years back I decided to write my own version of them so that I could have more understanding and control with what was going on, especially when considering scripted waypoints: those that allow additional animations for a "walking" creature. This venture was a reasonable success, as it did allow me to ensure the creatures I setup worked as expected ... but only "most of the time".

I still continued to encounter issues where walkers would sometimes become stuck in the environment; a problem exacerbated if a PC blocked a walkers path in a limited space. Previously, I had tried to alleviate the issue by forcing the creature to try to move somewhere else before continuing their walk path. The problem with this, however, was it could cause the creature to constantly reposition themselves if the path was blocked by a PC. It looked like they had the jitters! Thankfully, in the end, I figured a way to smash that long standing monster, by using a ClearAllActions that now simply pauses the walker in their walk until the path is clear again. It was a relatively simple fix to a long time issue I had been struggling with. The only caveat I learned at this time was also to ensure any WPs laid down MUST be done in such a way as to clearly be guided around any placeables. For if a WP guide line even slightly clipped a placeable, the engine did not appear clever enough to always be able to walk around the placeable object.

XP GAINED: 100

The Random Monster

Once again, I am not talking about a random wandering monster, but the monster of trying to work with random probabilities in the game ... or with any probabilities for that matter. Twice over the last few months, I have had to face some maths to do with probabilities. As many will likely know, trying to deal with any kind of randomness on a computer is difficult. (Do some background research if need be.) My first issue was trying to determine the probability of a drop to ensure I was giving the player the right odds at acquiring certain items and the second encounter was trying to ensure treasure drops randomized their location fairly. For the latter, I learned a bit about the dangers of naivete.

XP GAINED: 100

The Persistent Monster

I have certainly had my share of these critters! Those who have been following my campaign build of the last few years will have seen some of the types I mean. I can even include The Patrolling Guard issue as one of these types of issues, but as I have already covered that above, I will give an example of a couple of others I have had to deal with recently.

An example of the kind of thing I mean is the usage of a variable string instead of a variable name. So rather than GetLocalString(OBJECT_SELF, sVariable), I will have done something like GetLocalString(OBJECT_SELF, "sVariable"). The issue with this kind of problem is that both lines of code will happily compile as neither is a compiler error. The error is purely one of my own making using "sVariable" instead of simply sVariable. The last one I had one of these, I was stuck for quite some time trying to locate why my script was not working.

Another example of an issue I can encounter of my own making, is if I should happen to change a ResRef of an item, which I have previously added to a store with its old ResRef. This again has caused me all sorts of issues when I am trying to reproduce an item from the original store bought ResRef, which fails to do anything because all that I have there now is the newer reference. Thankfully, now I have been stricter in my approach, I believe I must be near the end of any such issues moving forward.

XP GAINED: 100

The Deep Rooters

When I hit one of these issues, I can usually write off an entire session trying to get to the bottom of it - sometimes even multiple sessions. These type of issues tend to rear their ugly heads somewhat further down the coding path, and often even after a module release. The reason being, these type of coding monsters often only show themselves under unusual (or rare) situations.

For someone who has coded their module in the way I have, this means I am more likely (I believe) to hit these types of issues more than most, simply because I have a number of deeply integrated systems that allow multiple paths and diversity for the player. As an example, even the way "Death" is handled in my campaign has multiple paths. I can thank my wife who has been able to test the module a number of different ways and offer feedback in some areas of the code, which even I have not been able to fully test due to time limitations. I hasten to add this is why feedback from players is invaluable to builders, as we simply do not have enough time to do everything.

As an example of one of these deep rooted monsters, in her latest testing, my wife discovered that if she had abandoned a dead PC in the Sanctuary (while playing hard-core death mode, being abandoned meant the PC could no longer be raised from the dead), if she now brought another dead PC to the same area, the code had not yet been considering such a situation where a player (like she had done), now tried to raise another PC that was still able to be raised within the same area. I had to trawl through multiple death scripts to finally locate the one which needed a simple variable check added to fix it. A simple fix in itself, but one that required a lot of code searching.

As a final example of a recent deep rooter, my wife discovered a situation where she could return to an area and the NPCs would not be there. She quickly discovered she could work around the issue by reloading, but it was still obviously an issue for me to have to resolve. Once again, the problem was hidden among a number of functions relating to the whereabouts of creatures subject to the time of day, and if they changed locations depending upon night and day habits. Now most people probably do not even worry about this area of module coding, but for me, who wanted to design a "realistic" environment where time mattered, I had to track down why certain NPCs had refused to jump to their relevant locations upon her arrival. This monster turned out to be quite an "end of level baddy" type, even requiring me to rename some functions to help avoid misuse due to their naming. Along the way, I was able to improve the scripts (as they go back quite some years), and finally add the relevant function call to the right script to ensure these lost NPCs would now return at the appropriate time.

I hasten to add that even when trying to improve some of these scripts, simply adding a GetIsDead check for some reason would crash the toolset! Again, it was only a minor condition I considered adding to help "improve" efficiency, but the toolset was not having it. The additional problem was, having added it during the process of the overall fix, trying to locate that it was the cause when the final test crashed, added more time to resolving the initial issue.

XP GAINED: 200

Gaining A Level

Anyway, after all this monster slaying, I can safely say that I have probably gained enough experience to go up a level now ... well, at least in some way. I am still not much better in area designs and such like, but maybe I have gained a point or two in conversations and some scripting. ;) And all this is being added up to hopefully bring to you module two one day ... speaking of which, here is a screenshot.

Let's Sit Down For A Talk


Tuesday, 8 December 2020

Episode 37: The Dungeon Environment!

As we all should know by now, dungeons come in many shapes and forms, fascinating us and piquing our curiosity, while at the same time, all too ready to do us harm! For those of us who enjoy both science fiction and fantasy, we are familiar with the many different environments of alien or bizarre objects we can expect to find, as well as the many denizens we are likely to encounter. This week, I have been trying to focus on some of those aspects, which I have found interesting to deal with in my own past gaming experiences ... and which I intend to include in my next module. Read on for all the latest updates ...

The Alarm System

Of all the games I have had the privilege to play, one of my favourites (as many of my regular readers will know) is System Shock 2. For me, it was the first time I experienced timed alarm systems, which could catch out the unwary player and send a horde of creatures their way if not handled correctly. I developed a system akin to this in my NWN1 module, Soul Shaker, where I employed "Watchers" to do something similar. In my next contribution with The Scroll: Predestinated Days, I hope to add another variation to a dungeon that players will need to negotiate.

Without going into too much detail that may spoil the experience, all I will say is that the alarm system I have devised has managed to capture all those elements I was after, including the ability for the player to be able to manipulate the system and gain an advantage if they play clever. If not, then there will be consequences ... The choice of play, however, will be left to the player.

Complementing Systems

Part of the joy of building a new module is being able to put together new ideas and systems that all work together to give the player a whole new gaming experience. For myself, it is not just about putting together a new story within the same fantasy world ... it is also about adding a new dimension to the game play itself. Please note that The Scroll series of modules are not as extreme in their design as my NWN1 Soul Shaker module is (as those who have played my modules will be able to confirm), but I hope those same players will also be able to attest to the many other new systems and options I have built within The Scroll to make it the unique playing experience I believe it is.

To this end, The Scroll: Predestinated Days will continue with some of those systems I have already developed in module one, but will also have a few new systems added to complement them. Hopefully, I have been able to incorporate them well enough to be reasonably intuitive to use, and most of all, a fun addition. New GUIs have been designed and included to make their inclusion easy to work with. At the moment, I have held back from showing screenshots that include them, but maybe in the future (and possibly nearer completion), I may be able to give one or two screenshots that I hope will tease the player with what to expect.

Conversations Overhaul

Some dungeons offer the opportunity to converse with its denizens, and so a good conversation goes a long way. Recently, I learned more about how animations work in conversations, and so ended up "fixing" (by removing broken animations) and "improving" (by adding some I knew that worked), not only for the second module, but also retrospectively for some of the conversations in the first module. Now, the NPCs respond more animated than before, benefiting both modules. NB: The first module will have access to these upon the next release (or update).

Code Improvements

Working on the second module, which shares the same core code as module one, allows me to continue to test and monitor the overall game play for the whole campaign of modules. As a consequence, I have had the opportunity to improve the code around journal updates, fix a minor auto-pause issue and improve overall efficiency.

These are all relatively small fixes to the code, and so I am holding back on any further module one release for now, and to also allow my wife to test these alterations before going public with it. It may even be that unless a critical problem is found that demands immediate attention, that the next release will not become available until the full release of module two anyway ... or perhaps when I am confidant that the changes are safe to release at any rate.

Chipping Away

I managed to finish another side quest, which ended up requiring more conversation nodes than I first realised would be needed. However, it was during this additional time that I learned about the conversation animations in more detail, and so it was time well spent.

I also managed to move the main quest further forward, reaching a new stage from where I can work from. This led me to working on an area where the next stage is to take place, and start to work on new conversations. The screenshot this week, however, is from a conversation I wrote last summer. Although, it does show a little bit about the "dungeon" environment ... in more ways than one.

A Dangerous Dungeon Environment?

Thursday, 26 November 2020

Episode 36: Camera Now Goes To 11!

The last few weeks since my last post have been relatively productive for me, and since that time we have also had the news that Arem (from the NWN2 Forums) has successfully managed to locate the hexadecimal locations of the nwn2main.exe to allow us to increase the zoom potential of the camera for the game. Technically, it goes much further than 11, but I hope my Spinal Tap reference has not gone unnoticed. (I have a clip to the hilarious link in my post below.) Read on for further information.

Overcoming A Hurdle

I am pleased to say that I managed to finish a difficult set of conversations that formed an important section of the main plot for moving the player forward in the game. The conversations included where the player learns of a situation, seeks what must be done and then decides what to do about it. The point is, however, this series of conversations was already being dictated by how the player had previously explored the area and what they already knew. Therefore, it involved quite a bit of logic flow checking, and even ended up needing a final potential event added to the area that had a small chance of requirement if the player had done something completely off the wall. For those interested, I even had to brush off my skills of calculating probabilities of a certain event occurring, to help ascertain requirements. My thanks goes out to Thierry (a.k.a. 4760), who re-educated me in this.

Leaving The Options In

With respect to what I say above, I know there is an argument that, as a builder, I can make the options simpler for myself with what I allow the player to do. However, as a DM from days of pen and paper (PnP), I like to place myself in the position of the player and try to accommodate as much flexibility and out of the box thinking by the player as possible. There are of course still limits compared to PnP, but if I can minimise these, I will. This last section of conversation writing was one such situation, and now that it is finished, it offers around four possible paths just for this one area of the game. Then the fun for me is watching (or hearing) how a player managed it in their game. Thankfully, I have a small group of players who I will see at first hand what they will do; and my wife, I am fairly sure, will try a number of them through various plays.

Conversation Animations

During the time of writing conversations, I also discovered some animations that failed to work reliably. After some testing, I eventually managed to narrow down those that (for me at least) appeared to work as described. However, again, having had info back from Thierry, my results differed from some of his own experiences, although he concurred there were some that gave him problems too. One that stood out to me, which I had liked to use, was the Scratch Head animation: sometimes it worked, other times it did not. The main point to note, however, is that NOT all animations work. I post my results at the very bottom of this post for information.

Overcoming A Bug!

I give as a warning to others who may do something similar ...  

If you have scripted your code to recognise a certain TAG reference, do NOT forget it! 

We all know about being careful with UNIQUE tags, but there may be others like me who may also use a common aspect of a tag to help distinguish between similar tags when applying a common aspect of code. The problem is, if you forget you have done this, it can come back and haunt you as a bug!

After my hiatus, I returned to continue building an area and added a number of "guards" that were required to fill it. At the time, I was using a standard "alb_npc_xxx" to help distinguish the various guard types. However, I had forgotten that I use the "alb_npc_" section of a tag to distinguish between specific and unique proper NPCs. So, when my code spotted one of these generic "guards" with the prefix, I ended up with some very strange results that were tricky to track down. E.g. One guard of a group of sleeping guards refused to sleep. (Insomnia I guess. 😏) Tracing the fault back, I discovered the guard had lost the variable that told it to sleep due to its tag making it have other code fire beforehand. What made this more difficult to track was that after this particular piece of code fired and prevented the guard from sleeping, it no longer fired for any other guard. i.e. The problem appeared specific to the particular guard, but turned out to affect any and all guards that had the wrong tag, but only the first ever one the code found.

The end result: I had to go over a number of areas re-tagging the erroneous guards and then also correcting all way points, triggers, conversations and scripts that referenced these tags. The good news is, while a pain (because each change also forced me to have to restart the toolset because it does not like such in area changes), I have now fixed that and can continue. And so finally ...

A Camera That Goes To 11 (At Last)

OK, for those that don't know the Spinal Tap clip, here it is ... Where have you been?

The real news, however, is that we can now go just that little bit further out with our camera zoom angles within NWN2. It has been a long time coming, but thanks to Arem (of the NWN2 forums), we have been blessed with the hexadecimal information we needed to apply this hak to the nwn2main.exe file.

For those that would like to do the same, here is a brief tutorial.

The Hex Editor I used was: HxD Downloaded From Here.

INSTRUCTIONS

Preparation:

  1. Always check any downloads for viruses before usage.
  2. Understand where you install a utility and access files. Install the HxD if you do not have it.
  3. Always backup any files you are working with. In this case nwn2main.exe.

Working with a copy of nwn2main.exe using HxD:

  1. Copy nwn2main.exe to your desktop to work with.
  2. Open HxD and open the nwn2main.exe copy on your desktop
  3. You will be presented with a lot of numbers and data in a window.

The hardest part when working with a editor is finding the part among the data you need to edit. The two sections we need to edit have been presented to us by @Arem as hexadecimal numbers:

  • For the height of the STRATEGY (default 25) the area to edit is located at: 572818
  • For the height of the EXPLORATION (default 22) the area to edit is located at: 580D64

I have personally set mine to both 35 as a test for the time being.

The simplest way to find it is as KevL points out (if you use HxD) as we both appear to do.

Long Explanation: The column presented on the left of the editor only shows you where different sections of these blocks of data begin. If it was in decimal, it is akin to showing 10’s, as in 10, 20, 30, 40, etc. Therefore, to continue the example and to look for say, 45, we would need to look for the 40 in the first column and then move along the row five places to reach the 45 position. In this case, however, the numbers are made slightly more difficult to read intuitively because we are using hexadecimal rather than decimal.

The easiest number to find is the 572818, because we can look for the column 572810 and then along until we reach the ninth location (including the zero offset), the one we want. (Note: These are called “offsets” and begin at “0”) NB: HxD shows the actual point you are at in the bottom left hand corner, so you know when you are the exact spot you need to be.

Here is the screenshot of where you should be for each place. Note the values on the right hand side of the images. These are the ones you need to edit to the value you want.

  

Once you have changed them, save the file and use the modified nwn2main.exe instead of the original.

KEEP THE ORIGINAL IN A SAFE PLACE!

And Finally!

Finally, and for an added bonus this week, I have three screenshots to leave with you, although all of the same image. The shots are from a new area I have started to work on. It is not "new" as in an additional one, but "new", as in I have finally reached the stage to work with it properly.

The three images, however, have been taken using the new camera angle settings I have with my game now ... one from each of the camera angles, with all now set at 35.

The differences to the normal setting may not be obvious or hard to tell from these shots, but I hope the view they give helps you to see how flexible the depth is even at the level of 35 in each case.

Camera: Character Mode

Camera: Exploration Mode (35)

Camera: Strategy Mode (35)

BODY ANIMATIONS TESTED ON MALE ELF:

NB: By “WORKS”, I mean it provided an animation of some sort, but may not be of much use. Some marked “FAILED” occasionally worked, but maybe only once and then not again. Most did nothing at all, BUT may work with other creature models.

ACTIVATE - FAILED
ANNOYED - FAILED
ATTENTION - Appeared to keep raising shoulders. (WORKS)
BARDSONG - FAILED
BORED - FAILED
BOW - WORKS
CHUCKLE - WORKS
CLAPPING - WORKS
CONVERSATION_ANIMTYPE_TALK_FORCE03 - WORKS
COOK01 - WORKS
COOK02 - WORKS
CRAFT01 - WORKS
CURTSEY - FAILED (May work on a female NPC.)
DANCE01 - WORKS
DANCE02 - WORKS
DANCE03 - WORKS
DEJECTED - WORKS
DRINK - WORKS
DRUNK - WORKS
EQUIP_WEAPON01 - WORKS
FLIRT - WORKS
FORGE01 - WORKS
IDLE_MELEE - FAILED
IDLE_MELEE_RAGE - FAILED
IDLECOWER - WORKS
IDLEFIDGETDRUM - WORKS
IDLEFIDGETFLUTE - WORKS
IDLEFIDGETGUITAR - WORKS
IDLEFLUTE - WORKS
IDLEGUITAR - WORKS
IDLEINJURED - FAILED
INTIMIDATE - Appeared to put back shoulders. (WORKS)
KNEELDAMAGE - FAILED
KNEELDEATH - FAILED
KNEELDOWN - FAILED
KNEELFIDGET - FAILED
KNEELIDLE - FAILED
KNEELTALK - FAILED
KNEELUP - FAILED
LISTEN - WORKS
LISTEN_INJURED - WORKS
MEDITATE - WORKS
NOD_NO - WORKS
NOD_YES - WORKS
PLAYDRUM - WORKS
PLAYFLUTE - WORKS
PLAYGUITAR - WORKS
POINT - WORKS
READ - WORKS
SALUTE - WORKS
SCRATCH_HEAD - FAILED (INITIAL SOMETIMES)
SEARCH - FAILED
SHRUG - WORKS
SIGH - FAILED
SIT_DOWN - FAILED (SOMETIMES WORKED)
SIT_DRINK - WORKS
SIT_EAT - WORKS
SIT_FIDGET - FAILED
SIT_IDLE - FAILED
SIT_READ - WORKS
SIT_TALK - WORKS (Looks good for seated talkers.)
SLEIGHT - WORKS
STEALTH_IDLE - FAILED
TALK_CHEER - WORKS
TALK_FORCE - WORKS
TALK_FORCE02 - WORKS
TALK_INJURED - WORKS
TALK_LAUGH - WORKS
TALK_NERVOUS - FAILED
TALK_NORMAL - FAILED (Nothing to show anyway?)
TALK_PLEAD - WORKS
TALK_SAD - WORKS
TALK_SHOUT - WORKS
TAUNT - WORKS
TIRED - WORKS
TOUCH_HEART - WORKS
UNEQUIP_WEAPON01 - WORKS
USEITEM - FAILED
VICTORY - WORKS
WAVE - WORKS
WAVE_SHORT - WORKS
WILDSHAPE - WORKS
WORSHIP - WORKS
YAWN - WORKS

Monday, 9 November 2020

Episode 35: Back To Althéa! (Predestinated Days)

After my few months hiatus to allow me the time to deal with moving home and settling in, I can now report that I have now managed to pick up the NWN2 toolset for the first time in months to allow me to return to building module two of the Althéa Campaign! I must confess that finding my feet again was difficult - not so much on how to work with the toolset, but how to get back into the story. Read on to hear of my return to the build ... 

Where To Begin?

The hardest part for me to do, after simply loading the campaign, was to remind myself exactly where I could jump back in. As I have stated in the past, returning to a build after leaving it for some time is difficult, and after a life-changing event like I experienced, this has been even more difficult. So, without a doubt, this first session back has been slow and involved more to do with reminding myself of the various plot lines as much as anything else.

However, here are some tips I can offer other builders that may be helpful, as they helped me: If you have kept track of plot lines via the journal, then open that and start to read over those quests and plot lines that will help to give the overall feel for the various plots and design. Secondly, hopefully you will have some paper notes to refer to as well (like I have) and browsing over those at the same time will start to help refamiliarise you with the module again.

A final tip that I found very useful is to load up one of the latest test saves and jump straight into simply playing the game from where you were last working. After a few conversations or running around the latest area, you start to notice aspects of the game that need some work, and before you know it, you are tinkering with the first minor aspects of the module, which gradually unravel and lead you into the code and conversations that need addressing.

What Did I End Up Working On?

Let me confess that upon initial return I did not follow my own tips above and thought that just jumping into a smaller area to start again would suffice. Simply put, this did not work! I found myself at a loose end not knowing at what stage the player was supposed to be, and how the area fitted into the overall story arc. However, after I applied those steps above, I found myself wandering back to an area of the mega-dungeon I had started work on a few months back.

Yet, I did not jump into area design (as I first thought I would do), but went to finish off a script I traced I had been working on, and to fixing other sections of code that I discovered had some conflicting tokens. By the time I started addressing this area of the module, I began to find my pace again, and although still stilted initially, it became easier as I slowly started to become familiar with the various aspects of the system I had designed for the mega-dungeon.

Small Steps

It's the first small steps I have taken in a while, but I hope as the days go on, and my wife and I become more settled in our new home, that I may be able to achieve a better pace, where I can start to finish off various areas and move ever closer to making the second module release a possibility. Even in the small sections I did manage, I was reminded how much I am looking forward to this module's release. I hope it will be better than my first, simply because my skills are better than when I first started. Furthermore, I am excited about some of the new mechanics I have set out for it.

Anyway, the toolset has now been re-opened ... I have started to find my way around the module again ... and I hope that all being well, more progress will now begin to take place. And for those that like a screenshot, here is one from the area and an object I was working on today ...

A Strange Rotating Black Crystal!

Tuesday, 14 July 2020

Episode 34: Overcoming Building Delays

UPDATE: I am having to take a hiatus for a few months due to real life issues. Hopefully, I will be able to update again around November time.

Things have been a little slower on the module building for me of late, simply because of real life demands. I have still been making gradual progress, but nowhere near as much as I would have liked. The brevity of this report will reflect this ...

Juggling The Story

One of the most frustrating time dumps (for me at least), is when I have had to take a break from module designing and then come back to it, only to have to go over my notes and code to catch up with where I last left it. It takes me time to work out what stage I had written some of the conversations with respect to the overall plot.

This happened on my return to the module this time around and I had to refamiliarise myself with the systems I was working on and how they interacted with the story. In module two, the player is going to be introduced to some new mechanics that tie heavily into the gameplay. Therefore, to make it work well, the systems and conversations all have to work together to make one practical whole. Thankfully, I have finished these main mechanics, and now it is the case of integrating them into the areas in which they are involved and finish some conversations that help to inform the player through NPC interaction. Believe me when I say, this sounds much easier than it is to implement, simply due to trying to accommodate potential player actions and choices.

One Area At A Time

To help me overcome the issues I am facing above, I decided to approach my building style a bit differently than previous, in the hope that it will help me when returning to building after any future small breaks. To this end, I decided that I am going to try to focus on one area at a time. That may be how people do things already, but for me it is a change, because previously, I used to follow the main plot through various areas until completed, and then finish off accompanying side quests that had come out of the main quest. The problem this time around is that the side quests are much more involved and integrated, and so, at the moment, I find myself following about three paths. It is quite fun to build this way, as it offers diversity for me. However, switching between them is when I have to add extra time to recall what stage I was at for that story line.

How dealing with one area at a time is going to work out (or not) is still open to question. After all, plot stages being addressed in one area are subject to plot stages set in other areas. I intend to add placeholders for these journal entries now, instead of working my design with them as I go, so it will be interesting to see if this works out. The advantage of working an area at a time (especially when it comes to a tighter story line), is that I can focus on all the details for each area as I work with it, as opposed to come back to half finished areas and try to consider elements for it that complement its design so far. Basically, the style and flow of module two requires me to have to reconsider how I can approach its design to make it easier on myself, and avoid wasting time going over my own notes.

Other News

Soul Shaker is undergoing one final play through by a couple of testers. Once one of them has completed their run, and if there are no further issues, I will upload the revamped Soul Shaker v2.00. I have not yet had to make any more fixes for it in its latest testing, and so I think it is probably stable now, but I will wait until the final play. This is why I am back to working on module two of The Scroll - where I did happen to notice a couple of minor issues as I worked on it. These issues were so minor, however, that the latest release (v1.35) was considered an optional update. It addressed lighting for some conversations, player name feedback and some chat text. All very minor fixes, but hopefully the last before I upload for module two. Time will tell.

The screenshot this week, is just another shot for the latest written NPC conversation, which again demonstrates the new PC background options that are available in some conversations ...


The Heroes Enter A Room Uninvited!