Changelog - picture heavy

Started by Andy ONeill, January 02, 2018, 02:08:07 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Andy ONeill

Pieces

I've added a small line to the front of pieces.
This is similar to those you see on maps of this period, within the limits of practicality of the code base.

Whilst doing the slope work I found it's fairly easy to forget some of those pieces are in column formation.
The line makes it a bit easier.
I chose a line because a more complicated or bigger symbol would introduce problems.
This will also still appear in "game" mode where it might be between two symbols.
( Have to consider that, it might be best to hide this thing in "game" mode.)
It will also still be visible when two pieces are in close combat and could well overlay an opposing piece.
It's not hugely intrusive so I don't see that as a problem.

I tried various options starting with a plain black line.
What seems to work best is a gradient white to black or black to white.
I switch between these depending on the facing of the unit to try and give best contrast against the dropshadow.
And because it's white-black-grey some part of the line will always contrast with whatever it's on top of.


Andy ONeill

Scenario Editor and Model

Skirmish fix up.

Skirmish formation was a relatively late addition to the suite and it turns out I missed some stuff out.
This wasn't added to the default movement rates and you can only edit values already exist for these.
They were also missing off turn time visualisation.
The way that view works is you mouse over the area with the graph like bars on the right for a unit type and it shows you text and numbers in the left panel.
The section you mouse over is selected so it changes style a bit - so it's clear what matches.
Adding another formation made the content of that left panel too big, so I re-organised the buttons from a vertical stack to a horizontal row.
I considered moving the close button somewhere else but I don't see a better option.


Andy ONeill

Terrain Type Checking

On further consideration, not all the terrain types we need are covered by costs.
At least the default "Empty" needs to be costed for everything.
Part of the code assumes it will be costed as field.
This is incorrect and pretty much removes the value of having fields.
Fields are often particularly difficult going if ploughed or full of big/tough crops such as maize or grape vines.
OTOH some of the great outdoors is particularly rough and some scenarios might have better going in cleared areas around BUA.
This means more entries which means more space in that right hand column.
They're probably not all going to fit.
I need a different approach to displaying that data in the turn time view and times for more terrains.

AI Editor
I've been helping Ezra with hiding Pieces.
This is to do with fog of war.
Two players will will have a different subset of Pieces they should be able to see on the board and we need a way to drive hiding those not in LoS.

Elevation Costing
I've made downhill use half the elevation difference for costing.
This is arguably a simplification but similar enough to the Langmuir additions to Naismith which ramblers use.
And these rambling estimation methods are the closest I've found to military.



Andy ONeill

AI Editor:

Added a method Ezra can use to show / hide a Piece for fog of war.

Game

I'm part way through prototyping move costing in seconds.
The move and elevation change calculation itself need bringing together.
That's the easy part.
I'll do this initially as a prototype.
This will require substantial refactoring but enable me to check the results look OK before I start complicating things.

Why will it require so much re-factoring?
There are a lot of complications in this area which need resolving.
Such as hedges and walls should take longer to cross.
A close order formed unit should be dis-ordered and require time to dress lines.
A unit can't just instantly stack and un-stack when crossing a narrow constraint such as a bridge.
Just forcing into column to cross a bridge or ford is too simplistic though.
There are very similar situations possible with a gap between two lakes or woods etc.
At the moment, only the elevation checks stop a piece just moving straight into a fort.
Some thought needs to be given to what to do about the like of frontier "forts".
If your fort is just a wall then that's not even an elevation change.
Maybe this is OK though and an undefended wall should be cross-able.

Andy ONeill

Game
Provide default gradient for the facing line.
Initial prototype for move costing in seconds.
Baby steps are necessary for this due to the many complications.

Scenario
A number of changes to the default move values
Add move values for empty
Add default move values for artillery in line – this would be manual handling or prolonging. Although the latter is arguably as fast as limbered there'd be little point taking the time to limber and form into column if move in line is anywhere near as fast as column.  Dragging cannon by hand was fairly common and the only way 7yw battalion guns moved.
Change Supplies formation for move from none to column.

Game
Enable equality check by implementing iequality interface on movementkey.
This class is used as a key for the seconds per metre movement values.
The change is necessary to be able to look up values in that dictionary at all. Without it, the app doesn't know how to compare an entry and none match.

Map editor
More investigation on background "slip" bug.
I've never been able to reproduce this behaviour so it's guesswork what's happening.
I've made several changes might fix this.
One being to tighten up how the sub tasks process. The message saying it's saved should now only appear once that task has completed.
My advice would be not to shut down the app the instant after you click save.

Andy ONeill

Game
Make the front indicator appear on top of the unit icon.
There was a subtle difference between the the piece in scenario designer and game.
That made the new line I added appear below the icon.
Putting the white part behind the drop shadow made it harder to see on "downward" facing pieces.

Fixing some of the calculations in move costing.
Since this is complicated the inevitable bugs are quite tricky to detect and trace. 
Fixing each is fairly easy once you know there's a problem and where it is.

Andy ONeill

Efficiency Improvements

As we creep slowly towards a working game, the time things take needs to be considered.
If opening a map in the map editor takes say 5 seconds rather than 2....
This is no big deal.
This is a relatively rare thing and you expect it to take a while.

If working out how long it takes to move from A to B takes 0.5 seconds rather than 0.2.
This is a problem.
Certain things need to be as fast reasonably possible.
As always with software development this is a sort of a balancing act.
If it took 10 days work to shave 0.1 seconds off a process then that process would have to happen a lot to be worth the time spent.

Sandbox and ai editor
Add size property with default value to viewmodel for piece.
This size property is now used to drive the size of a parts of the icon in a piece as well as the obvious size of it. All the pieces are proportioned based on the size.
Size has been moved into the piece viewmodel for efficiency in the game.
You might think.... "this isn't the game."  but pieces of UI come from a shared library.

