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

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

Slipping Away…

A unit side slipping to the right...

A unit side slipping to the right…

A five minute job it said…

Only five minutes!

Why not add side slip whilst fixing the other issues?

Come on it won’t take long….

What’s 5 minutes between you and me?

That ‘five minute’ job took around a day to code.¬†That’s the last time I listen to my brain! ūüėõ

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

What is side slipping?

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

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

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

Why did side slipping take so long to implement?

In the end, even the trivial case of simply side slipping forward dropped me in deeper than I thought! The green line is the route the unit would take if it followed the order arrow. However, following this line would result in the unit overshooting its endpoint. Instead, the red line is the route the unit must take to arrive at the shadow marked unit. This is because the arrow the player sees marks the front of the unit, but all unit's positions are calculated from their centres and not their fronts. Hence the additional, and rather unexpected calculations.... (Click for full sized image)

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

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

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

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

Lots of testing was required!

Lots of testing was required!

But after a day of solid work it all seems to work across multiple orders and formation shapes. ūüėé

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

Still behind the curve. You can see where the new formations change functionality got introduced on the 19th.

Still behind the curve. You can see where the new formations change functionality got introduced on the 19th.

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

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

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

Units that change formation now block line of sight properly across their more complex shapes.

Such as the ability for units that are changing formation to block line of sight properly across their more complex shapes….

Units that are changing formation can now be selected over their whole complex shape. The system now also detects the unit when the mouse cursor is waved over any part of the complex shape.

Or maybe the ability to select and detect units that are changing formation over their whole complex shape.

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

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

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

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

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

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

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

On the left is the old wheeling symbology, on the right is the new. Can you spot the difference?

On the left is the old wheeling symbology, on the right is the new. Can you spot the difference?

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

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

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

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

Laters

RobP

 

All Formed Up!

Notice anything new? :)

Notice anything new?

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

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

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

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

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

So what is modelled in an Ancient Armies formation?

Three characteristics are modelled:

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

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

Density menu filtering in action!

Density menu filtering in action!

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

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

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

This filtering also extends to frontages:

Frontage menu filtering in action!

Frontage menu filtering in action!

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

Formation menu filtering in action!

Formation menu filtering in action!

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

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

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

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

So how have I handled the transitions?

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

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

A time lapse composite showing a Macedonian Phalanx transitioning from Synaspismos to Open.

A time lapse composite showing a Macedonian Phalanx transitioning from Synaspismos to Open.

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

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

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

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

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

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

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

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

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

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

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

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

Laters

RobP

Bug Hunt!

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

Getting on top of things!

Getting on top of things! (Click for larger image)

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

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

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

Chronos replays were too slow!

This was an interesting bug and one that can be seen in the Chronos video.

The original replay functionality would wait for the time of one frame or larger to pass and then display the next frame. This is all well and good, but if the machine is doing other stuff, the next frame request could be several frames in the future. However, because of the way the system was coded, it would still retrieve the next frame in sequence – thus resulting in a slow playback.

To fix this, I simply changed the system to always retrieve the frame for the currently calculated time, regardless of how far in the future. This ensures, that even under heavy system load, the correct frame is always displayed for the elapsed time!

Irregular formation graphical bugs!

This issue has been a thorn in my side for a while. It was intermittent in nature, thus making it very difficult to track down. An obvious case of this bug can be seen in the Chronos video, where one can see the malformed irregular units.

Whilst fixing the code for this, I discovered that many mathematical ‘bodges’ had been put into the irregular unit calculation code. I decided to remove these, as I was fairly certain that it was these ‘bodges’ that were causing the graphical anomalies.

Once removed, I spent a bit of time trying to figure out why they were added in the first place. The result was rather surprising…

It seems that Ancient Armies was calculating unit widths incorrectly!!!! ūüėĮ

Before I go into the how and why, here is a question for you:

If I have a row of 5 men, each with 1 metre of frontage, how wide would the formation be?

Got the answer yet?

If you guessed 5 mtrs, you guessed wrong! ūüėõ

The correct answer is that the resultant formation should be 4 metres wide.

However, Ancient Armies was originally and incorrectly calculating 5 metres of width. This meant that the code for generating the irregular unit shapes had many bodges in it to try and mitigate the incorrectly calculated widths.

Once I knew that this was the core issue, it was relatively simple to fix and meant that the code for calculating the irregular unit shapes could now work with no bodges in it! ūüėé

