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 52: MP Considerations! (v1.50E News!)

It's been an unusual couple of weeks since my last update; mostly due to play-testing the campaign in multiplayer mode (MP). It has been a long while since I have tested the code in this area, and I apologise to any players who may have been trying to play in a co-op game, as there were a few glitches that needed addressing, especially with some conversations and, in my opinion, some awful area loading times. Anyway, this week's blog is all about MP care and attention, and the up and coming v1.50E! Read on ...

MP Conversations

One of the first elements that builders have to consider in a MP game is when players may or may not be speaking to an NPC and if that conversation is relevant to all players as a plot conversation. After all, it can be boring for another player to sit and wait if there is quite an important story conversation going on elsewhere with another player. This is why we have MP conversations, which involve all players. However, problems arise when certain NPCs can be both vendors (or independent NPCs) and potentially involved in a story conversation as well. Designing a conversation to switch from one style of conversation to another (SP-MP) depending upon when the player speaks with them (and what stage of the plot we are at) can be quite involved.

Unfortunately, in some of the later module releases, I had updated the system to allow for this kind of MP interaction, but the logic was around the wrong way. It was prioritising MP conversation over SP ones, which meant whenever a player spoke to one of these types of NPCs with multiple potential conversation lines, then other players could be kicked out of what they were doing, for no reason! In latest testing, this quickly came to light and I have now reset this conversation to work the correct way. Thankfully, there are only a few of these in the first module, and can normally be navigated anyway. The latest update, however, removes unnecessary interruptions. Coming in v1.50E I have also added some gaming info in some lines so players will know if a line they are about to chose will start a MP link. See this week's screenshot. I will use my discretion as to when best to notify the player, as sometimes the MP link will be automatically done anyway.

MP Area Load Times

Another aspect that quickly came to light in latest MP testing was the (in my opinion) unreasonable load times for some areas. I also discovered some old database code that added to the confusion at times, and could cause even longer delays. The old code has now been either deleted or updated to work as intended, especially with the next modules, and I have taken time to try to improve area load times by taking a closer look at what was causing the delays. I have posted a summary of my findings and how best to prepare for MP area load times below. The calculations are still "work in progress", but are reasonable enough now to give an indication of area load times for MP games according to how many and what type of objects are in an area.

I decided to work along the lines of a maximum of 30s per area load if possible, by altering both my own scripts for area objects and transition objects, and alter area designs accordingly if they were not overly compromised by doing so. Some aspects, like the number of clients in a game, I could do nothing about, but overall, I like to think the alterations have been most beneficial. However, there may be one or two areas (I am still working on them at this stage of writing), which may take longer to load, as they are much bigger and by their nature hold more objects. But, in such circumstances, the slightly longer load times may not be so much of an issue, because they are designed in such a way that the players have no need to leave them again for some time. Therefore, the overall area load time versus the amount of time they spend there is worth the extra few seconds wait. My key aim with this exercise is to ensure areas that are often revisited do not take more than 30s if I can help it, and am aiming for less wherever possible. (NB: In a SP game, these take only a few seconds, around 4-6 only.)

Module Two

I know some may be disappointed at the lack of latest news regarding module two, but I hope you can see that these improvements to the MP environment in module one, also ensure module two goes smoothly. Admittedly, those who only play SP are less affected, but rest assured, when I sort this kind of thing out for a MP environment, the SP aspect also benefits. Also rest-assured that in most circumstances, SP gamers will not notice any difference to gameplay with these changes (apart from a very eagle-eyed player who can spot even the slightest change), as any more noticeable gameplay changes only affect the MP game due to the requirements the MP game needs different to a SP game.

Hopefully, in my next post, I will be able to bring you some extra news regarding the progress of module two. MP testing will be well underway by then, and normally, once past the starting line, things normally settle down, and allow me to get back to plot writing. One thing I will need to address in module two straight-away, are the conversations like these, and check out the area objects! Whatever happens, I will keep you posted.

v1.50E News!