Started location refactor

Piece calculations such as move and sighting are done based on a Point struct which has double ( non integer ) values for X and Y.
Terrain and elevation, however, live in 2 dimensional arrays.
If you imagine a very fine grid laid over the map.
A given cell in that grid can be defined by X and Y where X is an integer offset right from the left-most column and Y is an integer offset down from the top row.
Any and all look ups for terrain and elevation values use integer values.
The 3d sighting code similarly relies on integer based locations.
Currently, those numbers are converted every time anything is done.
Each of those conversions costs a bit of processor time.
Not very much.
But there are lots of these and it's an avoidable overhead.
The plan with this refactor is to reduce down the number of times this happens.
This is something I would ideally have done this some time ago but we're where we are.
As it is, best to get this done before I write more movement code and firm up what I've got already.

Andy ONeill

Movement Costing

Translating some terrains such as wall to field.
Without this the movement cost lookup would fail to find any value and error.
Walls, hedge and Fences now add 3 metres to vertical cost.

Costed Move per PX refactor

Previously, a list of points and the total costs was returned.
Now returning a list with an entry per pixel, each has a cost for that specific pixel.
Also rationalised the code so wheeling can share the same approach and code.


Andy ONeill

Wheel Costing

Initial version calculating points and cost passed through for both mid and outer edge.
There's a bug lurking in there somewhere.

Andy ONeill

Wheel costing

Fixed bug, now getting values for both inner and valid values.

The background is explained in previous posts but in case you missed it or the significance wasn't clear:
When a unit wheels there were two lists of points calculated.
One for those the mid point of the unit passes through and another for the  outer edge.
You can see these visually represented (for debug and development only) by those dots in pictures above.
There were drills a unit would use to avoid problems due to "constraints" such as terrain blocking part of a wheel.
I still have to decide what to do about invalid terrain but it should not be as simple as bad terrain = stop.
But we don't want to allow wheeling to be used to cross a river or something.
That's something for another day though.
To minimise the opportunity for costing weirdness, I will use whichever total costs the most between mid and outer arcs.
This is likely to be the outer arc, because it's (obviously) going to be twice the radius of the middle and longer.

Reduced the cost multipliers for elevation change.
These previously scaled up. An exponential progression towards the maximum slope a unit can move seemed logical.
My progression scaled up less than exponentially.
Which seemed ( and still does really ) logical.
As you reach your limit it seems pretty obvious you'll slow disproportionately.
The cost curve should be sort of concave and maybe even an exponential progression.
In practice I was getting some quite high values for moves which didn't seem right.


Avoid costing any move which is invalid due to crossing invalid terrain.
This was producing a spurious error.
There is no cost for terrain a unit may not cross.
This is, of course, quite correct. No point in maintaining a cost that can't be incurred.
Because the costing code was always running during "rubber band" calculations this was trying to look up costs for all terrain. Including invalid terrain.

Andy ONeill

Scenario Editor

Add and set piecewidth property on the piece viewmodel as it's loaded.
Thought I did this previously.... but it seems not.
As previously explained.
In order to speed up rendering of each piece, components now uses this property rather than the more complicated way it previously found piece size.

Changed the slider mechanism so it now also updates that property in each piece viewmodel.

Andy ONeill

All

Apply Unit Type frontage multiplier to pieces in Game mode line formation.
This was previously not applied because scaling the pieces down doesn't leave much space in the icons when you have more than one.

The Simulation mode icons have always had a 0.7 multiplier for artillery.


Now the Game mode icons also have this applied.


If you've used the army editor or you "just know" the symbols used you'll be familiar with what each of these represents.
Just in case though...
Top to bottom the rows are Horse Artillery, Artillery and Infantry.

If you take a look at that little line middle top of each piece.
This is the "front" indicator I added.
On this light background the top end is almost invisible.
That's because it' a gradient white through grey to black.
On a light background, the black stands out best.
On darker backgrounds, the white will stand out more than the black.
Which means I don't need some "clever" code to work out what sort of background the line is against, whatever you have there will be some part of it gives reasonable contrast.
It's small because effective musketry range was very low.
In addition, the likes of zulu and cavalry were melee only and will move to contact.
Which means you can expect to see pieces very close or in contact with one another.
When that happens, the indicator overlaps the enemy piece.
A small indicator is then less intrusive.



Andy ONeill

Moving

Next up is to allow multiple moves.
I started this thinking it shouldn't be too hard.
Just make the start point to the last end point.
It seems there's rather more work to do than this though.

Andy ONeill

Model library

Added PieceLocation class
This will be used to work out the shooting and target points of pieces.
This has to work in the abstract rather than related to a piece's current position so it can cope with moves and encountering enemy part way through a move.
One of the bugs I found was related to calculating the two "ends" of a piece when it's going to wheel.
I took a short cut with that and this class is part of the refactor necessary to address that problem.

Game

Fixed (the obvious) bugs with multiple move input.
Seems reasonably stable now but could do with more test and maybe a bit more refactoring.

Below, I've clicked to commit two moves and the rubber band is shown for a third.


This is still prototype stuff.
Everything currently wheels, for example.
The "moves" are also not persisted in any way and we're going to need some standardised way to keep a list of orders:
Wheel 30 degrees, 120metres forward, wheel -24 degrees, wait until 4pm.

Andy ONeill

Game

A test-fix cycle following the multiple move changes.
Which seems remarkably close to stable in that I only found one immediate problem.

Avoid error when looking up invalid pixel costing.
This now returns a default cost which shouldn't ever end up being used but guarantees no crash.
There's a flag for valid move which is also set false.
Meaning you can't commit such a move.