General Staff will Ship in 2022

A few of Grant’s unsuccessful attempts to take Vicksburg. Map from West Point Atlas of American Wars. Library of Congress. Click to enlarge.

Grant took Vicksburg on his sixth attempt. He first tried a direct movement, east of the Mississippi, against the city but was forced to turn back after Confederate General Van Dorn’s raid destroyed his supply base. Sherman next attempted a direct assault and failed at Champion’s Bluff. Grant then tried to cut Vicksburg off from the Mississippi by digging a great canal across the neck of a giant oxbow. Unusually low water levels in the river that year caused another failure. Grant also tried more canal digging and river clearing at Lake Providence and the Yazoo Pass without luck.

Col. Theodore Lyman, a staff officer of the Army of the Potomac, wrote of Grant, “He habitually wears an expression as if he had determined to drive his head through a brick wall, and was about to do it. I have much confidence in him.”

Grant finally succeeded with his brilliant amphibious landing south of Vicksburg followed by a series of ‘must win’ battles that concluded with besieging the city on May 22, 1863. Confederate General Pemberton surrendered Vicksburg on July 4, 1863.

The General Staff: Black Powder Wargaming System is comprised of four separate programs: the Army Editor, Map Editor, Scenario Editor and the actual Game Engine, itself. The first three have been done for some time (it’s what I use to produce scenarios for testing the AI). They were written in C# using Microsoft’s Windows Presentation Foundation (WPF) which is often used for creating desktop business applications. This decision made sense because the Army, Map and Scenario Editors function not unlike a suite of business applications that create and share data with a common look and feel. However, while WPF was a good development decision for the Editor programs it turned out not to be a great tool for creating the Game Engine.

A flow chart of the General Staff: Black Powder Wargaming System. Files created in the Army Editor and the Map Editor are combined in the Scenario Editor to create a scenario or simulation. Click to enlarge.

What the Game Engine does is it takes data created in the three Editor programs, displays them in a visually exciting way, enables the user to make input (orders), and simulates those orders (as well as the AI’s orders) and the resulting combat to the highest degree of accuracy possible. That sounds like a lot, but it really isn’t. And the heavy lifting that the Game Engine is being asked to do is all visual: making everything look good on the screen.

Recently, I’ve been looking at Grand Tactician: Civil War which is an immersive voyage into 19th century American typography, cartography, tactics and grand strategy. I eagerly look forward to having the time to do more than gaze upon it in amazement ¹⁾Full disclosure, the developers were kind enough to give me a review copy of Grand Tactician and, damn, it looks fantastic.. I reached out to Ilja on their development team and he convinced me that we should complete the General Staff Game Engine in Unity (which is what they used for Grand Tactician). What they accomplished visually with Grand Tactician was precisely the look and feel that I wanted for General Staff ²⁾I’m talking about the typography and the UI, not thousands of tiny 3D soldiers on the battlefield; which look really great, but, General Staff is not that kind of a wargame..

Consequently, we are officially announcing that we are abandoning writing the General Staff: Black Powder Game Engine in WPF and, instead, will be creating it using the Unity engine. We believe that this will produce a far superior visual experience ³⁾Please note: we will not being using Unity to create a 3D simulation with tiny soldiers. I like playing those kind of games, but that’s not what General Staff is..

Because Unity is designed to facilitate the creation of computer games, this move will greatly accelerate the completion of the General Staff Game Engine and will allow us to ship General Staff: Black Powder this year.

I am certainly not U. S. Grant, though I like to think I have some of that bulldog determination. Like Grant before Vicksburg, I’ve had to acknowledge that our first attempt will not succeed and we’re moving on to another plan. I am sorry for the delay in the release of General Staff and am confident that, with Unity, we will soon be reporting some good news.

I am also very excited to announce that my good friend, Damien, will be joining the team to specifically work in Unity completing the General Staff Game Engine. Damien lives in Ireland and has been a devout wargamer since playing Arnhem on the ZX Spectrum. When not enjoying a Guinness or a Jamesons, he’ll be playing tabletop or computer games, whether that means pushing cardboard counters across hex boards, drawing LOS between badly painted miniatures on the tabletop, or day-long sessions in front of a computer – where he particularly enjoys playing against a challenging, non-cheating AI. Damien is a 28 year veteran of the IT industry, having worked on everything from telecoms, healthcare and financial systems, across Mainframes, Linux, Unix and Windows, and co-inventor of two messaging system patents. He has a particular passion for language processing and domain specific languages, originating from his interest in the elegance of recursive descent compiler construction.

