Changelog - picture heavy

[Andy ONeill]

Pathing

I changed a number of fundamentals in the spatial A* code and it now runs rather faster.
Processor and memory cost of running multiple calls at once is also substantially reduced.

If you choose a route which is logically unreachable due to water or cliffs or something then it can still be a little slow as it finds bad route after bad route.

There are still a couple of optimisations I could still try but I'm now out of time.
Might see if I can fit those in over an evening or two through the week.

For example.
Currently I ignore a possible cell if it's the one I just came from.
I could ignore that and ones to each side.
So if travelling north east, I'm ignoring SW but S and W are probably not going to be good directions to head in anyhow.

[Andy ONeill]

Pathing

Improved the algorithm working out addition to add for slope.
This is one of the more expensive parts of costing a cell so anything that makes this work any faster is worth while.
I have now reduced the cost of the calculation by pre-calculating a tenth of the metres per pixel.
An increasing cost is applied by looping up to ten times subtracting that from the difference and adding a cost each time until the difference is less than zero.
If it loops ten times and what's left is still over the metres per pixel then this is a big jump and a cliff or something so add a bigger value to cost.

Downhill is halved by * -.5 first.
A road cell ignores this process entirely.
Roads should always be best.

This pathfinding process is used purely to find a route.
Scenario based costs will then be applied.
These are more costly to process and that was a large part of the problem with the old version.
There is the potential someone chooses to make mud easier to traverse than roads or something.
The fix for that atm - just don't do that.

[Andy ONeill]

Spatial A*
Removed some code and data which is now unused.

Animations
I've been experimenting with some options to make the wiggly line you get for best path look a bit more interesting.
First couple of things I tried didn't give good results.
But that's kind of the point in trying stuff.

[Andy ONeill]

Game

Arrowed best route paths.
Previously, you just got a line for best path moves.
You now get an arrow on the end.
I've outlined everything in black like the direct move arrows.
I also changed from purple to red or blue matching the piece's side.
Ezra didn't like purple.



This is still somewhat experimental.
Internally, the arrowhead makes this trickier than you might think as the whole thing is now a shape.
When you fatten up a line to give it breadth, it also adds similar length.
I needed to chop that extra bit off the end, calculate and combine a triangle.

[Andy ONeill]

PathFinder

Now prefers to keep heading in the same direction.
This reduces the tendency for kinks, particularly in road movement.
If you look closely at the paths in the above post you'll notice the direction of travel can wander a bit at road junctions.
The algorithm didn't particularly care about moving in a straight line previously but now does.



Which doesn't completely remove the possibility of kinks, just reduces them.
Might have to consider a different algorithm.

[Andy ONeill]

Scenario Editor

Changed heading on edit move rates to make it clearer it's metres per minute.
Neatened up the view.
This has the same style scrollviewer as everything else which means it's narrower and there's still room for the original wider scrollviewer track.
That's still there but I've hidden the border that's around the containing control so it's less obvious.

Below you can see some of my development environment behind the scenario editor.
I've used psr to capture the cursor as the tooltip for the heading is shown.


When I just mouse over the area immediately to the right of the datagrid, the scrollviewer "thumb" appears.



Think I explained this elsewhere but you can drag that rounded rectangle up or down to scroll.
You can alternatively click the area above or below it on the "track" and that'll scroll.
With your mouse over the datagrid you can scroll up and down using the wheel on your mouse.
Or you could click a cell and arrow up / down.

[Andy ONeill]

PathFinder

I've added two steps of post processing applied to least cost paths in order to smooth them out.
Not sure I've explained why kinks are bad.
Why bother with all this stuff?
Any kink in a path will be particularly noticeable for a piece moving in column because they'd wiggle noticeably as they animate.

First step.
Something called a "string pulling" algorithm.
Not a name I made up but the intimation is you pull on a wiggly piece of string and it tends to straighten.
This goes through the list of cells and looks for one which is at least as good but more directly towards the target.
It has quite a subtle effect.
Although it's doing some expensive maths it's processing far fewer cells than spatial A* so is low cost.
Sample routes took 6 or 7 milliseconds extra.
Which you're never going to notice.

Second step
I built something which looks for straight lines in road movement.
Straight roads are one of those things you'd particularly notice kinks on because you've got a straight line to compare the move to.
And why would you weave around on a road anyhow?
Drunk Colonel?

This loops through the list of cells.
If it has a road cell it looks ahead 17 cells ( roughly half one of those squares on a map ) and sees if that's road as well.
If they both are then maybe this is a straight piece of road here.
It sees if it can draw a straight line between them which is all through road cells.
If it can then it uses those cells.
This process is very lightweight and even faster - took under a millisecond on most routes I tried.



Maybe stating the obvious.
I'm still part way through developing this thing so I can do things won't happen in the finished thing.
Here I have done moves for both sides.
In the completed game, you won't be able to see the enemy orders or tell them where to move.
Hence you'll only see red move arrows if you are red and blue if you're blue.

[Andy ONeill]

Map Editor

Improvements to terrain visualiser.
To recap how this works.
This gives you a view on a slice through your map between the two scope sight points.
Each pixel of the map is represented by a narrow band intended to give you an idea of what terrain and elevation each has.
The outline this gives will not give a true scale impression of elevation differences and is intended to emphasise these so unintentional steps or cliffs stand out.
Each band is colour coded.
If you mouse over this selects whatever band is under your mouse and you see more information, including what terrain type that band is.
One particular usage is to see whether your river is at the lowest point in a valley.
You will also see a "spot" appear on the map which shows you where that band corresponds to.

