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!

Laters

RobP

Advertisements

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!

Laters

RobP

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!

Laters

RobP