References[+]

References
↑1	Full disclosure, the developers were kind enough to give me a review copy of Grand Tactician and, damn, it looks fantastic.
↑2	I’m talking about the typography and the UI, not thousands of tiny 3D soldiers on the battlefield; which look really great, but, General Staff is not that kind of a wargame.
↑3	Please note: we will not being using Unity to create a 3D simulation with tiny soldiers. I like playing those kind of games, but that’s not what General Staff is.

Why Machines May Kill Us In Our Sleep

4 Replies

An amazing screen capture of the AI’s solution to a problem. It has found a 1 pixel gap between the data and the edge of the screen and is exploiting it to successfully find an ‘open flank’ of Red. Click to enlarge.

Professor Alberto M. Segre was my thesis advisor and one day he said to me, “You know when your AI is really working because it will surprise you.” Today I got to have one of those weird surprises.

The screen shot (above) is a visual representation of what the AI is up to. You won’t get to see this in the actual game. The program that’s running is called the AI Editor which is a bit of a misnomer because you don’t actually edit the AI in it; you mostly just get to observe what it’s doing. There’s a lot of stuff going on in the above image. There are multiple layers visually displaying different types of data (check out the blog – Layers: Why a Military Simulation is Like a Parfait – for more information about these). But, what interests us are the AI layers: Battle Groups, Objectives, and that thin yellow line that snakes from a group of blue units, crossing Antietam Creek at the Middle Bridge and then, amazingly, exploiting a data anomaly to reach its goal: a point far behind enemy lines.

Some background on the situation:

The map of the Antietam Battlefield (screen shot) with terrain and elevation layers displayed. Click to enlarge.

Underlying all the clutter from the first screen capture, top, is the battle of Antietam (above). The map has been rotated 90 degrees to the left so north is now pointing to the left; east is at the top of the screen.

After adding Blue (Union) and Red (Confederate) units to the map in their historical positions at 0600 September 17, 1862 the AI performed a tactical analysis from the perspective of Blue.

The AI ‘strategic’ analysis for Antietam playing Blue (Union).

The above are a list of Predicate Statements all of which the AI knows to be true. Statements preceded by the logical sign ∴ (therefore) are conclusions, or inferences, derived from the predicate statement referenced in the brackets. It is this analysis that determines if the AI will be on the offensive or defensive and what its objectives will be.

Next, the AI performs Range of Influence (ROI) calculations for the entire observable battlefield. I plan on doing a video about this later, but for now the darker the red (in the topmost screen capture) the more – and more powerful – weapons the Red army can bear on that point. The AI next divides all the units on the map into a forest of minimum spanning trees called Battle Groups. I want to do a video about this, too. However, if you can’t wait, these subjects are covered in my paper, Implementing the Five Canonical Offensive Maneuvers in a CGF Environment (free download).

Again, referring to the top screenshot you can see the AI’s calculations to this point:

It has determined it (Blue) will be on the offensive.
It has calculated enemy ROI.
It has assigned objectives to the first Battle Group.

Flanking Algorithm published in, “Algorithms for Generating Attribute Values for the Classification of Tactical Situations”. Click to enlarge.

Now the AI needs to determine if the enemy has an ‘open or unanchored flank’. In Algorithms for Generating Attribute Values for the Classification of Tactical Situations I published the Algorithm for Flanking Attribute Value Function (right). It basically comes down to this: can the AI trace an unbroken path from the center of the Blue Battle Group to a specific point (called the Retreat Point) far behind enemy lines without crossing into ‘No Go Areas’ (water, swamp) or entering any area controlled by Red’s ROI (literally the red areas in the topmost screen shot).

The reason that I was using Antietam as a test case for anchored / unanchored flanks is because years ago I had analyzed the battle for my doctoral thesis and knew it to be a classic example of anchored flanks; Lee’s left flank rests on the Potomac and his right flank is anchored on the Antietam. Granted, the Confederate flanks were held by Stuart’s cavalry with a little horse artillery support but they were still, by definition, anchored flanks.

