Changelog - picture heavy

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

Previous topic - Next topic

0 Members and 5 Guests are viewing this topic.

Adraeth


Andy ONeill

Thanks.
Back to orders next, I think.

In very broad terms:
Take input.
Queue up the instructions.
Suport saving these
Work out what happens
Record the results in repeatable form.
Support saving these.
Show the results.

Andy ONeill

Place Selection Animation

I increased the size of the ring and outlined it in the dark colour for owner.
Fixed a bug where the ring was getting "stuck" part way through an animation and left visible forever if you quickly selected different selected items.

Andy ONeill

Final Place improvements

In the scenario editor whilst working with the list of places you had to click the area between the textboxes and dropdowns in order to select it.
This is because clicking these controls has meaning and they sort of eat that click in order to act on it.
I've changed this so if any of the controls for a given place take focus then that place is selected.
Hence click on either textbox and the animation starts up.

Made the selection circle several circles so it's easier to see.
This makes it cover things but the animation is temporary.

I also neatened up the spacing a little between the textboxes.

Below,  I clicked the textbox and you can see the multiple rings frozen part way through their animation.




Andy ONeill

Game
Light up selected unit. This is similar to the scenario editor but selecting a unit using the army treeview lights up the corresponding piece on the map.
The is a light yellow background in the circle surrounds a  piece.


The triangle in front of the piece will be a variable icon used to indicate "posture".
Posture is intent. What those guys are supposed to be doing.
Moving, assaulting, withdrawing or holding a position for example.
We'll probably want to make that a bit bigger and maybe it should go outside the circle.
Have to think about that.

I've also been thinking about orders, friction and command ability.
This is a game so we don't want to totally frustrate players.
On the other hand we want to model reality and on battle the simplest thing becomes difficult.
More difficult for bad commanders.

As they give orders a commander will be limited in the amount they may issue depending on their capability.
As orders are issued a commander may hit a limit and be able to issue no more for that turn.
Essentially, there will be a roll off vs command skill per stage as an order is put together.
Fail so many times in a row and you can give no more orders ( that turn ) to the unit you're ordering.
Fail more and the HQ for that unit can give no more orders that turn.
This is a similar mechanism to those used in some tabletop games.

You won't know exactly when you're going to run out so that adds suspense.
Complicated orders are higher risk - which models reality.
Even terrible commanders should be able to give simple orders successfully.
If you can plan far enough ahead then you should be able to work round the limitations of dunderheads.

Andy ONeill

Loader

Bugfix:  Correct initial red/blue side selection.

Andy ONeill

Orders

I've started refining the structure of classes used to store orders.
I sketched these out a while back and then of course moved on to do other things so I'd forgotten how rough of a sketch that was.

Andy ONeill

Orders

I've started on persisting a move instruction into an order.
I've only just sketched out the structure of classes make up an order and ( as expected ) that still needs a fair bit of work.

Andy ONeill

Loader

Now uses the same preferences appsettings file as the rest of the suite.
When you switch between victorian and modern style this is the equivalent of victorian and plain in the rest of the suite.

Andy ONeill

Game

Refining how to persist a move order.
I need to shake out several classes - the sort of refactor you have to do all at once.

Andy ONeill

Map Editor

I've made a minor change which copies the terrain type from the pixel next to the edge to the edge px.
Why? You might wonder.
Ezra found something weird happened with the routing where a unit found a way past a river along the outermost pixel of the map.
This was still marked as terrain empty when he expected it to be part of a big river.
As it turned out this was a mistake in usage rather than a software bug.
But this is an easy thing to overlook.
They kind of look like they go to the edge until you turn the grid off, screen grab and increase the size of the picture in paint.
I've applied a fairly quick and dirty fix.
I can't imagine anyone will have a piece of terrain on the very edge of the map so you can only see 1px of it so I can't think of a downside.
It doesn't change the original source shapes though so if it turns out we see a problem I can easy rip the change back out and just saving a map would give you those edge pixels back.

Andy ONeill

Game

BugFix.
Better final direction for piece at end of best path move.
Previously I was averaging the bearing between a number of points on the move and the final point.
That averaging seems to be bugged and was giving some strange results.
As a result the triangle used for the arrow head would point in strange directions.
Just using the bearing between 8 px back along the path from finish and the finish seems to give better results.

Andy ONeill

Game

More work on orders persistence.
In the scenario editor I have calculations for the time a courier will take travelling between a piece's co to them.
That code is invoked when you mouse over a HQ and you can see the various paths the couriers will take appear briefly.
There was previously no equivalent in the game.
I've added a prototype implementation.

Technically, this uses somewhat tricky multi threading because it has to do a "best path" for the courier.
That's an expensive operation but it's "only" to work out when the order starts.
Meaning the player will want to continue to give orders and that courier calculation should not stop them.

Since this is a brigade commander which will be sending these orders out this is one of the subtleties of the system where player skill will show.
You want combat pieces to be covering each other's flanks and approaches etc.
Brigade HQ should be near enough to all that orders do not take forever to arrive and yet "safe" from enemy.
And the HQ may want to be able to see as much as possible but maybe not be seen by some enemy.

Andy ONeill

Map Editor

BugFix:
There was a problem importing complex area terrain types as custom resources.
This produced quite strange effects since it was connecting up the wrong dots and filling in areas it shouldn't, excluding areas it should have included.
I've changed the way these shapes are handled to obviate this issue.
There are some rather obscure technical side benefits which I won't bore you with.

The reason we noticed this bug is Ezra is building a map for Ligny.
Since the "rivers" across the battlefield didn't stop the French then they we can't make them rivers.
Any water stops direct moves.
Those rivers in question were a couple of meters wide and easily crossed.
With some mud either side.
So the whole translates in game terms into mud.
Mud is an area type terrain whilst the rivers and roads Ezra routinely imports as custom resources are line.
This was therefore the first time we tried importing complex shaped area type terrain.

Andy ONeill

Map Editor

alt + Page up or Page Down now moves the selected terrain to top or bottom of list.
Disable the river manipulation keys when there's no ink to manipulate.
This avoids an error if you've used custom resources to import a river.
Fixed a bug in templating which gave you unusable rows in the edit terrain list.
That was introduced by my refactor of area terrain.