Changelog - picture heavy

[Andy ONeill]

Game

Started on SaveGame structure.
This is the class which will be constructed and saved to disk when you choose to... save a game.
When you load a game after the first turn orders are committed, this is the thing will be read from disk and translated into objects in memory.
Since this will be a fundamental driver for pretty much everything I want to refine my ideas on what this will look like and how that translates into a working game.

Not that players need to understand all this but FYI this will look roughly like:

 Savegame
  Game
    Scenario
    CurrentTurn
    Armies
    Players
  Turns
    Turn
      StartingStates
         PieceState
            Piece
            Location
            CurrentStats
      VP Loss / gains at start of turn
         Places
         Pieces
      Orders ( the plan may cross turns)
      Orders this turn
      Piece state changes ( the results )
         Event
           DateTime
           Change- movement; morale; ammo; strength; Posture etc

Indentation indicates properties of parents, hence a piece state change is an event which happens at a specific time and  contains stuff about what is changing.

Resolving a turn is done in memory and the results can then be reviewed.
You don't see a turn resolved as it happens because a player could potentially interrupt and replay a result they didn't like the look at, hoping they were luckier the second time round. Or perhaps worse.

My current thinking for a pbem game.
The last person inputting orders only sees results after his opponent.

Both players will input their orders.
If A inputs their orders and then B inputs theirs, the turn will be resolved on machine A.
The results will then first be seen on machine B.
Which means extra emailing over just resolving on whoever inputs orders last.
Which is unattractive.

There are several options I can think of to avoid that.

The simplest would be to give a setting allows you to "trust" your opponent when you start a game.
That alters things so A inputs orders, they email to B.
B inputs orders, the result is resolved and he watches this.
He then sends the savegame back to A to watch the result.
Processing always happens on machine B.

Another is rather more involved but could be rather slicker.
The two players PCs would communicate directly to each other.
Both could input the next turn's orders at the same time,  commit and send.
The turn would be resolved on one of these.
The results could then be transferred in a similar way and viewed simultaneously.
This is rather more like the sort of thing I do commercially but running on a regular PC rather than a web server.
You'd need to open ports - another machine sending your stuff is pretty much what firewalls are designed to stop.

[Andy ONeill]

Bug Fix:

I noticed the HQ icon in the game and scenario editor treeviews had a white background.
This bug was introduced when I added the dropshadow to pieces.



Now fixed.

[Andy ONeill]

Scenario Editor

Format elevation to 1 decimal place
BugFix: Total maximum pieces in a force was not reset to zero on load so increased every load.

Game

More SaveGame classes.
This takes longer than just add a new class here and there because I'm working out how to best represent things.
I add something and then realise later that won't cover some other circumstance so I go back and change it.

[Andy ONeill]

Game

Defining events.
Here's the list I have at the moment:

        Move,
        Sighting,
        Shoot,
        Reload,
        Contact,
        StateChange,
        OrderReceipt,
        OrderComplete,
        PlaceTaken,
        PieceStatic, 
        PieceRout, 
        PieceDead

StateChange allows update of stats on a piece.
As a piece shoots, it becomes unloaded.
When it reloads it uses ammo and ammo is reduced.
It's then reloading for a while.
When they are shot, a piece loses strength and probably morale.

[Andy ONeill]

Game

Changed the styling and what data is used for the piece strength in the treeview.
Cursive writing doesn't "measure" so well. This is the process that windows uses to work out what space the text takes up.
If you therefore put cursive font next to another font it's very difficult to make them line up neatly.
If you look above on the changelog at the picture with white HQs, you'll see what I mean.

I've therefore removed the "Strength:" textblock - it's pretty obvious what that number is going to be anyhow.
Replaced this with a tooltip to explain what it is.
I changed what data it uses so it shows the current strength.



That then got me thinking.
Always dangerous.

Considering fog of war and the realities of a battle.
There you are mid battle and you're general whoever.
Your second battalion gets shot up.
You would only know exact losses once a post battle roll call was done.

I then changed it back to using the starting strength:

[Andy ONeill]

Game

Improving the look of a unit's entry in the treeview.
The design was copied in from the scenario editor.
In the scenario editor, greying the text of pieces once they were added to the board for a scenario was useful because the dark more obvious ones were those still available to be dragged onto the board and into a scenario.
Grey vague looking ones were "used" and deployed somewhere.
Part of the suite's design is that you can build an army but not use all of it in a given scenario.

In the game, making all the text grey just makes it harder to read.
The lime green background of a selected item is also out of step with the theming elsewhere.
Probably a matter of taste but I'm not so fond of lime green outside of pop art or the 1970s.

Made the text black.
Removed the greying of text off pieces which are in the game ( everything ).
When selected the text is now changed to white on a brown background.
Unit names are now far easier to read.
I also rationalised or removed several parts of the templating which also aren't appropriate in the game app.

[Andy ONeill]

AIEditor
Fixing library reference.

Game

I showed our ui to a couple of friends ( socially distanced via ms teams screen share of course ).
Something they both noticed particularly was you can’t read all the unit names in the treeview.
This is something I’d noticed myself.
Hence I've started on a set of changes to reduce the width used by the entries in the treeview.

You’re more likely to be able to see more / all of the unit names.
If you go with long names then these still aren’t going to help and many players will have wide monitors or higher resolution displays.
Previously, you max out the game you were still “stuck” with a narrow left panel and maybe a chunk of useless space.
Fixed that:
Added width resizing on width of left and right panels.
When you mouse-over the space between the two panels you will see a double headed arrow appears.
You may hold and drag left or right to adjust the widths.
(This is similar behaviour to apps such as excel for column resizing )

