Choose Your Language

Friday, 31 May 2019

Episide 5: What's Over There?

Now that I have taken the decision to stop further testing of v2.65 of module 1, I have been able to become more involved with developing module 2. (By the way, for those interested, here is the link to module 1 of The Scroll. NB: I will continue to upload a newer campaign version if I find any glaring issues with v2.65.) My latest toolset activity has been focussing on a new area that (originally) was not going to be in the module, as I initially considered it would be of little to no interest. However, as I looked at the area map I was currently working on, I kept on wondering exactly what was going on over in that "interesting looking place" on the map. And so I eventually concluded that if I thought that, then other players may well have their curiosity piqued too ... and so went ahead and designed the linking area required. The screenshot today is the loadscreen for the new area.


The last week has been all about area building ... and I had to remind myself of all those aspects needed to build (what I believe to be) a "believable" area design. I am the first to admit that my art design skills in this department are only adequate. However, I do like to think that I put enough thought into other general aspects of area design, such as lighting and sounds, to make an area a cut above the average. Basically, I like to include aspects that give a place a degree of atmosphere, which lighting and sounds (if used carefully) can transform an otherwise dull area, into something quite interesting.

1) LIGHTING: You will probably have a vague idea of the type of area I was building from this week's screenshot. However, I am deliberately skipping specifics to prevent spoilers, and even the screenshot may leave the reader with questions. However, the point being, I like to vary lighting according to the type of area the PCs find themselves in. And, the working line for me is, if there is no light at all, then it should be absolutely black! i.e. I try to avoid using any lighting that does not have a source. Therefore, each area I design must come with its own selection of light sources, or the PC must provide their own light via torch, lantern or magic.

The light source objects are dictated by the area type. If it's a natural environment, like a cave, then I tend to go for glowing flora or (if inhabited) wall torches, or even a combination. i.e I try to avoid man-made (or spell-like) light sources unless they can be justified. The main point, however, is that every area should (in my opinion) be able to be lit or placed into darkness according to light sources within the area. Being caught in complete darkness should be a possibility in some situations, and the player should be conscious of this by observation of the area lighting.

2) SOUND: Another aspect of design and probably just as important as the area lighting, are the area sounds. After setting the lighting, I tend to move on to adding the sounds, including the music and ambient sounds. However, I believe it is the positional sounds that go a long way to helping the player feel immersed within their environment. These can include simple sounds of water (pouring, dripping, splashing, etc), and critters running out of sight. I even try to include sounds that may alter with time or player interaction such as camp fire crackles or claps of thunder and rainfall. This latest area came with its own selection of sounds, which I hope should all add to its mystery and allure.

3) INTRACTABLE OBJECTS: Having setup the area lighting and sounds, I always like to add an interesting selection of objects for the player to interact with. This is what gives the current scenario (or area) the "meat on the bones" as it were. Note, these objects will vary from area to area, but are normally well understood by the player, and include such things as junk piles, bookcases, and chests, etc. However, I also like to use this time of area design to try to develop something "new" if possible, even if it's just a minor interaction. This "new" object would then be added to the collection of objects I can continue to flesh out future areas for the player to interact with. Over time, the collection of objects with which the player can interact should grow bigger or have new variations of such.

4) ENCOUNTERS & EVENTS: In the course of building module 1, I have gone through many renditions of various trigger and encounter events due to the many different requirements I have needed in module 1. Thankfully, now, I have a healthy selection of them to help populate a dungeon in a way that makes combat encounters efficient and (I believe) balanced. Therefore, it did not take me long to quickly add the monster events to the area, and all I am left to do now is add some comment events as I consider what should become available to the PCs. As some of this is tied to the bigger plot, these tend to get added later.

5) BACKGROUND & PURPOSE: Once I have all the basic area design in place (as above), I like to ensure that the player also leaves an area with a feeling of accomplishment, and some kind of memory of an area. It can be a simple as having the player complete a quest stage or acquire an item of importance, or even simply have a tough fight. The bottom line, however, is I want the player to feel they have been satisfied with what they have achieved in an area. My general goal for this is: if I test the area and do not come away feeling I either learned something, gained something new, or simply experienced a different aspect of gameplay, then it has not served a good purpose. Generally, I like to be able to tick as many of these aspects with every area, but overall design determines if this is warranted or not. I certainly try to minimise those areas that feel more of a "grind" than a source of adventure.


