Tag Archives: Maps

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.

Thank You Wargaming Community!

Last week I posted an appeal to the wargaming community and backers of The General Staff Wargaming System that I needed more maps and Orders of Battle (OOBs). The General Staff Wargaming System is designed to handle any conflict in the Black Powder era and the machine learning AI needs as much input as possible.

The five layers that make up a General Staff map.

The General Staff Army Editor makes it pretty easy to create four of the five layers of a map file (see above). The problem is the beautiful background image that the user sees on screen (the computer AI couldn’t care less about the visual map). I’ve been able to locate a lot of great maps; especially from the American Civil War and the US Library of Congress but we still need more.

Waterloo from Glenn Drover (Forbidden Games) and Jared Blando. Click to enlarge.

A couple of days ago I received an email from the famous game designer, Glenn Drover (Forbidden Games), who offered us the use of three maps that he had researched and were drawn by artist Jared Blando. Here’s a link to Forbidden Games’ site. Please check out their fantastic board games!

Ligny from Glenn Drover (Forbidden Games) and Jared Blando. Click to enlarge.

The three battlefield maps were Waterloo, Ligny and Quatre Bras.

Quatre Bras from Glenn Drover (Forbidden Games) and Jared Blando. Click to enlarge.

What is especially amazing is how well these three maps fit the style that I’ve wanted to create for General Staff.

In addition to these three great maps, which we will definitely be using for the battles of Waterloo, Ligny and Quatre Bras, I’ve received emails from a number of other wargamers who have offered to research OOBs; especially some in another language.

I am completely blown away (I know it’s a cliche, but I don’t have any other words) by the kindness and generosity shown me by the wargaming community. Thank you very much!

AI Routines Added But We Need More Testing Data (Maps & Armies)

The AI routines for calculating battle lines and range of influence have been ported over from the original C++ code to C#:

Antietam displaying Range of Influence and Battle Lines. Click to enlarge.

I’ve written a number of blog posts about these AI routines which you may find interesting:

Battle Lines, Commanders & Computers

What’s Wrong With This Picture?

Wargame AI Continued: Range of Influence

That’s the good news. The bad news is that I’m also installing the Machine Learning AI that was the basis of my doctoral research and it needs more battles to learn from. A lot more. Currently there are 15 armies (click here) and 5 maps (click here). Ideally I would like about 50 armies and 30 maps used to create 30+ battle scenarios.

Are you a cartographer or a researcher?  If you are, and you’re interested, I could use your help if you would like to volunteer. All the maps and armies were created using the tools that you, as a backer, have already been provided: The General Staff Army Editor and The General Staff Map Editor. A little bit of PhotoShop or another paint program was used to clean up the old maps and a free program, Inkscape, was used to create the paths for roads and rivers. The most difficult task is the research. Finding Order of Battle Tables (OOBs) are pretty easy but General Staff requires knowing the actual troop strength of every unit. Sometimes, that is very hard to find. For the maps, adding elevation is usually the most difficult bit, but there are a number of built-in tools to make this easier.

If you’re interested in helping add to the data files please contact me directly: Ezra@RiverviewAI.com.

Maps, Commanders & Computers

How a map of the battle of Antietam looks to us humans. Screen shot from the General Staff Map Editor. Click to enlarge.

How the computer sees the same map (terrain and elevation). This is actually a screen shot from the Map Editor with the ‘terrain’ and ‘elevation’ layers turned on. Click to enlarge.

Computer vision is the term that we use to describe the process by which a computer ‘sees'1)When describing various AI processes I often use words like ‘see,’ ‘understand,’ and ‘know’ but this should not be taken literally. The last thing I want to do is to get in to a philosophic discussion on computers being sentient. the world in which it operates. Many companies are spending vast sums of money developing driverless or self-driving cars. However, these AI controlled cars have had a number of accidents including four that have resulted in human fatalities.2)https://en.wikipedia.org/wiki/List_of_self-driving_car_fatalities The problem with these systems is not in the AI – anybody who has played a game with simulated traffic (LA Noir, Grand Theft Auto, etc.) knows that. Instead, the problem is with the ‘computer vision’; the system that describes the ‘world view’ in which the AI operates. In one fatality, for example, the computer vision failed to distinguish a white semi tractor trailer from the sky.3)https://www.theguardian.com/technology/2016/jun/30/tesla-autopilot-death-self-driving-car-elon-musk Consequently, the AI did not ‘know’ there was a semi directly in front of it.

