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!