Just for the record, I experienced an old issue of a placeable object not responding to a player's left click. To remind myself and those readers interested, if a placeable has zero hit points, then any onused script is ignored! I wrestled with a new prefab object for at least half an hour before I spotted this old issue again. Thankfully, however, even though this caused me some lost time, the benefits of building with all the existing scripts available to me helps go a long way to shorten the area build time.


So, the area that stole my attention is now "finished" apart from some final event triggers (if I decided they are required) and some plot elements that are still in development. I am happy with the way it turned out, as I have employed all those aspects I learned from my first module, including ensuring the PCs have room to move, and any combat zones are reasonably spaced.

In the coming days, I hope to go back to the original area I was working on and to look at other areas that can be transitioned to from it. In all, there are around another four areas that I need to build from scratch that transition from the area I am currently referencing. Once they are all done, I can move onto another area of the module. At this stage, everything feels quite a long way off. However, if I can continue to build areas at the rate I am at the moment, then I am more optimistic that module 2 will see completion one day.

Learning More About The Enemy!

Wednesday, 22 May 2019

Episode 4: Encountering New Monsters!

Last week had me getting to grips with the overland map again. In the process, I had to start looking at the related 2da files that covered the monster encounter information, and "goodies" that the PCs may find while exploring the map. While I did not get around to the latter, I did manage to get some more updates done on the monster side of things, especially as that is one of the first major differences that the player can expect in module two.


First and foremost, I managed to finish putting together the terrain 2da encounter tables for my overland map. It involved ensuring the monsters that could be encountered had valid blueprints, and the correct scripts attached. I have edited the way the encounters work because of the way my campaign works, but the end result is the same as a player may have experienced before: While exploring the overland map, a miniature version of a monster may spawn nearby and potentially be the source of an encounter. The monster ones aside, I now need to sort out the "goodies" 2da that allows PCs to find stuff as they explore. This is over and above other "map elements" they may find along the way; some of which may be new areas!


So once the blueprints were setup, I made sure there were various variant types available (e.g. archers, shaman, clerics, etc) where needed. However, I also spent some time going over some older blueprints removing original campaign string references both to the first name and description. This is because even though the description may appear blank, if a valid string ref remains, then that ref will be used with some of the code I use, which I do not want. I believe this may have been an oversight of the tool set design (i.e. a bug), but removing the original str ref resolves the issue. I also spent some time checking over module one for any missed there too, ready for its re-release.


Once all the new blueprints were in place for the map monsters, I decided to update the Althéa Bestiary with entries to cover some of the new monsters that the PCs will encounter. Some readers may recall that I have included a bestiary (accessible from the journal as an extra tab there), that gives an image and some extra information about a creature upon its encounter, which the player may find helpful when dealing with the monster in question. So far, I have added an extra 22 entries to an already existing set. I include a full list of the images I have used for individual entries below. I deliberately removed any naming info, to keep spoilers to a minimum. Furthermore, there is a possibility that one or two of the creatures represented by the images below may still not make it into module two. The ones that I have added to the overland map encounters will, of course, definitely be included.

Note, in the image below, "animals" of the various types are covered by their own single generic image. Therefore, creatures that would fall under such titles as "domestic", "dire" or "vermin" are not shown. Therefore, the icons you see below would represent monsters outside that description. E.g. The spiders below are not of the "vermin" variety, which would include any large or huge variety the PCs may have already met.

The Bestiary Increases In Size!


As well as general building, I have been testing the campaign further, which makes for improvements of the first module too. For example, I have improved the way spell feedback works, which in turn has helped remove some strain on the heartbeat script. Most players may not notice any difference, but I definitely do, as the PCs move more smoothly in the game now.

And on the note of mentioning the first module, testing continues, all be it, somewhat less now that I am focussing on the second module. However, because I am still finding the odd minor issue (e.g. It was possible for a cleric to enter the world with a invalid god if they imported the PC from a campaign that had their own gods.), I am allowing myself just a little more time for checks.

