Translations for our friends around the world.

Author Topic: Ancient Armies: by Rob Pollard  (Read 17895 times)

0 Members and 1 Guest are viewing this topic.

Online Asid

  • HAVOC
  • *
  • Posts: 26361
Re: Ancient Armies: by Rob Pollard
« Reply #15 on: August 19, 2016, 03:42:53 PM »


Bug Hunt!

Posted on July 31, 2016   


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! (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:


Read on: Click Here
funny
0
informative
0
Thanks
0
No reactions
No reactions
No reactions

I stand against Racism, Bigotry and Bullying

Online Asid

  • HAVOC
  • *
  • Posts: 26361
Re: Ancient Armies: by Rob Pollard
« Reply #16 on: August 19, 2016, 03:50:38 PM »


All Formed Up!

Posted on August 19, 2016


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!



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!


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 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.

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



Original post: Click Here
funny
0
informative
0
Thanks
0
No reactions
No reactions
No reactions

I stand against Racism, Bigotry and Bullying

Online Asid

  • HAVOC
  • *
  • Posts: 26361
Re: Ancient Armies: by Rob Pollard
« Reply #17 on: January 09, 2017, 12:16:24 PM »


Slipping Away…

Posted on August 29, 2016


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?


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….


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!


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.


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…


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



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?


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


Original post: Click Here
« Last Edit: January 09, 2017, 12:24:34 PM by Asid »
funny
0
informative
0
Thanks
0
No reactions
No reactions
No reactions

I stand against Racism, Bigotry and Bullying

Online Asid

  • HAVOC
  • *
  • Posts: 26361
Re: Ancient Armies: by Rob Pollard
« Reply #18 on: January 09, 2017, 12:23:27 PM »


Back on the Horse!

Posted on January 8, 2017


The new workplace!


I’m now back coding and designing Ancient Armies!

To aid with the ongoing development I bought myself a new development machine – A Microsoft Surface Book. This replaces my now deceased Apple Mac Pro.

I chose this machine because I was very impressed with them at my workplace. Plus having the ability to draw directly on the screen is essential for visualising the many geometrical problems that I have to overcome.

The fact that the screen also detaches from the keyboard to form a tablet is a bonus! All in all a very flexible machine!

So what have I been up to so far?

Firstly I spent 2 days designing how I was going to implement column based movement – both on road and off road. I also took additional time to design how movement orders will work for indirect orders – ie the orders you send by herald as opposed to direct command.

This is now all documented and safely stashed away in my Confluence system.

During the code research for the design work, I noticed that a few classes had got a little too big for their boots – yes Game I’m looking at you! As a result I invested some time to refactoring these so as to maintain a high level of code cohesion.

Refactoring is a perfectly normal activity and generally happens as a system evolves and takes shape. You can ignore the need to refactor, but you do so at your peril! The result can be an unmaintainable mess of code.

Although the design work for column based movement is now done, I will not start this new functionality until I have cleared down the backlog of bugs and issues that are still outstanding.

One issue I wanted to sort out straight away, is that I didn’t like the way the system automatically let the user side-slip a formation left or right. So I have modified the system so that the player must now make a conscious decision to side slip. This is achieved by simply holding down the side-slip key (currently mapped to left-shift), whilst issuing the orders.

If the side-slip key is not held down, the system will prevent the unit from side slipping.

In terms of bugs, the first one I ran into was this one:


Loads Desert Map…. Where did the overlay go?


Believe it or not this is the desert test map, which should normally look something like this:


Desert overlay in place!


It turned out that my overall approach to map overlays was way too simplistic. It failed to adequately accommodate the movement of files from system to system.

This bug only got discovered because Windows 10 on my new development machine gave me a different username from my other machines.

On the plus side, the system did fail gracefully – it loaded the map, but sans overlay. It was close, but no cigar!

The new overlay system is now much more robust.

When overlays are added to a map they are now imported into the system as opposed to merely loaded. Of course this in itself is complex as you need to be able to differentiate between images that are new and those that are already imported. Plus the system also needs to deal with the possibility that two different overlays may well have the same filename…

However, don’t fear! This has now all been taken into account and the system has been thoroughly tested.

So what’s next?

As mentioned above, I want to clear down the backlog before starting on the column movement functionality. There is a fair bit of work in there and I can see it potentially occupying a fair bit of my time.

If the bugs I’m fixing are relatively interesting, I will put up blog posts up about them. If not, you will probably hear from me in a few weeks time when I will declare that the backlog is empty!


Laters

RobP


Original post: Click Here
funny
0
informative
0
Thanks
0
No reactions
No reactions
No reactions

I stand against Racism, Bigotry and Bullying

Online Asid

  • HAVOC
  • *
  • Posts: 26361
Re: Ancient Armies: by Rob Pollard
« Reply #19 on: January 17, 2017, 07:18:54 PM »


Chasing the Bugs!

Posted on January 15, 2017


A lot of bugs have been squashed – but a lot of them have also been discovered…

As mentioned last week, my primary aim is to get the system into a relatively bug-free state prior to adding new functionality. The graph above shows that I fixed quite a few this week, but I have also discovered quite a few too.

Although no closer to starting the column movement code, it is still a good position to be in as I now have a system that has 13 fewer issues in it. Alas, not all coding can be glorious and exciting new functionality!

Most of the work that took place this week occurred in the Armies module – the module that models all aspects of units and armies.

The first ‘issue’ was this one…

Issues orders to cavalry units…


Starting positions for the default cavalry units.

Runs a 30 second turn and ends up with:


Errr…. What happened?

The units didn’t exactly move very far…

These kind of bugs can be quite hard to find as the system keeps track of a multitude of variables for each unit. These variables can be hard to follow because the system runs multi-threaded.

Luckily, one of the pieces of work that I also did this week was to update the formation classification system to bring it up to date with the current modelling.

The classification system puts a symbol on a unit to tell the user whether it is Open Order (OO), Order (O), Close Order (CO) or Dense (D). The idea being that a player can instantly see how tightly packed a formation is – something that would be impossible to tell just by looking at the unit.

This subsystem was very old and didn’t reflect what was really happening. However, this was rectified, resulting in units being properly classified.

That said, I should probably point out that the game does not use this classification – it knows a unit’s precise measurements – the classification is solely a player aid only.

In my case, the classification helped track the issue above…


Ah… That would be it…

When I zoomed in onto one of the cavalry units I saw that its density classification is ‘D’ or dense. That would explain why the units were having problems moving!

These units were created very quickly using default unit sizes, formations, frontages and densities. However, it would appear that these defaults don’t give you units that function well…

This defined my next task:

‘Update the defaults to generate units that function correctly when created!’

The result:


Starting positions with the new unit default sizes...

Note the defaults have made the cavalry units a lot larger. Ok, lets run a turn and see how they perform…


That’s more like it – there was actually some movement!

Bingo! All sorted….

Well almost….

The problem with the new defaults is that they highlight just how large the unit size variations can be. Alas, the Army Editor’s display window just couldn’t cope with some of these new sizes:


Oh – that doesn’t look right…

Damn! I’m missing a fair bit of the unit. Creating a Chariot unit results in the whole screen being filled by part of that unit! Not good at all.

Conversely, small units like a Roman Maniple became very small and difficult to see.

To fix this, I altered the code in that pane to automatically zoom the camera to properly show off the chosen unit. This code was not trivial as one has to work out apparent sizes in metres based on the camera distance.

Nevertheless it got fixed:


Much Better!

Perfectly zoomed!

Even small units are now zoomed correctly:


Even the tiny Maniple is now scaled appropriately!

The eagle eyed amongst you will have noticed that the window also gets a new scale in the bottom left so that users can more easily determine the size of a unit.

Fixes to tooling might seem a waste of time, but these tools are used to create the game assets – they will also be distributed with the game to allow players to create their own maps, units, armies and scenarios too….

Going back to the loaded scenario, I noticed another potential issue:


Classification ‘O’ (Order) – Really? A Macedonian Phalangite? You are kidding?

I thought ‘Oh No – the new classification system is broken already.’

Based on general wargamer bias and expectation, the Macedonian unit seemed to have an incorrect classification. Such a unit would at least be close order, if not dense!

However, after doing my research, I have discovered that this is in fact correct!

This is the default phalanx formation at 16 deep. The Macedonians didn’t even give it a name, because it was the ‘standard’ formation. However, some texts do refer to this formation as the Open formation!!! Woot! My system seems to have classified correctly!

If the above unit closes down to the 8 deep Pyknosis formation, as used prior to contact, the result is:


Pyknosis – classified as CO (Close Order) – Breaths a sigh of relief!

CO!!! Perfect. Closing the formation down further to the 4 deep Synaspismos results in the system correctly classifying it as ‘D’ or dense.

Of course, when I did my first formation change, I noticed a bug where the visible model’s density classification was not being updated. But this was a trivial issue and easily fixed.

So what’s planned for next week?

Well, I now have two big issues I need to look at.

First up is the text on the units. These don’t seem to be created at the correct sizes anymore. The font is either too small on large units, or too large on small units. I suspect that this is due to Windows 10 DPI scaling – most machines seem to be set to around 150%.

Fixing this issue will be difficult, but it is one that will need addressing as the unit text is the system’s primary way of communicating unit information to the player.

The next issue is related to the potential ‘bug’ described at the top of this blog entry….

It seems that Ancient Armies has got to the point where there are many subsystems acting on each unit. These affect a multitude of hidden variables with results that sometimes seem counter-intuitive – like in our example above.

However, debugging these issues is difficult as one really needs to see these variables changing over time to fully appreciate what is happening and why. This is made all the harder by the game being multi-threaded.

Luckily, Ancient Armies already records everything, all thanks to Chronos that was fitted last year. So the information is available, I just need a way to display it.

So one of my next tasks will be to create a debug monitor application. One that I can run on a separate computer that will monitor the game running and display graphs and debug information for each unit.

This will be a non-trivial task that will take a fair bit of time to complete. At first, this might seem to be a frivolous thing to do, but it will save a lot of time in the long run. This is because with such a tool I will be able to see what’s happening inside the units in realtime so that I can assess whether what I’m seeing is intended behaviour or not.

Going forward, the system will only get more complex, so a monitoring tool like this one will become critical to speeding up development.

So that’s my tasks fixed for the next few weeks! Sorry column movement, I will visit you eventually! Honest!






Laters

RobP


Original post: Click Here
funny
0
informative
0
Thanks
0
No reactions
No reactions
No reactions

I stand against Racism, Bigotry and Bullying

Online Asid

  • HAVOC
  • *
  • Posts: 26361
Re: Ancient Armies: by Rob Pollard
« Reply #20 on: January 30, 2017, 04:28:21 PM »


Telematics – Done!

Posted on January 29, 2017


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 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…

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


Original post: Click Here
funny
0
informative
0
Thanks
0
No reactions
No reactions
No reactions

I stand against Racism, Bigotry and Bullying

Offline Attila

  • Sr. Member
  • ****
  • Posts: 450
Re: Ancient Armies: by Rob Pollard
« Reply #21 on: January 30, 2017, 06:10:39 PM »
Thanks for the posting, very interesting technical view of a development.
funny
0
informative
0
Thanks
0
No reactions
No reactions
No reactions

Online Asid

  • HAVOC
  • *
  • Posts: 26361
Re: Ancient Armies: by Rob Pollard
« Reply #22 on: January 30, 2017, 06:11:34 PM »
This is one of my most anticipated titles.
funny
0
informative
0
Thanks
0
No reactions
No reactions
No reactions

I stand against Racism, Bigotry and Bullying

Online Asid

  • HAVOC
  • *
  • Posts: 26361
Re: Ancient Armies: by Rob Pollard
« Reply #23 on: March 17, 2017, 12:51:10 PM »


Welease Wodewick!!!

Posted on February 26, 2017

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.



Read on: Click Here
funny
0
informative
0
Thanks
0
No reactions
No reactions
No reactions

I stand against Racism, Bigotry and Bullying

Online Asid

  • HAVOC
  • *
  • Posts: 26361
Re: Ancient Armies: by Rob Pollard
« Reply #24 on: March 17, 2017, 12:55:35 PM »


A Wee Bit of Engineering!

Posted on March 16, 2017


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. :/

This is unusual for me; 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! (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)

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 that 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


Original post: Click Here
funny
0
informative
0
Thanks
0
No reactions
No reactions
No reactions

I stand against Racism, Bigotry and Bullying

Online Asid

  • HAVOC
  • *
  • Posts: 26361
Re: Ancient Armies: by Rob Pollard
« Reply #25 on: August 26, 2017, 07:54:57 PM »


Column movement development has started!

Posted on August 20, 2017


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!

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

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!

This might seem to be a trivial issue, but alas, we are dealing with mathematical curves that are actually composed of many triangles:


*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…

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


Original post: Click Here
funny
0
informative
0
Thanks
0
No reactions
No reactions
No reactions

I stand against Racism, Bigotry and Bullying

Offline Raied

  • New member
  • *
  • Posts: 35
  • New member
Re: Ancient Armies: by Rob Pollard
« Reply #26 on: August 27, 2017, 07:07:01 AM »
Ahhh, I was following that long time ago and just remember it again, very slow progress, but if the game happens it will be the best ancient game,
funny
0
informative
0
Thanks
0
No reactions
No reactions
No reactions

Online Asid

  • HAVOC
  • *
  • Posts: 26361
Re: Ancient Armies: by Rob Pollard
« Reply #27 on: August 27, 2017, 05:06:43 PM »
very slow progress, but if the game happens it will be the best ancient game,

Agreed. I am really looking forward to this  :thumbsup
funny
0
informative
0
Thanks
0
No reactions
No reactions
No reactions

I stand against Racism, Bigotry and Bullying

Online Asid

  • HAVOC
  • *
  • Posts: 26361
Re: Ancient Armies: by Rob Pollard
« Reply #28 on: August 29, 2017, 04:13:08 PM »


Column orders symbology – Done!

Posted on August 29, 2017



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 that into the orders system so that I could easily review and test these 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….



… 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.


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



Original post: Click Here
funny
0
informative
0
Thanks
0
No reactions
No reactions
No reactions

I stand against Racism, Bigotry and Bullying

Online Asid

  • HAVOC
  • *
  • Posts: 26361
Re: Ancient Armies: by Rob Pollard
« Reply #29 on: July 17, 2018, 12:15:29 AM »


It’s been a while…

Posted on July 16, 2018



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!


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. 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. 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. 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. 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…



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!



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

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.


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.

Read on: Click Here
funny
0
informative
0
Thanks
0
No reactions
No reactions
No reactions

I stand against Racism, Bigotry and Bullying

Tags:
     

    Aggressors: Ancient Rome

    Started by Asid

    Replies: 31
    Views: 17498
    Last post December 18, 2018, 01:20:54 AM
    by Asid
    Ides of March Promotion - up to 75% discount on Ancient Rome Games

    Started by Asid

    Replies: 0
    Views: 1795
    Last post March 09, 2020, 11:41:45 PM
    by Asid
    ancient steel shadows frontier

    Started by zakblood

    Replies: 2
    Views: 2512
    Last post November 26, 2018, 11:00:22 AM
    by zakblood
    Ancient Arenas: Chariots

    Started by Asid

    Replies: 0
    Views: 1689
    Last post May 15, 2022, 11:13:02 PM
    by Asid
    Ancient Frontier

    Started by Asid

    Replies: 0
    Views: 2791
    Last post February 13, 2019, 02:10:52 AM
    by Asid