Last time I was working on this thing I ran out of time and never quite got back to fixing up some things.

I moved the terrain band description over to the left.



The up-down arrow over on the right top is there to allow you to see the distribution of height-difference-steps along the line.
If a lot of these are your scale or more then you have cliffs and you need to do something or your little men won't be able to climb round your map.
The shaper smooth tool is a fairly easy option.
Anyhow.
Click that up down arrow and a datagrid appears in a popup.



The counts are of elevation differences between cells along your chosen line.
These are rounded to 1 decimal place and totalled.
0 means the cells are the same height.
High numbers of high numbers are bad.

If you have a lot of elevations then this datagrid will be scrollable.
You close that popup by clicking somewhere else other than the popup.
Until you do that the popup is the thing you're expected to interact with and there will be side effects - eg mouseover effects outside the datagrid will not work.

I also increased the base opacity of the slope layer.
This is the white and black layer intended to allow you to make elevation difference look a bit more interesting.
Reminiscent of the terrain layer in google maps.

[Andy ONeill]

Validation Prototype

The idea of this is to tell you when the thing you're building has fundamental issues.
This is just a reminder so it doesn't try and tell you what to do to "fix" anything and doesn't stop you carrying on with whatever you want to do.
Usage is therefore entirely optional.

It works by using a set of fairly basic generic tests which (when run) return a true = ok = tick or false = not ok = cross.
Each has a description.

The process is necessarilly "dumb" in that it always runs all checks and always just returns that true/false.
It doesn't do anything as well as it's check.
So doesn't care if you have a totally empty scenario or whatever.
Everything is run every time.
The approach itself is generic so it can be used in any app within the suite by "just" building a set of checks specific to that.
At the moment I have just 3 prototype checks.

If I explain exactly what one of these is doing.

Blue pieces is a header grouping checks.
There will be other ones, eg red pieces.

"All pieces on board".
Looks at all the blue pieces you have.
A piece has a flag "IsOnboard" which will be true if you've dragged it onto the board ( map ) to a valid position.
If none of these are false then that check passed and is ok.
No blue army?
There won't be any blue pieces to not be on the board.
It's going to pass.



Checks are run when you load a scenario or click the button in the header with the refresh icon.

Does it matter if a commander isn't on the board?
Yes.
You will have a broken game.
A combat unit needs it's commander to be on the board because loading units into pieces follows that hierarchy.
When you load a game, a combat unit "orphaned" will not appear in your game.
How do you work out which to fix?
Most scenarios will use most or all units and they're reduced to half opacity once dragged onto the board.
If you look at your oob treeview there will be that CO fairly obvious because it's full opacity and those on the board are half.

If I remove hooker off the map and take a look at the oob:



It's fairly obvious where the problem is once I know to go look for it.

You might think "hey... why don't you do other stuff like tell me which piece is the problem?".
I could have done that.
But each of the problems has the potential to be different.
I'd have to inject some extra generic functionality which could do different stuff for each.
Which would take longer.

As I review that screenshot.
I'm reminded that the treeview in the scenario editor is still the original style with pointy fingers eating up space.
I probably ought to take a look at that.

[Andy ONeill]

Scenario Validation

More checks.
I've refined the initial ones I added a bit so they fail if there's no pieces.
Added dropshadows to the tick so they look a bit more interesting.
Made the checking more reliable by rebuilding things each time you click the button.



I noticed that the meters per square was shown to two decimal places, which is rather excessive.
Changed that to zero decimal places and standard numeric display which will show thousand separators.


The bright green box is added by problem steps recorder.
If I instead used my more usual alt + print screen to capture the display the help menu would collapse and you couldn't see it.

[Andy ONeill]

Scenario Editor

More validations.
Looks like this is done now.
Usually, this is when I notice that thing I just finished is bugged. 



Bug Fix
Scenario start time wasn't working quite right.

[Andy ONeill]

Bug Fix

The path smoother was occasionally raising an error.
This was because it was a single instance ( static ) class with a single swap list.
In the scenario editor when you mouse over a CO, it works out the courier routes to all sub ordinates.
This is something which will be removed before distribution but allows me to easily test multi threaded pathing.
Glossing over the intricacies of threads this spins up multiple processes path finding processes at once.
Each of which will then get a bit of smoothing.
If two of them happened to try smoothing at once then they both grabbed the one collection and bad things happened.

In the game, I'll want to be able to process multiple pathfinding at once for things like calculating when AI orders arrive at units.

[Andy ONeill]

Map Editor



Added data checks.

[Andy ONeill]

Scenario Editor

Changed the oob treeview to the same style as used in the game.
As there, unit names are much more likely to fit without you needing to slide left on the control.
You toggle expanded or collapsed for nodes by clicking the unit icon.
Except combat unit icons, of course, which have no children.



In the above, I temporarilly removed a few pieces from the board.
Their nodes are full opacity whilst the rest are half opacity because those pieces have been dragged onto the board.

[Andy ONeill]

Scenario Editor

Changed default internal start time to 9 am.
This in turn means the check for time change is more reliable.

Fixed a checking bug relating to victory kills requirements.
This was a "classic" cut and paste error.
Both the red and blue checks (previously) used blue data.
I wrote one, copied it and failed to change the variable used.

Also removed the automatic runs of the checks.
You need to click the button to run them.
This makes it more obvious they're not somehow dynamic.