That time has been helpful, however, as I also discovered one or two other minor issues that I have now squashed, which will all help towards a trouble free game for the player. To end on a big plus, all those points I addressed since the last post have not caused any issues since their updating. ie. The inventory/store/transitions and conversations all appear to be working fine so far.

If there is anything you want to ask, have a suggestion, or simply want to chat about something so far, then please leave a comment.

Wednesday, 15 May 2019

Episode 3: Mapping The Way Ahead

Some of you may have noticed that v2.65 has not yet been released, as I had originally hoped to do last week .... latest early this week. However, because of the approach I have taken to module two, I decided to take a bold step and do some fairly "major" design changes, to make moving forward easier. This meant making some important code changes to the existing campaign files, including the following: (a) Inventory/Store Access, (b) Transitions and (c) Conversations. I know, it's nothing small is it! So before I explain what steps I did for module two last week, I want to say a little more why I made these other changes.


1) INVENTORY/STORE CONTROL: To be frank, this code was a bit messy, having already undergone some changes in the last beta testing to make sure it worked in a multi-player environment. Basically, it had become quite bloated with a good deal of irrelevant code, and contained an annoying "glitch", which I  wanted to be rid of: One had to click twice to compare an item in a store with existing equipment. So, the bottom line was I stripped the functions and rewrote the routine to now produce a reasonably slick system. In truth, it could (perhaps) be made slicker still, but I am quite content with the latest rendition for now ... and that glitch is gone!

2) TRANSITIONS: In the process of preparing module two, which involves transitioning on and off a world map (more on that below), I found that I also have "messy" areas of duplicated code that I wanted to streamline again. After all, transitions are a key feature of a module, and I'd rather ensure a clean set of scripts for the job going forward. Basically, many duplicated routines and checks have now been moved to dedicated functions, streamlining the code .. and, in theory, making any bug-hunting easier.

3) CONVERSATIONS: Pretty much for the same reasons as the rewriting transitions above, I wanted to make the code surrounding handling conversations tidier and more streamlined for future use. Also, I finally got around to simply placing some humanoids with the various "conversation" settings on them to try to learn how the different settings affected players in a SP and MP game. Before, it was a little hazy - even hit and miss for me. Now, I am fairly confident I know when and where to use the various options. Most interesting, I learned we can send a cutscene type conversation to a single player in a MP game, without it affecting any other players. I had always assumed all cutscenes were for all players. After learning that  ... and a few other conversation tricks, I decided to rewrite the core companion/created PC conversations, and ensure all in-game conversations could no longer be "interrupted". I also rewrote them incorporating a system that enabled all "new" interaction to switch to cutscene for all players, but remained for a single player when not required.

So, that is a lot of core changes .. and as you can imagine, is why I thought it prudent to put the campaign under another short testing period to ensure these core changes remain working for any imminent release. While these changes affect nearly every aspect of the module, I hope I know enough of the key core areas to be able to do some testing that won't take overly long ... That said, I'd rather make sure before release so players have the best experience!


I can also add that due to the changes I made to the campaign files, I found I needed to change some of the module elements too, be it simply adding or removing a "tick" from an object, or renaming a tag of an object. Suffice to say, the module has undergone some important changes as well in preparation to adding modules.


Apart from those important updates to the existing campaign code and module one, last week was about ensuring module one linked into one of the two potential entry areas of module two. One area of entry is a lobby (if bypassing module one completely), while the other is the Overland World Map if playing straight from module one into module two. It was when I was testing the transition to the Overland World Map that I discovered some of the "inconsistencies" of the tag requirements depending upon whether a player is using their own map (for quick travel) or moving straight to the Overland Map for slower movement. (Yes, there is even more than one way that this travel can start too.) Basically, the different number of options at the start for the player are what I am putting together at this stage and hence, the need to clean up those transition scripts. After much investigation, for instance, I discovered one of my tags being search for had an extra "OMWP" in front of it, meaning the transition kept failing. This opened up the can of worms that led me to tidy up the transition code!

Anyway, here is a screenshot of the overland map in operation .... Some explanation is below.

