Changelog - picture heavy

[Andy ONeill]

Map Editor

Marching ants prototype.
This is a proof of concept animating dashes around a polygon.

[Andy ONeill]

Scenario Editor

Minor adjustments on menu items formatting
Changed piece size slider to use brass pointer template
Removed all allowdrop settings out the UI - dragging things round is now all using non standard approaches ( for performance) rather than "proper" drag drop.

[Andy ONeill]

ModelLib & Scenario Editor

There are several libraries ( dll ) which are intended to be used in the various exe.
One of these is ModelLib, the "model" in programming terms is the data being represented and this contains a class called Map. Which is (surprise) all about the map. This is where what terrain is where is stored and has methods to read that data.

In order to give orders to units we want the user to choose a unit and drag to a waypoint.
With a "rubber band" showing the line it would take. Just a line from start point to where you're dragging or moving the cursor.

This is gaming stuff ( I'm a business app developer ) so Ezra designs this sort of thing and knows about game specific things like working out what terrain a line crosses.

Maybe this is interesting to someone reading.
There's this thing called a Bresenham line algorithm https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm.
Which Ezra "just knows" about and explained is very fast.

I've been prototyping something to see whether this'll work or not.
I grabbed this guy's code:
http://ericw.ca/notes/bresenhams-line-algorithm-in-csharp.html
Which is nice and efficient, I particularly like the use of yield.

We don't have a game solution yet so I've temporarily bolted this onto scenario editor.
I needed 2 points. Somewhere to go from and to, so I used a retreat point as starting point.
Turns out that algorithm is very fast and takes less than a millisecond.
My machine has a fairly recent i5 processor so it's reasonably fast but I'm testing this in debug mode so which is slower than optimised code.




I'm using faked terrain checking with woods, water and swamp as invalid for anything.
On the top image you can see the line crosses woods and is an invalid move.
On the bottom image the line crosses nothing invalid and is OK.

You can also see some debug info I've put in top right.
I'm using a stopwatch to check performance and you can see the milliseconds and "ticks" elapsed. ms 0 means less than one ms which is fast.

Conclusion
The experiment shows excellent performance.
I'd expect even an old i3 and maybe atom would be fine with this.

[Andy ONeill]

Map Editor

I've been looking into the work which needs doing on the Map Editor.
This is very much a prototype stages app.
Some work will see it stabilised, improved and sharing common code.
Short of dedicating my life, this is always going to be a relatively basic sort of a drawing tool.
I think also that drawing the map is by far the hardest part of scenario design.

Which got me thinking.

Some of you may of course be graphics designers so it'd be nice if you could use specialised software.
Others may want more sophisticated functionality but don't want to pay a couple of grand and spend 2 years learning how to use it.
Maybe some are like me - a developer but not so much of a designer.
Some others will be OK learning a little and doing some manual editing for something to work
Maybe some are even wpf designer/developers and already know XAML.

My plan is to try and include all these groups and offer more.
More is always good.

There's a free piece of software called InkScape.
This allows you to produce "vector" graphics by drawing or tracing.
I use it a fair bit for tracing stuff.
You can also convert graphics files to InkScape friendly format.
Once finished you can save the result as a .XAML file.

That can itself be edited and previewed in xamlpad or visual studio.
Xamplpad is a very lightweight self contained exe you just copy onto your machine, it's free.
You text edit in one pane and see the results in another.
Visual studio community is a pretty big install but also free.
I develop using visual studio.

As an experiment I modified the map designer so you can optionally load such a file.
I then fired up my copy of InkScape.
Because someone already expended some years working on InkScape there are a huge number of options available.
I picked a "pen", width and fill colour.
I then drew a wiggly blue line in inkscape.
When I drew this freehand it gives me totally smooth curves.
There's huge flexibility.
I could move, rotate or manipulate that little drawing in almost infinite ways.

I didn't bother with any of that because I'm just experimenting now.
I just saved my wiggly line as xaml.

This gives a bunch of stuff in a text file which I had to eyeball.
From that I picked the "Path" out of my saved file and put it in a canvas tag of a new .xaml file.
I did this in NotePad as a .txt file and then renamed to .xaml.

Ran my modified map editor and clicked the button.
The result was as expected and I get a line on top of my picture.
Because it's a control of sorts I can add some functionality to the map editor to work with it.

You might be thinking "If it's just about editing a picture then can't I just use a scan and be done with it?".
That'd be fine except the map isn't just a picture
Each pixel is a type of terrain - a field / road / woods etc.
Each pixel has an elevation.
With such a path I can write code works out which bits of the map it covers.
Allowing the user to say this area here is water.

Conclusion

This looks to be a good way to offer optional functionality for the power user.
Not everyone will want to bother but those that do will get a very powerful tool with huge flexibility.

[Andy ONeill]

Scenario Editor

Investigating optimisation of pathing.
Pathing uses spatial A* and is a very expensive operation.
At the moment it's only used for couriers which will be an end of orders calculation.
Hence it doesn't really need to be super fast.
This is just as well because it can take a while.

I have this on a background thread and have experimented with multi threading the process.
The problem with that is it's no faster due to the expense of creating the necessary arrays per search.
I've neatened up the code but it's just on one thread.

[Andy ONeill]

Scenario Editor

Refactor on place and points labels.
This improves the look, uses a more sophisticated approach for the objects.
Added mouseover effect on these which increases their z-index so they can be overlapped and still readable.
There's an anomaly in the way these were positioned, but this is cosmetic and can be resolved as part of the map designer work.

Now with rounded borders, a faded drop shadow and will respect the size of the text within.
With Victorian fonts:


With plain:

[Andy ONeill]

Scenario Editor ( but will really only be used in the game ).

Replaced Pathing.
The original approach was a prototype but bugged, slow and could not be multi threaded.
It also only used very simplistic terrain efffects.

After trying several alternatives, Ezra gave me a bunch of links to investigate.
One of them eventually led to this library:
https://roy-t.nl/2017/08/01/A-Star-Pathfinding-nuget-package.html
This initially showed some promise.
It turned out to be bugged and prone to running out of memory.
This is a bit of a problem in a live game.

[Andy ONeill]

Scenario Editor

Some improvements to place labels and points plaques.
Replaced the bitmap images with clearer, easier to read vectors.
Although not implemented at the moment, the new approach would allow us to use different backgrounds or fonts for the numbers on the plaques.
Anyhow, this should make it easier to read for those of us with less than perfect eyesight and or when running on a small display.

[Andy ONeill]

Map Editor

Improving handling of empty place names.
It's inordinately easy to add one. The whole cannot-fix-mistakes-you-make needs replacing but in the meantime at least don't read empty ones in.

[Andy ONeill]

Scenario Editor

Stabilising pathing.
Also made some changes to terrain costings, simplified maths for diagonal moves and changed some types to integer for faster maths.

[Andy ONeill]

Map Editor

Planning new approach to map editing.
When you draw thoings on screen they will be retained as objects which you can then select, move round and probably adjust  points on them.
You'll be able to fix mistakes at any point.

Created new Solution and started.

[Andy ONeill]

Map Editor

Standardised and optimised grid line drawing.
Styled up the various drawing options.
Added fancy divider control


Shooting

Ezra and I have been discussing shooting.
And cannons actually, but let's just talk about effectiveness of shooting.
This is pretty good at short range then drops off.
Graphed effectiveness vs range should look something like:



Rather than try and work out an equation representing this, I think the most practical approach is to have an array with a multiplier per percent range.
It's probably a bit different one weapon system to another as well so maybe there's two or three curves to represent.
Since our aim is to make as much as possible user configurable, such an array is likely to be user editable.

[Andy ONeill]

Map Editor

Experimentation with patterns for a tree fill.
The prototype uses random combinations of png which is kind of limiting and so I've been working on using dynamically constructed objects.
A few of these look like:


The advantage of this approach is flexibility - the user would be able to pick colour and size of what fills a piece of terrain.

[Andy ONeill]

Map Editor

First iteration: drawing a forest.
The way drawing areas works is you select your tool ( or you will once things are beyond prototype stage ).
You decide where you want your area ( forest ) to start. Click and hold the mouse button, drawing an area as you move the mouse.
When you release the button, the shape completes automatically. It's a polygon.
It's very difficult to "close" a shape precisely, so this approach means you just need to get near the start point and stop rather than absolutely hit it.

After some experimentation, I reckon the most "natural" looking way to do this is to randomly place the trees.
I do this by hit testing, within the area and not on a tree.
The size of trees is varied randomly and I'm using just one of several tree options.
Hit testing is quite a processing expensive process and of course as it progresses, there's less and less area it can drop a tree in.
As a result, it takes a few seconds to fill large areas.
Maybe I'm a bit weird or maybe it's because I wrote the code does this but I find it quite satisfying watching my forest grow.

This isn't going to give you trees perfectly up to the edge so I apply a background.
This is a texture generated at run time. The way this works, we could allow a user to pick the colours and proportions ( or not bother ).
So if your forest floors should be transparent then no problem, if you prefer a mix of browns or greens or everything sepia then this is all do-able.

As you draw an area you get an effect called "marching ants" the dashes animate around the outside. This will be used to denote the "active" selected area when you have multiple pieces of scenery on the map.
Once you finish you'd de-select your last piece and the finished map would have no dashes.
Unless of course you like em ;^)

The complete effect at 60%

A chunk at 100%

[Andy ONeill]

Map Editing

More work on the algorithm used to place trees. The size is now reduced as the process runs.
Put a panel over the various options whilst the process is busy.
Added a quill-in-ink-pot indicator which shows how far through planting trees the proces is.
This runs quick for small areas but for large complex ones it can take a while.

"Spinner" wait indicator.
This is similar to the fairly common spinning petals used on web apps and appears on the right of the toolbar.

Line optimisation routine.
As you draw any sort of line on screen it generates a bunch of points. These are x y co-ordinates.
The aim of the optimisation is to remove unnecessary points.
It considers sets of three points in the line and uses some rather geometry to decide if they all line up.
It removes the central one if they do.
There's a 2 degree of variation allowed.