GrogHeads Forum

Game Forge => General Staff Support Forum => Topic started by: Andy ONeill on January 02, 2018, 12:08:07 PM

Title: Changelog - picture heavy
Post by: Andy ONeill on January 02, 2018, 12:08:07 PM
Hi all.

The idea of this thread is to list the development work as it's done on the General Staff suite of apps.
This will be fairly low level stuff. I expect parts will not be very easy to follow unless you know the apps well.
Version numbers will eventually start appearing.
This way it should be easier for early adopters and beta testers to see what's in each change and Kickstarter supporters can see things are being done.
Higher level descriptions of work including significant milestones will be posted to Ezra's blog.

The thread is likely to get quite long and demonstrate just how dull most development work is with numerous iterations before you see Ta Daaa.... this bit looks like it's working... oh... well now it looks like it's working.... oh, wait a minute... better fix that bit.  And so on.

Much more of a crawl with occasional detours in the wrong direction than a sprint to the finish.

If you have questions, expressions of admiration  ;D or whatever then please start a separate thread.
Thanks in anticipation.
Title: Re: Changelog
Post by: Andy ONeill on January 02, 2018, 12:18:58 PM
Army Editor

These changes are intended to make it easier to work with the army editor when the window is narrowed. So you can work side by side with reference material, spreadsheets, Netflix or whatever.

Gridsplitter added between left treeview panel and right detail panel. Hover over the divider to see double headed arrow, click and hold to drag width left or right.

Items marked for copying now have saddle brown background and bottom border which is also increased to 2px.
The lime green selected item background overlays this but you can still see the bottom border and make out which are marked to copy without seeing the right part of the item.

Title: Re: Changelog
Post by: Andy ONeill on January 03, 2018, 12:48:29 PM
Scenario Editor

Minor changes to scenario info view.
Increased height of form so stacked controls have more space.
Scenario name textbox will wrap and grow if it fills but still limited to 50 characters so it fits on the main window OK.
Increase height of Scenario Description textbox and allowed it to grow as user types.
Added a little padding to number of turns textbox so victorian font numbers don't look cramped.

Title: Re: Changelog
Post by: Andy ONeill on January 05, 2018, 01:13:39 PM
Scenario Editor

Bug fix
For the victory conditions, you should see a list of target units to destroy under each army with a maximum based on how many are present.
These ought to be based on the enemy army.
Hence, if the red army has 8 light infantry units then under the blue army there should be a line which shows light infantry with a maximum of 8.
If you load just the red army and open the form, then you ought to only see a list of red units on the right side ( blue ).
This was previously the wrong way round - so you saw the blue totals under the blue army targets and the red under the red.
Very obvious once you know what to look for and load just one army, then open the victory conditions form.

Now fixed so the blue list of units appears under the red and vice versa.
Title: Re: Changelog
Post by: Andy ONeill on February 14, 2018, 05:05:06 AM
The current code base is still largely prototypical and some parts are pretty creaky. Bugged even.
There will be a lot of refactoring on existing code before it can be re-used in the game solution.

At the moment I'm working towards enabling re-sizing of the map board.
In doing this I'm also rationalising bits of code in order to simplify them.
Also with a long term eye on re-usability and multi threading for performance.

Scenario Editor

Refactored out all the "magic offsets" so the board, map pieces etc all go in one container within what looks like a frame you see in the right hand pane.
Removed several canvases that aren't needed.
Rationalised map background image loading.

Title: Re: Changelog
Post by: Andy ONeill on February 16, 2018, 01:21:02 PM
Scenario Editor

First iteration.
Refactor to replace drag drop of units.
I've ripped out the old drag drop code which was buggy and pretty nasty stuff.
The old version could not support stopping the user dropping units on invalid terrain or each other, which we want.
Started replacing with a simpler drag approach.
Further work is required.

The cursor isn't offset and unitvm isn't correctly added to the lists it needs to be added to ( I just realised this as I type ).
Maybe fix up with another iteration tomorrow.
Title: Re: Changelog
Post by: bayonetbrant on February 16, 2018, 01:24:20 PM
it's cool to track the development :)

Us non-game-dev IT weenies can appreciate the headache it can be
Title: Re: Changelog
Post by: Andy ONeill on February 17, 2018, 09:28:37 AM
Scenario Editor

Dragging units off the treeview and around the board is stable now.
I spent at least 2 minutes trying to break it and it just worked.
Way faster than the original drag drop and a LOT less code.
Buggy unexpected dropping - gone.
The improved performance is particularly pleasing. I can drag a unity as fast as I can move the mouse and it just copes.

Not quite finished yet.

To do.
Invalid location like off board in swamp or water or another unit still needs handling.
Probably stick a fews seconds red flashing border on the unit and then it's gone if the user doesn't grab it.

