Column orders symbology – Done!

Column orders symbology - Done!

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 it into the orders system so that I could easily review and test its 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:

The first iteration looked pretty cool until....

The first iteration looked pretty cool until….

... it was viewed alongside other orders symbology...

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

In edit mode the column's waypoints are visible as small circular waypoints.

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:

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!




Column movement development has started!

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:

It all starts with requirements!

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:

Column movement integration with the Army Editor.

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:

Column movement is now integrated into the orders sub-system!

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:

Pretty patterns!

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:

Calculations were a little hairy thanks to the vectorised nature of Ancient Armies!

*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:

Nearly 16 hours ploughed in and I'm beginning to suspect I won't make my estimate...

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:

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!



A Wee Bit of Engineering!

Warning! Engineering Construction!

Warning! Under Construction!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




Welease Wodewick!!!

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?

A build from within the TeamCity tool.

A build from within the TeamCity tool.

It allows me to configure and manage the build and release process. With it, I can build a particular version of Ancient Armies, automatically obfuscate the binaries, create installers, run automated tests and then deploy the installers to my NAS system!

That’s a bit of a mouthful!

The best part is that it all happens automatically the minute I commit anything to my remote master. It’s like magic! Write some code, commit it, wait around a minute or two, then miraculously I have a new build directory created on my NAS drive complete with an obfuscated and unobfuscated installer – all this without lifting a finger! ūüėé

Having the ability to be able to instantly recreate any version of Ancient Armies cannot be underestimated and will be especially useful during the Beta phase of development.

TeamCity also integrates exceedingly well with my JIRA issue tracking system:

The TeamCity dashboard in JIRA.

The TeamCity dashboard in JIRA.

In the above screenshot I can instantly see that I have built 20 versions of Ancient Armies, of which the last two builds went well. I can even click on the individual blocks to get detailed information with regard to each build.

The key principal with these builds and releases is that they are versioned. In the above screenshot, the current version is build number 20. This allows traceability through issues, code and the final finished components.

TeamCity also integrates tightly with JIRA issues:

The new Team City fields in Ancient Armies' JIRA issues.

The new Team City fields within Ancient Armies’ JIRA issues.

In this case, I can see that this fix (AA-230) went into build number versions 10 or later. This means that I now know precisely which versions of Ancient Armies have this fix in! And more importantly, which versions do not!

The new functionality also allows me to kick off a build from here, or to initiate one when the issue is closed or resolved.

All of this was simply not possible before.

I can even view the specific builds that incorporate code changes from the issue being viewed:

The TeamCity tab shows all the builds that incorporate changes from the parent issue.

The TeamCity tab of the JIRA issue shows all the builds that incorporate changes for that issue.

The versioning created by the build process automatically flows through to the installers and then on to the final components. The screenshot below shows the file properties for the Ancient Armies game executable:

File properties now display the file version number from the build.

File properties of the game components now display the file version number from the build.

From the screenshot above I can instantly see that this version of the game was created by build number 20!

Prior to the introduction of this release system, I would have had¬†no idea which version this executable was, or which fixes were incorporated into it –¬†all versions of the game were statically fixed to version 1.0.0!

In addition, the game itself is now aware of its new auto-generated version number:

The about window from the Ancient Armies game.

The about window from the Ancient Armies game.

Just by viewing the About Window for any part of Ancient Armies I can immediately see the dynamic version number for that component. In this case it originated from build number 20.

When it comes to testing, any issues found can now be reported against a very specific version number. This number can then be used to determine which changes went into that release so as to target any diagnostic work.

This all sounds like really good stuff, but there was a rather large fly in the ointment…

It turned out that the installer technology that I was using for my game could not be built by MSBuild. As a result it could not be incorporated into the¬†build and release process. This is a huge flaw. It’s fine having an automated build and release process, but if you cannot build and release the installers for the game, you are pretty much wasting your time!

I was a little shocked. I was using Microsoft technology in my installer, so the last thing I expected to be doing was re-writing it due to future incompatibilities.

There was a hint of trouble ahead from within Visual Studio 2015 itself. Its complete lack of¬†native support for the installer technology¬†that I was using should have¬†rang a few alarm bells…

