Movement & Maps

Screen shot showing unit movement arrows for the battle of Antietam scenario. Note how movement is stopped by the small creek in the upper left hand corner of the screen. Click to enlarge.

I‘m in self-quarantine. As many of you know, I had a bone marrow / stem cell transplant in 2014 followed by a year of intense chemo. I’m fine (all things considering) but my immune system took a beating. In 2014 H1N1 put me in the hospital for 3 days so I’m taking COVID-19 seriously as, uh, the plague. In a way, being cooped up in the house (the weather hasn’t been cooperating, either, as I had hoped to replace my daily gym workout with long walks with my dog, George) is a lot like a typical upper Midwestern winter: it’s what I call ‘good programming weather’. There’s not much else to do but hunker down and write code. So, obviously, I’m working on General Staff and I wanted to show you an update (above).

General Staff is being written in C# and Windows Programming Foundation (WPF). There are a number of technical reasons why this was a good idea but I’m not overly familiar with WPF and doing some basic things, like creating these transparent movement arrows, took far longer, and involved a lot more programming, than I thought it would.  My partner on this project, Andy O’Neill, is a WPF rockstar; I’m a novice. I would much rather be working on the ‘under the hood’ stuff (like AI) but for the last week or so I’ve been working on movement arrows while Andy is busy with another project (the kind that pays the rent). Anyway, I’m very pleased about how they turned out. Please feel free to write me with comments.

Movement arrows for units at Quatre Bras. Note how blue units are stopped by the stream feeding the large pond. Click to enlarge.

Forward movement of this blue division is stopped by this tiny creek.

But, I also discovered a very interesting problem while testing these movement routines: our maps are too good! If you look at this detail (right) from the Antietam screen capture (above), you’ll see that movement is stopped when it encounters a tiny creek. I’ve walked that area of the Antietam battlefield and that little creek (well, I think it would be more properly called a ‘crick’) wouldn’t stop a division moving forward. However, the movement validation routines stop units from crossing bodies of water (except in column formation while crossing a bridge or a ford).  Ed Kuhrt, who digitized these great maps and copied every small detail was, perhaps, too precise. Definitely better to err on the side of being too precise when it comes to maps, Ed.

We’re seeing the same thing at Quatre Bras (above): the little streams that feed Materne Pond (Etang Materne) are also stopping the French from attacking. I haven’t been to Quatre Bras but I know the French crossed the small streams to attack the Anglo-Allied army’s positions.

Luckily, fixing this is easy. If you have done any work with the General Staff Map Editor you know that erasing terrain features, like water, is quick.

Removing the water in the little stream that feeds Antietam Creek by placing a ‘field’ over the water. Note that the ‘Field’ object is ‘above’ the ‘River’ object on the left Edit Terrain tab. Screen shot. Click to enlarge.

In the above screen shot we’ve opened the Antietam map in the General Staff Map Editor and drawn a ‘Field’ over the ‘crick’ that kept the Union forces from advancing. Note that both the Field and the River are objects and whichever object is higher in the list on the left ‘overwrites’ lower objects. If, for whatever reason, we wanted to restore the water in the creek we could either delete the Field or move it lower down the list than the River object.

Edit: After originally posting this, some readers (see comments, below) suggested that units crossing a small stream should suffer a movement penalty. This is absolutely correct. Instead of ‘painting’ with ‘field’ terrain, I should have used ‘mud’. This allows for a movement penalty (set in the Scenario Editor).

Adjusting unit type speeds across various terrain types in the General Staff Scenario Editor. Screen capture.

And now that that obstacle to movement has been eliminated the I and XII Union Corps can advance:

Now that the water has been removed from the little stream feeding Antietam Creek the Union forces can advance again. Screen shot.

As always, I would love to hear any comments or feedback that you may have.