On a final note, some of you may have noticed I have withdrawn module one (v1.41E) until MP testing is completed. You may also note that the version jumps from v1.41E straight to v1.50E. This is because v1.50E has had some changes that will not be backward compatible with v1.41E and below. Trying to ensure backward compatibility is extremely difficult when I am trying to move forward. Therefore, rather than spend too much time trying to accommodate earlier versions, I announced the potential issues and left it a couple of weeks before withdrawing the previous version. However, I hope the extra wait for the latest v1.50E will be worth it, as it comes along with a couple of exciting updates such as an (i) improved journal, (ii) fast map travel and (iii) lip syncing on NPCs, as well as a number of fixes that will benefit all, like one-use items that stay in the quick-slot upon buying or finding more.

Demonstrating The MP Conversation Link

Area Load Time Investigation Summary

SUMMARY

In Summary, this is what I believe is worth considering when designing areas for a MP environment …

MP GENERAL

1. Each creature in the party adds load time. (Remove summons etal before transitioning.)
2. Each client adds load time. (Around 2-3s and is unavoidable.)
3. Area enter scripts add little time, but no more than a second or two. (Irrelevant.)

MP AREA SPECIFIC

1. Each creature already in an area can add a fair amount of time for a MP load. (0.25s each approx.)
2. Placeables with dynamic content creation may also add more time for a MP game.
3. Any objects created in an area (via scripting) add towards the total load time. (Remove prior leaving.)
4. Next, VFX are more time consuming than most other area objects because of the number used.

The bottom line is really the number of objects(*) in an area affects the MP load time, including any dynamically created during loading. Therefore, be sure to only create objects after the On Client has finished loading and be sure to remove them before exiting an area (and recreate again at next entry if still required).

(*) The objects that appear to do so more than any other are: creatures, VFXs, and placeables with contents. In testing, environmental objects appeared to have little impact, even when running into thousands as in Tsongo’s area.

SP games are much more forgiving and compared to MP environments can probably be ignored by comparison. However, as a guideline, I would offer these figures and guidance for MP area creation to best minimise load times for MP games to under 30 s.

1. Spawn constant area creatures after On Client load finishes and despawn on area exit transition.
2. If many, do the same with utility placeable objects, such as “weather units” in my own module.
3. Keep VFX to under 120. Keep inventory placeables under 40. (Non-scripted appear little impact.)

Doors, sound and light objects also appear to have a very small impact, but not enough to worry about unless you use a lot of them. Just compare your overall usage when considering these objects with relation to other objects used. For instance, if you do not use any VFX, then you can get away with a lot more sounds and light objects.

From following these steps, I reduced one area MP load time from 78s to 30s!

MP Load Time Guesstimate Formula