Moved the general out the treeview.
This is currently just a prototype piece of text - still needs more styling TBD.

The commander icons now act as the expand/contract button which toggles visibility of their subordinates.
Shifted the subordinates over further to the left so their indentation is actually a bit less than their parent's icon.

I also made a number of internal changes which are less visible and to do with rationalising how data is held for the army pieces.
One thing is visible - the oob you see now corresponds to the current player ( previously hard coded to red ).



Ezra particularly likes those pointy fingers.
( Sorry Ezra - they were too wide ).
I may re-introduce one in a rollover effect as you expand a HQ.
Not sure about that.
There are huge pointy fingers in the loader though.

I'm also thinking about the strength again.
This is the original strength.
If I moved that out into a tooltip I could save some height on every combat unit and reduce the chance of a vertical slider appearing.
No vertical slider means more width for the treeview items.
I could also re-template and reduce the width of those sliders.
I thought about using something similar to the small brass slider I built for menus.
Not sure about that one.
It'd perhaps have to be a different shape to be big enough to get your mouse on but narrow enough it didn't take more room.

[Andy ONeill]

All

Changed the symbol used to navigate through tabs.
This was previously similar to the material design chevron which is a triangle with a cut out.
Now a fancier victorian style thingummy if you choose victorian styling or a triangle.

Victorian style:



Otherwise

[Andy ONeill]

All
A number of changes intended to give more space for the content of those left panels and to make scrollbars styling match the suite pallette.
If you’re a user of android, ios or apps like Slack on windows you are likely to find the new look and behaviour of scrollbars very familiar.

Made the scrollviewer content fit the entire scrollviewer.
This means when there are scrollbars appear on a control, the content which would normally stop at the scrollbar extends under it.
Hence the content always fills the bounds of the control rather than stop at the scrollbar track.

Re-templated scrollbars so the track is now totally transparent and there’s a narrower “thumb”. On windows a thumb is usually a grey rectangle. The idea of scrollbars work is you can have a panel bigger than will fit in an area and you move the viewport on that panel to see a different area. To move the viewport up or down you have two options. You can click, hold and drag the thumb up and down. Alternately, you can click above or below the thumb on the track and it’ll page up or down. Similarly with horizontal scrollbars except of course the movement is lateral rather than vertical.
Less dead space.
More content.
Less grey.
More theme-brown.

This picture shows the treeview now.  There are both a vertical and horizontal scrollbars here, each is transparent until you mouse over it

When I mouse-over the vertical one you now see a rounded rectangle appears.


Game
Moved the strength value for units out the treeview and into the tooltip.
We’ll want a lot more info about units than just strength and that is probably best moved into a floating window you can drag round and some sort of unit tooltip or popup.

I don't think I posted a picture showing what happens if you drag the width of that left panel.
Below, I've done this and made the left panel just a little wider so all unit names fit.
The "(Kanawha Div." is now fully visible.

Notice that the map panel is smaller but retains the same proportions so it contracts vertically proportional to the reduction in it's width.
On my monitor I could drag the width of the parent window and make everything bigger but fit vertically.

[Andy ONeill]

PathFinding

Some optimising on the spatial A* pathfinder.
Avoid backtracking - don't include the cell you previously came from in the options to check.
Reduce iterator usage - for index o to n is slightly more efficient than foreach. Which is usually so marginal you wouldn't bother but pathfinding can do many of those loops.

Setting water to higher cost for units.
This makes it a bit less likely that a column of infantry will decide to try and cross a river.
There is a potential downside to this if you build a map with an island and a whole lot of sea between it and land.... then try and move a unit across that sea.
You may well find that crashes the app.
But you built something could never work.

[Andy ONeill]

All
Fixed the problems with my initial version of the scrollviewer/bars.
More pathfinding optimisation.

Game
Make up and down arrow navigate up and down the oob treeview with one click per node.

[Adraeth]

Thanks for everyday updates, the more i see the more i love this engine

[Andy ONeill]

You're welcome.

I wish i could work on this every day.
As it is, my day job means that's not practical.
Still.
Each little piece done is another bit closer to a working game.

[Andy ONeill]

All

Upgraded target framework from net core 3.1 to the shiny new Net 5.0.
Which is a bit faster.
Every new framework version, they optimise things here and there.
Something called garbage collection optimisation might not sound so glamourous but faster speaks for itself.

If you're technically minded or just curious you might find the detailed analysis and benchmarks interesting.
Obviously, if a process takes about 18ns in net core 3.1 ( previous target ) and about 15ns in net 5.0 that's roughly 3 ns or a sixth faster.
And whatever weird and obscure that might seem, a sixth faster for free is obviously a good thing.
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-5/

Time to drink beer, I think.

[Andy ONeill]

Pathing

Started replacing spatial A*.
For least cost path finding ( couriers and columns ) I use an algorithm called spatial A*.
The version we have ( had ) is too slow and not suited to with multi threading to carry out pathfinding for multiple units at once.

The original started off life as the fastest of several implementations I found on the interwebz.
It was acceptably fast.
Then I modified it for slope, different units and the user set movement costs.
Each of these changes made it less efficient.
I shaved an eighth of the processing off by tweaking it a bit.
Not enough though.
Time for to reach for the big hammer.