25 thoughts on “Movement & Maps

  1. Phill

    I’ve been following the progress of this title for a while now. I recall the Universal Military Simulator back in the 80s. I look forward to seeing what the Ancient and Modern Era aspects contain. This seems to be geared more towards large scale conflicts. Can it be used to create small scale engagements as well? I’m thinking each unit representing a squad or fireteam, each unit representing a tank, artillery, etc. Is that feasible within the scope of this program?
    Thanks for the work you’re putting into this big project. So many options for the user to create with.
    hope you’re staying healthy too.

    1. EzraSidran Post author

      General Staff will certainly support small scale engagements. I just happen to start with some ‘well known’ battles.

  2. CRAIG JOHNSON

    I too have been following from afar—-I’m concerned about the direction you chose to take—covering the stream feature with a field.
    Recognizing that features (rivers, streams, gullies) have impacts is appropriate—but they are also not “absolute” … even a wide shallow river can be crossed (though disorder might be severe)….so my point is there should be some “moderation” of movement BY FEATURE….big, deep, steep banked rivers may have 0% traverse ability , but your small stream something like 85%….so they are slowed like 15% and possibly a disorganization factor….Completely recognize the issue with features on the map then needing to be tagged—-Segments could inherit from downstream segments, segments hold individual values for things like fords, etc.

    Just masking it — special case change of actual map– smacks of the wrong direction, to me.

    You’ve got a Classic and invaluable thing going—short-cuts might be simple, but in the end I think they reduce the net contribution of your work.
    GOOD LUCK….I’ll look again at taking this into my chest of toys 🙂

    1. EzraSidran Post author

      What I should have done is drawn with ‘mud’, not ‘field’ and set a movement penalty as below:

      There are a lot of ways to do things in General Staff.

  3. woos

    I agree with CRAIG that the stream should slow down the troops a little and create a little bit of confusion.Rather than simply replacing it with a flat field, we are looking forward to the release of the game on steam. hope you’re staying healthy.Thank you for your good work!

  4. woos

    I agree with CRAIG that the stream should slow down the troops a little and create a little bit of confusion.Rather than simply replacing it with a flat field, we are looking forward to the release of the game on steam.hope you’re staying healthy.Thank you for your good work!

    1. EzraSidran Post author

      There are a number of ways to set up movement costs for various terrain types in General Staff. Let’s see if I can include a screen image in this reply…

      Hopefully there’s an image, above, of the Unit Movement matrix. Anyway, you could set that area to ‘Mud’, for example, and then set a slower movement speed.

      1. woos

        HelloEzra, Does general staff have a formation system for individual units? such as the ability for infantry to form rectangular formations against cavalry? Thank you!

  5. Erik

    I’m thinking the movement rates chart needs some expanding. There are a plethora of terrain types I do not see here, and would be needed in any system capable of fighting any period battle. Desert, steep, mountainous, rocky/rough, snow, etc all come to mind. The units may have to negotiate multiple terrain types at once, like crossing a ravine in a woods during the winter. Should the sum of the types exceed the movement rate of the unit, it halts in place. This would then make a piece of ground impassable. Just assign movement rates to all terrain. Even ocean. If a land unit somehow has the movement rate to enter the ocean, it can “walk on water” : ) All movement would then be controlled by the movement rate of the unit. Have enough, and you can enter. Assigning low movement rates (example artillery) ensures the unit can only move on easy terrain or roads. High movement rates (like for Jaegers) would allow these special units to enter most terrain types.

    I may be describing it wrong here. I’m not wanting to give jaegers massive movement ability in terms of distance travelled. They would move the same distance as other infantry on the road for example or close to it. I’d call it more like having sufficient “skill” to move through the terrain requires a certain movement ability (which I was calling movement rate). Mountain troops would move better in mountains than any others. This is just one example. Hopefully it makes sense.

    I know this adds significant complexity, but if we are going for a better battle simulator, then I am thinking these types of basic details need to be present and usable. Special troop abilities to navigate terrain types is a fundamental bit of reality I’d expect to see in a program such as this.

    I’m glad I backed this and am looking forward to more updates.

    1. EzraSidran Post author

      We calculate movement cost for each ‘step’ a unit makes. So, as it passes through various terrain types it incurs different movement costs.

      1. Erik

        Is that generic, such that all infantry moves the same through a “step” regardless of type of infantry? Using my example, will mountain troops move better through mountains? Or will all infantry move the same through mountains?

  6. woos

    Hello Ezra ,In the general staff a single unit could change formation? For example, when infantry threatened by cavalry do they become rectangular formation to against them ?Thank you!

  7. Eduardo Visconte

    Hello,
    I gather then from the comment that as long as a ford (or bridge) is present the AI can then plot movement across it ?
    That or muddy sections would solve the problem?
    Thank You

  8. Eduardo Visconte

    Hello again,
    would the depth of the creek be a hindrance to AI plotting a movement across?
    Noticing this in the map making process where creek banks could become gorges by a wrong shade
    of gray.

    1. EzraSidran Post author

      All points on the map have Terrain AND Elevation values. Slope is calculated and used in movement calculations (as is terrain and formation). So, yes, a steep bank would slow down movement.

    1. EzraSidran Post author

      Hoping for internal beta-testing of the actual game in a month or so.

Comments are closed.