World Map To Explore!
You may be asking what is going on in the screenshot above? What is being shown? Well, a key feature of my world map system is the "Travel Information" feedback GUI. Basically, as the party move around (controlled by the lead player in a MP game), the Travel Information GUI updates as you move with all pertinent travel info, from terrain being traversed, speed of travel, and (importantly) time, as this affects your vigour levels. i.e. Travelling this way has to be managed. Note, there are other ways to circumvent these factors, such as using a map (quick travel) or a nexus (alternative quick travel), but that is up to the player whether they choose to employ them, or even have the means to do so. The "advantage" of travelling the Overland Map, however, will be the chance to encounter monsters for combat and find many locations that may not be found by the direct paths. (Note: Some direct paths may not be available from the start anyway.)

So, if you are able to zoom in on the image above, you will also be able to see some feedback in the chat window giving an indication on how the party is fairing in their current travel with respect to their vigour and how tired and hungry they may be.

Hopefully, (am I always saying this?), I will be able to announce a release of module one v2.65 in the coming days. All I want to do now is make sure I can at least play through the first few areas, conversations, store transactions, etc to be sure all is still fine and I have not done any unknown damage. Of course, I hope if after release you do find anything, you would let me know. :)

Tuesday, 7 May 2019

Episode 2: Getting It Right!

One of the benefits of working on a second module is the opportunity to do it again minus the parts that one did not like so much in the first. Now, let me say from the start that I am 100% happy with the first module and that I would recommend everybody who enjoys a classic PnP (pen and paper) style D&D adventure to download and play it. However, having played it a number of times myself, I can see where I could have improved it, and it is in these areas I hope to do better in the second module.


1) BROADER PATHS: To be frank, my own area designs are left wanting, in many ways ... and I know that even my newest ones for the next module will be no works of art. However, one aspect of the area design I will look at "improving" is simply to make (if possible) the walk-paths easier to navigate, especially when handling a larger party. For while I have found some of the areas in the first module are good to look at, they can also be let down by too "narrow" paths when trying to manoeuvre a party through them. For instance, it is easily possible to have over a dozen characters in a single party; and while I have made a means of escaping such tight spots available to the player, even this can need some extra persuasion at times.

2) SMALLER AREAS: I have noticed that when loading areas, a MP game can take some time if the area is of the larger size. For instance, when I first designed the Holy Mountains and Ancient Crypt areas (both 32x32 or thereabouts if I recall correctly), I had not tested their load times in a MP environment. Since my own MP testing, I have decided that I will break larger areas into smaller areas to enable faster load times for all play styles. I have not determined my exact limit yet, but I am considering around 24x24 maximum - all subject to testing.


1) CUTSCENES: Personally, I have come to the conclusion that the cutscene conversations certainly do well to immerse the player in the game, and therefore want to maximise my usage of them in the next module. I actually started making design changes to this end with the latest version of module 1, but going forward, I hope to keep as many cutscene types as possible. Obviously, those that serve an individual player will continue to be such, but I hope to do more cutscene for the players as a party as a whole.

2) COMPANION INTERJECTIONS: These came late in the design process for module one, and did not go without teething problems with the script involved .... which was quite complicated. However, now that the script that handles these is finalised, I hope to be able to use it more fruitfully in the later modules. The script that handles these interjections is designed to intelligently supply a response from the most appropriate companion, be they provided by the plot, or created by the player. That was part of the complexity.


1) EFFICIENCY: As part of the transition from finishing module 1 and starting module 2, I have been trying to rewrite and make my campaign scripts more efficient. Part of the problem I have, however, is that some of the earliest scripts I have go back over ten years! Thankfully, my knowledge of coding has improved in that time, but with the new knowledge comes recognition of where some weaknesses are in my older scripts. Many of these scripts have been "updated" and "improved" as the years have gone by, but I may have to "lock down" some older code and rewrite some parts to be more effective moving forward. The point is, I will be building the second module with greater understanding of the way things work ... and more importantly, do not work!

2) MINIMISE NEW SCRIPTS: The thing I enjoy most (when it comes to building with the toolset) is writing scripts. And while I am no expert (even now), I do enjoy seeing the results of a script come together in a game. That said, my aim is to NOT to introduce too many more scripts, simply because they can be time-consuming and one of the quickest means of introducing extra work (at best) or bugs (at worst). My aim now is to make use of the scripts and functions I have already tried and tested simply to produce more material. If I find myself needing to write another script, then I will keep it to a minimum if possible.


