I’ve been away for a while as I have been rather distracted…
For those that don’t know, these are Virtual Reality (VR) goggles – in this case the HTC Vive. The more observant will just be able to discern the Star Trek Enterprise’s holo-deck!
I firmly believe that VR is the future. This is first generation tech, yet it puts one firmly inside the games and other realities that one plays. In the case above, I actually get placed inside of the holo-deck and it all just looks real – like you are really there! The feeling of presence is immense.
These kind of technical revolutions only happen once or twice a life-time, hence why I have been rather distracted by the whole thing. VR is quite literally a game changer and will eventually affect all aspects of life – its applications are not just limited to gaming…
Anyways onto Ancient Armies. What have I been up to? The image below provides the first clue:
For those of a technical persuasion you may have noticed the Commit hashes (6bb0638 and 6815d6e). What do these mean?
In my case, it is an outward indicator that my backend source control system has changed!
Once upon a time I used to use Perforce, but I have now switched to using GIT.
GIT has many advantages, but here are a few:
- Faster, a lot faster…
- Allows me to easily work offline – especially useful for my laptop.
- Each machine has a copy of the repository, thus reducing the risk of losing both the source code and history.
- Simple and easy branching – this makes coding experimental features a lot safer.
- The Master repository is on an always-on fully raided NAS drive.
- Switching between machines is very easy unlike the error prone Perforce.
- Better Visual Studio integration.
The move involved a little juggling as I wanted to retain all my source code history. However, thanks to the wonders of the internet I have managed to achieve just that!
In terms of changes to Ancient Armies itself, the Line of Sight (LoS) system got a major overhaul, as have a few other subsystems.
Why the overhaul?
The original LoS system was designed to run asynchronously in the background whilst the game was running. This system ran very well where a game turn had enough real time in it to allow the LoS system to perform all its calculations at a high enough frequency.
However, I ran into three issues with this system:
- Not very scalable. The more units on the field, the more time it required to run its calculations. Given that a turn duration was more or less fixed, this could mean that the frequency of updates to the various units’ LoS would decrease as the unit count increased.
- Time compression reduced its effectiveness. The time compression feature can actually reduce the amount of time that a game turn plays out in. This impacts how many LoS calculations that the system can carry out. The higher the compression, the smaller the number of calculations run and hence the lower the fidelity.
- Chronos. The arrival of the new Chronos subsystem meant that all game calculations are now carried out prior to a turn. These calculations are relatively quick, which meant that even for a 1:1 time compression, the LoS Calculations never quite got enough time to perform as often as was needed.
LoS is complicated in Ancient Armies. This is for a variety of reasons, but includes such things as the lack of coarse hexes that other games have, uniquely and variably sized units and also terrain that supported curves.
To its credit, the LoS system has been highly optimised over time, so for what it actually does it is relatively quick. But alas, for our needs, it was not quick enough.
How to get around this?
I decided to take a two pronged approach:
- Firstly, I would alter the code to auto-detect and fully take advantage of all the processor cores that are available on a user’s PC.
- Secondly, I would instigate an auto-scaling algorithm that would automatically reduce or increase the fidelity of the LoS system based on the user’s machine’s capabilities and the size of the battle being played out.
Of the two approaches, the first was by far the most difficult. My code would need to be able to run in multiple threads, in parallel, on all the cores of the user’s CPU.
Achieving this whilst maintaining data integrity and synchronisation across all the processes turned out to be a non trivial task.
Luckily, the .net platform can help out here, but alas, you need to be on at least version 4.0 to take advantage of the facilities on offer. However, up until now I could never get Ancient Armies to work on .net 4.0…
One day of hard graft later and I can report that Ancient Armies is now running against version 4.61 – the latest available to me 😎
In all, I have been working solidly all weekend to get this new and improved system up and running. Here are the fruits of my labour:
It doesn’t look like much, but to have the ability to detect the number of processor cores and spread the work out amongst them took a lot of effort.
The upshot of these changes are that Ancient Armies can now fully take advantage of modern machine hardware architectures and will scale itself appropriately.
Even in terms of LoS calculations, the system can now detect how well it is doing (or not) and automatically scale the fidelity of the LoS system based on the hardware and battle size.
This means that the system will now always be quick, regardless of hardware configuration. The new system will also work well across all time compressions and battle sizes too! In fact the system has never been so fast or so accurate! 🙂
To provide further options for the user, I have also added an options screen where they can, if they wish, override the automatic settings for the LoS System:
The new options screen also provides plenty of information for each setting so that the user is empowered to tweak their systems to their liking. That said, the Auto mode is so good, that for most people, I would just leave it there!
That’s it for this week!
Hopefully VR won’t prove to be too distracting….