Changelog - picture heavy

[Andy ONeill]

Game


Direct movement.

Or movement without wheeling.

The piece spins around it's front central point and heads towards where your cursor is.

This is for pieces in formations Skirmish, Column, Small or none

HQ essentially do not have a formation and there is allowance internally for some sort of a unit which isn't HQ and also isn't a full sized unit.
Although not implemented (yet) this could be used for scouts, messengers etc.

This piece is in column formation and hence it will have the option to take the most efficient route or move direct.



It's perhaps worth mentioning that there are parts of the code which aren't fully implemented but are there with future change or expansion in mind.
Hence a unit type which doesn't currently exist is partly supported so it would be relatively easy to implement.
Sometimes this is because of a change of direction in design.

EG ADC or messengers were originally to be visible moving across the map with the potential for enemy to intercept them.
On further consideration we realised this would be a bad idea as it risked turning the game into chase the messenger. Which might be an interesting game of itself, but not really what we're aiming for.
The complications of messengers travelling to where a piece was when it set out and then trying to find where it had moved to in the mean time also seemed just an over complicated distraction.
Hence messenger time will be calculated at outset rather than having to calculate a series of moves as the adc tries to find his moving recipient.

Sometimes it's just something which was easy to add

Another example is the number of sides in a scenario.
There are 3 armies in a scenario internally.
You can't set the third one at the moment but this could potentially be used for neutrals or a third player ( Blucher at Waterloo eg ).

I've also started planning for order persistence and implementation.

[Andy ONeill]

Movement Animation Experiments

At the moment I have some raw data that's used to add arrows to the map.
I also have some raw costing data for these.
What I want is some way to persist these.
This is, however,  linked to how it will be used.
One purpose will be animating pieces around on the map as a turn is played out or re-played.
I already have a rough plan in mind for this but it's very detail light.
Best to experiment with this and see what happens with the various options.
Which is what I'm currently doing.

[Andy ONeill]

UI library


I've added a custom facing animation to the UI library.

Whilst exploring the various animation options, it became obvious there is no "straight out the box" framework animation which would maintain facing in the direction a piece moves.
As a result I built this class.
The animations will all use one standardised mechanism.
All animate the x and y co-ordinates and the facing angle.
They will all rely on using a "path" supplied.
This will be an arc for wheeling, a straight line for direct moves and a wiggly line for fastest move.
The x and y co-ordinates are fairly straightforward and work in a similar way to graphing or standard maths definition of position.
x is horizontal position and how far from the left
y is vertical position and ( somewhat unusually ) how far from the top
These are relative to whatever container the point you're defining goes in.

The custom code I've written essentially works out the direction of travel so a piece can be rotated to face the way it's headed.

[Andy ONeill]

Model

More work on sketching out turn and move persistence classes.
An order will translate into a series of things the piece should do.
Each will need timings, details of exactly where it moves when, what direction it is to face in and what posture it should adopt.
All these things for all pieces need to be such that they can be saved to disk as a save game.
When the game reads that save game back into memory, it must give the same result you expected.

The opposition probably have different plans in mind and will likely interfere with your carefully considered moves.
Things will happen part way through carrying out that move from a to b.
The timing of your moves vs the enemy will be important.
The game loop will need to work out if and when moving opponents see one another.
When they do so their posture will define what they do.
Or attempt to do.

[Andy ONeill]

Wheeling cost roll up

I have two sets of costings for a wheel.
One for the cells the mid point will move through.
Another for the cells the outer point will move through.
Usually the outer arc will be more expensive.
When that is the case we need the cost of the outer point totalled into the appropriate mid.

Initially I thought I'd just divide one by the other giving say 2.
Add up each pair of outer point costs and set the next mid point to that.
Add any over to the last.

This is too simplistic though.
My first try at this gave odd results.
When I took a look at what was happening this was because you get numbers like 89 mid and 177 outer.
177/89 = 1.988.
Just less than 2.
Meaning 88 outer points cost end up totalled in the last mid one.

I need a plan B.
Work with the amount of relative rotation for each from the starting angle.
Which is more complicated but will give a much more sensible distribution.


 

