Firstly, my apologies for not having updated this blog in a while. But I do have a pretty good excuse…
Anyways, I’m now back and coding has once again resumed!
So what have I been up to?
Well firstly I fixed some Line-Of-Sight issues. In addition I also took the liberty of optimising the Line-Of-Sight system by adding what’s known in the trade as a ‘cache’.
What’s a cache?
I’ll try and explain…
Ancient Armies does not store terrain data in tables, instead it performs calculations to determine what terrain is where. This approach has one big advantage in that terrain detection will always be of a high-fidelity and 100% accurate.
However, the downside to this approach is that the act of working out what terrain is where can eat up precious CPU cycles whilst the computer runs the terrain detection calculations.
To speed things up I have modified the system so that it now ‘remembers’ the result of each terrain calculation that it has been asked to perform. These results are then stored in a ‘cache’.
That way if a request comes in for terrain data in a map location that has already been calculated, the system will simply pass back the data it has ‘remembered’ directly from the cache. This is far faster than having to re-run the same calculations again.
Once I had finished working on the Line-Of-Sight system, I was going to proceed with column/marching movement. However, I have decided to take a detour first…
Units generally adopt a march formation to increase their speed at the expense of combat effectiveness. However, the current movement system does not yet model this. As a result I decided to finish off the movement system’s modelling first.
This way I will be able to see the effects of switching to the march. In addition, it will also enable me to see what the impact on game performance will be. This latter factor will have an impact on the internal architecture of the game, so it is best to see what that impact will be sooner, rather than later!
So what exactly have I been modelling with regard to movement?
The short answer is ‘A lot’.
The longer answer is:
- Unit Density
- Unit Cohesion
- Unit Fatigue
- Unit Type
- Terrain Type (including specifics like height, depth and terrain densities)
This seems like a lot of modelling and indeed it is, but these calculations are all hidden away from the player. All the player does is command the unit to adopt a particular speed, then the system will work out the unit’s actual speed based on all the factors above.
In addition the system will alter a unit’s cohesion and fatigue based on the type of terrain being traversed.
So why have I gone into this level of detail?
Because I want the players to operate their units like real life commanders!
For example, under this new system, a unit with a lesser density and cohesion will tend to move faster over a particular terrain type compared with units that are more densely packed or have a higher cohesion.
As a result, players will want to keep their formations as open as possible if they have a lot of ground to cover and then start to close them down as they approach the enemy. This is exactly what the Macedonians and Romans used to do – albeit in two different ways.
That’s just one example, but there are many other subtleties that arise from this complex modelling – many of which haven’t been seen in a wargame before.
So unit speeds will vary a lot dependent on their formations, cohesion, unit types and the terrain they are trying to traverse! Just like real life.
All the above will have an impact on a player’s tactics as they try to move around the battlefield in the most efficient way possible without disrupting or fatiguing their own troops!
That’s it for this week.