Due to an error in the data that made up the Antietam terrain map a 1 pixel (about 3.8 meter wide) strip of ‘no terrain’ was inserted at the far right hand edge of the map (see blow up of screen capture, right; it’s the thin line between the water, represented in red, and the brown edge of the map). This meant there was a ‘land bridge’ across Antietam Creek where none existed in real life. A digital parting of the Red Sea, if you will. But, by the rules of the game the AI perfectly performed its function. There was no error in the AI – again, the AI performed better than I had dared hope – the error was with the data set.

And that’s how fifty years from now I can see a cyber-detective standing over the chalk marks around a body saying, “Yeah, the machine performed perfectly, brilliantly, in fact. But, the error in the data set killed him.”

It’s already happened in real life. For cars with autopilot the data set of the world in which it operates is crucial. However, “against a bright spring sky, the car’s sensors system failed to distinguish a large white 18-wheel truck and trailer crossing the highway, Tesla said. The car attempted to drive full speed under the trailer, “with the bottom of the trailer impacting the windshield of the Model S”, Tesla said.” The driver died. The AI functioned perfectly. But, the error in the data set killed him.

So, I fixed the error in the data set (probably caused by not using the right values in InkScape when I converted the Antietam Water.bmp into paths) and imported it back into the Antietam map using the General Staff Map Editor, saved it out, and ran the AI Editor again and saw this:

The AI did not display a yellow path from the center of the Blue Battle Group to the Red Retreat Point because none existed. Instead, it just wrote the first Predicate Statement in the Tactical Analysis stack: “Red’s flanks are anchored”.

Again, the machine was performing perfectly. And its results were no longer surprising.

Addendum

I recently got to experience this again (though this time it was caused by a different data bug) when I was reviewing the AI’s decisions at the battle of Manassas:

Because the Range of Influence was not calculating the very bottom row the AI found another, perfectly legal, way to reach its goal. Screen shot from the General Staff AI Editor. Click to enlarge.

In this instance, the error in the database was caused by the Range of Influence (basically a map of what red and blue can see and hit) not calculating the very last row. Consequently, the AI was able to legally trace a path from the blue forces in the northeast to their goal at the bottom of the map.

After this bug was corrected the AI performed as expected:

The AI correctly sees going around red’s left flank as the solution to the problem. Screen shot from General Staff AI Engine. Click to enlarge

In the above screen shot the AI has demonstrated the correct solution to the tactical problem facing blue at Manassas on July 20, 1861 (the day before the actual battle). Red’s left flank is unanchored. It’s wide open. Note how the AI identifies the one choke point (Sudley Springs Ford) in the plan.

So, the AI surprised me again. I think it’s looking pretty good. When you play against it, watch your flanks.

Seeing Old Battlefield Maps in a New Way

I Was Wrong About George Washington

Leave a reply

Washington Crossing the Delaware by Emmanuel Luetze. 1851. The Metropolitan Museum of Art. Click to enlarge.

I must confess that I was never much a fan of George Washington’s generalship. Having not studied American Revolution military history I thought that from 1776-1781 the British chased Washington and his sad excuse for an army up and down the eastern seaboard of what was to become the United States until the French Comte de Grasse defeated the British naval forces at the Battle of the Chesapeake and the Comte de Rochambeau at the head of a French army surrounded, besieged and eventually captured, Cornwallis at Yorktown.

To make matters worse, years ago I stumbled upon George Washington’s Expense Account which is, frankly, brutal. Washington turned down the magnanimous salary of $500 a month for being Commander in Chief of the Continental Army famously saying,

“As to pay, Sir, I beg leave to Assure the Congress that as no pecuniary consideration could have temped me to have accepted this Arduous employment (at the expense of my domesttic [sic] ease and happiness) I do not wish to make any Proffit [sic] from it. I will keep an exact Account of my expences. Those I doubt not they will discharge, and that is all I desire.” ¹⁾George Washington’s Expense Account, Washington, George & Kitman, Marvin, page 15

If Washington had accepted the salary he would have been paid $48,000 for five years’ service. Instead, his ‘expences’ came to $449,261.51! This book – and it contains a photocopy of every page of Washington’s Expense Account in fine copperplate handwriting along with a humorous explanation of the expense – is damning. Washington’s very first entry for June, 1775 was for $6,214 (over an entire year’s salary at $500 per month) for “…the purchase of five Horses… to equip me for my journey to the Army at Cambridge – & for the Service I was Then going upon – having sent my Chariot and Horses back to Virginia.” There are also numerous expenses for cases of the finest wines and plenty of food while at Valley Forge. Not surprisingly, when Washington offered Congress the same terms when he was elected president (no salary just expenses) Congress insisted that he take $25,000 a year; no expenses paid.

