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

 

Fatigue!

It could be argued that the title refers to some coding fatigue on my part – hence the month long absence. However, what I’m actually referring to is the new fatigue modelling that has now been coded into the system.

Before I get into any details as to what has been added over the last week, I think I should probably show off that I have now hit the 120,000 lines of code barrier! 🙂

Just hit the 120K lines of code mark! 8-)

120K – oh yeah baby! 😎

So what got put into the system to make the lines of code jump up like this?

Here’s the new functionality:

  • Unit equipment weight now affects a unit’s movement performance.
  • Unit fatigue is now modelled.
  • As a bonus unit collision detection has now been implemented too!

All in all a fair bit of code, however it wasn’t the coding that required the most effort. Instead, it was the design of the fatigue and equipment bearing systems that ate up the most time.

To produce these systems I had to design up-front what the effects would be on both movement and fatigue and how the two interrelate. This kind of design can only be achieved by sitting down, conducting research and then documenting the effects.

Gameplay and simulation mechanisms actually need an up-front design..... Heaven forbid!

Gameplay and simulation mechanisms actually need an up-front design….. Heaven forbid!

To jump straight into coding without first documenting the actual effects of these two complex systems would have lead to disaster.

It took a lot of internet research and a few iterations before I arrived at the mechanisms that I currently have. You wouldn’t believe how difficult it was to find the information that I needed. Even such simple facts as to how far an armoured infantry man can run and at what speed took a fair bit of time!

The fatigue modelling in particular is very advanced and takes a huge number of factors into account, including activity, training, terrain and any equipment carried.

To show you all this at work I have created a video which can be viewed at the end of this post. For those that are challenged in the video department I have included some screenshots below…

First up, unit collision detection:

Here I order the red cavalry unit to charge in the general direction of the blue chariot unit....

Here I order the red cavalry unit to charge in the general direction of the blue chariot unit….

In the bad old days the red unit would have continued right through the blue unit, but not any more! Unit collision detection is now in place! 8-)

In the bad old days the red unit would have continued right through the blue unit, but not any more! Unit collision detection is now in place! 😎

In the event unit collision detection proved to be a pain. The reason being that I wanted pixel perfect accuracy, along with a high calculation efficiency and speed. It took a few attempts to get there, but the current system is now lightning fast and very accurate.

It is designed to prevent units from passing through each other, unless one of the units has routed, or both units are Roman Maniples performing their pass-through manoeuvres.

The penalties for routing through a well ordered unit are pretty severe and one that I recommend that you don’t try at home! 😛

Next up, I will demonstrate how fatigue and equipment modelling impacts movement:

Eight units all perfectly inline and all ready to charge up the hill. Who is going to finish first? Which units are going to tire out first? Tune in for the next exciting instalments!

Eight units all perfectly inline and all ready to charge up the hill. Who is going to finish first? Which units are going to tire out first? Tune in for the next exciting instalments!

The blue and red units are identical. On the far left is a Light Infantry unit with average training and no kit. The rest of the units are all sporting medium armour. With the exception of the leftmost of the medium units, they all sport medium shields too. The main variation is in training. The leftmost medium infantry has average training, whilst the centre one is a conscripted unit, with the one on the far right being well trained.

The blue and red units are identical. On the far left is a Light Infantry unit with average training and no kit. The rest of the units are all sporting medium armour. With the exception of the leftmost of the medium units, they all sport medium shields too. The main variation is in training. The leftmost medium infantry has average training, whilst the centre one is a conscripted unit, with the one on the far right being well trained.

After one move (30 seconds), the light infantry unit on the left is pulling away. The next unit along is also pulling away from his comrades because he doesn't have to carry a medium shield. The unit at the back is a conscripted unit and is already tiring from the effects of running in medium armour...

After one move (30 seconds), the light infantry unit on the left is pulling away. The next unit along is also pulling away from his comrades because he doesn’t have to carry a medium shield. The unit at the back is a conscripted unit and is already tiring from the effects of running in medium armour…

After two turns (60 seconds) the light infantry unit is still in the lead and the conscripted unit has fallen further behind. Of interest, is that the right most 'Well Trained' unit is starting to catch up with the shield-less unit directly to it's left. That is despite the rightmost unit having to carry a shield. This is because the shield-less unit is starting to tire, whereas the 'Well Trained' unit is still going strong.

After two turns (60 seconds) the light infantry unit is still in the lead and the conscripted unit has fallen further behind. Of interest, is that the right most ‘Well Trained’ unit is starting to catch up with the shield-less unit directly to it’s left. That is despite the rightmost unit having to carry a shield. This is because the shield-less unit is starting to tire, whereas the ‘Well Trained’ unit is still going strong.

After 4 turns (2 mins), the shield carrying medium unit on the right has overtaken the shield-less averagely trained unit on the left. It looks like its superior training is paying off. The light unit on the far left has reached its destination a while ago and is busy resting!

After 4 turns (2 mins), the shield carrying medium unit on the right has overtaken the shield-less averagely trained unit on the left. It looks like its superior training is paying off. The light unit on the far left has reached its destination a while ago and is busy resting!

A zoomed out view after 2 minutes of game time. The units in the forest have fallen behind blues as they had a slower speed and their fatigue took a bigger battering through trying to run through a forest.

A zoomed out view after 2 minutes of game time. The units in the forest have fallen behind blues as they had a slower speed and their fatigue took a bigger battering through trying to run through a forest.

What is interesting in the above screenshot is the relative distances between the medium units in the forest and those outside. The gaps imply that the forest based units all got tired out within a relatively short period of time, whereas those outside of the forest became fatigued at much greater time intervals.

Onto menus and orders:

When a unit is fatigued certain orders can no longer be issued as denoted by the grey orders in the menu above. The eagle eyed amongst you will also have noticed that Ancient Armies is running very well on Windows 10 :D

When a unit is fatigued certain orders can no longer be issued as denoted by the grey orders in the menu above. The eagle eyed amongst you will also have noticed that Ancient Armies is running very well on Windows 10 😀

This blog post only scratches the surface of what is actually being modelled, but hopefully it will provide an insight into how fatigue and equipment will affect your units.

For those that can watch video, here is the You-Tube video (best viewed in HD):

Also, whilst I had the recording software out, I took the opportunity to update the Mapping System Overview video which can be viewed below. Again, best watched in HD:

The next thing I will be working on are the effects that movement, formations, terrain and fatigue will have on cohesion. The plan is to nail the movement basics before embarking on column road movement.

That’s it for this week!

Laters

RobP