1) RECIPE INGREDIENTS: Having made a start in the provision of items required for crafting and enchanting, I want to be able to focus more on this area of items and make further provision of such to the player. Once again, having the core crafting code already in place, I hope it will now be a relatively easier process of determining how to distribute some of those items that are less random; such as creature items.

2) MANAGEMENT: Module one already includes a comprehensive item handling system, which has taken some time to stabilise, especially with respect to keeping stackable items and/or plot items in the right count. Therefore, I intend not to go beyond what is already working here. Any future items will, therefore, hopefully be designed to work around the current system already in place.

I hope that by the time I write the Episode 3 report, I will have uploaded the latest revision of Module One and all bug searching will have come to an end, allowing me to focus completely on the new build. We shall see ... Hopefully more on the module two specific latest next time!

The Opening Loadscreen For Module Two

Friday, 3 May 2019

Here We Go Again! (Module Two!)


I am not sure if I will ever get to the end of what I am about to undertake, but I have finally found myself tinkering with module 2 of The Scroll, with a fresh hope of being able to finish it at some point in the future. In all fairness, the second module has a considerable amount of work done to it already, thanks to those who have contributed with area designs, and the fact that the campaign code is mostly already written. However, putting it all together with a plot that works well enough to keep the player playing and intrigued is that much more difficult to do, in my opinion. And that takes time and energy: the former I am currently blessed with, but the latter, not so much. If I don't pace this correctly, then it will never happen, no matter how much I would like it to. Therefore, I will keep this blog as a record and (hopefully) an encouragement to keep going. And any feedback that you (the reader) give me along the way, may well be the make or break of it.

First Things First

1) PLOT: Thankfully, the hard part, the plot, is already taken care of ... but only in part! The point being, if I did not have a story to tell, then no matter how many area designs I have available to me, a lack of conversations or plot would quickly bring this latest project to an end. However, there is still the problem that even though I have the plot in mind, the same problems of forming a good-flowing, fully cohesive story that a player can have pleasure interacting with, remain. i.e. There are critical plot points, but I need to fill the blanks with enjoyable and meaningful content. I will need to put flesh on the bones of the plot - and that will take time to create. This also means writing all those conversations!

2) AREAS: Again, I want to thank those people who have contributed area designs for module 2, which help a great deal towards this section of the work. I can honestly say that I have been most impressed with other people's artistic talent, which have gone a long way to help inspire me with ideas to flesh out the story. If it were not for their work already, then I think this second module would never have left the ground. That said, I still need to alter some parts of some of the area designs, simply because they need some aspects changed to work with the story I have in mind, which is based upon my pen and paper campaign (PnP) from the early 80's. There are also still a few areas missing, which I need to build.

3) CONVERSATIONS: This is the part where the story starts to come to life, with the "spoken" word! Actually, I also like to move a plot line along with the written word in the likes of readable books and scrolls too, but conversations with NPCs are what give a module "breath" in my opinion. However, these also take a lot of time and care, not just for the conversation itself, but to tie in all the events and options that become available to a player as they progress.

Facing The Blank Page

Having the main framework in place is one thing, but I still needed to open the toolset and start somewhere ... and opening the toolset can be much like facing the blank page when writing. In the last few weeks, I have been fixing any problems my wife has found in her SP testing, and updating the campaign to make module to module transfer work more smoothly. That "obvious" stuff now done, I am now turning to the creative element of coding, and hence, the start of this blog record.

Thankfully, I was able to find all my old PnP notes from the past, so that I could refresh my mind with the main plot ... there was a lot to consider. To begin with, the campaign is written for both players new to the campaign and those who have played from the PnP days. Therefore, especially with the first module, I had to consider what the player's PC would know and how they would react when in the world. However, this continues in the second module, especially when the player meets with NPCs that they may have met before if they played in the PnP days ... or not.

With this in mind, and having ensured the core module to module code functioned correctly with the v2.65 release, I decided to concentrate my efforts (for now) on the "first" adventure that the players could potentially come across, either by their own exploration (or guided by the story).

Now, true to form, I will try not to spoil anything by what I write in these blogs, but now follows my latest specifics ...


