A Wee Bit of Engineering!

Warning! Engineering Construction!

Warning! Under Construction!

Over the past two weeks I have been conducting a great deal of engineering work on Ancient Armies to get it ready for the implementation of column movement.

It all started when I was looking at a bug with the fatigue system. This is the bug that my new telematics system picked up a few posts ago where fatigued units were not regaining their freshness after exertions.

Whilst probing around the fatigue system I was horrified by the fact that the code for it seemed to be literally everywhere! Having the code for a single subsystem littering an entire game can make it very difficult to understand, debug and can of itself cause many other engineering problems further down the line.

An inspection of the cohesion subsystem revealed a similar issue. :/

I was mortified. I’m typically very hot on software coupling and cohesion. I guess it was just the way these two subsystems had evolved over time.

In the interests of simplification and maintainability, I decided to completely refactor both of these subsystems so that they are both located in one place within their own respective classes.

Doing this was a non-trivial affair, it involved grabbing bits of code from all over the system and moulding them into a singular coherent class.

It took a fair bit of time but the rewards have more than made up for it.

For a start, it made fixing the fatigue system incredibly easy:

Fatigue goes up, fatigue goes down! (click for larger version)

Fatigue goes up,  fatigue goes down! (finally!) (click for larger version)

For the first time, fatigue in the game is now being recovered properly after a unit’s exertions. The screenshot above shows the game providing real-time data to my telematics application on the right. This shows two units exerting and then resting with their fatigue levels doing exactly what I expected them to!

The telematics application has been a God-Send. For a start it originally discovered this issue, something that would have been very difficult to spot with standard tools. But more importantly, it also easily verified that my fix was working!

To try and prove this code fix was working from within the code editor would have been a tedious and time consuming affair. But with telematics, it is as easy as running the game and viewing the results!

The telematics system also came to the rescue with cohesion too:

The telematics application lending a hand in diagnosing a cohesion issue. (click for larger version)

The telematics application lending a hand in diagnosing a cohesion issue. (click for larger version)

After the refactor of the cohesion subsystem, the graphics weren’t showing a unit’s cohesion levels properly. A quick run up of the telematics application proved that there was nothing wrong with the underlying modelling and that it was in fact an update issue to the graphical subsystem!

Again, without telematics, this would have taken much longer to determine as it would have been difficult proving that the cohesion system was working properly over time.

The other tooling to provide great assistance was my new automated build process – as introduced in the previous blog entry. Seeing the installers magically appear on my NAS drive after committing code never grows old. Nor does being able to tell exactly which version of Ancient Armies I’m running! Both of these seemingly small details, go a long way to making the job of cracking bugs a lot easier.

Although the refactoring of the fatigue and cohesion subsystems took two weeks, it leaves the software in a much better state.

For a start, all the complexities of cohesion and fatigue modelling are encapsulated and hidden away within their respective classes. None of the rest of the system needs to know how they work. Even when I’m calling these sub-systems, I no longer need to memorise how they work as it is all nicely tucked away.

When other systems within Ancient Armies call fatigue and cohesion, they can now ask simple questions like, is a unit fatigued? or exhausted? and they can do so without having to do any of the sums themselves. This helps to simplify the code and to ensure that one achieves consistent results throughout the game.

The other big bonus from the refactor, is that if either sub-system needs tweaking in the future, I know exactly where to go – they are both housed in their own files. More importantly, I only need to learn what the code is doing in that one file to fully understand the subsystem. This is far easier than traipsing through the entire game’s codebase trying to work out what’s going on!

Finally, in what seems like a long journey, I am now in a position to start work on column based movement. So tune into the next post to see some of the early results from my efforts.

Laters

RobP

 

Advertisements

Cohesion!

Ello, Ello.... What's going on here then?

Ello, Ello…. What’s going on here then?

For the last week or so I have been reasonably busy, but I did manage to find some time over the weekend to implement the Cohesion Modelling system!

As with Fatigue modelling, this is one of those parts of the game where the actual modelling has to be designed up front…

A lot of design work went into cohesion modelling. And to think I thought Fatigue modelling was hard! :P

A lot of design work went into cohesion modelling. And to think I thought Fatigue modelling was hard! 😛

There are still some more tweaks to be made, but in essence, the majority of the cohesion modelling is now in the system. This blog post serves as an early preview only – things can and will change 🙂

So what is cohesion exactly?

Cohesion represents a unit’s state with regard to how well the men are formed into their lines and columns. It can be thought of as the solidity of the formation. The higher the cohesion the more solid the formation.

Unlike other games, having a low cohesion or even zero cohesion, will not cause a unit to rout. This is because Ancient Armies differentiates between cohesion and morale.

However, cohesion does have a big impact on shock combat. This impact will vary dependent on the deployed equipment. But in general, as a rule of thumb, the higher the cohesion the greater a formation’s ability to fight and defend in shock combat.

Going hand in hand with the cohesion modelling, is the new concept of irregular units:

Ancient Armies now differentiates between irregular units - the spotty looking one and regular units the other solid ones...

Ancient Armies now differentiates between irregular units – the spotty looking one and regular units the other solid ones. Note that I still need to work on the text clarity for these type of units…

