Slope costing

[Andy ONeill]

This update doesn't really fit in the changelog but I thought people might find it interesting anyhow.

I've been researching the effect of slope on movement.
As it turns out, this is a pretty complicated subject and it seems there's no military standard.
The nearest I can find is Naismith's rule.
That says that the time to add for a metre elevation change is roughly equivalent to 8 metres lateral travel.
This is for fit walkers who are rambling.
Soldiers will move slower and as the slope increases they'll slow more.
Not quite as much as I was originally thinking though so I've revised my planned costings down.

Part of the discussion about this touched on Austerlitz where Soult gave an oft referenced 20 minute prediction for a corps.
Turns out this was across a valley floor rather than up the Pratzen heights.
Along the way I found Austerlitz on google maps and downloaded some google maps data.

Here's the area on google maps.
Soult's predicted corps move was from the stream Goldbach to a line drawn between the villages Blaziowitz and Pratze.
The Goldbach is a stream - the one runs vertically through slapanice.
I think Blazowitz would now be Blažovice and Pratz Prace.

Here's the google maps link:

https://www.google.co.uk/maps/place/%C5%98%C3%AD%C4%8Dka/@49.1500399,16.7444888,13z/data=!4m5!3m4!1s0x4712ecc1e350035f:0x956d24070b7ba50a!8m2!3d49.1838418!4d16.7592828!5m1!1e4

The pratzen heights are that ridge over to the right.



I worked out some likely looking points for the top two corners of a map and downloaded some google data.
The result is probably bigger than you'd want if you built your own Austerlitz map but the richness of elevation data is quite interesting.
( Yes, I need to get out more ).



The google map is a subset of that  -  roughly the top left corner.
There will be some modern junk complicating the data there.
I don't notice anything which would have much significant effect on a game though.

[zu Pferd]

Hello Andy

very Interesting !
when will you know and how will you test?
second question
did you find a suitable working app to create a sat image map
(google maps pay version)

Laying down creeks and rivers would require some careful plotting?
My only experience with sat data was applied to Histwar map editor and there was a ceiling
where the 3D engine of editor could not go over and create
second point when it came for the units to slog it out over these steep elevation they did so
without any real loss in cohesion or speed of ascent.
Will the program take care of what is possible to climb, as in choosing to use a road instead,
and how will the roads correct or allow for the climb as they often are steep in themselves.
 

[Andy ONeill]

Hi,

That story with the 20 minutes quote now seems highly doubtful to me.
Something is wrong.
Comparing to the numbers from Nafziger's Imperial Bayonets it seems to be maximum speed you could expect on a perfect road.
And it's a whole corps rather than some small super fit light infantry unit.
It can't all be on an excellent road unless one huge column.
Which would then have taken time to Ploy Deploy.

It also turns out that as a costings test this route is not great.
It's unlikely to have more than a 30m "climb" in it.

This is what you find when you compare stories - history - to reality though.
History is often written by people who make stuff up.
Who interviewed people that mis-recalled or made stuff up.
Or simply have an inherent bias.

On map building generally.
The google maps download gets you elevation data.
You register and create a txt file with your unique key in it.
Google gives you a $200 a month allowance - I wouldn't expect "normal" usage to come anywhere close to that.
To reduce the effect of any anomalies this gets the data for every other pixel and then averages for values between them.

I looked into sources other than Google.
To generalise, these give you a thing called a geo tiff. Which sounds like a picture but is using the tagging mechanisms in tiff files to hold data.
The problem with these things is it's very difficult for a user to work out which piece of what file they need to use.
Making that sort of data consumable would be a huge piece of work.

There are some online sources give you a picture of wherever you like in the world.
All the ones I've seen are coloured.
You could use one of these as a source for greyscale import.
It will take a wide range of picture files and converts colour to greyscale.
So you'd be able to get some sort of elevation numbers out of one of these.
You'd probably do better doing some pre processing using a graphics package and converting to greyscale with higher contrast.

Ezra and I have different opinions on the "best" way to build a map.

He particularly likes the period maps you'd see in many history books.
These are, however, often quite different from reality.
You could maybe call these "sketch maps" because it's pretty obvious someone just sketched them out.
Maybe whilst in a local tavern.

These maps give you some interesting period feel kind of graphics and will often be familiar to wargamers.
And these are what our commercial maps will use.
In order to add elevations, an artist builds a greyscale representation of elevation.
This is then imported using greyscale import.
To add rivers, forests etc these are added either by tracing over the map as a background or using custom import.
The custom import is pretty much necessary to get a good match for a river whose width varies.
Custom import is kind of fiddly but basically the rivers are drawn and saved as a picture with a transparent background.
InkScape is used to "bitmap trace" that into vector representation and the geometry pasted into the custom import resource dictionary.
The import process is fairly straightforward if somewhat manual.
If you already had a map with rivers and water in a different colour to everything else you could "just" use filters in a graphics app to separate that out or you could use bitmap tracing via colour in inkscape directly.
The reason all that isn't just in the map editor is because of the huge extra functionality a graphics app offers.
It'd take forever to reproduce a fraction.

My own thinking is that getting the elevation map "right" is probably the hardest part of many maps.
Which is why I wrote the google elevation import.
There's a lot of fiddly detail in reality.
Once you have that the hypsometric layer shows you where all the hills and valleys are.
Google maps itself shows you where villages etc are now.
It got renamed but I doubt they moved Pratzen.

If you're doing imaginations and just want any old piece of land then you could choose a bit of real world or build something simple using just the shapers.

All sources are potentially going to give you step changes.
Google elevation is approximate - so you get noise values.
Greyscale only has so many levels in it and you can build something looks fairly smooth only to find it's not quite as smooth as you were hoping. It's therefore best to test what you have using tooling such as the terrain visualiser.

You can round everything off a bit using the new "smooth" shaper.

Back to the slope costing.
I've got the pieces done that work out what points a move will cross and to cost for each of them.
I'm about to bring all that together.
I then see what result it gives.
Compare that to Naismith and make sure a unit (of maybe 900 men in a formation all lugging packs and weapons) will move slower than a rambler.
But not super slow until it gets close to the limits.

[Andy ONeill]

I just realise I didn't cover some points there.

The elevations are now held as float.
Float is scientifically approximate - but that'd be less than a mm variation so it's effectively more accurate than we need.
It has decimal places and can hold a maximum way beyond what we'd need
340282346638528859811704183484516925440

The limit you're a lot more likely to notice is inherent to greyscale import.
There are only 256 levels of grey possible.
In theory there are 16bit greyscale but parts of windows will scale that to 256 levels.
Most battlefields aren't going to come near 256m of variation from lowest to highest but if you want to build one that does then the greyscale import will produce big steps between levels and just using a greyscale import will probably not give great results. You would need to smooth or use a different approach.

I have a costed best path algorithm you might have seen shown way back in the scenario editor.
A piece in close order line moves straight forward of wheels.
Or changes formation.
If a straight line happens to take a piece in line exactly down a road then it's base move will use road because it's the central point of a unit that counts.
This is arguable I suppose but working out what the entire frontage of a piece crosses, calculate the slowest etc is also arguably wrong.

Skirmish order and column can move straight or best path.
A best path move could be along road or totally road based.
That path calculation prefers roads.
It currently ignores elevation change.
Logically, a road should offer significant advantages over rough so that's good for couriers ( what it's used for currently ).
I've not decided exactly to do with full size units.
A reduced elevation change cost seems appropriate.