Like most Americans, what little knowledge I had of the battle of Trenton can be summed up in Luetze’s famous painting, above: Washington, posed heroically, crossed the Delaware River on Christmas Eve and surprised a garrison of drunken Hessian mercenaries at Trenton capturing them all without a shot. In reality, not much of that is true. Yes, Washington did attack Trenton but it was on the morning of December 26, 1776, and the Hessians weren’t drunk; they fought bravely and their commander, Col. Johann Gottlieb Rall, died leading them.

Then I discovered (from reading David Hackett Fischer’s Pulitzer Prize-winning Washington’s Crossing) that the amazing part of the story wasn’t the battle of Trenton (which really was an extraordinary tale of a small, poorly-equipped, non-professional army making an audacious amphibious crossing of an ice-choked river) but the campaign that followed the victory from December 30, 1776 to January 3, 1777.

The strategic situation in the Princeton / Trenton area, December 29, 1776. Screen shot from the General Staff Scenario Editor. Click to enlarge.

Washington’s forces had made it safely back across the Delaware River after the Trenton raid but he now faced a difficult decision: terms of enlistment were running out for many units in his army and he feared taking the field again in bitter cold with a diminished force. As always, Washington held a council of war. As the senior commanders of the army advised caution a courier arrived informing them that Brigadier General John Cadwalader with his Pennsylvania militia had already crossed the Delaware and was at Crosswicks itching for a fight with the British (this is the blue force at the bottom of the map, above). After more discussion, one group stated, “tho’ they would not have advised the Movement, yet it being done it ought to be supported.”²⁾Washington’s Crossing, David Hackett Fischer page 266. Eventually, with Washington’s urging, the council voted to support Cadwalader, recross the Delaware and, again, defeat the British in the field.

This was a bold strategy; a defeat of the Continental Army with its back to a river would probably spell the end of the revolution. Washington’s plan was to assemble his forces east of Trenton, in a strong defensive position on ‘good ground’ behind the Assunpink Creek and lure Cornwallis, who was commanding the British and Hessian forces, to attack. This Cornwallis did and was soundly defeated. Washington now moved decisively, sending his forces to capture Prince Town (Princeton) to the north. At the crucial moment in this battle Washington rallied the routed Pennsylvania forces saying, ” ‘Parade with us, my brave fellows! There is but a handful of the enemy, and we will have them directly.’ Washington [then] led his men straight into the center of the battle, within thirty paces of the British line. He was mounted on a white horse, an easy mark for any British soldier.”³⁾Ibid. page 334

Frankly, I cannot comprehend such bravery. The attack, of course, was a success and the Americans captured Princeton and, perhaps more importantly, demonstrated that their volunteer army would fight, could fight and could win. Washington showed superb strategic and tactical vision throughout these ten crucial days⁴⁾See https://tencrucialdays.org/wp-content/uploads/2019/09/eb14b5212fb62dfea8d100f3efd1950f.pdf for a wonderful series of maps that cover this campaign as well as extraordinary personal courage.

I was wrong about George. Washington.

References[+]

References
↑1	George Washington’s Expense Account, Washington, George & Kitman, Marvin, page 15
↑2	Washington’s Crossing, David Hackett Fischer page 266
↑3	Ibid. page 334
↑4	See https://tencrucialdays.org/wp-content/uploads/2019/09/eb14b5212fb62dfea8d100f3efd1950f.pdf for a wonderful series of maps that cover this campaign

Layers: Why a Military Simulation Is Like a Parfait

2 Replies

Detailed military simulations and wargames are made up of layers¹⁾Here is the obligatory link to Shrek and the layers, onions and parfait bit. by necessity. Layers keep simulation designers and users from being overwhelmed by oceans of data. In General Staff every scenario (battle) is made up of these layers (some are optional):

The Background Image. Ironically named because even though it’s underneath all the other layers it’s makes up most of what the user sees of the battlefield. However, the background image contains no data that is actually used by the computer; it is completely ‘eye candy’ for the user. That said, us humans get most of our data from looking at this map (we can make sense of the hills, roads, forests, rivers, etc.). But that’s not how computer vision works (see below).

The Background Image for the Antietam scenarios. Click to enlarge.

