The road ahead

[Andy ONeill]

Current guess for working game delivery:
December.

EDIT: 14 July 18
Still probably about December

As I write, I'm working on the Map Editor.
This still has a fair bit of work to do on it.
That'll take in the order of a month.

The other editors still need more work.
There are also other bits and pieces like the menu and installers.

Then there is the actual game.
If you've been following the changelog you'll have noticed absolutely no mention of this.
There's a simple reason for that - I've not started  it yet.

The game will share a fair bit of code that's already written but there's still going to be several months of work for me to do on that.
As this progresses it's likely that we'll reconsider some aspects of what's already been written.
Ezra or I think of a better way of doing something or I find something turns out to be less practical than expected.
This is the nature of "agile" development.

Parallel to this Ezra will be working on the AI.
Once we agree the map, army and scenario editors are stable, he will be working on scenarios.
Ed (he's an expert gaming artist) will be doing the map graphics.

An initial version will be delivered to backers with manual save transfer and load pbem functionality.
Steam integration, a more sophisticated pbem mechanism and a website will follow.
There will likely also be added functionality such as more shapers, buildings, trees etc.

[JudgeDredd]

I have no idea what game this is pertaining to 

[Pete Dero]

I have no idea what game this is pertaining to 

Posted in the General Staff forum.

This is the game : http://general-staff.com/

[bbmike]

Yes, look through this sub-forum for more information. Really interesting looking game so far. 

[Adraeth]

Excellent, i am happy there is a parallel work on the AI from Ezra and yours for engine and editors. Take your time and we will have an excellent kriegspiel 

[Andy ONeill]

Ezra and I have been discussing how to improve "drawing" elevation.
Smoothing out contour based slopes without taking forever (writing or running)
I think I have a way to do improve contour handling and tick both those boxes along with another.

If you've watched Ezra's videos or used the original prototype map editor you are probably familiar with the concept of drawing a greyscale background and importing this for elevations.
This is a good method because it's simple and a gaussian blur gives you smoothed out slopes.
Simple and practical are huge plusses.
So long as you're OK with photoshop or some similar package then you can use a gradient for gradual slopes and get pretty good results fairly easily.
Those users who don't have photoshop could use Paint.Net with a gaussian blur plug in ( free ).

The downside is the learning curve for those users who don't use such graphics software.

Reproducing photshop would be way too much work and even if I did then the learning curve moves from photoshop to generalstaff.
Clearly not a viable route.

Some sort of a simpler compromise option looks to be fairly easy to implement though.
There is already a way to draw contours.

The (outline ) plan is to translate those contours to a greyscale picture.
Using an approach similar to how I do elevation colours.
Run a gaussian blur over the whole image.
Then translate this to elevations in a similar way to the import.
That way anyone can do a few hills and valleys reasonably easily.
If you want more then you use the shapers ( more about these later ) or look into "proper" drawing software.

And of course.
If drawing contours sounds a bit like hard work then you can still download real wold elevation data or just buy a scenario.

[Andy ONeill]

Map Editor Progress

The shapers are nearly done.
Needs a bit of styling up.
And the odd bit adding - like it'd be an idea to show minimum and maximum elevation currently in a map.

Plus a test - fix cycle.
There are probably a bunch of bugs in there I've added along with the new stuff.

A quick list of the rest of the work on this:

Adding control of some attributes to the drawing options.
EG a transparent fill on City so you can see the picture underneath or just place buildings there yourself.
Or use a separate picture file entirely as fill.
( Alternatives to the current abstract representation. )

More choices on buildings and trees.

Custom layer to allow addition of own stuff entirely in uncompiled xaml.
This will be the fall back option allows you to do things the map editor doesn't do.

Import elevations from file.
+ at least one separate utility allowing you to translate DEM you've downloaded.

Command line switch for full screen.
Save and reload user preferences.

Bit of neatening up.

[Andy ONeill]

I've been looking into how to support import of elevation from DEM.
First step in any piece of development is a "reality check" look at the practicality.
With other things I already have an idea without any research so this is often just "yeah, I can do that by..... ".
In this case it's weird stuff working with third party data that's "free".
Free sounds good until you try and work with it and "free" software or interfaces often come at a cost elsewhere.
Totally free often means there's no money to make it easy to get that data and no support if you hit any problems.

There are several problems inherent to working with this data.
I already knew this was going to be way harder to write than the google api support.
That's why I chose Google as the primary third party supplier.
What I hadn't particularly considered is how hard it might be for someone to use one of these DEMs.

This particular post is therefore an explanation of why I'm shelving the work for now.

The long explanation:

Elevation data ( DEM ) is available from a number of sources.
These vary but you register as a user then you pick an area you want your data from.

Looking at one of these - ALOS World 3D – 30m.
You start off with a map of the globe and drill down from there by clicking on a square.
I tried to find Waterloo.
Took me two goes to find roughly the right part of europe.
Then you click on a square from that.
A couple of goes and I'm looking at:


The numbers at the top are latitude and longitude.
They seem to be the bottom left of that square, the pin marks that spot in google:


Finding a specific location is really hard.
Downloading a world of data and supplying it via our own front end would be another project and is not practical.

Next...
I loked into how I'd work with the data.
When you download a file for a square it comes as a tar compressed file.
A user would (you) then uncompress that file to get a geoTiff format file.
A tiff might be a sort of picture file but this is a data file which sort of re-uses how image files work internally for metadata.
You can't just display a geoTiff.
That needs re-processing to extract the data and then processing again in order to give a graphical representation.
Once I wrote code to do all that then the user could pick a rectangle out a displayed picture and I grab the grayscale from that.
Setting aside how hard it would be for someone to work out where they drag that rectangle on a huge chunk of europe....

Writing these steps are a fair bit of work and the last is technically problematic.
There's a high risk the last step only gives 255 shades of grey.

Summary:

Looks to be a lot of work.
Will be so hard to use maybe nobody actually uses it.
Shelved for now.

 

[Andy ONeill]

Investigating Open-Elevation

This project https://open-elevation.com/ offers elevation data via a web service "similar" to google elevation api.
Which initially sounded really quite good.
On closer examination there are several issues though.

1) This is a one man project which he pays to host privately. That means there's a high risk he will have to "go commercial" or take it down.
2) The signs of this are already showing. He's throttled it to 1 request per second. Which means downloading a map worth of data would be glacial. There are 929,775 cells in a map.
3) Support - well free software isn't really free. You pay elsewhere.
4) His dataset doesn't cover the entire globe and is only 250m resolution.