Title: Re: Changelog
Post by: Andy ONeill on February 18, 2018, 03:58:46 AM
Scenario Editor

Minor refactor:
Both retreat point and pieces now use their center X and Y for positioning and the same contentpresenter style.
This simplifies/improves some of the code used for positioning and pathing.
Also another minor step towards allowing the user to dynamically scale them.
Title: Re: Changelog
Post by: Andy ONeill on February 18, 2018, 12:03:41 PM
Scenario Editor

Added bad terrain and collision detection for unit locations.
When you stop dragging, it checks what terrain applies and whether that unit type is allowed in that terrain.
It also checks whether another unit is overlapping.
And whether the unit is entirely on the board.
If any of these fail then the border is set to red.
If you don't move it within 4 seconds the unit is removed from the board.
Title: Re: Changelog
Post by: Andy ONeill on February 19, 2018, 03:16:28 AM
Scenario Editor

Bug fix:
If you dragged a piece that was already on the board, it was being added to the PiecesOnBoard collection again.
Anything in there is templated into a piece meaning there were actually 2 pieces where you'd expect one. As they were all stacked on top of one another it looked just like one. But odd things happened.

Dragging a unit already on board seemed a bit sticky to start off with.
This was due to only starting drag when the user moved over 2 so many pixels at a time.
A piece is relatively small though and the tendency is to start slow. Too slow.
Removing the minimum move check fixed the problem and doesn't seem oversensitive if you just click.
Laptop mouse pads might be an issue but designing a scenario without a mouse doesn't seem very practical anyhow.
Title: Re: Changelog
Post by: Andy ONeill on February 19, 2018, 08:13:35 AM
Scenario Editor

I've added scaling of the map board.
There's probably more to do, but it seems stable at the moment.
Anyhow, as you drag the corner or edges of the screen the map "board" will scale to fit.
It retains it's proportions.
In the below, I've dragged the size of the window down, reducing height proportionally more than the width.
This means you'll get a gap either side of the board if you're not careful but gives you total flexibility.


I've also (since taking that screen shot) horizontally centered the elevation and terrain textblocks.
Title: Re: Changelog
Post by: Andy ONeill on February 19, 2018, 01:32:55 PM
Scenario Editor

Minor refactor on piece dragging to reduce overhead.
Narrowed the scope of the piece dragging routed event handlers.

Refactored a load of mapping orientated code out of the mainwindow code behind into
Needs to be re-used in the game exe. Eventually.

Refactored out a number of public variables from mainwindow.
Title: Re: Changelog
Post by: Andy ONeill on February 20, 2018, 04:07:28 AM
Scenario Editor

Added user notification mechanism.
Textblock in menu bar shows a new message which then fades out.
Neatened up the "busy bee" which is used to show a long process is busy - during pathing calculations at moment. Now yellow with fine black outline rather than red.
Moved map scale and size to help menu

Added user messages explaining why drop location of piece is invalid.
Refactored some code around pathing.
Fixed pathing error when you drag HQ which is off board.
Title: Re: Changelog
Post by: Andy ONeill on February 20, 2018, 09:23:47 AM
Scenario Editor

Added Scaling of Pieces and Retreat Points.
There's a new slider in the preferences menu which you can drag. It goes from 20px to 80px, the default size is 35px. A px is a "device independent unit" and in theory 1/96 of an inch. Windows user settings alter that though.

The combination of Window resizing and Piece scaling should mean the game is usable on most sensible set ups.
At the risk of stating the obvious, there is only so much you can do on this.
Scaling units can make them bigger and they could then in theory overlap each other.
Bad things are likely to happen if you played a game like that.
In the below picture, I first reduced the size of the window down so it's pretty small.
That scales everything on the board down, which makes pieces tiny.
I then maxxed out the piece scaling.
The screen shot is just to kind of give you the idea, it's resized to 60% of size in case anyone cares about bandwidth.

Title: Re: Changelog
Post by: Andy ONeill on February 20, 2018, 12:10:02 PM
Map Editor