As I begin this series on the latest module build, I decided to do it in an episodic format, just because it helps me ... and maybe makes it feel less dry for the reader. ;)

Because the player is still joining the module in one of two backgrounds, I decided that the best course of action is to allow the player to continue with their quest, according to the remaining quests from module 1. This, ultimately, will mean travelling to Boran. However, there are a number of places they could veer off to along the way, as the opening area will be an overland map.

Irrespective of this for now, I have decided to work on some interior area layouts to do with an outdoor area that was created for me by HOSA. The outdoor area represents an area my original PnP players PCs will have visited in the past, and so I need to try to be as faithful to its original PnP design as possible, but with some poetic licence thrown in for using the NWN2 toolset.

I find that writing for such an area (like I did for New Edgeton in module one) comes with its own set of challenges, mainly because the buildings provided do not always match what I may have originally drawn. Thankfully, this PnP scenario was played over 30 years ago, and so even my most loyal player would have trouble remembering the original design. The benefits of using previously employed PnP material, however, is that it helps drive me along, much like the other player created areas do.

The other advantage of using material from so long ago is that anything I do rebuild within NWN2 gives my old time players a chance to revisit the places and even redo the original scenario (with some minor plot alterations to reflect the changes since they were last here), and be designed in such a way that the quest works for old and new players to bring them both up to speed with the main plot. After all, the old time players will have most likely forgotten much of the plot themselves in the years that have passed since we played, and so the remade scenario works all round bringing all players backgrounds to the same point.

So, that will do as an intro for now ... Basically, I am currently working on some interior areas that support the existing area by HOSA, which I have modified slightly. I will write more about this progress, and mention some of those aspects I am changing with respect to design in Episode Two, the next blog post. For now, here is a screenshot from HOSA's area to whet the appetite.

What Place Is This That The Heroes Have Discovered?

The Scroll: New Version 2.65 Release Imminent (Big Update) - PENDING!

First, I would like to thank my wife for giving the time to play test The Scroll in its single-player (SP) mode, enabling me to be able to iron out any new bugs that may have been introduced since our testing/updating of the multi-player (MP) sessions a the few months previously. She is finally coming to the end of the story (for a second time) after playing for another 70 hours (according to the in-game timer).

I would also like to thank all of you who have been waiting patiently for the latest version after the many updates I had been doing to overcome MP issues (and some updates), which may have introduced their own problems in the course of the latest changes. In some tests, I had even had to reverse/adjust some updates, as they did cause some issues of their own. Thankfully now, however, I believe the work has now paid off to allow me to present the latest v2.65, which should be relatively sound, even with the latest adjustments.


Of all the changes, the main thing is that the latest code has been finalised with respect to module swap-overs. While this will not have any immediate obvious effect on playing The Scroll, it does now enable the player to keep either, in order of preference (a) A final save game, or (b) An exported PC, with which to start play with any of my modules released in the future. e.g. The Scroll (Part 2). And while this may appear to be a long way off, I am still trying to write this latest module when my health and time allows. It is my hope to release both modules 2 and 3, but time will tell.

The good news with respect to later modules is that the core campaign code is in place and means adding new material is somewhat more easy simply because I am not having to rewrite the core code, allowing me to concentrate on plot and any dedicated story scripts instead.

NB: I need to point out that due to a core change in one of the module's areas, this latest version is definitely NOT compatible with any previous editions of the game. I apologise for that, and can only recommend you start afresh - and hopefully are able to enjoy the game in its more completed state.


During the course of many updates since withdrawing the module for repairs, it has undergone probably a further 100 or more updates, ranging from simple typos, to some significant code changes. And while I know it is unlikely that I will have squashed every bug (even now), I do hope the critical ones have finally been put to bed. Some of these have included:-

1) JOURNAL ENTRIES: In some unusual circumstances, in the course of testing, a journal entry sometimes failed to update. Most of the times it was non-critical, but was still misleading. The ones that may have not fired that were critical often related to other areas of code problems, such as critical item drops (need to be acquired to update the journal). Such areas of the code have now undergone some rigorous testing to ensure the journal entries stay up to date. I also had to reinstate some "double" update code to accommodate TOKENS usage in journal entries, so varying journal entry info updated correctly.