In my doctoral research I created a system by which a program could ‘read’ and ‘understand’ a battlefield map4)TIGER: An Unsupervised Machine Learning Tactical Inference Generator http://www.riverviewai.com/download/SidranThesis.html. This is the system that we use in General Staff.

The two images, above, show the difference in how a human commander and a computer ‘see’ the same battlefield. In the top image the woods, the hills and the roads are all obvious to us humans.

The bottom, or ‘computer vision’ image, is a bit of a cheat because this is how the computer information is visually displayed to the human designer in the General Staff Map Editor. The bottom image is created from four map layers (any of which can be displayed or turned off):

The four layers that make up a General Staff map.

The background image layer in a General Staff map is the beautiful artwork shown in the top image. The place names and Victory Points layer are also displayed in the top image. The terrain and elevation layers are described below:

The next three images are actual visual representations of the contents of memory where these terrain values are stored (this is built in to the General Staff Map Editor as a debugging tool):

Screen shot from the Map Editor showing just terrain labeled as ‘water’. Click to enlarge

Screen shot from the General Staff Map Editor showing the terrain labeled as ‘woods’. Click to enlarge.

Screen shot from the General Staff Map Editor showing the terrain labeled ‘road’. Click to enlarge.

A heightmap for Antietam. This is a visual representation of elevation in meters (darker = lower, lighter = higher). Click to enlarge.

To computers, an image is a two-dimensional array; like a giant tic-tac-toe or chess board. Every square (or cell) in that board contains a value called the RGB (Red, Green, Blue5)Except in France where it’s RVB for Rouge, Vert, Bleu  ) value. Colors are described by their RGB value (white, for example, is 255,255,255).  If you find this interesting, here is a link to an interactive RGB chart. General Staff uses a similar system except instead of the RGB system each cell contains a value that represents various terrain types (road, forest, swamp, etc.) and another, identical, two-dimensional array, contains values that represent the elevation in meters. To make matters just a little bit more confusing, computer arrays are actually not two-dimensional (or three-dimensional or n-dimensional) but rather a contiguous block of memory addresses. So, the terrain and elevation arrays in General Staff which appear to be two-dimensional arrays of 1155 x 805 cells are actually just 929,775 bytes long hunks of contiguous memory. To put things in perspective, just those two arrays consume more RAM than was available for everything in the original computer systems (Apple //e, Apple IIGS, Atari ST, MS DOS, Macintosh and Amiga) that I originally wrote UMS for.

So, not surprisingly, a computer stores its map of the world in which it operates as a series of numbers 6)Yes, at the lowest level the numbers are just 1s and 0s but we’ll cover that before the midterm exams. that represent terrain and elevation. But, how does a human commander read a map? I posed this question to Ben Davis, a neuroscientist and wargamer, and he suggested looking at a couple of studies. In one article7)https://www.citylab.com/design/2014/11/how-to-make-a-better-map-according-to-science/382898/, Amy Lobben, head of the Department of Geography at the University of Oregon, said, “…some people process spatial information egocentrically, meaning they understand their environment as it relates to them from a given perspective. Others navigate more allocentrically, meaning they look at how other objects in the environment relate to each other, regardless of their perspective. These preferences are linked to different regions of the brain.” Another8)https://www.researchgate.net/publication/251187268_USING_fMRI_IN_CARTOGRAPHIC_RESEARCH reports the results of fMRI scans while, “subjects perform[ed] navigational map tasks on a computer and again while they were being scanned in a magnetic resonance imaging machine.” to identify specific, “involvement or non-involvement of the brain area.. doing the task.”