Irregular units represent units that have no solid formation, but instead, consist of a number of entities that are randomly moving about within their allotted formation space. These type of units are never subject to cohesion losses, but then again, these type of units also have a cohesion level of zero!

So as a hint, you might not want to commit irregular units to shock combat! 😛

The regularity (or not) of a unit is stored at formation level, so a unit could conceivably have a number of formations, some of which are solid and regular, whilst others of which are fluid and irregular!

So what has gone into cohesion modelling?

The short answer is a huge amount of stuff! There are so many variables that affect cohesion that it’s not really worth me mentioning them all here. However, if you watch the video at the end of this blog entry it will provide some insights as to what is being modelled.

Anyways, here are some examples:

For our first test we will issue standard move orders over open terrain. The units from left to right are: Well Trained, Average Trained, Conscript and the Conscript ally in purple. To the right of the ally is a skirmisher unit.

For our first test we will issue standard move orders over open terrain. The units from left to right are: Well Trained, Average Trained, Conscript and a Conscript ally in purple. To the right of the ally is a skirmisher unit.

Note that I have set up the manoeuvres of the allied conscript unit so that it pretty much loses cohesion the moment it moves. This is to show some of the flexibility of the system.

In this particular case it would be a good way of modelling the conscript infantry from the golden age of the chariot. In those days these units could barely form a square when stationary! When asked to move they would simply fall apart.

Such units need a lot of care and attention to make sure they are manoeuvred in such a way that they get time to recover!

After around 1 minute of movement, from right to left, the allied unit is showing substantial cohesion damage. The standard conscript unit has some cohesion damage, whilst the average unit has very little. The Well Trained unit on the left has got away scott free so far!

After around 1 minute of movement, from right to left, the allied unit is showing substantial cohesion damage (as described above). The standard conscript unit has some cohesion damage, whilst the average unit has very little. The Well Trained unit on the left has got away scott-free so far!

After two minutes all the units seemed to have regained cohesion, with the exception of the allied unit.

After two minutes all of the units seemed to have regained cohesion, with the exception of the allied unit.

In the above example we used a standard movement order. When used out in the clear, most units will get away with little to no cohesion damage. But what about something a little more strenuous?

Now to try the same test with a charge, rather than a standard movement order...

Now to try the same test again, but this time with a charge…

After just 30 seconds all units are showing signs of cohesion damage, with the well trained unit on the left being the only one that has escaped so far.

After just 30 seconds all the units are showing signs of cohesion damage, with the well trained unit on the left being the only one that has escaped so far.

As can be seen the units that are charging are taking cohesion damage far faster than those that don’t. This when combined with increased fatigue means that one will need to time one’s charges and counter charges properly!

Now to throw in some terrain into the mix:

What about standard movement into a forest?

What about standard movement into a forest?

Further into the forest and all the units have taken even more damage, with the exception of the cavalry unit on the right who has been recovering.

Once into the forest, the units have all taken a lot of cohesion damage. That is with the exception of the cavalry unit on the right who has been recovering.

The above example shows the folly of sending line units into a forest. It really plays havoc with their cohesion – and that’s just for standard movement. If one were to charge in, the effects would be even more severe!

What is interesting in this screen shot is that the expert unit appears to be slower than the average unit, which itself seems to be slower than the conscript unit!

How could this be?

At first I thought it was a bug, but it is in actual fact a product of emergent behaviour from all the simulation systems working together in harmony! And in this case, it is the correct emergent behaviour!

The reason why the above happens is that the well trained unit has more cohesion than the others, thanks to its superior training in reducing its overall cohesion loses. However, the side effect of this is that its formation is more solid than the other formations. So it has in effect, a harder time of trying to push that formation through the trees.

Whereas conversely, the conscript unit has taken a lot more cohesion damage, but its formation is now a little more open which allows it to move through the forest a little faster.

It’s almost like the well trained unit is taking its time to get through the forest with the minimal of cohesion damage!

I find it quite thrilling when this kind of emergent behaviour comes out from a system. It’s this type of behaviour which will shed new light with regard to how these battles were actually fought! 😎

There is a lot more going on behind the scenes than I describe here. All I have done is merely scratch the surface with this post. But this is the advantage of computer wargames over their board game brethren – they allow one to include a huge amount of simulation modelling without necessarily exposing the player directly to it.

The video below provides a few more insights into the modelling, but still leaves a lot out as there would simply be too much to cover!

So where next? See below…

1 Week, 3 days and 6 hours later with a staggering 53 commits has got me this far for movement modelling. I still have some tidying up to do for cohesion modelling and I need to implement road/march movement. JIRA is telling me I only have 1 day and 2 hours remaining of my original estimate.... Looks like this one is going to go a little over...

1 Week, 3 days and 6 hours later with a staggering 53 commits has got me this far for movement modelling. I still have some tidying up to do and I need to implement road/march movement. JIRA is telling me I only have 1 day and 2 hours remaining of my original estimate…. Looks like this one is going to go a little over…

In addition to all this work I am also reading yet more books on the subject of Ancient Warfare, this is the current one:

Thank you Erich Swafford - this book is proving to be a great read! :)

Thank you Erich Swafford – this book is proving to be a great read! 🙂

That’s it for this post. In the mean time have a good one!

Laters

RobP