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

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

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!

Laters

RobP

 

Back on the Horse!

The new workplace!

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:

Where did the overlay go?

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:

A unit side slipping to the right...

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