This map came from the Library of Congress (here). The Library of Congress is a great place to get royalty-free battlefield maps from American history. Personally, it’s exactly these old maps that inspired me to create General Staff. There is, however, one problem: these old maps are just not ‘GPS accurate’. That is to say, even though the General Staff Map Editor allows the user to directly import Google Maps elevation data, it won’t align properly with maps made over a hundred years ago without GPS data. That means the scenario designer will have to enter the elevation data by hand and not import it from satellite data.

The Terrain Layer. This layer is a visual display of what the computer ‘sees’ of the terrain: forests, water, fences, hedges, walls, swamp, mud, field, city, road, river, fortification, buildings (seven kinds), fords, and bridges.

The terrain layer for Antietam. Click to enlarge.

The Terrain Drawing tab (right). This is one of the tabs in the General Staff Map Editor (click here to go to the online Wiki for more detailed information). Click on the desired terrain type and then draw with either the mouse or a digitizing tablet and pen. I have absolutely no drawing abilities, but I’ve watched actual artists create a map using a digitizing tablet and pen in about 30 minutes. If you’re drawing a river, the harder you press with the digital pen the wider the river gets.

There are three ways you can input water and roads in the Map Editor: mouse, digitizing tablet and XAML code. For me, because I have very limited drawing abilities, I find using XAML code the easiest (below):

The Road Net Layer (optional). This image (below) was created in a paint program (PhotoShop, though any paint program that you’re comfortable with will work just fine). It was then imported into Inkscape (free download here) and exported as XAML.

The road net at Antietam. Click to enlarge.

The Water Layer (optional). Like the Road Net image (above) this was created in a paint program (PhotoShop). It was then imported into Inkscape (free download here) and exported as XAML.

Antietam water map. Click to enlarge.

The Elevation Layer. There are four ways to input elevation in the General Staff Map Editor: you can draw with the mouse, use a digitizing tablet and pen, input elevation data directly using Google Earth and directly importing a BMP image.

Antietam height map. Click to enlarge.

The Slope Layer. This layer shows the extrapolation of slopes from the elevation layer (above). Combined with the Background, and Elevation layer it can produce a dramatic 3D effect. See Trenton, below.

The Slope Layer for Antietam. Click to enlarge.

Blending Multiple Layers. This is a blend of the Background, Elevation, Terrain and Slope layers. The user can set the blend values (see screen shot from the Map Editor, right).

Antietam with background, elevation, slope and terrain blended. Click to enlarge.

The Places and Victory Points Layer. This layer allows you to set certain locations as Victory Points or Placenames. A Placename is a descriptive text placed on the map that has no importance to the simulation; e.g. labeling the Potomac River (below).

The Victory Point and Placenames Layer. Click to enlarge

The Units Layer. This is a visual representation of the current simulation state showing unit locations. This information may be filtered by Fog of War (FoW) and what units can observe other units (both friend and foe) using 3D LOS (see below):

The Units layer for Antietam. Note: reinforcements are displayed on this layer even though they won’t enter the scenario until later. This screen shot was taken from the Scenario Editor. Click to enlarge.

The Fog of War Layer. This layer is a visual representation of what can be observed from any point on the battlefield; in this case, the 3D LOS view from the Pry House (McClellan’s Headquarters at Antietam).

Antietam with complete Fog of War displayed for McClellan’s HQ at the Pry House. Click to enlarge.

The AI Layer. This layer is a visual representation of the output of a number of AI algorithms including Range of Influence (ROI), battle groups, and flank units. This is how the AI ‘sees’ the battlefield.

The AI Layer displays Red and Blue Range of Influence. Click to enlarge.

Trenton. I recently began working on a Trenton scenario. One of the best places to begin a search for a contemporary map of an American battle is the US Library of Congress. That is where I found the extraordinary campaign map for Trenton published in 1777.

From the US Library of Congress (published 1777, London). Click on the map to go to source.

From the above original map, Ed Kuhrt created an elevation or height map (see above) in PhotoShop. From that Elevation Layer we extrapolated the slopes and displayed them using an algorithm created by Andy O’Neill. When blended together the result is striking:

Screen shot of the Trenton map in the General Staff Map Editor. Note how the blending of the slope layer with the elevation and original background create a 3D effect. Click to enlarge.

References[+]

References
↑1	Here is the obligatory link to Shrek and the layers, onions and parfait bit.