Changelog - picture heavy

[Andy ONeill]

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 ) *
Resize
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.

[Andy ONeill]

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:

• mapname.Zip file ( mapname is variable ).
  This contains the data and png you need to play a game using the map.
  
• mapname.designer.Zip
  This contains the design data for map editing purposes - and will not be required to play the game using the map.
  I've not started on this part yet.
  

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.

[Andy ONeill]

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.

[union square]

Thanks for the Changelog, Andy.  It continues to be fascinating stuff for those of us interested in the project!

[Andy ONeill]

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.

[Andy ONeill]

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.

[Andy ONeill]

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.

[Andy ONeill]

Map Editor

Further experimentation with the hit testing approach uncovered a rather strange issue.
It appears that microsoft's hit testing component is more bugged than I realised.
It becomes ridiculously slow under some circumstances.
Unacceptably slow.

This is one of those un-fun situations that happen every once in a while in development.
I'm now exploring whether there's a practical work round retaining hit testing.
If not then I move to a similar approach I use with contours.
That has some complications but could well be a more elegant solution.

[Andy ONeill]

Map Editor

I've replaced the way hit testing is done. It now runs for each piece of terrain on a background thread as you finish drawing it.
This still takes some time for some complicated drawings but you can carry on drawing other things.
Proof of concept is now sort of working.
I can save maps and open them in the scenario editor and it doesn't take all day.

[Andy ONeill]

Map Editor

Various improvements to the terrain detection process which is now stable.
You can keep on drawing pieces of terrain whilst the app works out exactly which area your previous pieces cover.
I've added a visual indication to show this is still going on. It appears top right in the toolbar and you get an icon per terrain being processed. Most recent left to right.
I drew a river and then a road for this:


Small pieces of terrain process very quickly.
What's called the "bounding box" is used to decide where to look. This is the rectangle a piece of terrain fits in. A building is therefore a teeny tiny bounding box and almost instant.  A road stretching from one corner to the opposite diagonal corner has the whole map as it's bounding box and is the slowest.
I should think few people will often want to draw roads like a giant X on a map but if you do then it's going to take a while to process and you should do them first.
When I did the screen shot above, this is what I did with a road and river.  Both took 30 seconds to process.
Your experience will vary so this is ballpark indication only. The time it'll take to run will depend on machine, processor other processes running etc. This is running alongside my development environment and in debug mode.  Visual studio is memory and processor hungry itself and the final deliverable compile optimised code will run faster.
In the vast majority of "normal" use I expect all this means usually no wait at all.

The actual game map save to disk is a couple of seconds on my machine.
This has an SSD and your experience may be a little slower but the game map save is not a particularly large file by the standards of today.

If you look closely at the above picture you will see there's a bit of an odd anomaly like a circle on the end of the road.
These are noticeable initially on any "line" type of terrain. They disappear a while after you draw one and i've deliberately took a screen shot before that happened.
I use one geometry type initially for speed optimisation.
I then later replace it with a nicer looking but more process intensive one which is (again) created on a background thread.
 

[Adraeth]

This is going to be a Masterpiece

an usual italian would scream : "Mamma mia!!" 

[Andy ONeill]

Thanks.

[Andy ONeill]

Map Editor

Added option to choose colour for the text of places.  This is because a place name on a dark background like a forest just disappears if it's black.
The two mysterious little squares on the right of the place are combo boxes.  The top one does which side "owns" the place and the bottom one the text colour.



New "Tab" in left panel ( which will be shown initially ) for map details. You can now enter name, description and pick the DPI the map png will be generated at. 96 dpi is likely to be enough, 300 dpi more than enough but if you wanted to print at high resolution there are higher options. These produce bigger files of course.



I also changed the way the terrains are held internally which improved performance a little but also introduced a bug.  Almost nothing works first time when you develop. Even if you tried to, perfection is way too time consuming so we go for kind of working and see what needs fixing.

[Andy ONeill]

Map Editor

Hide left chevron when first tab selected and right chevron when last selected in the left panel tabcontrol.

First iteration of saving and reloading design.
Save design.
When you choose load map you see a new view which lists maps and their descriptions. You pick one and then it's reloaded so you can carry on editing it.
It all kind of works but losing ink at the moment which would be limiting on "line" terrain. Just needs some more coding to handle ink.

Avoid terrain adding extra children (trees for forest, waves for lake) when reloading.

[Andy ONeill]

Map Editor

First iteration of save and load designer data. 
This includes the "ink" for line objects such as rivers meaning you can reload a map and still change the width of rivers.
Stable but still needs a refactor or two to neaten up the code.

Added "Work" folder within Maps folder and Ink folder within that.
This now holds all the files which will be zipped up into the current <yourname>.zip and <yourname>.design.zip
They are deleted each time you "save" a file to be replaced with the new files.