Dogs Of War Vu

Sim/Strategy/War => Games Discussion => Topic started by: Asid on September 20, 2015, 01:10:33 PM

Title: Ancient Armies: by Rob Pollard
Post by: Asid on September 20, 2015, 01:10:33 PM
(https://ancientarmies.files.wordpress.com/2014/03/cropped-header.jpg)

Ancient Armies
(In Development)


Description
An advanced simulation of Ancient Warfare. With the possibility of modelling periods all the way up to the late 1800’s. In addition, the mapping system (tentatively called ‘Atlas’), is coded to be completely stand-alone. As such Atlas can be used for any period or game!

What makes Ancient Armies unique?

It will be one of the first wargames that will put the player firmly in the place of the commander. The player will only be able to see and react to the events that a real leader who is physically present on the battlefield will be able to.

The finished map editor and mapping system.
(https://ancientarmies.files.wordpress.com/2015/01/screenie.jpg?w=584&h=352)

Official Site:
https://ancientarmies.wordpress.com/

Official Videos:
https://ancientarmies.wordpress.com/video-media/

Official Youtube:
www.youtube.com/watch?v=Rt1-6gwNvh8&list=PLAWNvkDrHeDHNiw2YnT-p5mFwKZ7dOukb/

Official FAQ:
https://ancientarmies.wordpress.com/about/

Manual: N/A

Official Forum: N/A


Features

•   An Advanced Mapping System. Ancient Armies features one of the most advanced mapping systems currently available to any wargame – gone are the hexes and squares of older computer based games! The mapping system can simulate maps from hundreds of metres across, up to around 50 km across, though more than likely it will be able to go much larger. The mapping system is also fully vectorised, which in layman’s speak means that it will provide a smooth and continuous zooming capability with no loss of mapping detail – regardless of how close one zooms in. In addition, the mapping system supports massive customization, terrain overlays and Bezier based curves for more natural looking terrain.

•   An Industry Leading Line-Of-Sight System. When set to its highest setting, it models not just terrain based line of sight, but also unit based line of sight too. It is so advanced that it can show the effects of screening units and has the capability to show things from purely the commander’s perspective only. In addition, it even takes into account such things as terrain clutter and the actual height of the commander! For example a person on a horse can more easily see over a unit of men….

•   Realistic Command and Control. Going hand in hand with the Line-Of-Sight system, is probably one of the most realistic command and control simulations seen in an Ancient Warfare game. Most of your battles will be pre-planned using signals to trigger off events – just like real life. However, as a commander you can dispatch and receive messengers (called heralds in the game) and even personally order other units that are close enough directly yourself. In addition, the system will model your ability to be able to command dependent on whether you are actively fighting or taking a more backseat role. Both styles of command have their advantages and disadvantages…

•   Detailed Formation Modelling. Ancient Armies includes some of the most advanced formation modelling ever seen in any game! Formations actually have a big impact on the game. Formations will impact combat, movement, cohesion and fatigue. Units will be able to adopt a wide variety of formations and unit densities – just like real life! This will enable players to experience the differences between a Roman Maniple and a Macedonian Phalanx (a first in a wargame) – thus forcing a player to operate them the way they would be operated in real life. In addition, Ancient Armies models the actual locations of the individual people within a formation down to a precision of 10cm!!! These locations are dynamically modelled so that as a formation takes casualties, you will be able to see that impact on their shapes…

•   Realistic Manoeuvre Modelling. Most wargames treat all units of a given type the same way. Not Ancient Armies! These other systems also take big shortcuts with regard to the modelling of the various manoeuvres, such as having units turn from their centre points – a manoeuvre that would be almost impossible to do in real life. In Ancient Armies the manoeuvres available to each unit are unique – for example a Roman unit will be able to do a lot more than a Barbarian unit. In addition, the way that each unit carries out these manoeuvres will also be unique as the system takes into account a variety of variables that would affect that unit’s performance.

Title: Re: Ancient Armies
Post by: Asid on September 20, 2015, 01:17:41 PM
Development Videos

The video below shows the effects of movement on unit cohesion:
https://youtu.be/i-Ze_y2QB0Y

And this one shows the effects of fatigue (cohesion was not yet in when this was filmed):
https://youtu.be/4yNl3DbJeUM

This earlier video shows the effects of the terrain on the units in the game:
https://youtu.be/SXKDYmsIt4I

This video presents an overview of Ancient Armies’ unique mapping system:
https://youtu.be/xFjdPCa6mnw

A stress test of the mapping system that shows it can be used for large and complex maps:
https://youtu.be/PLVEn3njCGw

This video demonstrates the three line of sight modes used within Ancient Armies:
https://youtu.be/nUzMG2DYqA4

The next video shows off Ancient Armies detailed unit turn mechanics – probably the most detailed of any currently released wargame:
https://youtu.be/zV6RxKpth9M

The next video is an early one that shows the simultaneous unit movement and time compression controls:
https://youtu.be/QXlvpQtkBGQ

Ancient Armies Improved Orders Symbology
https://youtu.be/ljHT2mLcVoQ
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on September 20, 2015, 01:33:50 PM
reserved
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on September 20, 2015, 01:34:14 PM
Reserved
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on September 20, 2015, 01:34:40 PM
Reserved
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on September 20, 2015, 01:35:01 PM
Reserved
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on October 02, 2015, 11:59:13 AM
Improved Orders Symbology!

(https://ancientarmies.files.wordpress.com/2015/10/oldneworders.jpg?w=584&h=355)
In a static picture the changes between the old and new systems are quite subtle. You have to see the system moving to experience the full effects of the enhancements (see video at the end of this post). That said, what is immediately apparent above, is that the new system’s curved and straight arrows are now harmonised in terms of look and feel.

Although most of my time is tied up learning ASP.Net MVC in preparation for my next job, I have found a little time to tweak some of the existing subsystems in Ancient Armies.

First to come under the spotlight was the orders symbology subsystem.

There was a lot about it that really grated against my engineering perfectionism….

Firstly, there’s the ghastly oscillation of the symbols when the units are moving. If you watch any of the previous Ancient Armies videos you will see the movement arrows bouncing up and down as the units moved!

Not on my watch! This kind of amateurish behaviour has to go!

More here: https://ancientarmies.wordpress.com/2015/10/01/improved-orders-symbology/
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on October 12, 2015, 01:44:57 AM
Line of Sight is now in Real-Time!

https://youtu.be/K-CgvABO8ic

Published on 11 Oct 2015

Thanks to some major optimisations, line of sight is now calculated in realtime! This quick video shows leader-based line of sight in action.


Full post here: https://ancientarmies.wordpress.com/2015/10/11/line-of-sight-is-now-in-real-time-p/
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on October 31, 2015, 05:39:16 PM
Subsytems Updated

(https://ancientarmies.files.wordpress.com/2015/10/enhancedorders.jpg?w=584&h=399)

Some of the updates:
•   Orders system symbology
•   Cohesion subsystem

See Here: https://ancientarmies.wordpress.com/2015/10/31/a-bit-of-spit-and-polish/

Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on November 08, 2015, 11:30:06 PM
Out of Time! Update

(https://ancientarmies.files.wordpress.com/2015/11/armies2.jpg)
Initial stress testing of the system.


The screenshot above shows a number of semi-historical units in a mock battle to test how the system can deal with many units. It’s not the largest battle in the world, but it is a lot bigger than the ones that I have been testing up until now.

With this many units in play and moving about, there was a negative effect on framerates.

I can probably perform more optimizations to make things liquid smooth again, but I now think that the time is right to implement my fall-back plan *Muhahaha* :twisted:

Many of you know that the system runs using 30 second real-time turns. Some of you might have been wondering why I had gone down this design route instead of making the game fully real-time?

Well here are the answers:

    I wanted a game that could easily be played by email – a popular means of playing wargames on the internet.
    I also wanted to provide a back-up plan for potential future performance issues…

Answer 2 probably needs a little more elaboration.

Real-time games have one technical disadvantage, they are constrained by the fact that all the game calculations have to be performed at least 60 times every second. As a result each set of calculations must be finished before its 16 millisecond slot elapses.

Calculations can take longer, but at that point they will start to negatively impact the game’s frame-rate. Either that or the calculations will start to introduce significant lag to the gameplay.

Another obvious side-effect of this technical limitation is that it will ultimately restrict the maximum size of the battles that you can run before the system starts slowing down to a crawl. More units always equate to more calculations…

By designing the game with 30 second game turns, it has provided me with a fallback option of performing all the calculations for a turn up front. This will however result in a progress bar appearing with the words ‘Thinking…’, just before each turn starts.

I believe that this is a small price to play to enable one to have battles of any size and to allow one to have more leeway with regard to the calculation timings.

In fact, it will allow me to add complex Artificial Intelligence (AI) routines to the game without having to run into the 16 millisecond constraint. Of course, I can’t go completely nuts, as no one wants to wait for an hour whilst the computer works out the next turn! :P

Having a progress bar between turns also has the advantage that it provides a cue to the user that they are about to switch from planning to operations – something that’s not readily apparent right now.

To implement the above system properly will be technically challenging, especially as I see it as an opportunity to add replay functionality to the system. Replays would essentially be leveraging very similar functionality to that used for a pre-processed game turn, so I might as well code the system so that it does both.

The upshot of this is that the next tranche of work is going to take longer than usual, as a result the next update on this blog may end up being some time away. But do not fear, I will be beavering away!

Original post here: https://ancientarmies.wordpress.com/2015/11/08/out-of-time/
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on February 21, 2016, 01:22:23 AM
Adventures in Hi-Fi Line of Sight!

Posted on February 21, 2016

It has been a while since the last update as I had decided to take a break from home development to free up some time for my many other hobbies. However, I’m now back!

My intention is not to add any new functionality, at least not just yet. Instead I want to concentrate on fixing all known issues and putting what I have through the wringer to make sure that everything is working as designed.

The first thing through the wringer was the Line Of Sight system. This system had many speed optimizations made to it, so it had to be thoroughly tested. It was during this testing that I found many subtle bugs.

Some of these had been introduced as the result of the optimizations, whilst others were down to the quantized nature of the terrain and the units (the old system could only handle elevations and unit heights in whole numbers only).

This limitation inevitably lead to heights and elevations that got rounded up. For example, a 1.8 metre high infantry unit would have its height rounded up to two metres.

There was code in place to try and mitigate this limitation, but it kept failing with many corner cases. So I kept adding more and more code, only to find other corner cases creeping out of the woodwork.

In the end I decided that instead of fighting the system, I would change it. As a result, terrain elevations and unit heights can now be specified up to 5 decimal places – assuming that you really want to do that sort of thing…. :shock:

However, the more practical upshot of this modification is that units with a height of 1.8 metres are treated as units with that height, with no kind of mathematical workarounds having to be implemented! As a result, many of the subtle bugs that were in the system have simply disappeared! :)

Line of Sight is massively important to this game as I want to simulate the confusion of battle. The only way I can do this is by showing the player exactly what they would see on the battlefield if they were there. Hence the need for the high fidelity Line of Sight routines.

The Ancient Armies Line of Sight system has so many unique features that I have put together a new video that can be viewed at the end of this blog post.

For those that are challenged in the video department, here are some screenshots showing off some of these features:

(https://ancientarmies.files.wordpress.com/2016/02/spotinfmode.png?w=584)
The fidelity of the Line of Sight system is now so high, that the eye level for the Line of Sight tool has to be set. This is because different units can see differing things due to their varying eye levels. This screenshot shows the tool in its default mode which is simulating the view from an Infantry unit.

https://youtu.be/UTo1viy2UOM
Ancient Armies Line of Sight has many relatively unique features including taking into account that units can block Line of Sight. It even simulates the observer's eye level! Furhermore, terrain clutter is also taken into consideration - as a result, hills now take on the same tactical importance that they used to in battles of antiquity.

There are three Line of Sight modes in Ancient Armies:

1. Leader Based Line of Sight: Everything you can see is soley from the perspective of your leader.

2. Side Based Line of Sight: You can always see your own units, and you can see everything that they can.

3. No Line of Sight: In this mode you can see all units from both sides, regardless of where they are located on the map.



Read on: Click Here (https://ancientarmies.wordpress.com/2016/02/21/adventures-in-hi-fi-line-of-sight/)
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on March 30, 2016, 11:20:07 PM
Say hello to Chronos!


(https://ancientarmies.files.wordpress.com/2016/03/a3.png)


Who or what is Chronos?

That’s a good question…

But first lets digress a little…

Many moons ago I tested Ancient Armies with a full Macedonian and Roman Army. The results in terms of performance was a bit of a let down. The whole game ran like an arthritic slug…😕

I had known ahead of time that there might be issues as Ancient Armies has to perform a lot of calculations for the high fidelity Line of Sight system. The complexity of these calculations is compounded by the fact that the terrain supports infinitely zoomable bezier curves. All these calculations can suck up valuable processing time.

Luckily, I had designed the system to run with 30 second turns. This mechanic provided me with the option to add a turn processing phase later on should it be needed…

In  this case, it was most definitely needed!


Read on: Click Here (https://ancientarmies.wordpress.com/2016/03/30/say-hello-to-chronos/)
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on July 11, 2016, 01:03:03 PM
What have I been up to? The image below provides the first clue:
The Cores Cannea Take No More!
Posted on July 10, 2016

(https://ancientarmies.files.wordpress.com/2016/07/gitjira.jpg)
Can you spot the subtle difference?

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.

(https://ancientarmies.files.wordpress.com/2016/07/devenviron.png)
The old and the new!

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 source code.
•   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:
1.   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.
2.   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.
3.   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:
1.   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.
2.   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  8)

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:

(https://ancientarmies.files.wordpress.com/2016/07/cores.png)
This is Ancient Armies on my gaming machine. As you can see, it successfully detected all 8 cores and spread the load between them! (The peaks are from a turn’s LoS calculations):)

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:

(https://ancientarmies.files.wordpress.com/2016/07/options.png)
The new Line Of Sight options screen.

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….

Laters

RobP

Read on: Click Here (https://ancientarmies.wordpress.com/2016/07/10/the-cores-cannea-take-no-more/)
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on July 18, 2016, 03:24:10 PM
Satellite Imagery & Contours!

Posted on July 17, 2016

https://youtu.be/bPJ_FkvZwoU?list=PLAWNvkDrHeDHNiw2YnT-p5mFwKZ7dOukb

This is a quick video to show off Ancient Armies' new contour system within the Atlas mapping engine.

These contours are primarily designed to allow hills to be easily integrated with satellite imagery and other overlays. That said, they can also be used on standard maps to provide a different stylistic slant.

(https://ancientarmies.files.wordpress.com/2016/07/cont1.png)

This week has been one of giving the system a good and thorough testing to make sure it is in a good position for the next major phase of development.

It saw many Line-Of-Sight bugs squashed. It seems that these were introduced as a consequence of the addition of the new Chronos subsystem.

It also saw the testing of other functionality that hadn’t really been put through the ringer before, including satellite mapping/overlays….

Some of you will know from previous blog entries and videos that Atlas – the mapping engine – supports a wide variety of mapping overlays, including satellite imagery.

When I went to test this functionality in the actual game, I found that it didn’t work😐

The issues at hand were trivial in nature and it wasn’t long before the satellite maps were available for use in both the main game and scenario editor.

However, my joy at fixing the bugs was short lived when I noticed a slight design flaw in the system….

The hills….

It seemed that there was no aesthetically pleasing way of including hills in satellite imagery. Sure you could add them, but this lead to a problem:

(https://ancientarmies.files.wordpress.com/2016/07/theoptions.jpg)
Option 1 – Show the hill and puke! or… Option 2 – Hide the hill and not know where it is.

The user has to either leave the artificial hills visible on the map, which fails aesthetically and obscures much of the underlying satellite imagery. Or alternatively, the user could hide the hills. They would still be computed and available, just that they are hidden from view.

Whilst the latter option works well in terms of aesthetics, it fails in terms of usability. There is simply no easy way for a gamer to know where the hills are!

In fact the only way to work out where the hills are located is to scan the mouse across the map whilst reading the terrain output on the status bar at the bottom left. Not very user friendly at all!

To resolve this issue I decided to add contour lines to the system. This would allow a player to easily see where the hills are, whilst at the same time preserving the aesthetics of a satellite based map.

Coding these contour lines was fairly challenging, especially with regard to the elevation numbers. These had to be aligned directly on a contour and be facing the right way regardless of orientation.

To make things a little more tricky, the system would also need to calculate where to put a large enough gap into the contour line to prevent the elevation numbers from being obscured!

No problems!

Changes would be needed to the Atlas mapping engine and to the map editor. The game and scenario editors would not need touching – the rather neat architecture of the system will allow these two applications to automatically pick up any mapping enhancements with no code changes😎

After a lot of hammering away this is the result:

(https://ancientarmies.files.wordpress.com/2016/07/new-cont.png)
Hills! Now with contours and elevation numbers!


Read on: Click Here (https://ancientarmies.wordpress.com/2016/07/17/satellite-imagery-contours/)
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on July 25, 2016, 02:01:36 PM
Zed Said ‘No!’….
Posted on July 24, 2016

(https://ancientarmies.files.wordpress.com/2014/03/cropped-header.jpg)

Whilst putting the new contour system through its paces I noticed a particularly annoying bug:

(https://ancientarmies.files.wordpress.com/2016/07/bug.png)
See the bug?

If you look carefully you can see that the contour is drawn over the unit and not under it as expected.

Fixing this bug resulted in a major re-write of the contour system.

Why?

Basically, Direct-X has an issue where it treats lines and polygons quite differently with regard to Z calculations (depth). Especially if one is using any kind of bias.

Of course, I didn’t realise this straight away and spent a number of hours banging my head against the wall trying to work out what was going on! After all, my contour lines Z values were calculated to draw them under the units and not over them.

Once I made this discovery I realised that the fix for this issue would be quite major:

(https://ancientarmies.files.wordpress.com/2016/07/triangle.png)
The fix was changing from drawing lines to drawing triangles…

This might seem like a simple change, but calculating the triangles’ corner points to fit the requested bezier curve is not an easy problem. Luckily, I had already solved this issue with my linear terrain features, so I could reuse many of the algorithms from that section of code.

With most of the contour system re-written to work with triangles rather than lines, I then set about fixing other issues…

First up was contour clipping. When one draws a hill contour it should be clipped so that it fits the map. Alas, I had forgotten to test this aspect. So I was a little surprised when I saw this:

(https://ancientarmies.files.wordpress.com/2016/07/noclip.png)
Whoops! That’s not supposed to happen!

The hill was being clipped, but not the contour! Had I not re-written the system, I would not have been wise to this issue. Anyways, it is now fixed:

(https://ancientarmies.files.wordpress.com/2016/07/clipped.png)
Contour lines are now clipped to the map boundary.

Whilst in the contour system, I decided to update the code that deals with the elevation numbers to add a small enhancement:
Large contour elevations now have commas put in them for that more 'authentic map look'. (click for a larger image)

(https://ancientarmies.files.wordpress.com/2016/07/bigcont.png)
Large contour elevations now have commas put in them for that more ‘authentic map look’.

Although the re-write sucked up a large amount of time, the one positive thing to come from it, is that we can now set the thickness of our contours! From very thin to very thick…

(https://ancientarmies.files.wordpress.com/2016/07/thick2.png)
On the plus side, I can now manipulate contour thickness….

I’m not sure why anyone would want contours this thick, but hey, the system can now do them!:)

Back in the main game the new contours perform flawlessly:

(https://ancientarmies.files.wordpress.com/2016/07/result.png)
Contours – now in their ‘All-Fixed’ Edition!

Notice how the units now appear over the contours? – Perfect! Just wish that it didn’t require a re-write to fix…

That’s it for this week’s unexpected tour of the contour system.

Laters

RobP
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on August 19, 2016, 03:42:53 PM
(https://ancientarmies.files.wordpress.com/2014/03/cropped-header.jpg)

Bug Hunt!

Posted on July 31, 2016   


This week has been one of fixing bugs and generally stabilising the system so as to put me in a good position for the next phase of development.

(https://ancientarmies.files.wordpress.com/2016/07/bugz.png)
Getting on top of things! (Click for larger image)


The above graph shows raised issues (red) vs fixed issues (green). Over the last few weeks a lot of testing has taken place resulting in many red issues being raised. The volume of these issues was such, that I was finding them faster than I was fixing them!

However, over the last week or so, the tables have turned, with my fix rate exceeding the detection rate. I’m now in a happy position where there are only 2 minor issues left and both of these are enhancements rather than genuine issues. This means that I am now in a good solid position for the next phase of development!

Although many things got fixed over the last week, I’ll just go over the two main issues that were addressed:


Read on: Click Here (https://ancientarmies.wordpress.com/2016/07/31/bug-hunt/)
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on August 19, 2016, 03:50:38 PM
(https://ancientarmies.files.wordpress.com/2014/03/cropped-header.jpg)

All Formed Up!

Posted on August 19, 2016

(https://ancientarmies.files.wordpress.com/2016/08/many-orders.png)
Notice anything new?


The last week or so has kept me extremely busy with the implementation of formation changes in the actual game.

Formation modelling has always been part of Ancient Armies, but until now, the only way to get at this modelling was via the Army Editor. Not any more!😛

I originally estimated 7 hours for the job, but in the end it took a tad over 26 hours – a lot of time and effort.

Part of the reason for this can be seen in the screenshot above. The orders symbology had to be updated to cope with the fact that a unit’s formation can change at any time. Any subsequent orders would need to take the last formation change into account!

In addition, I wanted the leading edge of a unit to remain in the same place regardless of which formation it transitioned to. This is a requirement to allow units to keep their place in line. Of course, this wasn’t entirely simple because different formation types have different centre of masses.

So what is modelled in an Ancient Armies formation?

Three characteristics are modelled:

1.   Formation: This defines the formation’s actual shape (Ancient Armies supports many historical shapes)
2.   Frontage: This defines the number of people in each row and column. Of course it’s a little more complex than this as certain shapes don’t have rows and columns
3.   Density: This defines the gap surrounding each person in the formation. Depth and width are both independently modelled.

These characteristics allow the user to model practically any historical formation!

(https://ancientarmies.files.wordpress.com/2016/08/cav2-orders.jpg)
Density menu filtering in action!



The above screenshot shows a unit that has a formation shape of ‘Hipparch’, a frontage of ‘Standard’ and a density of ‘Standard’. As you can see, the upper menu is quite long….

I decided to add menu filtering to the system that would allow the menu options for formations to be intelligently pruned to keep them manageable. This can be seen in the screenshot above where the bottom menu has received pruning.

This pruning makes it much easier for the user to interact with formations and removes a number of what are essentially unnecessary choices.

This filtering also extends to frontages:

(https://ancientarmies.files.wordpress.com/2016/08/macmenext.jpg)
Frontage menu filtering in action!


And it will even remove the entire ‘Change Formation’ entry if a unit only has one formation that it can be:

(https://ancientarmies.files.wordpress.com/2016/08/cav1-orders.jpg)
Formation menu filtering in action!


Formation changes take time to accomplish. These changes are defined per formation and frontage within the Army Editor. However, these timings are not fixed, they are merely a base timing.

In terms of gameplay the timings will always vary slightly, plus there are chances for units to take additional time for the formation change. This is based on the unit’s training and discipline.

Of course, changing the formation of a unit reduces its cohesion somewhat (again based on training and discipline). This reduction is such, that players should try to allow enough time for the formation change before enemy contact!

If any enemy contacts a unit in the middle of a formation change it could be game-over for that unit!

So how have I handled the transitions?

In an ideal world I’d precisely model the position of every man and show them moving to their allocated positions. But alas, this is not really practical due to the many different drills adopted by the various nationalities.

So in the end, I decided to take a functional approach. I wanted the graphics to be able to show a player when a unit was changing formation and I also wanted them to give that player a rough idea as to how far through the transition the unit is.

(https://ancientarmies.files.wordpress.com/2016/08/formchange.jpg)
A time lapse composite showing a Macedonian Phalanx transitioning from Synaspismos to Open.

The above screenshot shows the compromise I arrived at. Here a Macedonian unit is expanding to open order. One can see how the graphics show the transitioning of the formation.

The individual dots don’t necessarily represent the positions of actual men, they are purely indicative of the formation change in general.

I’m rather excited by all this and the fidelity that Ancient Armies brings to the table.

For the first time that I know of, we have a simulation that explains why a Macedonian Phalanx had three formations and demonstrates to the player how these formations work.

Just by playing the game, you will soon get to understand why the Macedonian Phalanx operated 16 deep, then switched to the 8 deep Pyknosis formation prior to contact. If you don’t do this, you might run into the same difficulties that the real life commanders faced!

Of course, I have just singled out the Macedonian Phalanx here, but the formation modelling is so detailed that it applies equally well to other formation types.

The simulation has now got to the point where it is providing me with genuine insight into the workings of Ancient formations and is also enabling me to probe the authenticity of many Ancient historical texts!

I’m not aware of any other game system that has this level of fidelity – hence the excitement!😎

To show off the formations change system and to demonstrate the subtleties of operating a  Macedonian Phalanx, I have put together the following video – enjoy (Best viewed in HD):

https://youtu.be/DyqfedTVZFg

As with any large update there are a few more additional bugs that I will need to sweep up. My intent is to switch back to maintenance mode and address these as a priority.

Once this is done I will start working on the next subsystem for which architecturally, the formation change system has provided me with a bit of a leg-up…

So be ready for road and track movement – Ancient Armies style!

Laters

RobP



Original post: Click Here (https://ancientarmies.wordpress.com/2016/08/19/all-formed-up/)
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on January 09, 2017, 12:16:24 PM
(https://ancientarmies.files.wordpress.com/2014/03/cropped-header.jpg)

Slipping Away…

Posted on August 29, 2016

(https://ancientarmies.files.wordpress.com/2016/08/veer.png)
A unit side slipping to the right…


A five minute job it said…

Only five minutes!

Why not add side slip whilst fixing the other issues?

Come on it won’t take long….

What’s 5 minutes between you and me?

That ‘five minute’ job took around a day to code. That’s the last time I listen to my brain!😛

But we now have the ability for units to side slip.

What is side slipping?

It’s the ability for a unit to move or charge forward whilst slipping the whole formation either left or right.

Ancient units used side slipping where it could replace wheeling as it didn’t take as long and didn’t affect cohesion as much. But unlike wheeling, side slips are limited by unit type, training, formation density and unit speed.

So not all units will be able to side slip very well.

Why did side slipping take so long to implement?

(https://ancientarmies.files.wordpress.com/2016/08/close-up.png)
Even the trivial case of simply side slipping forward dropped me in deeper than I thought! The green line is the route the unit would take if it followed the order arrow. However, following this line would result in the unit overshooting its endpoint! Instead, the red line is the route the unit must take to arrive at the shadow marked unit. This is because the arrow the player sees marks the front of the unit, but all units’ positions are calculated from their centres and not their fronts. Hence the additional, and rather unexpected calculations….


The image above shows one reason why there were a few technical hiccups. Who would have thought that a side-slipping unit’s actual course is actually slightly different from the order arrow? Not me!🙄

Of course (pardon the pun), that’s just a simple ‘trivial’ case.

Once you start adding lots of other orders, such as wheeling, the calculations get exceedingly hairy indeed!

(https://ancientarmies.files.wordpress.com/2016/08/complextesting.png)
Lots of testing was required!


But after a day of solid work it all seems to work across multiple orders and formation shapes.😎

Although side slipping has accidentally stolen the limelight this week, the real bulk of the work was fixing the issues introduced from the formation changes that were added last week.

(https://ancientarmies.files.wordpress.com/2016/08/health.png)
Still behind the curve. You can see where the new formations change functionality got introduced on the 19th.


I have a policy of not starting any new functionality (side slipping excused), until I get the outstanding issues under control. As can be seen from the graph, I still have a little ways to go before I have a clean system ready for adding road travel functionality.

So what were the ‘outstanding’ issues that I had to fix?

Many of them came about from required functionality that I had simply not thought about for formation changes…

(https://ancientarmies.files.wordpress.com/2016/08/los.png)
Such as the ability for units that are changing formation to block line of sight properly across their more complex shapes….


(https://ancientarmies.files.wordpress.com/2016/08/selected.png)
Or maybe the ability to select and detect units that are changing formation over their whole complex shape.


There were other issues too. Such as removing the ability for a player to delete a change formation order if a unit is already in the middle of carrying it out.

All these smallish issues were issues that were not necessarily thought about up front, but are needed to make the change formation functionality usable.

In addition, as a bonus, I fixed the graphical anomalies on unformed units!

Regular readers will be thinking, ‘But you already fixed that?’ Well I thought I had, mainly because I couldn’t see the issue on my development machine.

Further investigation revealed that the corruption was down to the way I was dynamically calculating index buffers for the units. On AMD hardware (my dev machine) it worked perfectly, but on my games machine which has nVidia hardware it caused the occasional graphical issue.

I have since re-coded how the index buffers are calculated using a much safer algorithm and now, finally, everything is back and working again! Woot!😀

I even managed to spend a little time on cleaning up the wheeling orders graphic…

(https://ancientarmies.files.wordpress.com/2016/08/oldnewwheel.jpg)
On the left is the old wheeling symbology, on the right is the new. Can you spot the difference?


The older symbology used to have a solid line that was drawn perpendicular to the unit that connected the pivot point to the endpoint of the unit. However, these days, the order graphic shows a shadow of the unit, so there is no need for this line to be displayed anymore!

That’s it for this week. For the next week I will carry on stabilising the system, and once it is ready I will start on the new road travel functionality.

Some people might be thinking that this is a slow way of going about software development, but in my view if you don’t stay on top of an application’s quality it will soon get on top of you!

Anyways, I will leave you with a short video demonstrating what unit side slipping is. Best viewed in HD.

https://youtu.be/6ZUE-h06Fj4


Laters

RobP


Original post: Click Here (https://ancientarmies.wordpress.com/2016/08/29/slipping-away/)
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on January 09, 2017, 12:23:27 PM
(https://ancientarmies.files.wordpress.com/2014/03/cropped-header.jpg)

Back on the Horse!

Posted on January 8, 2017

(https://ancientarmies.files.wordpress.com/2017/01/dsc01705.png)
The new workplace!


I’m now back coding and designing Ancient Armies!

To aid with the ongoing development I bought myself a new development machine – A Microsoft Surface Book. This replaces my now deceased Apple Mac Pro.

I chose this machine because I was very impressed with them at my workplace. Plus having the ability to draw directly on the screen is essential for visualising the many geometrical problems that I have to overcome.

The fact that the screen also detaches from the keyboard to form a tablet is a bonus! All in all a very flexible machine!

So what have I been up to so far?

Firstly I spent 2 days designing how I was going to implement column based movement – both on road and off road. I also took additional time to design how movement orders will work for indirect orders – ie the orders you send by herald as opposed to direct command.

This is now all documented and safely stashed away in my Confluence system.

During the code research for the design work, I noticed that a few classes had got a little too big for their boots – yes Game I’m looking at you! As a result I invested some time to refactoring these so as to maintain a high level of code cohesion.

Refactoring is a perfectly normal activity and generally happens as a system evolves and takes shape. You can ignore the need to refactor, but you do so at your peril! The result can be an unmaintainable mess of code.

Although the design work for column based movement is now done, I will not start this new functionality until I have cleared down the backlog of bugs and issues that are still outstanding.

One issue I wanted to sort out straight away, is that I didn’t like the way the system automatically let the user side-slip a formation left or right. So I have modified the system so that the player must now make a conscious decision to side slip. This is achieved by simply holding down the side-slip key (currently mapped to left-shift), whilst issuing the orders.

If the side-slip key is not held down, the system will prevent the unit from side slipping.

In terms of bugs, the first one I ran into was this one:

(https://ancientarmies.files.wordpress.com/2017/01/nomap.png)
Loads Desert Map…. Where did the overlay go?


Believe it or not this is the desert test map, which should normally look something like this:

(https://ancientarmies.files.wordpress.com/2016/08/veer.png)
Desert overlay in place!


It turned out that my overall approach to map overlays was way too simplistic. It failed to adequately accommodate the movement of files from system to system.

This bug only got discovered because Windows 10 on my new development machine gave me a different username from my other machines.

On the plus side, the system did fail gracefully – it loaded the map, but sans overlay. It was close, but no cigar!

The new overlay system is now much more robust.

When overlays are added to a map they are now imported into the system as opposed to merely loaded. Of course this in itself is complex as you need to be able to differentiate between images that are new and those that are already imported. Plus the system also needs to deal with the possibility that two different overlays may well have the same filename…

However, don’t fear! This has now all been taken into account and the system has been thoroughly tested.

So what’s next?

As mentioned above, I want to clear down the backlog before starting on the column movement functionality. There is a fair bit of work in there and I can see it potentially occupying a fair bit of my time.

If the bugs I’m fixing are relatively interesting, I will put up blog posts up about them. If not, you will probably hear from me in a few weeks time when I will declare that the backlog is empty!


Laters

RobP


Original post: Click Here (https://ancientarmies.wordpress.com/2017/01/08/back-on-the-horse/)
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on January 17, 2017, 07:18:54 PM
(https://ancientarmies.files.wordpress.com/2014/03/cropped-header.jpg)

Chasing the Bugs!

Posted on January 15, 2017

(https://ancientarmies.files.wordpress.com/2017/01/work.jpg)
A lot of bugs have been squashed – but a lot of them have also been discovered…

As mentioned last week, my primary aim is to get the system into a relatively bug-free state prior to adding new functionality. The graph above shows that I fixed quite a few this week, but I have also discovered quite a few too.

Although no closer to starting the column movement code, it is still a good position to be in as I now have a system that has 13 fewer issues in it. Alas, not all coding can be glorious and exciting new functionality!

Most of the work that took place this week occurred in the Armies module – the module that models all aspects of units and armies.

The first ‘issue’ was this one…

Issues orders to cavalry units…

(https://ancientarmies.files.wordpress.com/2017/01/startbroken.jpg)
Starting positions for the default cavalry units.

Runs a 30 second turn and ends up with:

(https://ancientarmies.files.wordpress.com/2017/01/notveryfar.jpg)
Errr…. What happened?

The units didn’t exactly move very far…

These kind of bugs can be quite hard to find as the system keeps track of a multitude of variables for each unit. These variables can be hard to follow because the system runs multi-threaded.

Luckily, one of the pieces of work that I also did this week was to update the formation classification system to bring it up to date with the current modelling.

The classification system puts a symbol on a unit to tell the user whether it is Open Order (OO), Order (O), Close Order (CO) or Dense (D). The idea being that a player can instantly see how tightly packed a formation is – something that would be impossible to tell just by looking at the unit.

This subsystem was very old and didn’t reflect what was really happening. However, this was rectified, resulting in units being properly classified.

That said, I should probably point out that the game does not use this classification – it knows a unit’s precise measurements – the classification is solely a player aid only.

In my case, the classification helped track the issue above…

(https://ancientarmies.files.wordpress.com/2017/01/the-clue.jpg)
Ah… That would be it…

When I zoomed in onto one of the cavalry units I saw that its density classification is ‘D’ or dense. That would explain why the units were having problems moving!

These units were created very quickly using default unit sizes, formations, frontages and densities. However, it would appear that these defaults don’t give you units that function well…

This defined my next task:

‘Update the defaults to generate units that function correctly when created!’

The result:

(https://ancientarmies.files.wordpress.com/2017/01/fixedstart.jpg)
Starting positions with the new unit default sizes...

Note the defaults have made the cavalry units a lot larger. Ok, lets run a turn and see how they perform…

(https://ancientarmies.files.wordpress.com/2017/01/fixeddone.jpg)
That’s more like it – there was actually some movement!

Bingo! All sorted….

Well almost….

The problem with the new defaults is that they highlight just how large the unit size variations can be. Alas, the Army Editor’s display window just couldn’t cope with some of these new sizes:

(https://ancientarmies.files.wordpress.com/2017/01/editor1.jpg)
Oh – that doesn’t look right…

Damn! I’m missing a fair bit of the unit. Creating a Chariot unit results in the whole screen being filled by part of that unit! Not good at all.

Conversely, small units like a Roman Maniple became very small and difficult to see.

To fix this, I altered the code in that pane to automatically zoom the camera to properly show off the chosen unit. This code was not trivial as one has to work out apparent sizes in metres based on the camera distance.

Nevertheless it got fixed:

(https://ancientarmies.files.wordpress.com/2017/01/editor3.jpg)
Much Better!

Perfectly zoomed!

Even small units are now zoomed correctly:

(https://ancientarmies.files.wordpress.com/2017/01/maniple.jpg)
Even the tiny Maniple is now scaled appropriately!

The eagle eyed amongst you will have noticed that the window also gets a new scale in the bottom left so that users can more easily determine the size of a unit.

Fixes to tooling might seem a waste of time, but these tools are used to create the game assets – they will also be distributed with the game to allow players to create their own maps, units, armies and scenarios too….

Going back to the loaded scenario, I noticed another potential issue:

(https://ancientarmies.files.wordpress.com/2017/01/beforechange.jpg)
Classification ‘O’ (Order) – Really? A Macedonian Phalangite? You are kidding?

I thought ‘Oh No – the new classification system is broken already.’

Based on general wargamer bias and expectation, the Macedonian unit seemed to have an incorrect classification. Such a unit would at least be close order, if not dense!

However, after doing my research, I have discovered that this is in fact correct!

This is the default phalanx formation at 16 deep. The Macedonians didn’t even give it a name, because it was the ‘standard’ formation. However, some texts do refer to this formation as the Open formation!!! Woot! My system seems to have classified correctly!

If the above unit closes down to the 8 deep Pyknosis formation, as used prior to contact, the result is:

(https://ancientarmies.files.wordpress.com/2017/01/afterchange.jpg)
Pyknosis – classified as CO (Close Order) – Breaths a sigh of relief!

CO!!! Perfect. Closing the formation down further to the 4 deep Synaspismos results in the system correctly classifying it as ‘D’ or dense.

Of course, when I did my first formation change, I noticed a bug where the visible model’s density classification was not being updated. But this was a trivial issue and easily fixed.

So what’s planned for next week?

Well, I now have two big issues I need to look at.

First up is the text on the units. These don’t seem to be created at the correct sizes anymore. The font is either too small on large units, or too large on small units. I suspect that this is due to Windows 10 DPI scaling – most machines seem to be set to around 150%.

Fixing this issue will be difficult, but it is one that will need addressing as the unit text is the system’s primary way of communicating unit information to the player.

The next issue is related to the potential ‘bug’ described at the top of this blog entry….

It seems that Ancient Armies has got to the point where there are many subsystems acting on each unit. These affect a multitude of hidden variables with results that sometimes seem counter-intuitive – like in our example above.

However, debugging these issues is difficult as one really needs to see these variables changing over time to fully appreciate what is happening and why. This is made all the harder by the game being multi-threaded.

Luckily, Ancient Armies already records everything, all thanks to Chronos that was fitted last year. So the information is available, I just need a way to display it.

So one of my next tasks will be to create a debug monitor application. One that I can run on a separate computer that will monitor the game running and display graphs and debug information for each unit.

This will be a non-trivial task that will take a fair bit of time to complete. At first, this might seem to be a frivolous thing to do, but it will save a lot of time in the long run. This is because with such a tool I will be able to see what’s happening inside the units in realtime so that I can assess whether what I’m seeing is intended behaviour or not.

Going forward, the system will only get more complex, so a monitoring tool like this one will become critical to speeding up development.

So that’s my tasks fixed for the next few weeks! Sorry column movement, I will visit you eventually! Honest!






Laters

RobP


Original post: Click Here (https://ancientarmies.wordpress.com/2017/01/15/chasing-the-bugs/)
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on January 30, 2017, 04:28:21 PM
(https://ancientarmies.files.wordpress.com/2014/03/cropped-header.jpg)

Telematics – Done!

Posted on January 29, 2017

(https://ancientarmies.files.wordpress.com/2017/01/dsc01731.jpg)
It’s Magic!

This is a relatively short update post.

The photo above shows the end result of my work on telematics. Here I have a game running on my Surface Book laptop on the left, whilst my Surface Pro on the right is picking up that game’s internal data in real-time! 🙂

As a result I’m a very happy chappy!

I can now run with two machines, with one of them configured to show me realtime data feeds directly from within the game itself. This will reduce by a significant order of magnitude the amount of time that I will need to invest in future debugging endeavours.



(https://ancientarmies.files.wordpress.com/2017/01/telematics.png)
The finished application.

The finished application has had a lot of additional functionality added to it to allow one to pan and zoom around the data – hence all the additional buttons.

It’s underlying protocol has also been switched from Named-Pipes to TCP/IP. This change proved to be remarkably trivial thanks to the way I architected both Hermes (the communications layer) and the Telematics solution itself.

In terms of project time, I pretty much hit the nail on the head too:


(https://ancientarmies.files.wordpress.com/2017/01/timeest.png)
Not bad…. Only an hour out…

The original estimate was for 1 week of development, the actual time taken was one week plus 57 minutes. As estimates go, that was a good one!

I’m now in a good place with regard to communications. I quite literally have the technology to code the multiplayer functionality that I want to add.

So where now?

The next phase is bug fixing. This will be a few weeks of relatively-boring-but-has-to-be-done-fixing and architectural tweaks.

Once complete I will make a start on the mythical column movement.

I will see you then!

Laters

RobP


Original post: Click Here (https://ancientarmies.wordpress.com/2017/01/29/telematics-done/)
Title: Re: Ancient Armies: by Rob Pollard
Post by: Attila on January 30, 2017, 06:10:39 PM
Thanks for the posting, very interesting technical view of a development.
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on January 30, 2017, 06:11:34 PM
This is one of my most anticipated titles.
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on March 17, 2017, 12:51:10 PM
(https://ancientarmies.files.wordpress.com/2014/03/cropped-header.jpg)

Welease Wodewick!!!

Posted on February 26, 2017

Things have appeared quiet over the last few weeks, but in reality I have been hard at work in a special kind of hell normally reserved for Dev-Ops type people.

I was going to be using my time fixing bugs and getting Ancient Armies ready for the next stage of development. However, I kind of got myself side-tracked….

I had always known that my development environment lacked one very crucial piece of functionality…

The ability to create reproducible and traceable builds along with their associated releases.

Up until now, if I wanted a release, I would fire up Visual Studio and hit build. Next I would run the installer for Ancient Armies, then away I went.

However, this process had a number of issues:

•   I could not reliably reproduce an exact build or release from the past.
•   I didn’t really know what code changes were in my releases.
•   Ancient Armies itself lacked any formal version numbering – which exacerbated point number 2 above.

All of these issues are critical. If one does not know which code changes are in a particular version of the game, then one cannot test the game.

To resolve the above, I decided that I would create an automated build and release management process. After a little research and a personal recommendation, I decided to integrate a tool called TeamCity into my development environment.

What does TeamCity actually do?

(https://ancientarmies.files.wordpress.com/2017/02/teamcitybuild.jpg)
A build from within the TeamCity tool.



Read on: Click Here (https://ancientarmies.wordpress.com/2017/02/26/welease-wodewick/)
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on March 17, 2017, 12:55:35 PM
(https://ancientarmies.files.wordpress.com/2014/03/cropped-header.jpg)

A Wee Bit of Engineering!

Posted on March 16, 2017

(https://ancientarmies.files.wordpress.com/2017/03/under-construction-sign-hi.png)
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. :/

This is unusual for me; 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:

(https://ancientarmies.files.wordpress.com/2017/03/fatigue2.png)
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:

(https://ancientarmies.files.wordpress.com/2017/03/cohesiongoodgraphicsbad.png)
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 that 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


Original post: Click Here (https://ancientarmies.wordpress.com/2017/03/16/a-wee-bit-of-engineering/)
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on August 26, 2017, 07:54:57 PM
(https://ancientarmies.files.wordpress.com/2014/03/cropped-header.jpg)

Column movement development has started!

Posted on August 20, 2017


As many of you know I have been relatively busy at work and that when combined with my other hobby pursuits has meant that Ancient Armies hasn’t quite got the attention that it deserves.

However, development is still continuing where I can grab those odd free moments where my brain can strut its funky stuff! ….That funky stuff currently being column movement.

I want to simulate column movement with a relatively high level of fidelity as it has a large impact on battles. In fact, some of the famous battles like Lake Trebia and the Teutoburg Forest cannot even be simulated without accurate column mechanics.

Given the inherent complexity, I thought I’d start out with some requirements:

(https://ancientarmies.files.wordpress.com/2017/08/column6.png)
It all starts with requirements!

Getting the requirements down took several iterations as I had to figure out how to combine high fidelity column movement with Ancient Armies’ existing sub-systems.

The first challenge was integrating columns with the formation and manoeuvre modelling systems:

(https://ancientarmies.files.wordpress.com/2017/08/column3.png)
Column movement integration in the Army Editor.

This involved a minor headache trying to get column movement to fit in. The big hurdle being that unlike other formations, the column formation has to be closely tied with its associated manoeuvre. This is because a column is both a formation and a manoeuvre.

To make things complicated you couldn’t have one without the other…

In the end I decided to make the manoeuvre (the right had red ellipse) the master reference. The designer would add one of these which would automatically add the associated formation (the left hand red ellipse).

The column formation can be edited and even have additional frontages and densities added to it to allow players to select from one of multiple columns where required. Given that a column formation can have multiple frontages and densities I decided that a designer would only be allowed to add one column formation to a unit at most.

This design decision was made easier by the fact that one can only add a particular manoeuvre to a unit once. When adding the column manoeuvre, its associated formation would automatically be added too – problem solved! (Column formations cannot be directly added as formations)

Next up was the integration with the orders sub-system:

(https://ancientarmies.files.wordpress.com/2017/08/column5.png)
Column movement is now integrated into the orders sub-system!

Unlike other orders, column movement can have multiple waypoints – up until now all orders had just one waypoint each.

This involved super-charging the orders system to allow it to deal with orders that have multiple waypoints. Again, this caused a bit of head-scratching to work out the best way to achieve this within the confines of the current system.

The next bit of work would be even more difficult…

I would have to add code that would be capable of calculating a unit’s path in column formation based on the waypoints that the player provided:

(https://ancientarmies.files.wordpress.com/2017/08/column1.png)
Pretty patterns!

This might seem to be a trivial issue, but alas, we are dealing with mathematical curves that are actually composed of many triangles:

(https://ancientarmies.files.wordpress.com/2017/08/column2.png)
*Wireframe Mode* Calculations were a little hairy thanks to the vectorised nature of Ancient Armies!

These triangles all have to be calculated in realtime as the player places that unit’s waypoints! Getting this right was a major milestone, but one that has now been achieved! 😎

When a unit adopts a column formation, you will eventually be able to see columns peel off from the originating formation from right to left – hence why the columns shown above are on the right of the units.

As the columns peel away, the column feed will move left across the source unit depleting and shrinking the width of that unit. The opposite will happen to the destination unit. This part hasn’t been implemented yet, but the column positioning at the peel off point has.

Overall, the column model is pretty complex. It has a source and destination unit model that will strip-down and fill-up in real time. In addition it will also include the Bezier calculated column routing that will move as the unit proceeds up it.

Obviously, these are early days and we are still far away from where I want to be, but quite a few technical obstacles have now been resolved!

Alas, the price so far has been quite high in terms of time taken:

(https://ancientarmies.files.wordpress.com/2017/08/column4.png)
Nearly 16 hours ploughed in and I’m beginning to suspect I won’t make my estimate…

I had estimated it all taking around 3 days of development effort, but given where we currently are, I can see me blowing away this estimate in a very big way.

For more information and a demonstration of this milestone pop over to You-Tube and watch this video:

https://youtu.be/8smfS-i9YuE

Updates will be irregular whilst I try to find enough free time, but stick with me to see the evolution of what will be one of the most accurate simulations of column movement ever put into a wargame!

Laters

RobP


Original post: Click Here (https://ancientarmies.wordpress.com/2017/08/20/column-movement-development-has-started/)
Title: Re: Ancient Armies: by Rob Pollard
Post by: Raied on August 27, 2017, 07:07:01 AM
Ahhh, I was following that long time ago and just remember it again, very slow progress, but if the game happens it will be the best ancient game,
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on August 27, 2017, 05:06:43 PM
very slow progress, but if the game happens it will be the best ancient game,

Agreed. I am really looking forward to this  :thumbsup
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on August 29, 2017, 04:13:08 PM
(https://ancientarmies.files.wordpress.com/2014/03/cropped-header.jpg)

Column orders symbology – Done!

Posted on August 29, 2017


(https://ancientarmies.files.wordpress.com/2017/08/columnorders.png)
Column orders symbology – the finished article!


This week I have been working on adding the orders symbology for column movement and completing further work for its integration into the orders subsystem.

The symbology shown last week was an embryonic unit graphic rather than the orders symbology graphic. I had hacked that into the orders system so that I could easily review and test these graphics without having to fully implement them.

All of that had to be pulled out and replaced with a new set of graphics that represent the actual orders symbology itself. Don’t worry, the previous work hasn’t been thrown away, it’s still there lurking, ready for the next development phase.

My biggest concern with designing the orders symbology is that it had to fit in seamlessly with the other existing orders symbols.

My first attempt wasn’t entirely successful:

(https://ancientarmies.files.wordpress.com/2017/08/oldcol.png)
The first iteration looked pretty cool until….


(https://ancientarmies.files.wordpress.com/2017/08/oldcolint.png)
… it was viewed alongside other orders symbology.


I found that the first iteration’s attempt looked fine on its own, but looked very jarring and out of place when combined with other orders. This resulted in a further iteration to refine the symbology so that it fitted in perfectly – the results of which can be seen in this post’s first image (all images can be clicked on to view close ups).

Another feature of the orders symbology is its ability to display its waypoints whilst in edit mode:

(https://ancientarmies.files.wordpress.com/2017/08/waypointsnew.png)
In edit mode the column’s waypoints are visible as small circular waypoints.


A small touch, but one that helps everything feel like a coherent whole. Once the order has been issued the waypoint markers disappear.

Getting the Bezier based arrows to look like the other arrows was a tricky job as the arrow thins down along its length like the other arrows. Calculating the many triangles for this proved to be entertaining, especially as Direct-X insists on all triangles being wound in a clockwise direction (they won’t show if wound the other way!).

Below is a short video showing off the new symbology in action. Best viewed in HD:

https://youtu.be/7Vptc--V_M4

So what’s next on the agenda?

That will be the ability for our units to actually move down those designated column orders! It’s going to be a big task, but I will be breaking it down by only concentrating on the basic integration first.

Advanced integration with Atlas will happen in the sprint after the next one.

That’s it for this week!

Laters

RobP



Original post: Click Here (https://ancientarmies.wordpress.com/2017/08/29/column-orders-symbology-done/)
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on July 17, 2018, 12:15:29 AM
(https://ancientarmies.files.wordpress.com/2014/03/cropped-header.jpg)

It’s been a while…

Posted on July 16, 2018


(https://ancientarmies.files.wordpress.com/2018/07/ancientarmiesfamily.png?w=584)
The Ancient Armies Software Suite. Click  here (https://ancientarmies.files.wordpress.com/2018/07/ancientarmiesfamily.png) for the full-sized version. (Clockwise from top left the apps are: Telematics Application, The Army Editor, The Scenario Editor and the Map Editor. The actual game takes pride of place top centre! 🙂

I’ve been away for a while pursuing other hobbies. In this case
 Astro Imaging (https://ukastroimager.wordpress.com/) and Guitar. The former purloined my laptop, which necessitated the removal of all the development environment server components.

I had kept promising that I’d invest in the hardware and software to rectify this, but never got around to it until now!

In the end I invested in a dedicated server, updated all software licenses and adopted the very latest in Visual Studio tooling. The new development environment looks like:


(https://ancientarmies.files.wordpress.com/2018/07/devenvironment.png)
Infrastructure!


With this new environment, I can work either from home or away. Regardless, I will always have access to the support services that I require.

Adding the dedicated server will safeguard the development environment and prevent any of my other hobbies from encroaching on its space!

The new environment also provides many benefits over the older one including password-less commits (everything now works with public and private crypto keys over SSH), release artefacts and much tighter integration between, builds, releases and my work tracking system.

As a few examples of the new tighter integration consider the images below:

(https://ancientarmies.files.wordpress.com/2018/07/build.png?w=584)
Build and release integration in JIRA. I can instantly view all the builds and what issues went into them. I can even drill down to individual issues to get more detailed build information, including the source code changes that went into that issue!


(https://ancientarmies.files.wordpress.com/2018/07/builds.png?w=584)
A list of builds and their releases. Click  here (https://ancientarmies.files.wordpress.com/2018/07/builds.png) for full-sized version. I can now access all historical builds from anywhere and get hold of their artefacts and other information. Note – This screenshot was taken before I standardized the build numbering.


(https://ancientarmies.files.wordpress.com/2018/07/release.png?w=584)
Release information. Click  here (https://ancientarmies.files.wordpress.com/2018/07/release.png)
 for full-sized version. Here I have picked a build and can immediately see what went in it in terms of fixes and changes. This will aid in testing and traceability.



(https://ancientarmies.files.wordpress.com/2018/07/installers.png?w=584)
Build artefacts. Click  here (https://ancientarmies.files.wordpress.com/2018/07/installers.png) for full-sized version. In addition, I can download and run that build’s versioned installers from anywhere – Perfect!


Overall a much improved system that should impact on my productivity in a positive way.

That’s enough of environments. What have I actually been up to with regard to Ancient Armies?

So far, it’s been a relatively busy month…


(https://ancientarmies.files.wordpress.com/2018/07/activity.png?w=584)
I did say busy!


Nearly 30 issues addressed!

Whilst impressive, this graph doesn’t actually tell you what I have been up to and where I intend to take the project.

After the development environment was restored, I decided to address a particular piece of technical debt that had been haunting the project for a long time. I had tried to avoid it, as it was going to be one of those long and repetitive tasks…

The technical debt centred around naming conventions and general structure…

When the project was first started I knew nothing about C#. The result was that I had adopted many Java conventions. Alas, these conventions go against the grain of .net and more importantly had irritated me every time I wrote a line of code.

This situation had to be resolved as the engineering part of my brain was almost preventing me from coding – I simply don’t like writing code that I know isn’t correct – especially as I knew that any new code added would be increasing the size of the problem.

Besides, I figured that I would benefit by going through every source file in the project as it would help re-acquaint myself with the current state of play.

The Ancient Armies system is pretty big for a home project. It spans some 19 projects with a total of 34,641 manually written lines of code!


(https://ancientarmies.files.wordpress.com/2018/07/solutionarchitecture.png?w=584)
The overall system… So far…


At first I thought I could find an automatic way of updating the code, but none of the approaches I tried worked. In the end I just bit the bullet and went through every source file updating it by hand.

Now that this is done, the code is in great shape. It follows the C# standards and takes advantage of many of the newer technologies offered by .net, such as async and anonymous methods.

The other advantage to come from this is that I can now come home from work and carry on coding using exactly the same styles and philosophies that I use professionally (I’m a web developer by trade). This eases the transition from my professional environment to my home environment – and vice-versa.

These changes are all well and good, but where are we with regard to Ancient Armies? What happened to column movement?


(https://ancientarmies.files.wordpress.com/2018/07/releases.png?w=584)
Planning? Yes, we now have planning! Click  here (https://ancientarmies.files.wordpress.com/2018/07/releases.png) for full-sized version.


The above picture should give you a preview as to what I’m doing and the order that I’m going to be doing it in.

Read on: Click Here (https://ancientarmies.wordpress.com/2018/07/16/its-been-a-while/)
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on August 15, 2018, 03:52:24 PM
(https://ancientarmies.files.wordpress.com/2014/03/cropped-header.jpg)

I have engaged the Borg!

Posted on August 14, 2018


(https://ancientarmies.files.wordpress.com/2018/08/aa2.png)
Everything’s still working! 🙂


Ok, the title is a little melodramatic, but I have finally started work on column movement.

I wasn’t going to update the blog until column movement was done, but have relented so as to provide a quick update as to what’s going on. After all, it’s been around a month since the last update.

In many respects, the above image is quite significant.

Practically every line of code has been touched or changed since July. That’s a lot of code changes. Overall, I’m pretty happy that things are still working as they should be!

The code changes encompassed the following:

•   Updating all source code to modern coding standards – a big task
•   Replacing the Microsoft serializer with my own home rolled one – an even bigger task!
•   Removing all calculations in degrees and having everything done in radians only – another big task.

Of the three changes, I’m most proud of the serializer. For those that don’t know, the serializer’s job is to both save and load data. Such as saved games etc…

I had been using the Microsoft Binary serializer, but that one had many issues:

•   Very brittle. Any code changes would result in all previous file assets being rendered unusable. This invariably lead to having to continually recreate those assets.
•   The obfuscated saved games and data were not compatible with the non-obfuscated saved games and data. (Obfuscation refers to making the final binaries (the game) commercially releasable.)
•   Different obfuscated versions were not compatible between themselves! *Ouch!*

Designing a new serializer that would address all the above issues, and be easy to retro-fit into the system was quite a challenge – but one that I rose up to!   8)

I’m really pleased with the new one. It addresses every issue posed by the Microsoft one. In addition, it also produces much smaller files, is faster and type-safe – the latter makes it a lot harder for me to code dodgy code!

This new serializer has already paid dividends and saved me a bundle of time.

Being able to make changes to armies to support columns and then have the system still be able to load the older versions of these armies and automatically patch them to the newer versions never grows old.

With the Microsoft one I would have had to delete all my maps, armies and scenarios after every code change. Not any more!  :)

The new serializer has also saved me time by allowing me to create data whilst programming and then being able to use that exact same data with the obfuscated released versions of the game (and vice versa) – something the Microsoft one could not do.

In terms of the practicalities outside of the development environment, the new system will allow me to patch the game post release – all without breaking anything! This is very important for the users.

Overall a worthwhile enhancement.

The other big change to have taken place has been to my development process. I now have a much more robust planning pipeline, one that starts off with releases.

Releases are now planned ahead of time – up to 4 or 5. Each release is tied to a defined high level goal. No further releases are planned until the current tranche of releases is done.

Here are the current ones in the system:

(https://ancientarmies.files.wordpress.com/2018/08/releases.png)
Each release is tied to an envisioned piece of functionality…

These pre-planned releases provide focus and enable me to concentrate on the project from a reasonably high level. As an additional bonus, a release’s progress can now be tracked too. From the above screenshot you can see precisely where I am and what I have achieved!

Each release has an ‘Epic’ associated with it.

Epics can be thought of as high level work packages. They contain very high level information as to what the objectives are. One can think of these as business requirements.

When I start a new release, I spend some time refining that release’s associated Epic.

Refinement is the process of analysing the requirements of the Epic and then synthesizing a number of tasks that will ultimately deliver on that requirement.

For example here is the Column movement Epic after refinement:

(https://ancientarmies.files.wordpress.com/2018/08/column.png?w=584)
Each epic is broken down into a number of tasks/stories…

You can see that it now has a number of lower level tasks, each of which can be monitored for progress.

Having this level of planning is a God send for complex pieces of functionality like this. Without such a plan it can be hard to know where to start. This can lead to analysis paralysis, which can ultimately slow down or halt development.

With such a plan development becomes easy and focused – just follow each task!

Once all the tasks are complete, the Epic is closed and the release is released. This helps produce a project heartbeat:

(https://ancientarmies.files.wordpress.com/2018/08/prog.png?w=584)
The project now has a heartbeat!

In the above diagram I can review the releases over time and see the number of created issues vs the number of fixed issues. This graph is on the first page of my JIRA system so I can immediately see where I am and where I am going.

It shows the 0.2, 0.3 and 0.4 releases, as well as the number of tasks that went into them.

Overall, I’m very happy with the new development process. It helps generate direction and focus from the highest levels down to the lowest levels. This means that I never feel lost and that I always know exactly what I need to do.

This is invaluable tool when you are a lone developer working on such a large project!

That’s it for this short update. The next one will be after column movement is done   :)

Till then

Laters
RobP





Original post: Click Here (https://ancientarmies.wordpress.com/2018/08/14/i-have-engaged-the-borg/)
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on November 23, 2018, 01:43:15 AM
(https://ancientarmies.files.wordpress.com/2014/03/cropped-header.jpg)

Slow, But Steady!

Posted on November 19, 2018


(https://ancientarmies.files.wordpress.com/2018/11/aa.png?w=584)
Spot any changes?


Before we start, those who prefer to watch a video rather than reading, should scroll down to the end of this post and watch the video there. For those that prefer to read, carry on, but I still highly recommend that you watch the video too!

The last month or so has seen a lot of work put into Ancient Armies. Alas, most of that work will not be visible to the user. :/

Adding column movement was proceeding rather smoothly, right up until the point where I had to add a unit’s text to the column model.

I discovered that there was no easy way to copy text from an original unit’s model to the column model. The reason for this was due to the fact that a unit’s text was not encapsulated and involved many calculations.

Calculations?

Yes!

For those that don’t know, Ancient Armies units are dynamic. They are sized based on the underlying data. This means that the text that appears on them has to be able to scale properly and fit within the constraints of the user designed unit.

This is no simple task. Every formation shape had a lot of arcane code to calculate the text sizes and positions for a variety of unit shapes and sizes.

Alas, this code was scattered all around the formations models system which makes it very difficult to copy text to the column model.

To get around this I would need to create a specific class to encapsulate the concept of unit based text. This seemed kind of simple until I discovered that the Ancient Armies graphical model system does not support this very well.

The upshot of all these observations was that I had to refactor the entire model graphics subsystem to enable me to create a text model. This was the task that sank most of my time.

Was it worth it?

Yes! (in my opinion)  😎

I now have a much simpler code base, though paradoxically, one that is also a lot more powerful.

A lot of duplicate code got removed and much of the technical debt that I had accumulated over the years got fixed as a result of this refactor. I was going to address this technical debt, but at some point in the future. However, the text issue forced my hand on the matter.

With the new system I can now easily copy text. But I also gain other advantages too. Text scaling now works properly:

(https://ancientarmies.files.wordpress.com/2018/11/smallinf.png?w=584)
Text now works with all sizes of unit – regardless of size!

Direct-X’s implementation of text has a flaw where if you change the font size, it makes no difference whatsoever! The older code had a particular approach to get around this limitation, but it wasn’t robust across a wide range of unit sizes – as seen in the upper unit above.

The new text class has custom code in it that addresses the scaling issue in a totally different and neater way. As a bonus, it now allows for the accurate positioning of text, as well as performing scaling in a robust manner across a myriad of unit sizes.

The new text code also incorporates a lot of additional functionality such as text clipping (needed by column movement). But the best thing of all is that this powerful code is now located in one place, neatly encapsulated within one class.

Thanks to the new text system we can now do this:

(https://ancientarmies.files.wordpress.com/2018/11/col.png?w=584)
A unit in the process of stripping down to move into column. (The window top left is the replay window)

Here a cavalry unit is in the process of stripping down to move into column (the column itself is not shown as that is still being developed). Notice how the text is perfectly clipped?

Without the new system there would be no clipping, and indeed, as far as the column model was concerned, no text at all!

Unit stripping and reassembly are one of the crucial parts of column movement. The implementation was non-trivial but we are now around 80% there. Once this part is done, I’ll be able to work on the actual columns themselves.

The column system is very flexible and allows a unit to be specified with multiple column formations:

(https://ancientarmies.files.wordpress.com/2018/11/colchoice-e1542565863176.png?w=584)
Multiple column support

In all I’m happy with the progress so far, despite the massively expanded scope of the column release:

(https://ancientarmies.files.wordpress.com/2018/11/issues.png?w=584)
70 Issues – Ouch!

I am starting to win the fight on this release with only 20 more issues to crack. Had the architectural issues not reared their heads, I would have been a lot further along with column movement. But it is what it is.

At least I am now winning the fixes vs new issues battle! :

(https://ancientarmies.files.wordpress.com/2018/11/overtake.png?w=584)
A month of swimming against the current!

In addition to the start on column movement, I have also given the Ancient Armies fatigue system a few changes. Units now have their fatigue capped at 100%. They now slow down as they get near that figure, until eventually, they stop.

One of the things that grated me with the fatigue system, is that unlike cohesion, there was no visual feedback to the player. This has now changed:


(https://ancientarmies.files.wordpress.com/2018/11/fatigue.png?w=584)
We can now see fatigue!

The unit on the top left is heavily fatigued. This is now visualised by a unit’s colour getting paler as its fatigue increases. This provides instant visual recognition and works pretty well with the cohesion system’s visualisations too.

Other fixes also managed to be snuck in…

Rhomboids had an issue with their size calculations – this was only discovered whilst testing the column stripping functionality:

(https://ancientarmies.files.wordpress.com/2018/11/rhomboids.png?w=584)
Rhomboids fixed!

The fixed version is on the bottom. Although not as aesthetically pleasing, it is accurate and also reflects some of the ancient descriptions of these formations being described as lozenge shaped.

Below are some of my original notes that I used to meticulously check the calculated results:

(https://ancientarmies.files.wordpress.com/2018/11/rhomnotes.png?w=584)
Funky rhomboid notes!

Another fix was the unit flags. These never used to scale at all. This resulted in them being very tiny on large units. Now they scale to the size of the parent unit to make them more visible.

This is can be seen by comparing the old and new rhomboid units above.

Another important fix was an issue with Chronos – the replay and time system.

I discovered that it wasn’t being used to playback a turn! It was only being used when the replay system was activated. This meant that the turn replays tended to slow down or speed up unpredictably. It also caused a number of bugs when using the game at high time compressions.

This has now been fixed and Chronos is now used for everything. We now have super-accurate timings regardless of the computer specifications running the game. Plus, as an added bonus a lot of redundant code got removed as Chronos took on the burden of animating the player’s turn.

That’s it for this post. I wasn’t originally going to put anything up, but then decided that a progress report would be good. After all, you folks need to know that the game is being actively worked on.

Below is a You-Tube video showcasing all of the new improvements. It’s worth watching as I cover a fair bit of ground not covered here! Best viewed in HD-4K 😎

https://youtu.be/xEmmknPolC0


Laters

RobP



Original post: Click Here (https://ancientarmies.wordpress.com/2018/11/19/slow-but-steady/)
Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on December 22, 2020, 02:24:10 PM
(https://ancientarmies.files.wordpress.com/2014/03/cropped-header.jpg)

I’m Back! And this time I brought Euterpe!

Posted on December 22, 2020



After two years away, I decided to get back into coding Ancient Armies.

I’m changing the format of these posts in that they will be 100% video from now on to maximize the time coding – besides, I think most people would much rather see things working in the flesh!

https://youtu.be/vopmeYieufE

I’m Back!

I hope you enjoy the video update!

Have a Merry Christmas and I’ll see you all in the New Year!

RobP

Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on February 10, 2021, 02:20:45 AM
(https://ancientarmies.files.wordpress.com/2016/12/cropped-ancientarmiesheader6.png)

Computer says ‘No’

Posted on February 09, 2021


Late last year my computer broke down – it was experiencing intermittent resets. These random resets have made any kind of concerted coding almost impossible.

After replacing a number of parts, rebuilding the system and even adding water cooling, the issue has still remained.

My original intention was to not bother posting about this as I had put in an order on the 6th January for a replacement computer. The expectation being that I would get a brand new machine in a number of weeks and things would be back to normal.

Alas, after around a month of waiting I decided to get in contact with the vendor and it appears that they are still waiting for their suppliers to provide the graphics card and as of now there is still no ETA as to when this will arrive. I guess COVID is affecting everything.

For the moment Ancient Armies will be on hold until the new machine arrives. I’ll be keeping tabs on the computer order and it might be that I will have to cancel it and go for a different specced machine – but I’ll cross that bridge when I get there.

I’ll let you folks know as soon as anything changes!

RobP

Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on July 28, 2022, 07:53:07 PM
(https://ancientarmies.files.wordpress.com/2016/12/cropped-ancientarmiesheader6.png)

Intel!
Posted on July 14, 2021   

My computer is now fixed and the coding is on again 🙂

In this video update I demonstrate the new Intel system. Battlefield information is always incomplete, which can make for some tricky decision making – and for some fun situations!

As with the last post I’m keeping the coverage of the new functionality to video only so as to maximize my coding time. Have a look at the video and let me know if you have any feedback.

https://youtu.be/fjUC6SY_S38


RobP

Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on July 28, 2022, 07:56:29 PM
(https://ancientarmies.files.wordpress.com/2016/12/cropped-ancientarmiesheader6.png)

Large Map Optimizations!
Posted on July 18, 2021   

(https://ancientarmies.files.wordpress.com/2021/07/comp2.png)

Ancient Armies is now faster, much faster! 😀

The last post demonstrated the new intel functionality on a small map. There was a very good reason for this.

I tried running that demo on this Marathon Map (this is still a test map so don’t worry about lack of detail!):

(https://ancientarmies.files.wordpress.com/2021/07/marathon.png)
Marathon done ala-quick!

The game ground to a halt with many bugs becoming apparent – hence why the last post was demonstrated on a small map.

After a day of optimization I can happily report that large maps are no longer an issue! For full details on the optimizations and other fixes watch the video below:

https://youtu.be/SUr-WBR-scU


Big Maps? No longer a problem! 😀

Laters

RobP

Title: Re: Ancient Armies: by Rob Pollard
Post by: Asid on July 28, 2022, 08:01:43 PM
(https://ancientarmies.files.wordpress.com/2016/12/cropped-ancientarmiesheader6.png)

Sojour!?!
Posted on July 28, 2022

Sojour? What’s that? And what does it have to do with Ancient Armies?

Sojour is a solo RPG VTT Tool that I have been working on. It is this that has taken me away from Ancient Armies development. I thought I’d better put up a post to clarify what’s going on 🙂

The good news, is that Sojour’s development has finished – at least for the initial release. It is 100% functionally complete. The only thing left to do is beta testing and then releasing it to the world at large.

This does have some advantages for Ancient Armies. Firstly, I’ll gain some business experience and will already have the business stuff up and running for when Ancient Armies is ready to ship.

Secondly, Sojour used a bunch of Ancient Armies technology. This technology transfer will not be one way. Much of what was exported to Sojour got improved upon and will find itself back in Ancient Armies.

For example map scales:

(https://ancientarmies.files.wordpress.com/2022/07/scale.png)


On the left is Sojour’s map scale and on the right is Ancient Armies map scale. Sojour’s range of scales are much larger than Ancient Armies. It can go from cms/inches up to thousands of miles or km’s, plus as a bonus it supports both the imperial and the metric systems. In addition, Sojour’s scale can be sized to fit the screen resolution. Ancient Armies scale cannot. So the size you see above is as big as Ancient Armies’ scale can ever get.

So by porting this tech back to Ancient Armies, we get all of the advantages of the enhancements made in Sojour.

These advantages even extend to new map measurement tooling:

(https://ancientarmies.files.wordpress.com/2022/07/measurements.png)


Sojour can measure map ranges, arcs of fire and areas of effect – none of which Ancient Armies can do right now. This tech might seem simple, but it is quite hard to produce accurate measurement tooling that supports both imperial and metric measurements. However, this has now been done within Sojour using Ancient Armies map marker tech. So once again, these improvements can now be easily back-ported the other way back to Ancient Armies.

There is a lot more tech in Sojour which will be planted back into Ancient Armies too. So although I have been away from the project, it will still benefit from the development work in Sojour.

So what made me prioritise Sojour over Ancient Armies?

Money.

Playing Role Playing Games is extremely expensive, many of the books can easily run you into spending hundreds of pounds or a lot more. To make matters worse, many of the commercial Virtual Table Tops (VTTs) force you to re-buy books that you already own, simply to use them in their VTTs. This is obviously very expensive.

So in the end I decided to write my own VTT – Sojour. At the time of writing, it has already saved me North of £400 and is still saving me more money with each new purchase. Hence its prioritisation. These savings don’t even include how much easier Sojour is to use when compared to the other Commerical offerings.

Please do not be alarmed. As noted above, Sojour’s coding has been completed, it’s just minor bug fixes and some minor enhancements for the initial release.

Once Sojour is released, the intent is to go back to Ancient Armies, back-port Sojour’s enhancements back into Ancient Armies and then get coding again.

I do apologise for the shift in priorities, but alas, there is only one of me and I can only do so many things in any given day. I sometimes wish I could clone myself 🙂

For those that are curious about Sojour, you can see what it is in this You-Tube video. Its best viewed at 4K. However it is rather long, so feel free to use the timestamps at the bottom.

https://youtu.be/FA53LPGMAOE


I hope to get my hands back into Ancient Armies as soon as possible.

Laters

RobP