I searched high and low for a replacement technology. I had found that most commercial installers can cost upwards of £500 and were usually priced in the thousands! Far too rich for my pocket.

In the end I did find an open source technology, one that is even used by Microsoft itself: The WiX Toolset.

This toolset is a double edged sword. It is exceedingly powerful Рmuch more powerful than the technology that I was using, but alas very complex and lacking any kind of wizard or UI design tools. Everything is done by creating low level XML code  Рnot exactly very friendly!

I found myself continuously banging my head on the wall trying to bend the WiX Toolset to my needs. Even the simplest of tasks devoured a disproportionate amount of my time. In addition, the whole toolset follows a multitude of hidden and non-obvious rules, all of which are set to trip-up the unwary.

I think it would be fair to say that the WiX learning curve was exceedingly steep and incredibly precipitous. In retrospect I might have picked a simpler toolset like Inno, but alas, we are where we are…

With much persistence and having written nearly 400 lines of XML code, I now have a world class installer for Ancient Armies. More importantly, this installer can now be built from the command line, which means that it can be incorporated into the automated build process.

Over the next few screenshots I will take you through the differences between the old and the new installers. The old one is on the left, whilst the new one is on the right.

First up, the introduction page:

The introduction page from both installers.

The introduction page from both installers. (Click for larger version)

Straight away one can see that the new installer on the right looks much more like a standard installer. In addition, and rather importantly, it automatically picks up the build version number from the build process. Here we can see that it is the installer for version of Ancient Armies. This build labelling was simply not possible with the older installer on the left.

Incidentally, the rather alarming legalese text at the bottom of the old installer is not mine, it’s automatically incorporated by the installer itself with no option to turn it off.

Next up is the licensing page:

The licensing page from both installers.

The licensing page from both installers. (Click for a larger version)

There isn’t much of a difference here other than the ability to print the license agreement on the new one. The new one’s title bar also indicates the specific version of Ancient Armies that is to be installed.

Clicking the next button results in the options screen:

The options page from both installers.

The options page from both installers. (Click for a larger version)

Here the differences are very pronounced. The new installer on the right is much more advanced in that it allows one to pick exactly which components are to be installed. In this case, the Main Game (not optional), the Editors and/or Telematics.

The older installer is an all or nothing affair – you cannot choose your components.

Clicking the next button takes you to the pre-install screen:

The confirm installation page from both installers.

The confirm installation page from both installers. (Click for a larger version)

Here, both installers are very similar, though the new one on the right makes it absolutely clear that you are about to perform an install and it warns you that Admin privileges will be requested by the icon shown on the button.

Clicking next takes one to the installation itself:

The progress page of both installers.

The progress page of both installers. (Click for a larger version)

The new installer on the right wins again. Its progress information not only shows a progress bar (not currently visible), but it will also tell you what it is doing at any particular time. Alas, it runs so quickly that I couldn’t capture this. In addition, its¬†progress bar takes third party installations like Direct-X into account.

The old installer on the left provides no real feedback other than progress and even this is flawed as it always hangs at the end whilst Direct-X and other third party software is being installed.

Once the installations are completed one is taken to the final screen:

The final page from both installers.

The final page from both installers.

Note that the new installer on the right tells you precisely which version of Ancient Armies you have just installed. This is simply not possible with the older one on the left.

In addition, if one looks at the Windows Applications Management Window, one is now presented with the version number there too:

Windows Applications now shows the correct and dynamic version number of the game.

Windows Applications now show the correct and dynamic version number of the game.

As a result one is never in doubt as to precisely which version of the game is installed.

Writing the new installer using the WiX toolset took an inordinate amount of time and effort. Despite the frustrations, I think the end result was worth it.

I now have a modern contemporary installer that can pretty much do anything.

However, the real story here is that I can now produce automated builds and releases from end to end with dynamic version numbers incorporated into all the finished components. This new capability should not be underestimated!

Had the old installer technology worked with the build process, the whole build and release process would have been configured in a matter of hours. Instead it took me around two weeks of continuous tweaking, two weeks that could have been spent coding.