BASE: (# Player connected x 2.5 + # Additional Party Members (inc associates) x 1)
AREA: (# Creatures x 0.25) + (# Doors x 0.06) + ((#Sounds + #VFX) x 0.08) + (# Lights x 0.04)
VARIANCE: (#Placeables x 0.06 - 0.25 Subject to scripts attached.)

FINAL LOAD TIME = BASE + AREA (+ VARIANCE)

EG: My Area (With Host Only):

HOST: 2.5s + My Entry Scripts (2s) = 4.5s

• Area Creature Objects (15x0.25) = 3.75s (*)
• Area Door Objects (17x0.06) = 1.02s
• Area Sound+VFX Objects (120x0.08) = 9.6s (**)
• Area Light Objects (55x0.04) = 2.2s
• Placeables (Lowest = 34 x 0.06 = 2.04 TO Highest = 34 x 0.25 = 8.5) (***)

( * ) Using default scripts may lower this value.
( ** ) Actual VFX used in area will alter this slightly.
( *** ) Use lower value where no scripts or inventory used.

MP TOTAL LOAD TIME = 21.07s + (2.04 - 8.5s) or 23.11s - 29.57s

In practice, this example area loads in around 24s with just the host.

CAVEAT: Testing is by no means complete and these figures may be subject to further changes.

That’s as far as I have tested for now, but may add more info as time goes by. Again, my thanks goes to KevL and Tsongo for helping look at this with me. 

UPDATE: Script with latest timings .... These are seconds allocated per area object:

// OBJECT LOAD TIMES (CHANGE AS EACH TEST IMPROVES)

float fCREINV = 0.07;    // CREATURE WITH INVENTORY
float fPLCINV = 0.15;	 // PLACEABLE WITH INVENTORY
float fPLCUSE = 0.24;	 // USEABLE PLACEABLE
float fDOORS = 0.11;     // DOORS
float fVFX = 0.05;       // VISUAL EFFECTS			
float fLIGHTS = 0.1;     // LIGHTS

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 50: A cRPG About 3rd Edition PnP D&D!

Those who have known me for some time will know that my RPG interest stems from a PnP (pen and paper) AD&D background. For me, NWN2 offered the best way to get AD&D PnP scenarios into a cRPG environment. Importantly, it offers an excellent interface that allows individual companion possession as well as encouraging multiple players to team up and play a game together. For my own campaign, there was still a lot of work for me to do with respect to improving the MP coop environment, but at least the core program was flexible enough to allow me to transfer from one medium to another. Over the years I have been doing this I have noticed other builders use NWN2 from quite a different angle. My observations follow ...

THE CORE REQUIREMENTS

Turn-Based Combat System

When I first started designing The Scroll, (using NWN1 at the time) my initial modules were created around a completely unique true turn-based combat system that I spent a long time coding within the NWN1 environment. It involved individual players controlling their own mannequin, which in turn controlled every PC they owned. Through this system, as DM, I was able to control the combat in a true turn-based system, which allowed DM and players alike to take turns according to when the next creature's initiative came along. Of course, when NWN2 came along, which allowed the instant switching between PCs for players, the mannequin concept I had developed could take a back seat if we were prepared to play a pseudo-turn-based system: where all players and DM (or AI) assigned their actions at the same time for the up and coming combat round. To me, the newer NWN2 approach offered greater benefits for us, not only as it meant I would not have to edit every spell to work in a true turn-based system, but it reflected a more "real" response in a combat round. (The spell editing was something I had started with NWN1, but stopped when the decision was made to switch to NWN2 when it came along.) Another benefit of moving to NWN2 was that it meant I could create the campaign for a larger audience, now allowing the new turn-based system to be merely an option for any new players that may like to play my campaign using tactical turn-based combat.

As the years have passed, however, I have seen less and less interest in some of these key elements of gameplay of which I hope to cover here: tactical turn-based combat being near the top of what appears to me a wave of "old ways rejection". I hasten to add this is not the case for myself or my own players, as we still very much like to play a combat using a character by character assignment in every encounter! However, I think there are other elements of which I hope to cover below, which have also taken a hit to inclusions due to changes in attitudes. I will approach these as I believe they have impacted the gameplay.

Resources: Rest and Recovery

Much of what governed the way a D&D module played in the PnP days was as much about good player management of their player character (PC) resources as anything else. Timelines, equipment, spell uses and hit points all mattered! I know there may be those who would argue they still do, or maybe there are others that will argue they are glad that such aspects of play no longer matter. My argument, however, is that while I am quite keen to see changes to mechanics that add interesting elements of gameplay, I am saddened when (in my opinion) elements are broken, or simply removed altogether. To me, it matters because such changes also break some of the key gaming aspects of a role-playing-game (RPG), especially with respect to the spirit of a D&D module.

Even the official NWN2 campaign suffered from this when players are allowed to rest almost at any time and anywhere. A simple pressing of the "R" key to rest and most (normally all) ailments, hit-points and spells are fully recovered. It becomes such a farce that it begs the argument of even having any "usage" for such recovered elements of play at all! Furthermore, once these kind of resources "no longer matter", such things as tactical combat (pause and assign commands) becomes meaningless, as we may as well use all our best resources against any foe because the moment the fight is over, we can just recover everything! It's no wonder that players today do not appreciate the more tactical side of playing a D&D combat. Basically, it has changed from players carefully considering their "limited" options to ensure they progress both in story and character as a team effort, to one of a fast solitary mega-build to compare their PC builds to their fellow players. Just look at the way coop games have declined over the years. I am referring to true D&D party coop and not large MP worlds.

The Timeline

The alteration of or even complete omission of a timeline also has damaging repercussions, albeit more subtle than that mentioned above. For while "free resting" is an obvious abuse of a timeline, it is made worse if left out altogether. When playing an RPG, events are occurring, and normally within a time frame. At the very least, even if no actual calendar is used, the world should reflect changes in light from night and day, even if scripted to do so if not through actual time passing. Otherwise, again, the player is no longer thinking about the resource of time and how that may have an impact on what they need to achieve. 

Basically,  the more we remove aspects like the importance of time and resource management, we are moving away from the RPG and into the realm of an "adventure game". There is nothing wrong with an adventure game, for I have played many and still enjoy them now. My point is, however, as the years have passed, I have noticed builders, even of AAA "RPGs" steer away from these traditional core RPG gaming elements.

Suspended Realities: Items & Encumbrance

I believe there is a difference between a fantasy game that considers resource management and one that does not. I have already mentioned the effects of some of the more obvious resource management issues to do with combat, but there are others that I would like to mention here too, such as encumbrance. Once again, I know the arguments used with such a game mechanic, but to ignore it completely (or even partially) can (in my opinion) imbalance a game. If you allow any PC to carry any amount of equipment (including gold), then one of the benefits of having strength among the PCs becomes less of an importance. The point I am trying to make, however, is that when too many aspects of gameplay mechanics are ignored, then we move away from the player even considering what they carry. Anything and everything becomes a viable item for the pack-rat that such a system encourages, leaving any items of importance just another bauble in the avalanche of "prizes". Personally, I believe the game is already over-generous with the strength allowances it gives. My preference, however, is to encourage an environment that gives value to finding a bag of holding or at the very least has players recognise the carrying capacity of a low strength PC. This is why to this end, I ensure gold does weigh something in my campaign.

The Economy

This brings us nicely to the economy of a world. I am the first to admit that balancing such is no easy task, but a clear game-breaker for any resource considering world has to be how common certain items are found in a world. I understand that certain items are necessary to help a world move along, but the value of a fantastic item is truly lost if every other vendor carries the next best thing.

IN CONCLUSION

I was going to consider some other aspects of gameplay that reflect a spirit of D&D, but I believe if the core concept of managing resources is understood as a vital distinguishing mark, then other aspects such as archetypal classes and NPC interaction also fall into place. I hope I am not alone in my observations, and that others also would like to reclaim some of those elements that have fallen by the wayside with time. Or perhaps I and others like me, are now a dying breed. Maybe the RPG has moved on to those who have better dexterity (for real), and don't really want to know about role-playing an avatar in a world where tactical choices beyond a bigger and better sword or spell matter, as long as they can beat the next creature that comes along and grab its massive horde. Please understand that this is NOT a complaint about any specific choice or style of play, but at worst, a lament for a kind of "depth" to a game that appears to be no longer in fashion. What about you?

MODULE 2: PREDESTINATED DAYS

For those interested, Predestinated Days will be written and designed in a style as close to PnP 3.5E AD&D rules as I can achieve, with some of my own additional mechanics that reflect the current world setup and main plot. This means you will need to consider resource management, and have the option to switch to turn-based combat if you need to, to help manage your resources. You will have to consider what PCs you have in your party to help manage all those situations you may find yourself in, but will also have the flexibility to adapt to the situation with any PC if you take time to learn about the world. You will face different creatures with different backgrounds and goals. You will come across difficult locks that only the best at lock picking can crack. You will also encounter puzzles to test your mental agility, and characters ready to test your moral fibre. Think D&D with an AI DM at the helm, as you will not simply be able to kill your way through the game.

But, you will not be left without the means to succeed. You can only fail if you lack the ability to manage a party of PCs both carefully and wisely. It's not a casual game, although you can certainly make it a lot easier by dropping the game options where I have taken care to allow easier foe and puzzles, but even with such adjustments, the player NEEDS to make careful decisions. It's a true traditional D&D game (as close as I could make it), based on a PnP campaign, including some of the original paper written dungeons, that will have you having to stop and think at times. If you have ever played PnP D&D, then I hope you know what I mean ... otherwise, unless you like a challenge beyond input device twitches, then maybe it won't be for you. ;)

Below is an original image of a city called Southstrong from my PnP campaign, of which some areas will be used in Predestinated Days. The two images below the map show a tavern from that city, and a thief attempting to pick a lock. (GUI improved from the first module to work on chests now.) NB: The option to switch to a NWN style pick lock is also available on the GUI.

Original Pen And Paper Map Drawing of Southstrong

A Tavern Within The City of Southstrong

Chest Demonstrating the Lockpick GUI

 

EPISODE 50: UPDATED VIDEO FOR THE SCROLL

Episode 49: Traditionally Different. (PnP Conversion.)

It always seems to happen: Just when I think I have all the areas I need, or think I know what remains, another area requirement arises! It all started when I was looking at adding a couple of small scenarios to do with a city the PCs will find themselves travelling to. I had my core storyline ready, but the city was not quite spacious enough to cater for the two old PnP conversions I wanted to add. Read on below ...

Pen and Paper (PnP) Conversions

I have some PnP modules that I wrote over 20 years ago, which I have always wanted to preserve by including them in my NWN2 campaign. Strictly speaking, these modules have already been "played" in the timeline where the player can first encounter my campaign in NWN, but because these modules are so far in the past for the campaign (and especially my players' memories), I can add a little poetic licence and repurpose them in this latest module. The modules original location, (the city of Southstrong), and plots (one an undead mystery and another a murder case) will remain relatively unchanged, but will be modernized to be included within NWN2. 

To this end, I recognised that I needed to add another outside area. To save time I managed to find an official  NWN2 area that with some tweaking fitted my purposes well. (I will keep it secret and see if anyone recognises it at the time.) A couple of this weeks screenshots show some of the new parts. Of course, the issue now, however, is that now that I have made a new outdoor area, it's going to require some new interiors too. I reckon it will be worth the extra time though! It's been great reading over old notes and trying to see how I can integrate them into the module with improvements. Most of all, I hope they will be fun for a new and larger audience too.

Reworked Scripts

As I am currently working with city environments, it means I have been able to take another look at some of my very earliest scripts that are used when players interact with NPCs that duplicate some of the things I have already coded. Again, I find myself improving some of these old scripts to be able to better cater for the gaming environment. A simple example is when catering for a bard who may wish to perform at a tavern to earn a few gold coins. In my first module, the player had to manually switch between PCs to reach the bard to make the request to perform. Now, as long as the player has a bard in the party, the option will become available. This appears a minor detail, but has a knock-on effect, as it means I can now use a cutscene conversation style with the conversation in question, which in turn, means I can switch from a MP cutscene to a SP one seamlessly. This is a great improvement to the conversation style that helps accommodate both a SP and MP environment when a conversation needs to be seen by all players, but only for some aspects of that conversation.

New Objects

To go along with the new areas, I have also found myself designing new signs and notices, based upon great work already in the community, including that done by RDS and Topoun. The signs and notices are my first steps towards my PnP conversion. So, alongside new NPCs and areas, replete with their own new adventures, all I can really say without giving too much away at this stage, is that I have (at last) started to fill a large section that fell between two sections I had already made large headways into. Admittedly, I still have many areas that have been started with work remaining, but completely untouched areas are becoming fewer, and the plot lines are starting to bind together at last. It is a satisfying feeling and one that arguably suggests the beginning of the end is in sight. But, I don't want to get ahead of myself, as there is still much left to do. I just wanted to share my latest projection with you.

Bloodstone College

Something Has Broken Out!

Southstrong Market -  Demonstrating NPC Detection Facility

Episode 48: Tell Me About Yourself! (PC Backgrounds.)

Predestinated Days is intending to offer more conversation options to the player subject to the various backgrounds that they allocate to their PC and companions or other created PCs. Furthermore, as I wanted to support exported PCs from other games, as much as my own first module, allowing the player to add a PC background retrospectively was important to me, so that's what I did. Read on for more details and other news ...

PC Backgrounds

One of the big areas I have been dealing with over the last week or so is building a GUI to allow players to quickly and easily work with a PC's background. Normally, this is a "feat" option that is only allowed for Created PCs from the start of play. I believe a builder could also pre-allocate a background "feat" personality for potential companions, but unless this has been done, then this "free" feat, which generally comes with pros and cons for taking it, is often not used. However, with the new GUI, a player need only right-click on their character sheet portrait and an option to add any missing background can be achieved. (See this week's screenshot below.)

In this case, I believe having a PC background to be a very useful aspect of play that both players and builders can put to good use, especially when role-playing a particular PC within conversations. For while we all generally like to play our PCs certain ways, having some background guidance can go a long way to help steer this gameplay. Take for example a PC who is a bit of a "flirt" compared to one who is more of a "bully"; they would tend to approach a conversation rather differently to one another. Therefore, while it is important for the builder to be able to provide a useful selection of options, having some stereo-typical background types can also help us to add "colour" the conversations too.

There is an argument that this may make our PCs appear rather two-dimensional, and I do understand that. However, compared to every conversation otherwise speaking with "one voice", then having a few core background types options thrown into the mix cannot help but make the conversations a little more interesting. To this end, I looked at the backgrounds and decided to set aside five core groups, of which the fourteen character types we have available to us fit within. Look at the following table ...

PC Background Types

A table showing how the fourteen background options split across the five core groups.

NB: There is an ERROR in this table. COMPITENT (sic) should be CONFIDANT.

How The Backgrounds Fit Into A Specific Group

When a player comes to play Predestinated Days, I am hoping they might select a PC background for each of the PCs they play, with at least one coming from each major group. If they do this, then when it comes to actual conversation gameplay, the player should end up with one or two different options that better reflect their PC background choice. Furthermore, and to encourage such play, I give an additional XP award every time a potential role-play option is opened, irrespective of which conversation line the player ends up taking. And now, with the new GUI, even adding a PC background that previously had not one added for one reason or another, can simply add one.

Writing the conversations and taking extra care to ensure I can include some better background type choices certainly takes more time, but I hope the end result will add some more gaming depth and personal role-play for the player. So while not every conversation will have these extra lines, I hope to include them in many, especially the more important story related ones.

PC Portrait GUI

On the back of adding a new Background GUI, I also looked into the existing portrait XML, from which the new Background GUI is associated. I found a really odd unintuitive setup for selecting a new portrait, and it was clumsy to use, and so I edited that to make the whole portrait selection much more user friendly for those that like to change their portraits for their PCs.

I was also able to write a new XML that allows builders to force update a portrait on a PC for any reason. I did this after andgalf (of the NWN forums) requested such, and as I was in that area of coding and it was something I also was looking into doing, I just went ahead and did it. The end result worked for andgalf's purposes, but it did not yet do what I was after due to requiring an XML file for every portrait. At the least, it may come in useful at a later time.

World Map Travel

I also spent some more time finishing off some world map code, especially the area of code that calculated map travel speed and related times. I wanted to give the player a "real time" feedback of passing time as they travelled the overland map. This is done now and works well enough for my liking. Furthermore, as Predestinated Days intends to use all three world map systems, arranging all the various waypoint types (WP) depending on the system the player wanted to use was a task. For example, in some places a player may choose to use a MAP and jump to a location on the map, or choose to travel overland instead. Two jump types for two different scenarios. Add to this a potential portal jump option and keeping track of WPs becomes tricky, as much to ensure overland map GUIs are on or off as much as anything else.

The First Day Updates

Updates to the first module of The Scroll campaign will now be referred to as updates to The First Day, which is the proper working title for the first module. To clarify, I may still refer to my modules as The Scroll in general, as that is the campaign name, but each of the three module of which it comprises each have their own name.

Anyway, module one, The First Day, continues to benefit from general campaign improvements, including updates to the weather system (clouds are randomly scattered now subject to weather condition); a couple of open door conversations have been made more "secure" to avoid overzealous clicking by players. All these updates, as well as others mentioned in previous posts will become available in the next v1.41E release, so be sure to download it. There will also be a new module release, as mentioned in previous posts, but will also benefit from other updates of late, including some waypoint colour changes for ease of locating. E.g Exits in cyan; important point in yellow.

Once my wife has finished her latest play through, I will likely upload v1.41E then, unless there are any other alterations I want testing prior to another release.

Missing PC Backgrounds Can Now Be Added During Play!

Episode 47: Overland and World Maps!

I continue to chip away at the second module, Predestinated Days, of The Scroll campaign. This time around I have been sorting the World Map and all the links that will be available from it. The last time I looked at any of this code was probably around 2009, when I pieced together the code that would allow the player to examine maps in module one (but without travel), and in preparation for this latest module I am currently working on. In the last couple of weeks, those maps (and associated code) have been dusted off and looked at once again. Read on for the latest news ...

The World Map

This section of my campaign goes back many years, and I have a video of when I first started working with them as long ago as 2007. If you want to look at some of my first ever playing around with them, you can check out this video where I was pleased to have managed to code "map within map" change overs! (If you have played the first module, you may have seen this already.) Predestinated Days, however, will be the first module of my campaign series that will make use of them proper. I have "improved" the process since that time: the main difference being I now use the later (expansion 2) style map for normal travel and keep this original style world map for Nexus Travel.

Like most of my earlier code, I had to rewrite some of it, as it did not work as well as I required for module two. I have become more familiar with the functions since those early days, and had some newer requirements too. One observation I would like to point out for all would-be map builders, is to make sure you change the default 0 x 0 icon size, which (obviously) will not appear on your map when called via code, even after placement, as it is simply too small. I now use 16 x 16 for icon size. In my latest return to World Map usage I did not immediately notice this and so thought there was something wrong elsewhere. Once I had spotted the difference in this aspect, by comparing icons properties I had placed this time around from those years ago, things were sorted.

The Overland Map

As many NWN2 players/builders will know, the way the "world map" is presented has changed with each expansion. In the original campaign, it was a basic map interface (like the one shown in the video link above); in the first expansion, the world map interface came along with additional info, along the lines of my edited version in the image below. By the time we had the second expansion, we were now presented with an "overland map" style, where the party was represented by the leader who the player controlled over the "map" itself.

In Predestinated Days, I am aiming to implement all three systems in one way or another. To this end, an overland map has already been built and is in the process of being tested, which denotes the first areas of world that the PCs adventure in. In The Scroll, the idea is that the overland map acts as a "zoomed in" section of the actual world map, which becomes more effective later, as the PCs get to know the world better. However, to allow diversity of play, I have also allowed players to start using the static "World Map" as an option from quite early on too if they prefer to avoid the overland map style.

I had to spend some time going over the format I had setup with respect to how the map pins associated with their WP counterparts, but eventually worked out a solution that now supports the various world map policies in place. Whether the player chooses to explore the overland map or simply click on a world destination via a static map, all transitions now work as they should.

Food Rations

One of those side issues that came to light when working with world maps was the use of food rations. There was nothing fundamentally wrong, as the food count went down as expected, and apart from fixing a small "hunger" bug, the food count worked as expected. The problem was more to do with purchasing them for travel. At is currently worked, food rations could only be bought one ration at a time, which is fine if you are staying within the local vicinity. However, as travelling now involved much farther regions, I had to up the ration count that could be purchased to ten at a time to prevent the player having to spend minutes purchasing sufficient rations for an entire party. As a side benefit, it offers a discount for bulk buying. Remember, however, if a party has a cleric who can pray for Create Food, then no ration purchases are required.

Other Updates

My wife and I continue to play test module one, testing the latest changes and looking out for any new issues that may arise because of them. A few minor issues were found and addressed:-

i) Sleep animations were re-timed to ensure the player does not see the NPC fall to sleep.

ii) Crafting was fixed to ensure correct gold bags remained and essences used.

iii) An EffectListOverFlow was fixed related to the encumbrance icon on PCs.

iv) An ActionListOverFlow was fixed on relocated NPCs who used walkwaypoints.

As previous, once my wife has finished her latest play testing, v1.41E will be uploaded, which addresses any issues that were present in earlier versions. NB: Not all reported issues may be present due to changes made since last release.

NOTE: The following images have changed since being taken and have spoilers removed.

Viewing World Map In The Toolset

 

Viewing World Map In The Game

A New Place - A New Role!

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 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!

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!

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!

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!