For those that are still unconvinced, lets consider our hypothetical man:

Consider a man with a defined formation with setting of 1 metre...

Our example man!

As you can see he has a frontage of 1 metre centred around himself.

Now if I pop him into a 5 man formation, this is what I get:

A unit of five of the above men (Click for larger image)

A unit of five of the above hypothetical men (Click for larger image)

As you can see from the above diagram, the correct unit width is 4 metres!

This is because Ancient Armies unit markers represent where the men actually are, it does not represent their raw frontages. Frontages are only used to calculate the spacing between each individual man. For the men on the ends, this spacing is irrelevant – hence the 4 metres width! ūüôā

That’s it for this week. Next week should be more interesting as I can now start work on formation changes…

Laters

RobP

Zed Said ‘No!’….

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

See the bug? (click for a larger image)

See the bug? (click for a larger image)

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

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

Why?

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

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

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

The fix was changing from drawing lines to drawing triangles... (click for a larger image)

The fix was changing from drawing lines to drawing triangles… (click for a larger image)

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

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

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

Whoops! That's not supposed to happen! (click for a larger image)

Whoops! That’s not supposed to happen! (click for a larger image)

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

Contour lines are now clipped to the map boundary. (click for a larger image)

Contour lines are now clipped to the map boundary. (click for a larger image)

Whilst in the contour system, I decided to update the code that deals with the elevation numbers to add a small enhancement:

Large contour elevations now have commas put in them for that more 'authentic map look'. (click for a larger image)

Large contour elevations now have commas put in them for that more ‘authentic map look’. (click for a larger image)

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

On the plus side, I can now manipulate contour thickness.... (click for a larger image)

On the plus side, I can now manipulate contour thickness…. (click for a larger image)

I’m not sure why anyone would want contours this thick, but hey, the system can now do them! ūüôā

Back in the main game the new contours perform flawlessly:

Contours - now in their 'All-Fixed' Edition! (click for a larger image)

Contours – now in their ‘All-Fixed’ Edition! (click for a larger image)

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

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

Laters

RobP

Satellite Imagery & Contours!

I wonder what's new here? :)

I wonder what’s new here? – Click for a larger image

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

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

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

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

When I went to test this functionality in the actual game, I found that it didn’t work ūüėź

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

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

The hills….

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

Option 1 - Show the hill and puke! or... Option 2 - Hide the hill and not know here it is!

Option 1 – Show the hill and puke! or… Option 2 – Hide the hill and not know where it is! (Click for a larger image)

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

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

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

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

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

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

No problems!

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

After a lot of hammering away this is the result:

Hills! Now with contours! :D

Hills! Now with contours and elevation numbers! – Click to view larger image.

Not too bad? Eh?

These contour lines are strictly optional and can be turned off to preserve the look and feel of the original system. Alternatively, you could go the opposite way and turn off the hills whilst retaining the contour lines:

The contour lines without the hills themselves. This style of map is very similar to the styling found in standard maps.

The contour lines without the hills themselves. This style of map is very similar to the styling found in standard commercial maps. Click for a larger image.

As you can see, this totally changes the look and feel of the map!

To allow the map designer to tinker with these contour lines, I had to update the map editor’s properties panes for contours:

The enhanced properties controls in the map editor!

The enhanced properties controls in the map editor! Click for a larger image.

It is now a tabbed control to accommodate all the other new controls!

Contour colour, opacity and even the position of the elevation numbers can be easily changed with this system:

Here I have changed most of the parameters to show off what can be altered on a contour. In this case, colour, opacity and elevation number positioning!

Here I have changed most of the parameters to show off what can be altered on a contour. In this case, colour, opacity and elevation number positioning! Click for a larger image.

With the contour system in place, it can now be used with satellite maps¬†to great effect ūüôā¬†In addition, all the built in features of Atlas are still available, such as Line of Sight:

All Ancient Armies functionality is still there. Here I'm carrying out a line of sight check across a hill. Green is visible, Red is hidden.

All the Ancient Armies functionality is still there. Here I’m carrying out a line of sight check across a hill. Green is visible, Red is hidden. Click for a larger image.

As always, things are a lot easier to understand by simply watching the video (best watched in HD):

Next week I will be fixing more bugs. Once they are all squashed, we can move forwards and upwards!

Laters

RobP