Marching ants prototype.
This is a proof of concept animating dashes around a polygon.
Title: Re: Changelog
Post by: Andy ONeill on February 21, 2018, 03:09:56 AM
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.
Title: Re: Changelog
Post by: Andy ONeill on February 21, 2018, 05:10:32 AM
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 (
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: (
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.

The experiment shows excellent performance.
I'd expect even an old i3 and maybe atom would be fine with this.
Title: Re: Changelog
Post by: Andy ONeill on February 22, 2018, 03:49:10 AM
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.


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.

Title: Re: Changelog
Post by: Andy ONeill on February 22, 2018, 08:56:13 AM
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.

Title: Re: Changelog
Post by: Andy ONeill on February 23, 2018, 07:33:19 AM
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:
Title: Re: Changelog
Post by: Andy ONeill on February 24, 2018, 12:59:09 PM
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:
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.

Title: Re: Changelog
Post by: Andy ONeill on February 26, 2018, 08:05:25 AM
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.
Title: Re: Changelog
Post by: Andy ONeill on February 26, 2018, 09:18:11 AM
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.
Title: Re: Changelog
Post by: Andy ONeill on February 27, 2018, 06:57:08 AM
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.

Title: Re: Changelog
Post by: Andy ONeill on February 28, 2018, 09:14:19 AM
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.

Title: Re: Changelog
Post by: Andy ONeill on March 02, 2018, 10:23:37 AM
Map Editor

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


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.
Title: Re: Changelog
Post by: Andy ONeill on March 03, 2018, 10:32:44 AM
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.

Title: Re: Changelog
Post by: Andy ONeill on March 05, 2018, 09:53:07 AM
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%
Title: Re: Changelog
Post by: Andy ONeill on March 06, 2018, 12:59:50 PM
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.

Title: Re: Changelog
Post by: Andy ONeill on March 07, 2018, 06:21:28 AM
Map Editing

Experimenting with drawing smoother lines in a separate solution just intended for this purpose.
To some success.
This would just be for "line" drawing such as rivers and roads.

If you take a look at some of the roads in images above you will notice there's a lot of jaggies going on.
This experimental method uses "ink". This is intended for purposes like drawing your signature for the postman. To smooth out drawings this tech uses some very tricky smoothing stuff with Bezier splines.


The above 2 pictures are crops of part of the window and the road/river is 5 px wide, so on my monitor they're magnified in the forum preview compared to the app running.
They're drawn as two lines on top of one another.
The dark wider one is "below" the lighter top one so it looks like an outlined shape.
We could allow selection of colours and width of both.

In an ideal world I'd write a more flexible algorithm, but that looks like it'd take way too long.

Title: Re: Changelog
Post by: Andy ONeill on March 08, 2018, 03:24:04 AM
Map Editor

More work on "line" structures.
The graphics you see on the screen are only part of the map story.
The game "knows" what terrain a unit is in based on a matrix ( a two dimensional array ).
That means once you draw something I have to work out what cells the shape covers so I can mark them as road or river ( forest / fields etc for other tools ).
Once you draw something it's shape is defined by a sort of series of points like join the dots.
With that fancy spline stuff, smoothed out shapes aren't just plain straight lines though.

My first attempt uses a sort of brute force hit testing around each of the points in the line.
Hit testing is quite an expensive action and there are thousands of such points.
The result is a bit slow really and I'm going to try plan B.

Title: Re: Changelog
Post by: Andy ONeill on March 08, 2018, 09:42:51 AM
Map Editor

New shiny improved way to find all the points inside a line.
This uses a different technique which is faster and can also be multi threaded.
Also worked out a couple of bugs in my code.
Still experimental but can be ported into the real app.
With a bit of neatening.

Title: Re: Changelog
Post by: Andy ONeill on March 09, 2018, 10:00:13 AM
Map Editor

Refactoring prototype drawing process towards production ready code.

Title: Re: Changelog
Post by: Andy ONeill on March 10, 2018, 05:33:47 AM
Map Editor Prototype

Many rivers aren't the same width along their length.
Today, I did a quick experiment with making a river widen from start to finish.
This seems pretty effective so I think I'll be adding this as an option.


Title: Re: Changelog
Post by: Andy ONeill on March 19, 2018, 03:01:55 PM
Scenario Editor

Fixed a minor bug with the place names display.
Changed pathing to take into account elevation changes. Climbing is harder except on a road. It's assumed a road takes best path going up and down hills.

Map Editor

I've done a fair bit of experimentation with stylus support for ink - this is definitely a good option and I'll be adding support for a stylus and "pressure".
I've also been iterating towards allowing the user to select terrain already drawn.
Using the prototype, you draw something and commit it. That's it.
My version will allow you to select objects you have drawn and delete or edit them.
There's only a load of code to show for this at the moment.

I've also done some investigation into storage options for the various pieces of map data.
This needs to be made secure for PBEM games in order to stop an opponent cheating.
It'd also be a good idea to drive down the size of files.
I'm thinking of zipping up and encrypting all the files into one.
Title: Re: Changelog
Post by: Andy ONeill on March 20, 2018, 02:19:34 PM
Map Editor

More work towards allowing you to switch between drawing modes.
You can now actually draw a forest and get it to appear.
Terrain objects are now numbered with an Id so the app knows which are what.
"Children" of these eg the trees which appear to go inside a forest are allocated this id so you can tell which trees are associated with a particular forest.

Prototyped a tabcontrol which allows you to arrow through it's tabs ( less intrusive than clicking tabs ) for the left panel.
Added the templates etc for this into the map editor.
Moved the existing drawing list into this.
Second tab which will allow you to pick a terrain object already on the map is as yet just a stub.

In the picture below, Drawing Options is the current tab.
Click the chevron to the right and it switches out to Edit Terrain

Title: Re: Changelog
Post by: Andy ONeill on March 21, 2018, 05:55:03 AM
Map Editor

First cut of the Edit Terrain tab.
In the screen shot you can see I've drawn a bunch of woods and the list to the left refers to these. The number is their ID and incremented as you add each terrain object.
Selecting one of these on the left gives the corresponding terrain on the map a "marching ants" animation. The dashes in the screen shot are moving in the real thing.

Title: Re: Changelog
Post by: bayonetbrant on March 21, 2018, 05:57:32 AM
The marching ants effect is a nice suble way to suit what's selected
Title: Re: Changelog
Post by: Andy ONeill on March 21, 2018, 09:58:01 AM
The marching ants idea was Ezra's. 
He thought it couldn't be done though  :D  ::)

It's obvious which one you're working with, but you can see the content and it doesn't cover other stuff impact image quality like eg a dropshadow would.

I was going to make the animation work in all "modes" but it's quite processor intensive and I want to keep the hardware threshold low. ( Within reason, functionality and time expended developing are also important ).

If the animation is running whilst you're drawing there's a noticeable gap between the pen and the ink appearing following it.
Ink offers smoothing which is huge for anyone isn't some sort of graphics ninja.
Presumably that smoothing is also quite processor intensive.

Rather than spend weeks optimising things nobody cares about, the simple fix is to just do the animation whilst in edit mode.
If you just drew a lake or woods then you know which one you just drew.
The effect is also a bit distracting so I think this is a plus all round.

Title: Re: Changelog
Post by: Andy ONeill on March 21, 2018, 02:15:28 PM
Map Editor

clipping canvas so you don't get weird stuff happening when you draw outside it's bounds.
I found it kind of funny the first time I drew a forest over half the options in the left tab but...

Choose a terrain in edit mode and hit the delete button. The terrain and any children (trees if it's a forest) are removed.

Stop user drawing unless they're in drawing mode

The outline of woods isn't as definite as I'd like.
Added very fine dotted line round them, which seems to work.

Reclassifying some of the drawing types and removing pluralisation

First iteration of drawing Lakes.
Title: Re: Changelog
Post by: Andy ONeill on March 23, 2018, 01:19:00 PM
Map Editing

Shook out some bugs and added waves to Lakes.

Title: Re: Changelog
Post by: Andy ONeill on March 24, 2018, 10:50:48 AM
Map Editor

Setting the colour of the ink you draw with depending on what terrain you've selected to draw.
Water is blue, for example.
Title: Re: Changelog
Post by: Andy ONeill on March 25, 2018, 01:35:28 PM
Map Editor

Added swamp.

Title: Re: Changelog
Post by: Andy ONeill on March 26, 2018, 04:23:53 AM
Map Editor

Added Fields.

The fill on these is randomised using the same mechanism as the woods background. I could potentially allow a user to customise the colours and frequency used for both.
Title: Re: Changelog
Post by: Cyrano on March 26, 2018, 09:22:51 AM

That is all...

Title: Re: Changelog
Post by: Adraeth on March 26, 2018, 09:44:40 AM
It feels like an excellent engine ... i am here wonder how many battles i will edit with this new UMS .... work hard and bring it to us  O0

thanks for every update
Title: Re: Changelog
Post by: Andy ONeill on March 27, 2018, 05:20:14 AM
Hi guys,

Good to see people are keen.
I hope that lasts  :)

I'm still a while off completing the map editor.
This version will have some ( I guess quite big ) files associated with a map that you use just to edit them.
As you draw there are many points define the line you draw. These will be saved to files and of course "many" anything means big.
I plan on zipping these though.

The prototype you may have tried only has the areas you drew until you click that commit button. They're then copied onto a picture and gone.
You make a mistake then you have to live with it or start again.
This is the nature of prototypes.

The new version will retain all the data so you can edit later and retain the quality.
It is planned to allow you to export vector pictures ( probably pdf ) so you can print a high quality map to poster size.
When playing the game, these terrain objects probably won't be used and you'll instead effectively use a picture of the map as a background.
I might think about giving the option to retain those objects instead but the large size would mean we couldn't support transfer from a pbem / live server as is planned. There's also a fair bit of overhead in stuff like arranging all the trees in a forest.

Then there's the actual game to write.
The pace probably looks pretty glacial from an observers point of view but it's pretty quick for development generally.

Another thing worth mentioning is that the apps will also be improved after release.
As we see issues, receive do-able suggestions or I think of stuff then they will be added.
This is a suite which is intended to have a long life time.

Title: Re: Changelog
Post by: Andy ONeill on March 27, 2018, 09:54:49 AM
Map Editor

Added City.

I spent a while thinking about how to draw a convincing looking city.
This works with a sort of vector scan of a real map.
The user will be able to pick from a number of such models but they don't really scale so well.  I have three. I did what I felt was the least convincing first as a proof of concept.


The image I see in preview is about 1.3 x the original. It'd also probably look better if I was more careful about drawing the shape.
If it looks a bit abstract, that's intentional.
Title: Re: Changelog
Post by: Andy ONeill on March 28, 2018, 03:34:43 AM
Map Editor

Here's another option.


I'll do a couple more pre-built ones.
Clearly, it's impossible to offer something for every single sort of city people might want and we want flexibility to encourage people to get creative.

I'm going to allow the user to add specific buildings.
You can't really beat the human brain for working out sensible layouts.
This will offer the flexibility required to place a house next to a road or river and another next to it.
Villages will work better that way and if you have the time and energy for a complete city then you can go wild.
Those that don't care and are happy with an abstract rectangle kinda looks like buildings.... well they're already covered.

There will be another option to import a picture. You would draw an area on the map set it to your picture and allocate a terrain type  to that. City will be one option. This will be necessarilly rather fiddly but is the only realistic way to cover some possibilties. Bear in mind the entire map can also be a picture if you want buildings scattered all over a massive city.
Title: Re: Changelog
Post by: Andy ONeill on March 28, 2018, 09:16:20 AM
Map Editor

First cut of contours ( for hills ).

Not terribly exciting I'm afraid.
I still need some way for the user to say what elevation each contour is to be and decide how to  display that for review. Probably when selected.

When I did this I drew several contours inside one another and found a bug.
Pretty nasty one actually.
The animation which does the marching ants wasn't always stopping and that's very bad because it's a resource hog.
Fixed that.
Title: Re: Changelog
Post by: Andy ONeill on March 30, 2018, 12:57:42 PM

Added Square to formations.
After some discussion we came to the conclusion that Infantry will be able to form square but light infantry will not.

Map Editor

Added setting height to contours.
This is in "units". There's a factor which converts these to metres.
Elevation units vary from 0 to 255.
The reason for this is due to how elevations are held and the way we intend most maps to be built.
Contours are intended as a fallback because drawing a map using these can be pretty tedious and there is no gradation between layers.
The preferred approach is to use a picture with white throug shades of grey to black.
255 shades of grey.
We're the team that just keeps on giving.
More than 5 times the grey of those colourful books  ;)

In case you missed earlier posts.
The contour with the black dashes corresponds to the one selected in the left and it has a "marching ants" animation makes those dashes move round. You will not miss which piece of terrain you selected.


I might hide the id over on the right since it has no particular meaning to the user. That's what internally identifies the piece of terrain but you will never have to actually know that. It should quickly be obvious to any user that the most recent terrain they drew appears at the top of that list and the first at the bottom. It will scroll if you draw a lot.

Title: Re: Changelog
Post by: Andy ONeill on March 31, 2018, 09:19:52 AM
Map Editor

Added roads.
I'm undecided about the colour of the outline and fill.
Because black looked a bit harsh I've made it fairly fine ( 1px ) and dotted.

You will notice that a road always has a line all he way round it. That's because it's not clever, it doesn't know part of it is on top of another road.
I will probably give an option to combine all roads into just one shape for making the map "picture" at the end of the process to avoid that effect.
I'd have to try it and see but I can't think of any bad side effects from doing that.
Doesn't mean there aren't any.


I hope everyone is enjoying Easter.
Title: Re: Changelog
Post by: Andy ONeill on April 01, 2018, 09:55:06 AM
Map Editor

First cut of Rivers.
When you draw them initially they're a line the same width like a road.
On the edit tab there's currently a prototype button with a > on it.
This applies ink "pressure" along the stroke you drew for the selected river.
It does so from the end you started drawing.
There'll be a < button to do from end to start. Although drawing a river that way just seems wrong to me.
I'll do some better symbols for the signs rather than lt and gt signs.
We also need a way to specify width since rivers will vary a fair bit.
If you use a stylus to draw a river then you can alter the pressure yourself manually.
For anyone unfamiliar with stylus - the higher the pressure the thicker the line you draw.


Similar to roads, you'd currently get a line round any bit of water. I'll allow the user to combine lakes and rivers into one compound object which will avoid that line across joins I talked about in the roads above.
Title: Re: Changelog
Post by: Andy ONeill on April 02, 2018, 08:46:31 AM
Map Editor

Finished the buttons for setting widening on rivers programmatically.


The chevron pointing  to the right will make the narrowest part the end you started your ink stroke from.
The one on the right does so from the end ( which seems weird to me but maybe someone will want to draw that way ).
The rectangle makes the width equal all along.
Title: Re: Changelog
Post by: Andy ONeill on April 02, 2018, 11:46:26 AM
Map Editor

Prototyping combined water.





Note that the waves on the lake are in a layer below the combined result. They're still there, you just can't see them. I'll fix that once I've shaken the bugs out of this method.
Title: Re: Changelog
Post by: Andy ONeill on April 03, 2018, 05:48:04 AM
Map Editor

Another iteration on combining water.
You can now combine and split water.
When you combine it hides the separate objects, when you split it will show them again.
Combined water appears in the "correct" layer so waves are on top of a lake once combined.
It's actually a separate object and the process of working out how the various shapes combine is pretty expensive but only takes a couple of seconds on my i5 machine in debug mode. It will be faster in the real thing - debug code is not optimised by the compiler and Visual Studio (the development environment) isn't exactly lightweight.

Title: Re: Changelog
Post by: Andy ONeill on April 04, 2018, 04:13:36 AM
Map Editor

Added roads to combine / split logic.
They go on top of water.
Submerged roads aren't terribly practical.
I reckon some people will want to dash off a quick map as quick as possible and this allows you to not bother with bridges.

Fixed a bug which was eating processing.


Title: Re: Changelog - picture heavy
Post by: Adraeth on April 04, 2018, 06:16:08 AM
Roads (instead of bridge) over troubled water  ;) ... excellent idea; yes i am one of those to make a fast map to play almost immediately
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 05, 2018, 03:28:41 AM
Map Editor