This is the one downside of home development, one has to wear many hats and be multi-skilled. These additional hats can and often do take one away from the core software development effort. The only silver lining, is that from a professional standpoint it does make me a well rounded developer.

Whilst I’ll look back at this period of development work as not particularly pleasant, at least it is now done and dusted. Time to look forward to some real game development!



Telematics – Done!

It's Magic!

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.

The finished application.

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:

Not bad.... Only an hour out...

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!



Telematics – Courtesy of Hermes!

Telematics Baby! (Click for full size)

Telematics Baby! (Click for full size)

Last week I alluded to having to write a new telematics system for Ancient Armies.

Well, it’s now here, mostly….

The screenshot above was taken from the new telematics application. It can connect to any game running on any networked machine and provide real-time graphical detail with regards to the multitude of hidden variables within the game.

Below is a screenshot of the game that was sending its data:

The scenario that's sending its data.

The scenario that’s sending its data. (Click for full-sized image)

You will need the eyes of an eagle-hawk, but the only noticeable difference between this game window and the older ones is the new telematics button on the far right of the main toolbar.

This button is normally hidden by default. To show it and gain the use of telematics one must first go to the options screen and pop across to the new Telematics tab:

The new telematics tab!

The new telematics tab!

This tab allows one to enable telematics and to pick the machine that the telematics application resides on. I have greyed out my machine names as I don’t want the internet to know the names of my local computers.

Once enabled, the telematics button becomes available on the main menu. Simply click this to allow the automatic sending of data.

If the telematics application is not running whilst the game is sending data, this is not an issue. The system will simply wait for the telematics application to start then automatically send the backlog of telematics data. In the meantime, one can carry on playing!

This new feature brings a lot to the table. Firstly, I can now see what’s happing in every unit on the battlefield, all¬†in realtime! Being able to see their variables changing over time allows me to spot bugs easily and to check that the modelling is working as expected.

In fact this system has already found its first issue. If you look at the first screenshot at the top of this post you will see the cohesion (orange) and fatigue (blue) levels for all the units in the scenario over the first turn.

One thing I noticed is that for some orders, the units were not recovering from their exertions. Such an issue would have been very difficult to spot without this tool and may well have gone unnoticed whilst introducing many subtle issues.

The other thing that this system brings to the table is Hermes.

What’s Hermes?

Hermes is my new communications layer for the game. In fact, like Chronos and Atlas before it, it has been made generic enough that it can be used for any game or program.

The best thing about Hermes is that it hides the complexities of low level communications thus making it very easy to use. It also allows one to use a variety of low level protocols (simply inject them in), all whilst presenting developers with the same simple to use interface.

As expected, Hermes also handles all the other¬†issues normally associated with communications,¬†such as¬†multi-threading and queuing. All in all, a very powerful system. ūüėé

In terms of the game itself, having Hermes in place means that multiplayer gaming is now a possibility – I just need make use of the technology that is now there!

However, there is still more work to do on the telematics system. My expectation is that I will be finished by the end of next week.

Time on Telematics!

Time on Telematics!

In fact my JIRA system says that I have just over a day’s worth of additional development to do – assuming my estimating was good. That’s after having invested nearly 4 days of effort into this system – 4 days well spent in my book.

I’ll leave you with a video showing how this new system works. Enjoy!



Chasing the Bugs!

A lot of bugs have been squashed - but a lot of them have also been discovered...

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…

Starting positions for the default cavalry units.

Starting positions for the default cavalry units.

Runs a 30 second turn and ends up with:

Errr.... What happened?

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…

Ah... That would be it...

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:

Starting positions with the new unit default sizes...

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…

That's more like it - there was actually some movement!

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:

Oh - that doesn't look right...

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:

Much Better!

Much Better!

Perfectly zoomed!

Even small units are now zoomed correctly:

Even the tiny Maniple is now scaled appropriately!

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:

Classification 'O' (Order) - Really? A Macedonian Phalangite?

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:

Pyknosis - classified as CO (Close Order) - Breaths a sigh of relief!

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!