2) ITEM COLLECTION: Various aspects of the code surrounding the acquisition of plot items was the most critical area of updating this patch addresses, as it could potentially be the biggest cause of broken quests. From item drops on the death of creatures, to items passed from NPC/PC to others, the code has been looked at very closely. As always, most of the issues were caused by timing of the code, which I have now streamlined.

3) FORCED CONVERSATIONS: Addressed some rare issues of some important conversations failing to fire if the player was either "compromised" or the player was not playing their Main PC. While these conversations could often be recovered (by manual player interaction), this could, nevertheless, not be relied upon.

4) TRANSITIONS: The last of the critical aspects addressed were transitions, which one would have thought to be the most straightforward from the very start. However, due to the number of checks the module makes when a player exits an area, a timing issue caused some failures if the transition was from a conversation. It was a simple enough fix when found, but still required testing to ensure I had caught all places it was required. There was even one last requirement in the last session my wife play-tested, which was pretty much well after she had been everywhere. Thankfully, this is one of those issues that once fixed, will stay fixed.

Going forward, I hope now that all my critical hook scripts, On(UN)Acquire, On(UN)Equip, etc, are now fully settled and tested sufficiently for both PCs and NPCs/Monsters to such a degree that any "additions" are now only made to those linked executable scripts, which do not interfere with the general functionality of the main ones. E.g. The On Area Enter  now calls its own dedicated executable script for events that happen on entering the areas, including any new ones I have to cater for. Therefore, in theory, the existing code (including those parts already in the additional executable) will not be affected as I continue to update with newer modules/areas.


Many of the last updates I was uploading previously was to do with changes related to the MP side of the game, and the alterations I was having to make for both MP and SP support. This is why (in the end) I made the decision to stop the many updates and concentrate on a SP testing to allow me to re-release the module after further updating/testing.

1) TB SYSTEM: I believe those issues that MP testing highlighted gave me some important pointers on where I needed to improve the SP code too. In particular (and I know not all will be using this aspect of the game), was the Althéa Turn-Based Combat System. I provided a video to show how the newer update allowed better switching between AI and PUPPET MODES for all or individual PC control. As my wife used this system with every battle, I was able to overcome all the issues that she encountered, including such things as "compromised" PCs. I believe I have ironed out all major issues with this system now, and hopefully even the minor issue we had of "ghosted" ammo appearing in an ammo slot when it clearly is not actually available. (Let me know if you experience it.)

2) RIGHT-CLICK INVENTORY: After recognising that the right-click was missing the option to open an inventory, I decided to add it. The default is the Main PC, or the PC you right-click on.

3) RECIPE BOOK INFO: The information for a recipe book now falls inline with other inventory items, in that you now have to left-click on the book to have the feedback in the chat window, rather than simply hover as before.


As I implied above, there has also been a large number of minor "annoying" bugs fixed, from (a) intermittent problems with the automated inventory item collection system and stacking; (b) the  Summon Clockroach horn failing; (c) placeable damage feedback; (d) Cutscene encounters not firing; (e) Sound files not firing, and even (f) Encumbrance values, among some others I do not mention here.


Now the challenge remains for both me and you! For me, it is to try to persevere with the next module, especially now that my wife and friend are awaiting the next instalment. And for you, if you feel encouraged to do so (and when it is finally uploaded), is to try out The Scroll for yourself!

Be warned, however, that among other things, I have addressed creature balancing, which my wife found more challenging on her SP game, second time around. I believe it can still be possible to run through the game without taking a "defeat", but the path you take will affect the odds.

Furthermore, The Scroll is as much a thinking man's dungeon as well as a dungeon-crawlers, who usually like to simply hack their way through. You will come across puzzles that require player input, even if there are often short-cuts too.

However, the game CANNOT be beaten unless the player takes note of what is provided by the story, and is involved with what is going on. It is the closest "PnP feeling" game to D&D on computer that I know of, and I have played my fair share of computer games. It was designed as a D&D campaign from the start; and as a DM of pen and paper for many years, I used to design puzzles for my players to overcome within the game as a matter of course. This aspect remains within The Scroll, and would require your attention!

As the advert says in the first Ripped Puzzle: "Illiterates need not apply!"