This version includes fog of war enhancements added as a result of customer feedback.
Once again, thank you for this feedback, it is invaluable.
If you want to know more about the Fog of War enhancements pop over to this You-Tube video:
Fog of War Enhancements!
Here are the full list of changes for this release:
RPG-335 Fixed an issue that could occasionally crash the journal when changing between font types.
RPG-336 Tokens can now have their ability to affect the fog in fog of war toggled by using a right click context menu item. See the manual and the video for each token’s type defaults.
RPG-341 Sojour’s file handling code has been tightened up. However, note, that windows file paths default to having a maximum length of 260 characters. If you go above that, you will need to enable it with this registry tweak.
RPG-347 The map preview is now left on for the duration of map scaling and the map scaling token now always appears above the fog. This makes custom token scaling easier on maps with fog.
RPG-348 This is a corner case fix. If you drag a character to a map that the character is already on, then drag your cursor off the map, Sojour could crash in certain circumstances. This has been fixed!
RPG-350 The map free draw function has had code added to it to smooth out drawings (they used to come out quite jagged!)
With the Fog of War release out of the door, I thought I’d get some metrics together!
This is a technical post for those that like numbers and might be especially interesting for those that write software.
I should probably preface this post by saying that my views on software development are my own and should not be considered the views of any employers that I have worked for, either past or present.
First up, the code itself. How big is it?
Basic code metrics (click for larger image)
Sojour consists of 4 main components, not including the installer. These 4 components have a total line count of 28,214 lines of code! The installer would add another 381 lines of code to that count.
However, these figures don’t tell the whole story as Sojour comes with a 161 page illustrated manual and various art assets that also have to be maintained.
Not all of this code was written from scratch. Quite a lot of it had been borrowed from my other project Ancient Armies.
The maintainability index has a range of 75–81. This index is a broad indication of code quality. Microsoft suggest anything from 20-100 is good, so I guess Sojour’s scores put it at the higher end – which is good news 🙂
How long did it take to write?
That’s a more difficult question due to the fact that when Sojour started I never took it seriously! It was considered a ‘quick’ and ‘dirty’ project reusing Ancient Armies code classes to deliver a VTT that was more suitable for my style of play. It was never originally intended to go on sale!
There was sporadic development between December 2021 and July 2022, but I don’t know exactly how much development took place in that time period as Sojour had no development pipeline setup for it.
It wasn’t until July 2022 that I started to see its potential and take it seriously. At that time the full development pipeline was put in place. This pipeline is fully automated and allows traceability from stories to code and then on to released binaries and vice versa. It provides an internal Wiki which is also linked to stories and it can build any specific version of Sojour at a whim (handy for testing). It’s this environment that’s also responsible for Sojour’s seemingly random version numbers (not all builds are released).
JIRA is at the beating heart of my development pipeline! (Click for full size image)
Despite the lack of metrics prior to July 2022, I do have very accurate measurements subsequent to that period. All figures are from that point on and do not consider the sporadic work prior to that.
According to my system a total of 490hours has been sunk into the project. That’s around 61, 8hour days in little more than a year! Not bad considering that this was all done in my free time!
How good was I at estimating time for my work?
It turns out I was pretty pants.
I tended to get my work done at approximately 64% of the original time estimate. So I’m over-estimating to a tune of 36% on average!
What about story/work break down? What have I actually been up to?
For this I will show the metrics post-release as the pre-release metrics would seriously skew what’s presented, mostly because there were no customers pre-release!
All stories breakdown (Click for full sized image)
From here we can see that the story breakdown is almost equally divided between 50% bug fixing and 50% new functionality. Note that this chart and the others below are broken down by number of stories and not time. As such they don’t represent effort.
Unlike Ancient Armies, Sojour has no automated tests, at least not yet. The way development works is that a story is tested whilst it is being developed. Then I change my hats and the story goes in for internal testing. It’s at this point that the internal bugs are raised and fixed.
I suspect that the lack of automated tests is down to the fact that Sojour’s design and feature set have been extremely fluid and volatile. If I were to have put in automated tests right at the beginning, those tests would have created a resistance to change that is directly proportional to their numbers – they would have hindered more than helped.
In addition, their inclusion would have pushed the release date right by at least 6 months. Adding full test coverage to any software project tends to multiply its codebase’s size anywhere from 200% to 400%, sometimes more!
The inclusion of automated tests is on the cards. But the time invested in those will take me away from time required to implement the new features that the customers want. I will need a strong business case to switch feature time out for automated test time.
For that to happen, I would need some consistently problematic areas to appear within Sojour – but thus far, they have failed to materialise.
Lets take a closer look at the bugs:
Bugs story breakdown (click for larger image)
Before we start, I should probably air my views with regard to bugs and specifically how they relate to Sojour’s development.
Controversially, I consider bugs a natural and intrinsic part of the software development cycle. I view them as a form of iterative feedback. Addressing them is simply addressing that feedback and iterating on an initial code design and implementation.
One could debate that automated tests could reduce the number of internal bugs, but I could debate that for Sojour, manual testing, raising the bugs and fixing them is a faster and a more flexible iterative process than writing and maintaining rigid tests. This is especially true when the majority of the detailed features of Sojour’s stories tend to be discovered during the manual testing phase – after all, the best way to test the flow of a system is to actually use it!
With that out of the way, we can concentrate on the chart’s results 🙂
The results indicate that the internal testing effort has been reasonably effective. 23% of all internal bugs made it to the outside world, of which 43% of those are either unreproducible (normally singular reports) or the result of external factors beyond Sojour’s control (For example Microsoft releasing a broken operating system component – those bugs tend to need quick workarounds placed within Sojour).
On the plus side, that means that 77% of bugs never make it out of the door! That’s not a bad figure, but ultimately it’s one that I aim to improve upon.
What about customer requests for new features? Are any being actioned?
Story breakdown by source (Click for larger image)
It turns out that 65% of all new functionality comes from me, with the remaining 35% coming from the customers. This pie chart represents delivered functionality too, so I guess it does prove that I do listen to my customers!
That said, the ultimate aim will be to equalise these figures a little more.
I suspect that the bias is down to my strong product vision. I have so many ideas that I want to incorporate and these tend to bias the story pipeline.
Finally – How happy are my customers?
This is a really difficult metric to determine.
The review comments and social media comments have been really positive and Sojour tends to be favourably compared with much larger and more expensive commercial offerings:
“Overall, Sojour Solo RPG VTT offers a level of functionality and ease of use that is unmatched by any other VTT platform.” – From a review on DriveThruRPG.
In the case of DriveThruRPG’s review scores, at the time of writing, there are 10 reviews in total, all of which have a straight 100% 5 out of 5 star rating:
Whilst good, 10 reviews is a tiny percentage of the overall customer base. As a result I don’t know how the other customers feel with regard to Sojour!
(If you are a customer, please let me know how you feel about Sojour! Tell me what you like or dislike about the product. This will help shape the future direction and journey that Sojour needs to take to be the best software that it can be!)
That’s it for this post – I hope it sheds some light on what’s going on behind the scenes!
This version adds the missing Fog of War function alluded to in the earlier video – the ability to have the mouse preview / torch switched on whilst dragging tokens. I eventually figured out how to do it, so for the moment, this first iteration of Fog of War is now feature complete!
The old video will be taken down as it is no longer representative of what one can do.
You are encouraged to view the new one below as having the ability to use the mouse preview whilst dragging tokens is a game changer for ease of use!
This is a hotfix for custom calendars. Current calendars will automatically be upgraded and customers shouldn’t see any change of functionality.
This fix separates the concept of TimeUnit number and day of at n level.
Warning! The next few paragraphs are highly technical and only really applicable to customers that are using Sojour to create custom calendars!
Previously, the n.number command did not return the TimeUnit number at level n. Instead, it used to return the day of number at that time unit level.
This is a little misleading to say the least.
To fix this all n.number commands have been renamed to n.dayof and n.numberth commands have been renamed to n.dayofth.
These names better represent what those commands are doing.
There is no need for you to change your existing custom calendars! Sojour’s auto-update system will do this for you automatically! 🙂
The n.number command has then been re-introduced, except that this time it actually reports the number of the selected TimeUnit at the chosen level.
I know this is going to sound like absolute gobbledegook to most people! The intent will be to put out a new custom calendar tutorial video that will make this a lot more clear.
The coding is done, as is most of the testing. The only things left to do are updating the manual and creating a new tutorial video that will take you all through the new Fog of War system.
This release contains quite a few enhancements that are mostly centred around the map context menus. These menus now tell you what they are focused on and their options are now filtered based on what you right clicked on.
Here we are right clicking directly on a map:
The top of the menu now shows the name of the focused item. In this case the North Soujorny map.
There is also a new option here too 🙂 You can now clear all tokens on a map with just one click! Note this will not clear static campaign assets as those are considered to be part of the map. They have to be manually deleted.
The image below shows what the context menu looks like on a map link:
A character:
A campaign asset:
And finally a token:
The eagle eyed amongst you will notice a new menu item for tokens called ‘Alter On-Map Characteristics’. Clicking this results in this new dialog window appearing:
From here the user can update the token with a very specific set of characteristic values. This is handy for those occasions where a scenario specifies an encounter with standard creatures that have very specific characteristics.
A lot of fixes and enhancements went into this release. This is the full list:
RPG-318 Campaign Asset documents can now be viewed by right clicking them on the Assets Browser treeview
RPG-320 Multi-instanced tokens can now have their on-map characteristics changed. This is for those occasions where a scenario is using standard creatures but with specific characteristics.
RPG-321 Removed a soft lock issue where some smaller modal dialog windows could appear behind the tokens palette, thus resulting in a locked system. Sojour now hides the tokens palette when the smaller modal dialogs are shown. The tokens palette is restored once the smaller dialog windows are completed.
RPG-323 The initiative tracker now properly resizes to support long character names.
RPG-324 There is a new menu option when right clicking a map that will allow the user to remove all tokens from the map. Note, this will not remove static campaign assets as these are considered part of the map. Static campaign assets have to be removed manually.
RPG-326 The assets treeview alphabetical sorting now takes numbers into account. For example in the past 12 would appear before 4 as this is correct for strict alphabetical sorting. The new version will take these numerals into account and sort the nodes so that 4 appears before 12.
RPG-327 The map now has much better right click context menus. They look better and they tell you what they are focused on. In addition, you now only see options related to the thing you are right clicking on.
RPG-328 Tokens dragged onto the map couldn’t initially be moved right away. Now they can!
This is a hotfix that fixes an issue identified by a customer in the campaign calendars. It also fixes an issue that I noticed this morning whilst using it.
RPG-315 Fixed a number of issues related to changing the large year field (top centre) of the campaign calendar. Changing this would sometimes lead to odd dates appearing, some of which could crash the system because they were invalid dates. This has been fixed.
RPG-316 Fixed an issue where custom user sized token’s healthbars would appear at the wrong size when Sojour was reloaded.
I have a zero tolerance policy to bugs – so if you find any, please report them and I’ll do my best to get fixes out as soon as possible.
You will need to pop into your DriveThruRPG accounts to download this update.
This release fixes a number of issues and also adds token size locking to prevent accidental token resizing.
With this version you must unlock a token before you can resize it with the mouse wheel.
Tokens are unlocked by right clicking on them and toggling the ‘Token size locked :
Sojour remembers this setting for each token on each map.
Tokens that have their default sizes changed by the user can now be reset back to the map’s default token size by right clicking on them and selecting ‘Restore Default Size’:
These two enhancements should make token size management a little less fiddly 🙂
Here is the full list of changes and fixes in this release:
RPG-309 Fixed an issue with the dice parser not understanding capitalised dice expressions.
RPG-310 Token sizes are now locked by default. To resize a token you must first unlock it on its context menu. This is to prevent accidental resizing. A new menu item has also been added to allow the user to resize a token back to its default size where it has had its size overridden by the user. In addition the map context menu has been tidied up!
RPG-311 Experimental fix to remove user key collisions with a journal’s automatic background processing.
RPG-312 The Microsoft WebView component used for the PDF viewer has been updated to the latest version
RPG-313 Tokens no longer move when left clicking the map immediately after right clicking on a token.
RPG-314 The map no longer flashes white when the ctrl or shift keys are used in the journal.
As usual all updates are free for paying customers! Just pop to your DriveThruRPG accounts and download the latest version!
Sojour 