Not a viable option.

[Andy ONeill]

Game Design

The editors are now stable and cover enough to move on to the game.
We are now discussing design of the game.

Due to the nature of agile development, this is likely to mean changes to the editors.
That's just how agile works.
You get a better end product by starting with an approximate design and adjusting that towards perfection rather than trying to design perfect from scratch.

[Andy ONeill]

Changes are definitely necessary to existing code.
These are significant but not huge.

We're still discussing the best way to do various things in the game and details in the design are still fairly fluid.
Flowing towards a slicker better design, naturally.
:^)

The game itself will be the most substantial module, but we (obviously) already have some code it will re-use.
My best guess is still December.
I'll probably be wrong one way or another though.

This is for the game and design modules.
We're still talking about the best way to test.
This will be delivered ASAP to you guys who have already paid.
Any pbem will be entirely manual at that stage.

I will then move on to steam integration and a web site.
The web site will be necessary if we're to make the pbem experience any smoother.
But all that is blue skies.

[bbmike]

Sounds great! Do you still need beta testers? If so, I volunteer.

[Andy ONeill]

If you're an early backer then I think beta testing is part of the deal.
I'll mention it to Ezra though.
It will be him arranging beta testers and taking bug reports / suggestions.

[Andy ONeill]

I'll shortly be starting on the game.
One significant initial aim will be to build in a way to prove our shooting algorithms.
These work fine in theory but it's a core part of the game and they will need refining and proving.
It's best to do this work early because it'll be easier to cast aside those parts of the app which are purely for allowing this write-test-refine-test-repeat cycle than if I build it all and then try and nail on a way of testing.

As well as discussion of the design, Ezra has been working on a Wiki, so testers will have documentation.

[Andy ONeill]

Time for a re-assessment of delivery date.

Today I created solutions for the Game and Sandbox.
This is now October and my guess is in the order of 6 months work before the game is likely to be finished.
That would be April 2019.

The Sandbox.
This will be a utility primarily for internal usage.
We may decide to release this to users so they can experiment with the results of changes to stats.
Maybe leverage it as a sort of simplistic trainer.

The idea is that this allows a user to easily test the results of combat.
You load a scenario.
From that you can pick a red and a blue unit.
These can be dragged around and rotated.
When you hit a button the combat routines are run and results displayed.
I'll probably run it 10 times or so.

Detailed design to be decided as I go.
Since it's "just" a utility there are likely to be corners cut on the ui design wherever that saves time.