Choose Your Language

Friday 12 April 2024

Episode 83: Alpha Testing (Stage One)

I have, at last, reached a position where proper alpha testing of stage one of the second module, Predestinated Days, can begin! This is a huge milestone for the development cycle, and one I feel great relief in reaching. This first stage (of three stages) for the second module is the largest in many aspects. As the module currently stands, it has the "lion share" of the number of overall areas that can be explored and the quests that can be done. It is comparable to an estimated 70% of the size of the first module. Read on for more information.

Alpha Testing

As this is only the first part of the module, as well as being the very first time that it is going to put to a proper gaming test, the testing is going to happen in-house only. This means at the hands of my wife, who probably knows my first module and what to expect in campaign play more than anyone else anyway. However, that is not where I want to end testing, as fresh eyes and unfamiliarity are also always a good thing to have to give feedback too. Therefore, once all three stages of this module have been alpha-tested, I hope to be able to find beta-testers who can brave the testing period for me when the time comes.

Hopefully, in the next blog, I will be able to give some feedback on how well (or not) the overall alpha testing is going. I will obviously try not to give away any spoilers, but, at the same time, give you some honest feedback on how my wife's experience of the testing is going, and if there were any major issues discovered during her experience. I can safely say now, she will not be able to test every path that is available, simply because there are too many potential ways for her to cover in the time. Furthermore, as this is only the first stage, any testing she does do, effectively ends and would require a restart by the time stage two becomes available for testing.

Cutscenes

One of the delays of the last month was taking time to cover a few cutscenes I wanted to put together for a section of the first stage. However, I believe the time spent on them has been worthwhile, as the outcome of the last one I tested was exciting for me to see the end result. I believe I have covered the majority of the cutscenes for this stage now, apart from maybe one or two minor party conversations.

One aspect I have been working on, and is part of the initial testing, are cutscenes around various party builds, and need to work subject to various party conditions and states. Accounting for the many options that the party can be in by the time the cutscene starts can require some thinking out to ensure logical flow works in every situation, especially for journal entries. As an example, I am dealing with variables that could have been set many gaming sessions earlier, and even then subject to backgrounds selected and race of PC played. I can often sit making notes and pathway diagrams to ensure I have all the logic correct. Again, I hope much of this will be part of the initial testing.

Puzzles

In the latest quest I was working on to have stage one ready, I found there was an ideal situation for a cutscene I had in mind, which, as mentioned above, played out well. However, due to the nature of this cutscene, I felt that as it was quite a dramatic moment, that it also required some build up before the player was rewarded with the scene. To this end, I designed a multi-stage puzzle with new GUIs, and items. The end result, I believe, will be a fun and rewarding exercise for all who play it. In this case, there is a possibility that a player could miss out on this section altogether if they make a different choice and end up on a different path. Hopefully, however, the adventurous spirit will win out and most, if not all, players will discover this section of the adventure and enjoy the fun of the puzzles and the end cutscene for it.

Campaign Update

As I continue working on the second module, I cannot help but discover occasional areas of code that require a minor alteration or fix due to new situations that coding module two brings. In the latest building, these issues have been relatively minor, and will be available for v1.2 of the campaign in the near future.

As most of these issues can be avoided by mindful play, or can simply be ignored for the time being, then I am holding back any newer patch until after I receive any further feedback from current play testers. In this case, I would rather only add a new patch after I believe the new code is stable. I am trying to reduce the number of patches with this newer system. Priority fixes, if required, will continue to be responded to with an immediate fix and updated as soon as possible.

At this time of writing, there are currently no further module build updates for the first module. The 30th March 2024 is still the latest module build. Neither, currently, do the TLK or UI need any newer files. If these are altered, the latest versions are always included in the latest campaign file download anyway.

Anyway, that's all the latest for now, and so I leave you with a couple of screenshots from the latest Stage One of Predestinated Days. If you have any questions, or would like to hear more about anything specific with the campaign, just add a comment and ask.

The heroes investigate a cavern...

...And discover a strange machine!

Tuesday 12 March 2024

Episode 82: March Big Update!

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

The Enhanced Is Dead! Long Live The New!

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

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

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

Even The Start Screens Have Been Updated!

DM Client Support Removed

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

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

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

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

Database Handling Improved

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

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

Fast Travel System Overhaul

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

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

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

Area Map With Fast Travel Pop-In Open

Persistent Skill Bonus Fix

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

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

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

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

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

There's A Lot More!

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

TLK & UI Updated!

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

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

Saturday 10 February 2024

Episode 81: New Year Progress!

I took a hiatus in January, which means this is the first blog for the campaign this year. Prior to my break, I released v2.60E of the campaign, which has been relatively stable. That said, I have picked up on a couple of minor issues, which will be covered in the next release. Also, I have picked up building module two where I had left off at the beginning of January, and making progress once again. Read on for more details and the screenshot of the month.

More Area Work

At the beginning of this year, I am focussing on finishing off the final couple of areas that Stage One of module two requires to be ready for alpha testing. To this end, I have completed another section of an area that serves as multiple locations. That is, the area being worked on, actually serves three locations, with this section being the last (I believe) that I needed to add. I have some scripting left to do for events related to this area section, but I had managed to do the hardest parts just before I took the break.

The time-draining section for me is the tidying up of an area to make sure it looks good in-game. This potentially involves adding blocks and events that allow the area to "unfold" as the player explores it without having sections of the area showing due to existing VFX (visual effects). Unfortunately, some visual effects can show up in sections of an area that the player has not yet reached, which can spoil the immersion. Some are more easily hidden than others, but one or two have required extra work to help maintain the quality I am after.

Another Henchman

The latest module work also gave me the opportunity to introduce the possibility of another henchman. (NB: I am not talking about a companion that a player control, but an additional party member along the lines of Scraps or Sebastion in module one. Although, there will also be the possibility for a couple more companions in the second module as well.) However, this also means I have to examine the logistics of the total number of henchmen that a party may have in it. If a party is already quite large, or is a MP game, I need a fair way of handling how this new henchman is going to respond to such. However, as there are also plot implications involved with some henchmen, I am going to have to see how handling this goes in testing. Note, players can already bring the existing two henchmen from the first module along with them to the second.

Moving Forward

I am hoping that progress will continue as normal this year, although I am conscious that my health is not what it was, and I have to consider more appointments to deal with that alongside module building time. Module one has very few issues now, and any I find are usually as I am testing aspects of module two that I recognise also have an impact on the first module. Therefore, I am spending less time addressing fixes there, which is allowing me the time to focus on the second module. My wife is still testing various aspects of the campaign as a whole (both modules), but has not found anything major in the last few areas of testing. I also have another tester who is quite thorough, and has not yet had any other issues to report other than confirmation of old issues being fixed, which is encouraging.

As I allude to, I have already returned to the toolset and started to familiarise with where I was last at, and hope to be in a better position to be underway as normal next week. In the meantime, I will leave you will a screenshot from the latest area I am working on.