[Andy ONeill]

PointI
Fixing bugs associated with these.
This is the thing which is used to hold X Y integer co-ordinates.
There were problems working with these in collections and with adding the values to use them in a similar way to a vector.

Map
Bresenham circle fix, removing duplicates
A bloke called Bresenham invented several algorithms. These find the cells crossed by line or circle in a grid.
The original purpose being so you could print lines or circles on a dot matrix printer or old style monitor.
As it turns out, all the "standard" implementations of Bresenham circle returns duplicates.
This had some unfortunate effects in wheeling because I wrote code which relied on each point being unique.

These changes seem fairly stable.
With one exception.
After the first move, further moves with a significant wheel go wrong and start using the wrong start point.
That's either because.
Something was relying on a broken version of the above.
Or
There was a bug there already and I just hadn't noticed it.



Game
Wheeling cost: Rolling up the outer point cost into mid points when the total is greater.

[Andy ONeill]

Game

Whilst trying to fix a bug where the wheeling decides the wrong direction and heads off clockwise rather than clockwise I introduced a new bug.
The move handler stopped doing anything after the first move was committed.
This was because the timer wasn't being restarted after committing the move.
One line change but quite difficult to track down.
This is the problem with complicated code, and why I usually spend time trying to simplify what I've got after I get it working.
That's quite difficult to do with the move - it's inherently quite complicated.

Back to tracking the original bug.

[Andy ONeill]

Game

Wheeling direction fix.
Quite a relief to work out what was happening and fix this.

Wheeling calculates the cells in an arc between the piece's initial point and that which would be a tangent to where the piece should move.
In order to do this it uses a list of points for the whole circle and iterates through until it gets to an angle it's calculated as being correct.
If it goes the "wrong way" round the circle it will use the points outside of the best arc instead.
This is what was happening.
The problem was I'd written this initially and "just to get it working" used the original facing of the piece.
Which worked fine for one move.
Add in more moves and those looked ok, so long as you were always rotating in generally the correct direction.
I now use the original move or facing of the last committed move.

Which will break if I add undo or go back and select an arrow to add more moves.
We'll need a list of move (orders) anyhow.
I should probably refactor that implementation, ensure (end) facing is one of the properties and work with the last off that list.

[zu Pferd]

Hello Andy,
                I pray you are doing better healthwise.
I just got caught up with all the posts about the work you've done and doing.
Best Regards

[Andy ONeill]

Hi,

Thanks for your concern. I appreciate it.

My health is pretty much 100% now.
It's a weird thing BPPV / Labyrinthitis. And a right nuisance.
Initially it was just totally disabling.
Now I'm pretty much ok but it comes and goes as you're getting better.
I think "Hey... I'm fine." then one or two days later I wake up with the nausea back.
Doctor says this is usual and a slow recovery is expected.

The lack of game development progress is because I'm on a job search at the moment.
Between searching, applying and dealing with agencies ( who of course all have a fabulous requirement I am perfectly suited to ).
Revising for technical tests.
Doing those.
Company research, interview prep and the actual interviews.
There's not much time and energy left for much else.

Thanks.
Andy

[Andy ONeill]

UI Library

Converter optimisations.
This library has things commonly used across the suite in it.
There's a piece of code which is used to position things on the map.
I've changed the way this works and made it a single instance rather than one per usage.
That reduces memory usage and improves performance a tiny bit per usage.
There are, however, a fair number of usages so what would be a negligible effect on one thing is more significant with many.

[Andy ONeill]

Scenario Editor

Deferring the route calculation process.

In the scenario editor there is a "best route" calculation for couriers.
This is done for all subordinates when you mouse over a HQ.
This process is quite expensive since it's using a spatial A* algorithm to calculate the cost of each cell to the next in the possible routes from HQ to subordinate.
Although this is multi threaded a low powered machine can max out on concurrent threads.
Your full on i7 gaming machines will get through this rather faster but we want to allow for lower powered devices.

