About RobP

Got into backpacking in the spring of 2012. I started as a couch potato then made my way through walker, hiker and now backpacker! As you can see from below I have far too many hobbies! :)

It’s been a while…

The Ancient Armies Suite. Click here for full-sized version.

The Ancient Armies Software Suite. Click here 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 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:

Infrastructure!

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:

Build and release integration in JIRA.

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!

A list of builds and their releases. Click here for full-sized version.

A list of builds and their releases. Click here 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.

Release information. Click here for full-sized version.

Release information. Click here 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.

Build artefacts. Click here for full-sized version.

Build artefacts. Click here 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…

Been pretty busy!

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!

Architecture

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, anonymous methods and lambda functions.

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?

Planning? Yes we now have planning! Click here for full-sized version.

Planning? Yes, we now have planning! Click here 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.

Thanks to tighter integration with Team City, my releases can now be properly planned. Right now, I’m on the final stages of testing the big code changes that I have made. Things are looking good so far, so I anticipate that release 0.2 will be completed in the next day or so.

If you look carefully at the screenshot you will see that column movement is still there, but I want to address two other rather important issues before I get to that.

The first issue is serialisation, or put simply, the way the system loads and saves its data. The current system is a royal pain and has cost me a lot of wasted time and effort. Its biggest issue is that it is very brittle to change. This means that created maps, armies and scenarios soon become incompatible as coding proceeds.

The upshot of this is a lot of rework having to continually recreate these assets. Besides, in the real world, post release, I don’t think the users would be very happy if I released an update that broke all their saved data…

This is why I want to address this one early. The earlier it’s fixed, the more time it will save me! In addition, just like my previous coding updates, this is one of those issues that only gets bigger the longer you leave it.

Once serialisation is done, the next thing on the hit list are the internal mathematics systems. The specific issue here is that the system currently uses a mixture of radians and degrees throughout – partly because of my inability to visualise radians to the same degree as degrees! (see what I did there? ūüėõ )

Having two competing units within the system means that many unnecessary calculations are being performed from one to the other and back again every single frame render. Utilising two units can also cause confusion as I try to work out which units I should be using at any particular point.

Right now many of the subsystems support both. Removing degrees from the system will simplify everything and reduce the constant conversion overhead that’s currently taking place.

Architecturally, I had decided that viewing angles in degrees is a user interface concern and not something that the back end libraries should be concerned with. After all Direct-X only works with radians – only the users will want to see degrees and these conversions can be taken care of in the user interfaces.

Once this critical work is done, I will end up with a simpler system that has better performance characteristics – not that Ancient Armies is a slouch!

Only after these two issues have been addressed will I move back onto column movement – something I’m really looking forward to nailing.

In terms of blog updates, my intent is to limit them so as to maximize time spent coding. To that end, the next blog update will be made after the column movement system is in place. There is a LOT to this system, so I expect this to be some time down the line.

In the mean time I will leave you individual screenshots of the various systems that make up Ancient Armies – enjoy ūüôā

The Map Editor. Click here for full-sized version.

The Map Editor. Click here for full-sized version.

The Army Editor. Click here for full-sized version.

The Army Editor. Click here for full-sized version.

The Scenario Editor. Click here for full-sized version.

The Scenario Editor. Click here for full-sized version.

The Telematics Client. Click here for full-sized version.

The Telematics Client – real-time monitoring of the units over the network. Click here for full-sized version.

The game itself. Click here for full-sized version.

Finally, the game itself. Click here for full-sized version.

That’s it for this post – I’ll be back when I have some cool column movement to show you ūüôā

Laters

RobP

Advertisements

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

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

A Wee Bit of Engineering!

Warning! Engineering Construction!

Warning! Under Construction!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Laters

RobP

 

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 1.0.0.20 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!

Laters

RobP

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!

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