I might have explained this earlier but maybe at the risk of repeating.
Which terrain is on "top" isn't just a visual thing.
There's a 2 dimensional array of terrain type used for spatial A* navigation and for tactical movement.
This will need to be calculated at the end of drawing a map.
Whichever piece of terrain is top wins and that's what the square terrain is.
There are 1155 x805 "squares". They're 1px x 1px  - and very small.
The grid you see on the screen shots is 35x35px.

A road over a river makes the cells it crosses road and a crossing point. Your courier might decide to swim across if the alternative is a very long distance and a river is narrow. Combat units will not.

Development work, largely internal:
Changed background colour of swamp to green (from light blue) so it is more clearly distinct from water.
I've refactored the "marching ants" animation process. This was to avoid repeated storyboards ( the thing that does the animation moves the dashes ). There's a very technical reason why this was worth doing that only wpf developers would be interested in.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 07, 2018, 09:59:43 AM
Map Editor

Added Fortifications.
These are necessarily somewhat abstract.
There are numerous things you might want to classify as fortifications during our period. They come in all sorts of shapes and sizes and it's not practical to give a way to draw any of these dynamically.

If you want something that looks like trenches, breastworks or a star fort then you'd use a different mechanism and import your path or picture, then tell the editor that is fortifications.

Title: Re: Changelog - picture heavy
Post by: Adraeth on April 09, 2018, 02:53:09 AM
About trenches, fortification:

