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

The Cores Cannea Take No More!

I’ve been away for a while as I have been rather distracted…

Do you know what it is yet?

Do you know what it is yet?

For those that don’t know, these are Virtual Reality (VR) goggles – in this case the HTC Vive. The more observant will just be able to discern the Star Trek Enterprise’s holo-deck!

I firmly believe that VR is the future. This is first generation tech, yet it puts one firmly inside the games and other realities that one plays. In the case above, I actually get placed inside of the holo-deck and it all just looks real – like you are really there! The feeling of presence is immense.

These kind of technical revolutions only happen once or twice a life-time, hence why I have been rather distracted by the whole thing. VR is quite literally a game changer and will eventually affect all aspects of life – its applications are not just limited to gaming…

Anyways onto Ancient Armies. What have I been up to? The image below provides the first clue:

Can you spot the subtle difference?

Can you spot the subtle difference?

For those of a technical persuasion you may have noticed the Commit hashes (6bb0638 and 6815d6e). What do these mean?

In my case, it is an outward indicator that my backend source control system has changed!

Once upon a time I used to use Perforce, but I have now switched to using GIT.

The old and the new!

The old and the new!

GIT has many advantages, but here are a few:

  • Faster, a lot faster…
  • Allows me to easily work offline – especially useful for my laptop.
  • Each machine has a copy of the repository, thus reducing the risk of losing both the source code and history.
  • Simple and easy branching – this makes coding experimental features a lot safer.
  • The Master repository is on an always-on fully raided NAS drive.
  • Switching between machines is very easy unlike the error prone Perforce.
  • Better Visual Studio integration.

The move involved a little juggling as I wanted to retain all my source code history. However, thanks to the wonders of the internet I have managed to achieve just that!

In terms of changes to Ancient Armies itself, the Line of Sight (LoS) system got a major overhaul, as have a few other subsystems.

Why the overhaul?

The original LoS system was designed to run asynchronously in the background whilst the game was running. This system ran very well where a game turn had enough real time in it to allow the LoS system to perform all its calculations at a high enough frequency.

However, I ran into three issues with this system:

  1. Not very scalable. The more units on the field, the more time it required to run its calculations. Given that a turn duration was more or less fixed, this could mean that the frequency of updates to the various units’ LoS would decrease as the unit count increased.
  2. Time compression reduced its effectiveness. The time compression feature can actually reduce the amount of time that a game turn plays out in. This impacts how many LoS calculations that the system can carry out. The higher the compression, the smaller the number of calculations run and hence the lower the fidelity.
  3. Chronos. The arrival of the new Chronos subsystem meant that all game calculations are now carried out prior to a turn. These calculations are relatively quick, which meant that even for a 1:1 time compression, the LoS Calculations never quite got  enough time to perform as often as was needed.

LoS is complicated in Ancient Armies. This is for a variety of reasons, but includes such things as the lack of coarse hexes that other games have, uniquely and variably sized units and also terrain that supported curves.

To its credit, the LoS system has been highly optimised over time, so for what it actually does it is relatively quick. But alas, for our needs, it was not quick enough.

How to get around this?

I decided to take a two pronged approach:

  1. Firstly, I would alter the code to auto-detect and fully take advantage of all the processor cores that are available on a user’s PC.
  2. Secondly, I would instigate an auto-scaling algorithm that would automatically reduce or increase the fidelity of the LoS system based on the user’s machine’s capabilities and the size of the battle being played out.

Of the two approaches, the first was by far the most difficult. My code would need to be able to run in multiple threads, in parallel, on all the cores of the user’s CPU.

Achieving this whilst maintaining data integrity and synchronisation across all the processes turned out to be a non trivial task.

Luckily, the .net platform can help out here, but alas, you need to be on at least version 4.0 to take advantage of the facilities on offer. However, up until now I could never get Ancient Armies to work on .net 4.0…

One day of hard graft later and I can report that Ancient Armies is now running against version 4.61 – the latest available to me 😎

In all, I have been working solidly all weekend to get this new and improved system up and running. Here are the fruits of my labour:

This is Ancient Armies on my gaming machine. As you can see, it successfully detected all 8 cores and spread the load between them! :)

This is Ancient Armies on my gaming machine. As you can see, it successfully detected all 8 cores and spread the load between them! (The peaks are from a turn’s LoS calculations) 🙂

It doesn’t look like much, but to have the ability to detect the number of processor cores and spread the work out amongst them took a lot of effort.

The upshot of these changes are that Ancient Armies can now fully take advantage of modern machine hardware architectures and will scale itself appropriately.

Even in terms of LoS calculations, the system can now detect how well it is doing (or not) and automatically scale the fidelity of the LoS system based on the hardware and battle size.

This means that the system will now always be quick, regardless of hardware configuration. The new system will also work well across all time compressions and battle sizes too! In fact the system has never been so fast or so accurate! 🙂

To provide further options for the user, I have also added an options screen where they can, if they wish, override the automatic settings for the LoS System:

The new Line Of Sight options screen.

The new Line Of Sight options screen.

The new options screen also provides plenty of information for each setting so that the user is empowered to tweak their systems to their liking. That said, the Auto mode is so good, that for most people, I would just leave it there!

That’s it for this week!

Hopefully VR won’t prove to be too distracting….

Laters

RobP

Say hello to Chronos!

Uh oh.... What's going on here?

Uh oh…. What’s going on here? (Click for full sized image)

Who or what is Chronos?

That’s a good question…

But first lets digress a little…

Many moons ago I tested Ancient Armies with a full Macedonian and Roman Army. The results in terms of performance was a bit of a let down. The whole game ran like an arthritic slug… 😕

I had known ahead of time that there might be issues as Ancient Armies has to perform many calculations for the high fidelity Line of Sight system. The complexity of these calculations is compounded by the fact that the terrain supports infinitely zoomable bezier curves. All of these calculations can suck up valuable processing time.

Luckily, I had designed the system to run with 30 second turns. This mechanic provided me with the option to add a turn processing phase later on should it be needed…

As things had turned out, it was most certainly needed!

Turn processing in action. (Click for full sized image)

Turn processing in action! (Click for full sized image)

The processing occurs when a turn is kicked off. By conducting all the heavy mathematics before the turn, I have effectively taken the load off of the system during the critical phase of animating the battle.

The result of this pre-processing is a super smooth frame rate regardless of battle size. As an additional bonus it also allows Ancient Armies to run on very modest machines.

Battles that used to be impossible to play with the old system are now gobbled up with ease on the new one! 🙂

However, as cool as this new functionality is, by far the coolest new feature brought to the table is the ability to watch full battle replays!

Ancient Armies now supports full battle replays too! 8O (Click for full sized image)

Ancient Armies now supports full battle replays too!  (Click for full sized image)

With Ancient Armies, one can now replay an entire battle and easily be able to navigate around that recording to re-watch certain sections.

This provides a means for players to save their most glorious moments! These recordings can even be saved with Line of Sight turned off (after the battle only) – even where Line of Sight was turned on for the actual battle! I’m sure that this feature will lead to a few surprises when players get to see what really happened in their battles!

So back to the original question…

What’s Chronos?

To put it simply, Chronos is a generic subsystem library that can record and play back pretty much anything… As such, it can be re-used for many other applications!

There you go – mystery solved!

Writing about turn processing, silky smooth animation and replays is one thing, but I think a video will paint a 1000 more words… (Best watched in HD)

Not bad for a few days of work! 😎

Laters

RobP