The real down side of this process is that it kicks in as soon as you mouse over a HQ.
That's convenient but it's quite easy to inadvertantly move your mouse over one.
Which'd be fine if this was sub second but you're talking more like 10 for complicated maps.
This is not so fine because you'll decide you want to save your scenario... Ooops....
You mouse over a HQ on the way to that menu.
And then those busy indicator petals are spinning and you're burning up cpu calculating routes you didn't want to.

There's more work to do on routing.
This needs to work for units other than just messengers.
In the mean time though I've applied the simplest fix which mitigates inadvertant mouse over.
I've deferred execution of the route calculation ( for 0.6 seconds ).
It then checks whether the mouse is still over the piece before processing.
This means if you're just moving on past a piece then it won't start up.
If you stop your mouse on the piece, it'll be there longer than the threshold time and the process still works.
Trying this out, the delay isn't particularly obvious so this feels like a reasonable fix.
At least for now.

[Andy ONeill]

Refactor

I've started work on least cost pathing for pieces moving in column.
Column is inherently a more flexible formation than line and a unit in column takes an optimum route rather than a straight line.
Our columns abstract the several different real world options of column of attack / division / march.

This was written and working for messengers and called from scenario editor.
I need to be able to call the same code from the game as well so it can't live in the scenario editor.
I've refactored the code and moved into the UI library which is referenced by all other front end projects.
Maybe it's just my imagination but it seems to run a bit faster.

This needs more work to cope with different unit types because it was designed to work purely for messengers.
There is only one set of costing and a messenger is assumed to be able to cross any terrain.
The cost is just very high for some terrain.
The same concept might be retained for other units.
A river would be a very time consuming thing for a battalion to cross.
They would do it eventually though if there was simply no alternative.

My Dad was in the Chindits in ww2.
Jungle river crossing was a routine necessity.
One lucky fellow swam with a rope and recce'd the far bank whilst some of the force covered from the friendly bank.
Once "clear" he would secure the rope and the covering force remained whilst part crossed.
Then the remains were covered by the majority.
In case an enemy force was on their trail, a "tail end charlie" remained behind on the new friendly bank covering the far one with a Bren gun for a while.

Dad's top tips:
Don't get picked to swim across first or stay behind.
Put your pack on up-side-down ( or you can't get out because you have a pack full of water on the far side ).

Anyhow.
Back to game building world.

I also noticed there's no gap between the "HQ" in a HQ icon and the outline.
Which makes it a little harder to read than it could be.
Since a piece is of course of variable size and you can't easily scale text these are actually a vector representation path.
Added 1px margin round HQ path.

[Andy ONeill]

Game

Added prototype least cost move for units which aren't in line.
HQ and column will by default take whichever route looks to be the easiest and fastest to where you want to move them to.
In the picture below you can see some of these moves represented by the bright red lines.



The process of calculating which is the best path is quick for simple moves like down a road where it's pretty obvious the road is your best option. When you are heading off into the weeds and hills the calculation becomes quite expensive and time consuming.
As I mentioned, this is currently a prototype version and I've pretty taken the code was in the scenario editor for and couriers slammed it in here.

The road routes were quick enough I didn't feel I needed any more feedback.
That route heading north around hills, took 2 seconds which is time to start thinking "did it do anything?".
This movement type doesn't have the "rubber band" effect that direct movement uses because that code path does a bunch of validation and calculations on the path. Least cost will try and go round invalid terrain so might be a valid route even if the direct line crosses a big river or something.

We need some other similar but visually different rubber band to show this is where you're headed.
Maybe also to flash or something as calculations are performed.

Additionally, the unit type should be taken into account for terrain costs.
There's just one set of costs at the moment.

In order to avoid terrain paralysing couriers, the current algorithm doesn't have absolute blocks. A river or cliff is "just" a very high cost per pixel.
That 1 pixel wide trickle of water will not totally block couriers.
A similar approach is probably best for units.

[Andy ONeill]

Unit Type Best Route Costing

I've started working out the best way to implement this.
At the moment, we have something which is designed just for couriers and one fixed set of costings.
What we need is something that will work with the movement rates specified by unit type and side in the scenario.
Long story short.... this is not easy.