do you think Red is the right color for them? might them be confused with red army units?

However i can't think about a different color, maybe grey?
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 09, 2018, 06:19:31 AM
I don't think you'd confuse this red with units, they're a paler sort of red.

Red is extremely intrusive though.
They are going to be fairly important things but maybe we don't want them to stand out quite that much.

There's actually two parts to this. Probably clearer with a picture.
The dashes and center can be different colours.

If you think in terms of castle wall sort of things then this'd look a bit too much like just a stone wall ( one of the boundary options ).
Dark and light gray

I think I prefer Sandy brown and Sepia.
Title: Re: Changelog - picture heavy
Post by: Adraeth on April 09, 2018, 07:58:03 AM
Sandy Brown and Sepia is excellent, reminds me of old battle maps  ;)
Title: Re: Changelog - picture heavy
Post by: bayonetbrant on April 09, 2018, 08:39:46 AM
FWIW - the obstacles and engineer works appear in green on modern-day US/NATO graphics overlays, with friendlies in blue and enemies in red.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 09, 2018, 10:23:30 AM
Green is an interesting thought.
Another boundary type will be hedge though and that'll involve green of course.

Hedges and walls can be quite substantial things in the European countryside.
Not often quite so substantial as in the bocage but still significant defense against small arms.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 09, 2018, 10:28:14 AM
Scenario Editor, ModelLib and Map Editor