So, how computers and human commanders read and process maps is quite different. But, at the end of the day, computers are just manipulating numbers following a series of algorithms. I have written extensively about the algorithms that I have developed including:

  • “Algorithms for Generating Attribute Values for the Classification of Tactical Situations.”
  • “Implementing the Five Canonical Offensive Maneuvers in a CGF Environment.”
  • “Good Decisions Under Fire: Human-Level Strategic and Tactical Artificial Intelligence in Real-World Three-Dimensional Environments.”
  • “Current Methods to Create Human-Level Artificial Intelligence in Computer Simulations and Wargames”
  • Human Level Artificial Intelligence for Computer Simulations and Wargames.
  • An Analysis of Dimdal’s (ex-Jonsson’s) ‘An Optimal Pathfinder for Vehicles in Real-World Terrain Maps’

These papers, and others, can be freely downloaded from my web site here.

As always, please feel free to contact me directly if you have any questions or comments.

References   [ + ]

1. When describing various AI processes I often use words like ‘see,’ ‘understand,’ and ‘know’ but this should not be taken literally. The last thing I want to do is to get in to a philosophic discussion on computers being sentient.
2. https://en.wikipedia.org/wiki/List_of_self-driving_car_fatalities
3. https://www.theguardian.com/technology/2016/jun/30/tesla-autopilot-death-self-driving-car-elon-musk
4. TIGER: An Unsupervised Machine Learning Tactical Inference Generator http://www.riverviewai.com/download/SidranThesis.html
5. Except in France where it’s RVB for Rouge, Vert, Bleu
6. Yes, at the lowest level the numbers are just 1s and 0s but we’ll cover that before the midterm exams.
7. https://www.citylab.com/design/2014/11/how-to-make-a-better-map-according-to-science/382898/
8. https://www.researchgate.net/publication/251187268_USING_fMRI_IN_CARTOGRAPHIC_RESEARCH

New Battles on Old Battlefields

Plate 1 from, “The American Kriegsspiel. a Game for Practicing the Art of War upon a Topographical Map,” by W. R. Livermore, Captain, Corps of Engineers, U S Army published in 1882. Click to enlarge.

When I was about ten years old my father brought home an original copy of Esposito’s The West Point Atlas of American Wars. My life was forever changed. I had always been interested in military history and maps but now I could clearly see the complexity of tactical maneuvers and how these battles unfolded.

In previous blogs, I have written about my introduction to wargaming through Avalon Hill’s superb games. While diving deeper into the history of American wargaming I discovered Livermore’s American Kriegsspiel (by the way, it is available online from the Library of Congress here). When I first saw Plate 1, above, I couldn’t help but think of the officers at West Point, ‘practicing the Art of War’ on that black and white map.

Consequently, one of the first things that I wanted to do with the General Staff Map Editor was bring Plate 1 back to life so new battles could be fought on it:

The American Kriegsspiel map imported into the General Staff Map Editor and converted for use with the General Staff Wargaming System. Grid lines are optional. Click to enlarge.

My good friend, Ed Isenberg, did the colorization and we added some new features in the Map Editor to support importing rivers, roads and other terrain features, from a PhotoShop image (for more information see the online documentation for the Map Editor here).

Importing the American Kriegsspiel map into the General Staff Wargaming System was a good beta test of the Map Editor. If you are an early backer you should have the location and password to download it. If, for some reason, you don’t have these, please contact me directly.

One of the interesting features of the General Staff Wargaming System is that any two armies created in the Army Editor can be combined to create a battle scenario on any map created in the Map Editor. Thinking about all the ‘mix and match’ combinations I decided to create an army, in the Army Editor, from the Order of Battle Table (OOB) for the French Imperial Guard, August 1, 1813 from George Nafziger’s, superb “Napoleon at Dresden,” book:

The French Imperial Guard Order of Battle in the General Staff Army Editor. Click to enlarge.

We are currently beta testing the General Staff Scenario Editor. Here I’ve imported the American Kriegsspiel map (from above) and the French Imperial Guard (from above). To position units, just click and drag from the OOB on the left:

Screen shot of the General Staff Scenario Editor where the French Imperial Guard is being positioned on the original American Kriegsspiel map. Click to enlarge.

Hopefully, this will get your imagination going and thinking about what maps, armies and scenarios you would like to see. In addition to the ability to create your own new scenarios on old battlefields, General Staff will ship with 30 historical scenarios (the list is published in previous blogs).

Please feel free to contact me directly if you have any questions.