Added new area terrain type, Mud.

At the moment, all unit types can move through mud.
Some do so very slowly.
Since this is new ( I realised we'd want mud a couple of days ago ) we may decide to make it impassable to some units.
As it stands though, you could just use swamp if you want really really bad mud that most unit types can't move through.
Title: Re: Changelog - picture heavy
Post by: Adraeth on April 10, 2018, 08:14:38 AM
Mud is excellent to slow and "disorder" horses and artillery, and can portrait easily  bad weather (rain)
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 11, 2018, 09:34:12 AM
Mud can be used for any zero height terrain which will impede movement.
You will be able to decide by how much it effects each type of unit on a scenario by scenario basis.

I think mud was quite significant at Waterloo.
There are other similar types of terrain though like moorland or just somewhat marshy ground. Either is very difficult going as anyone who's ever done any hiking walking will tell you.
This can add interest to some battles would otherwise be somewhat featureless.
Maybe Culloden ( I don't know offhand ).
You might consider some "swamps" in French Indian/1812 etc might be more appropriately set to mud.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 11, 2018, 09:46:04 AM
Map Editor

Added Boundary as a first iteration.  The first version is intended to be fence.

I'll probably go with red brick walls and of course green hedges.

This particular one led to some discussion about how fence, hedge or wall should work.
These are all slightly different boundaries.

You might think horses can jump fences so they cross them.
It seems they proved too much of an obstacle for some formed units. Maybe the average cavalry nag isn't much of  a jumper and large bodies of men/horse don't do so well with any obstacle.
There is also the issue of the likes of enclosure walls. Often not strong enough to stop a cannon ball so not a fortification really. But if the French could just walk into hougomont then things would have gone rather differently.

At the moment I have fixed "hard coded" settings control who can cross what terrain. This is as well as rates.
It has to be an on off thing because it'll be used real time as you drag a move order "puck" round. No you can't cross one of the pieces of terrain in that direction or yes you can cross all of them.
I'll make this editable per scenario in a new view within scenario editor.
It's then up to you to decide what fences do in a specific scenario stop.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 11, 2018, 12:32:59 PM
Map Editor and ModelLib

There are now 3 different boundary terrain types -  fence, hedge and wall.
Boundary is just a logical grouping of these though.
A boundary is drawn as a fence and you can then switch between the three options using 3 buttons in the editor for Boundary:


Drawing boundaries works slightly different from most other drawing objects in that the tendency to smooth to a curve is suppressed.
That's because these are one of the few things in the countryside where you may well really want a straight of wiggly line.

Hedge and wall will block line of sight to a height of 2 metres.
To use these as cover, you put a unit on the piece of terrain.
This represents your unit lining on one side of the wall but using it as cover.
If you are not on it then it blocks los for you, unless you or your target are somehow higher than 2m than the wall.

Fences just block movement. Or not - depending on your preferences.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 12, 2018, 10:38:52 AM
Map Editor

Added Bridge.
Drawing a bridge works somewhat differently from everything else so far in that you're not actually drawing an area or a line. As you mouse down and then up this defines the two ends of a straight bridge between.


Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 13, 2018, 05:51:04 AM
Map Editor

Added Ford.
Since bridges are way better than a ford (in the real world) they count as mud for speed of travel and whether they block some unit types.

In the above picture I've drawn sort of along the river and back in order to show you can do an irregular shape if you want.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 16, 2018, 04:46:43 AM
Map Editor

Added first iteration of Place.


In order to do this I've moved a bunch of things round such as the view for places which is now in a common library.
I also resolved a number of issues to implement just clicking to add a point differently from everything else with it's Ink support.

I'm still considering whether to allow multi line names for places and a combo box for the points value. At the moment if you typed a number I've not set a geometry up for, you get nothing in the plaque. I will probably just set up paths for 0-9, force only numeric input and leave it up to the user if they feel 99 is really a sensible VP for a place.
I still have to allow the user to pick which side the place is currently associated with.

In the picture, you will notice that the "marching ants" rather mysteriously continues some distance below the plaque rather than just under it. By default, you get the place name above a plaque. If you position a place close to the top of the  map then of course there is no space for the name above, so it appears below instead.  There are two of the labels in the control. I hide the bottom or top one depending on position. The control positions itself so the centre of the plaque is where you click. In order to do that reasonably easily I divide the width and height by 2 as part of the position calculation. Hence there are always the two labels there in the control, it's just one is hidden but still contributing it's height to the calculation.

For this one, "Top Place", I've clicked close to the top of the map. The label you see is the one below the plaque and hence those ants are marching off the top of the board. 
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 16, 2018, 10:15:05 AM
Map Editor

Another iteration on Place.
You can now have multiple line place names.
VP are limited to 0-100
You can't type anything but numbers in the vp box.
There's a combobox allows you to pick which side initially "owns" a place that's worth points.
You just get the text (no plaque) if a place is worth zero points.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 17, 2018, 10:11:30 AM
Map Editor

First iteration of Building. 
I've gone with terracotta tiling because it looks nice and bright, it's appropriate to most of Europe and it's not the same colour as units.
No buildings will have little arrows on them so even if the viewer is colour blind it should be pretty clear a building is not a unit.
Red vs orange colour blindness is also pretty rare.

Functionality still outstanding includes:
Rotate ( a bit ) *
Add a number of alternative styles to pick from.


Like all the other visuals, this is built using vectors and will scale.  Should you want to print a huge version of the map (once I write something allows you to export to pdf ) you will get a high quality picture.  I've not made the shadow and outline of shapes scale yet but at a larger size, that looks like:


I'm thinking of doing some building parts as sort of components. You add a basic kind of cross shaped church then you pick a spire or dome and stick that on top.
This is one of those things I could pretty much spend forever on and still come up with new options styles and things to do. 

Rotation will probably have to be rather limited because these aren't going to be lightsourced 3d meshes. 
Certainly as it stands, the gradients aren't going to change as you rotate. I can rotate the shadow so they point in the same direction, but if you rotate a house 90 degrees it'll look like it has a lightsource in a different direction to everything else. You'll get away with 20 odd degrees but anything more than that would mean a different building option.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 18, 2018, 10:10:26 AM
Map Converter and Scenario Editor

For various reasons, we need a new format for the map data.
That meant that the old maps we have already would of course be incompatible.
I've put together a utility which converts these.
The new format will come as two zip files. There will be:

From the user's perspective you get one or two zip files rather than several per map.

I have the first cut of the utility working.
The scenario editor now uses the new format and loads the data OK.
Still some work to do on that as I've not yet done some things like place names and the px to metres scale. 

The utility is just for our internal use and the ui is what you might call minimalist.
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 19, 2018, 04:32:58 AM
New Map Format

This is now firmed up and the converter produces a new format zip file.
Scenario editor now shows places.
The converter is stable.
Stable enough for one map at a time internal use, anyhow.

The map editor is not yet saving state at all, so that's probably next up.
I'll get this end to end working before returning to mere details like rotating houses and different options for terrain and...
There's still a fair bit of work to do on the map editor.

Title: Re: Changelog - picture heavy
Post by: union square on April 19, 2018, 12:22:02 PM
Thanks for the Changelog, Andy.  It continues to be fascinating stuff for those of us interested in the project!
Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 20, 2018, 04:31:57 AM
Thanks, I appreciate that.

Like Ezra says, watching software development is usually on a par with watching paint dry.
Hopefully this is slightly more interesting but it's a slow process.
Quality takes time.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 21, 2018, 09:16:23 AM
Map Editor

Started on save map process.

First part of this to do is to work out what terrain type is where in terms the game understands. There's a cell per px in a 2 dimensional array 1155 x 805.
To do that I need to hit test a point for each of these.
That's a lot of points.
Since hit testing is fairly slow, this takes a while.

I started with a proof of concept doing one point where I click. That meant a bit of jury rigging since clicking usually does other things but enabled me to prove what I was getting for a point was what I expected.
As it turns out there was a bit of a complication.
The piece of framework I'm using is bugged and stuff that shouldn't be returned from a hit test was.
I worked out how to filter these out and got the proof of concept to work.
Refactored that into something more re-usable.
I can now fill a 2d array.
This takes some time - around a minute whilst in debug mode.
Should be faster in an optimised compilation release but you're never really going to want to sit there watching it work.

I think I'll do a separate game map and design map save so you can save the design faster and then do the game save once you're totally happy with your master piece.

Title: Re: Changelog - picture heavy
Post by: Andy ONeill on April 22, 2018, 10:04:06 AM
Map Editor

Map saving - applying contour elevation.
This is kind of tricky because a contour can be under some other terrain object and you still need it's effect.  If I'd included contours in the hittesting for every single px that would not be able to stop at the top object hit, it'd need to get any and all objects under that point. That would have slowed down something which is already pretty slow.
The approach I took converts each contour to a new geometry which can then be processed on a background thread whilst the hit testing takes place.
Not only is this on a separate thread so it can be done at the same time as hit testing, it's inherently faster.
The reason I use hit testing at all is because it's the simplest way to work out what is the topmost terrain.
I could impose an explicit z-order and do everything that way. That's a possibility for a later refactor.

Note that contours are all one level. They're like those weird warhammer hills where someone just cuts an oval out of polystyrene and the top is horizontal, the slope vertical.
OK for a casual game where you want to dash off a quick map.
You will want one or more of the alternatives for anything more sophisticated.
The choice will be either or. You use contours or you use the alternative options.
I'll explain these at a later stage.