Category Archives: Computers

Why This Game Is Taking So Long

Why is this wargame taking so long? The short answer is that I made a series of bad decisions. The longer answer involves explaining the bad decisions.

Before I began work on General Staff: Black Powder I had done a project for the US Army called MARS (Military Advanced Real-Time Simulator).

Image from the MARS: Military Advanced Real-Time Simulator feasibility report to the US Army. Screen shot of MARS.

I had used a Microsoft IDE (Integrated Development Environment) called XNA to write MARS in C# and I thought it would be a good environment in which to develop General Staff. XNA, on top of being fairly easy to implement a 3D or 2D game environment, had another interesting advantage: any program created with it was immediately portable to the XBox game console. This dovetailed nicely with my dream of someday bringing wargaming to a larger (and younger) audience.

Consequently, the first version of General Staff – including the Army Editor, Map Editor and Scenario Editor – was written using XNA. I had just begun working on the actual game itself when Microsoft suddenly announced that it was no longer supporting XNA. This, of course, sent shock waves through the XNA game development community.

Since I had already written a great deal of the necessary code in C#, and Windows remained my target audience (Windows makes up >90% of the gaming market) I decided to port (that’s a game development word for rewrite for another environment, but hopefully not rewrite everything) to Microsoft Windows Presentation Foundation (WPF).

I wasn’t thrilled about porting to WPF. First of all, I wasn’t that familiar with it and, secondly, it wasn’t easy (at least for me) to do a lot of the things that needed to be done. The Army Editor was a pretty easy port, but the Map Editor had some very specific, difficult problems having to do with drawing on the screen. Luckily, I found Andy O’Neill, who is a certified expert on WPF. Andy took over and decided to rewrite my code (properly for WPF) and, eventually, the Army Editor, Map Editor and Scenario Editors were completed. If you are an early backer of General Staff: Black Powder you should have these. They are also available for download on Steam.

By this point the General Staff: Black Powder suite of editors had now been rewritten three times for two different environments, but, it was finally completed and in a stable version. I have been using these programs to create numerous scenarios (some of which are already uploaded to Steam).

The Quatre Bras scenario in the General Staff: Black Powder Scenario Editor. Screen shot. Click to enlarge.

The last thing to do to complete General Staff: Black Powder was the actual game, or game engine. Usually, this isn’t too hard because about 80% of the code is recycled from the Army, Map and Scenario editors. Unfortunately, I just wasn’t happy with the how the game looked in WPF. WPF is great for creating business apps but it just wasn’t giving me the 19th century Victorian look and feel that I wanted. About this time I discovered that a number of former XNA users had banded together to maintain and expand the original IDE; it was now called MonoGame. I decided to write the General Staff: Black Powder game engine in MonoGame.

I was making pretty good progress, but ran into some problems and asked the MonoGame community for help (by the way, I’ve found the MonoGame community to be a great group for answering newbie questions and generously providing time and solutions). It was on the MonoGame community forum that I met Matthew T. who is an experienced XNA/MonoGame game developer (he has a game on Steam that has sold over 100,000 copies). Matthew, eventually, decided to rewrite large hunks of my MonoGame code (vastly improving it) and then began to add some wonderful debugging features.

Screen shot of Ligny scenario in General Staff: Black Powder debugger mode. Click to enlarge.

Matthew and Darin Jones also implemented Steam player versus player (PvP) and we’ve done some early playtesting with Matthew in the UK and me in the US playing against each other in real-time (this was an amazing experience and something that I never envisioned that we could pull off).

So, that’s where we are now. We’ve made great progress and we’ve taken far longer to do it than I had hoped or anticipated. A lot of the same code has been written and rewritten for different environments. With 20/20 hindsight I certainly could have managed this a lot better. I think we’re about two months away from a pre-release beta starting with PvP playtesting. This would involve all the early backers who would get new Steam keys.

As always, please feel free to contact me directly with any questions or comments

 

Fixing a Major Mistake

This screen shot is an example of the design flaw that has now been corrected. Units don’t instantly change from line to column formation. Note that the red infantry unit is first in line formation (facing northwest), it receives orders from the HQ to switch to column formation advance to a position, switch to line formation, travel in line formation, then switch to column formation and travel in that formation. If you observe closely, the unit one instant is in column formation and the next it is in line formation occupying a different portion of the terrain.

The first lecture I would give at the beginning of every semester started: “The greatest asset you can have as a programmer – or as a human being – is the ability to admit that ‘I screwed1)Full disclosure: I wouldn’t say ‘screwed up’. If you want to get an undergraduate’s attention use the ‘f word’. up’ fifty times a day if necessary. Because, until you admit you made a mistake, you can’t find you mistake. And until you find you mistake you can’t fix your mistake. The first step to fixing a mistake is to first admit you made it.”

In the above screen shot there is a glaring error and I didn’t see it for years. In my defense, nobody else saw it, either. The screen shot, below, shows the correct movement and unit formations:

In this screen shot you can see that the unit is switching formations correctly. Note how the unit first changes from line to column formation by ‘a left face’ command, then moves in column formation, avoiding the artillery battery, moving on to the road and advancing to the assigned location where the unit stops, changes into line formation via another ‘left face’, advances in line formation as ordered until it reaches its destination, stops, forms column by another ‘left face’ and then advances to its destination.

Without getting into details, this was a pretty complicated fix. Looking for help with this, and some MonoGame2)MonoGame is a community supported version of Microsoft’s XNA which was created specifically for making cross-platform games. Microsoft stopped all support for XNA in April 2014. Previously, I had used XNA for some work that I had done for the US Army and the Department of Defense and thought it had great potential for creating computer wargames and simulations. specific problems, I encountered Matthew T. from the MonoGame forum who very kindly volunteered to help. Not only did Matthew fix the line / column formation problems but he identified and fixed a bug with the typography for the game, too:

These two screen shots show the difference in the clarity and spacing (called kerning) of the letters. In the left screen shot notice the lowercase ‘g’ in Debug and the spacing of the letters in the word ‘positions’. In the right screen capture, after applying Matthew’s typographical fixes, the letters are clear and properly spaced.

Matthew is also cleaning up the codebase. I have a tendency to write code ‘fast and furious’ and then hope to go back and optimize and clean it up later. Matthew has already begun cleaning it up and has reduced the codebase by something like 7,000 lines of code! Furthermore, Matthew has also sped up the load time and the time between game turns from about a minute to about 10 seconds (obviously, time varies based on scenario).

Steam Update

Darin Jones has been working on the Steam side. He created the Installer and is working on setting up Player versus Player (PvP) leveraging Steam’s built-in features. While this has been a steep learning curve, Darin has made some significant progress:

Screen shot of Steam Player vs. Player invitation for General Staff: Black Powder. This is not a Play by Email (PBEM) system, rather it uses Steam’s internal messaging system

Darin is also setting up a ‘Workshop’ area where you can upload scenarios, armies and maps that you create and want to use in a PvP game.

What’s Next

Our goal remains to get General Staff: Black Powder into beta-testing (that’s you guys playing with it) as soon as possible. We want to use the Steam PvP method, above, as the vehicle for testing. I’m grateful for the emails that I’ve received that are encouraging me to not rush General Staff: Black Powder out before it’s ready and to deliver a solid game (see also, Gabe Newall on why game delays are OK: ‘Late is just for a little while. Suck is forever.’).

As always, please feel free to contact me directly at Ezra[at]RiverviewAI.com.

 

References

References
1 Full disclosure: I wouldn’t say ‘screwed up’. If you want to get an undergraduate’s attention use the ‘f word’.
2 MonoGame is a community supported version of Microsoft’s XNA which was created specifically for making cross-platform games. Microsoft stopped all support for XNA in April 2014. Previously, I had used XNA for some work that I had done for the US Army and the Department of Defense and thought it had great potential for creating computer wargames and simulations.

Schwerpunkt: Calculating the Optimal Point of Attack

MATE’s analysis of Blue (Union) position at Antietam. NB: Unable to outflank Red’s position, MATE has calculated the Schwerpunkt, or optimal point of attack on Red’s lines. Click to enlarge.

The holy grail of military science is an algorithm that calculates the optimal point of attack upon an enemy’s lines. In German, the word is Schwerpunkt and is commonly translated as “the point of maximum effort.” I have written extensively about Schwerpunkt previously in this blog, in academic papers and in my doctoral thesis.

MATE (Machine Analysis of Tactical Environments 2.0, the AI behind General Staff: Black Powder) is now able to calculate Schwerpunkt to a new, substantially greater, degree of accuracy. There are a number of reasons why this is now possible, but the primary cause must be the ability to analyze the battlefield in 3D and to accurately map where every unit on the map can project its force. Indeed, for many years now I have looked at the problem of computational military reasoning (AI for tactical situations) as a force projection problem.

Below, is a visual representation of the total force projection of all units at Gettysburg, Day 3 (July 3, 1863 0600 hours):

Visual representation of the total force projection (Range of Influence, or ROI) for all units at Gettysburg Day 3. Note: normalization and alpha values affect color output. Also, note how the terrain (woods, depressions, hills) shape the projection of force. Also, all projections are independent of unit facing. Click to enlarge.

If we ask MATE to determine the Schwerpunkt for the Confederates in the above situation, it responds with:

MATE’s selection (labeled OBJECTIVE) for Red Schwerpunkt. Click to enlarge.

And adds the following commentary (edited for brevity, the numbers are the Premise Statement ID#s. This is basically a logic trace of MATE’s thinking):

8|∴ The enemy does not need to capture more Victory Points.
9|∴ The enemy will be on the defensive.
...
22|The enemy's flanks are anchored.
23|[9] + [22] ∴ Frontal assault is the only remaining option.
...
25|COA: Battle Group #1 (Mixed) assigned objective Weak Point Calculated by ROI coords: 551,232
...
33|Red Battle Group #1 is opposed by Blue Battle Group #6
34|Red Battlegroup # 1's strength = 21,663
35|Blue Battlegroup # 6's strength = 13,635
36|Red Battlegroup # 1 has a numerical advantage of 8,028. Red has a 1.59 / 1 advantage over Blue Battle Group #6.
37|Distance to objective is 1,029.86 meters.
38|The maximum slope along the line of attack will be on an upward slope of 3.64%.
39|The attacking avenue of approach will be in enemy ROI for 541.18 meters.
40|The greatest enemy ROI along the avenue of approach is: 1,276.00 .
41|There is an unrestricted avenue of attack.

In other words, MATE has found a path to its objective that encounters the least amount of enemy projection of force. MATE would much prefer to flank the enemy position but it has calculated that this is impossible (#22, above).

ROI (Range of Influence) is calculated using values set up for each unit in the General Staff Army Editor and running a 3D Bresenham line algorithm to ensure that there is direct Line of Sight (LOS) to that point.

Screen shot of the General Staff Army Editor showing the interface for entering values for a typical artillery unit. Note that the accuracy curve is user editable (there are also default curves for various common weapons). Click to enlarge.

It is because every unit has an accuracy curve attached to it we can exactly map out the overlapping fields of fire (see above) and we can precisely calculate how long each attacking unit will be under fire and its intensity. That is how MATE chooses the optimal attack point: the path where its troops will be under the least amount of fire.

When MATE is presented with a tactical problem it first determines what it needs to do to win; is it on the offense or defense? On the offense, MATE will next check to find the enemy’s open flank and, if there is one, are there any crucial choke points on the flanking route? If MATE is unable to ‘fix and flank’ the enemy, and it has determined that it must be on the offensive, MATE then calculates Schwerpunkt (above). With this new Schwerpunkt algorithm the last big piece of the offensive AI puzzle is in place. Ironically, much of MATE’s defensive calculations involve first figuring out how to attack itself and then countering what it determines are its own optimal moves against itself (see this blog).

As always, please feel free to contact me directly with comments or questions.

Feeding the Machine

The famous Turing Machine1)It was first described in Turing’s, “On Computing Machines with an Application to the Entscheidungsproblem,” in 1937 which can be downloaded here: https://www.cs.virginia.edu/~robins/Turing_Paper_1936.pdf. Also a very good book on the subject is Charles Petzold’s, “The Annotated Turing: A Guided Tour through Alan Turing’s Historic Paper on Computability and the Turing Machine.” was a thought experiment and, until recently did not physically exist 2)Yes, somebody has built one and you can see what Turing described here: https://www.youtube.com/watch?v=E3keLeMwfHY . When computer scientists talk about machines we don’t mean the, “lumps of silicon that we use to heat our offices,” (thanks Mike Morton for this wonderful quote), but, rather, we mean the software programs that actually do the computing. When we talk about Machine Learning we don’t think that the physical hardware actually learns anything. This is because, as Alan Turing demonstrated in the above paper, the software functions as a virtual machine; albeit, much more efficiently than creating a contraption with pens, gears, rotors and an infinitely long paper strip.

When I talk about, “feeding the machine,” I mean giving the program (the AI for General Staff is called MATE: Machine Analysis of Tactical Environments and the initial research was funded by DARPA) more data to learn from. Yesterday, the subject at machine learning school was Quatre Bras.

Screen shot of the General Staff AI Editor after analysis of Quatre Bras and calculating the flanking Schwerpunkt or point of attack (blue square).  Click to enlarge.

The MATE tactical AI algorithms produce a plan of attack around a geographic point on the battlefield that has been calculated and tagged as the Schwerpunkt, or point where maximum effort is to be applied. In the above (Quatre Bras) scenario the point of attack is the extreme left flank of the Anglo-Allied (Red) army. I apply the ‘reasonableness test’ 3)Thank you Dennis Beranek for introducing me to the concept of ‘reasonableness test’. See https://www.general-staff.com/schwerpunkt/ for explanation and think, “Yes, this looks like a very reasonable plan of attack – a flanking maneuver on the opponent’s unanchored left flank – and, in fact, is a better plan than what Marhshal Ney actually executed.

It would be good at this point to step back and talk about the differences in ‘supervised’ and ‘unsupervised’ machine learning and how they work.

Supervised machine learning employs training methods. A classic example of supervised learning is the Netflix (or any other TV app’s) movie recommendations. You’re the trainer. Every time you pick a movie you train the system to your likes and dislikes. I don’t know if Netflix’s, or any of the others, use a weighting for how long (what percentage watched over total length of show) watched but that would be a good metric to add in, too. Anyway, that’s how those suggestions get flashed up on the screen: “Because you watched Das Boot you’ll love The Sound of Music!”  Well, yeah, they both got swastikas in them, so… 4)Part of the problem with Netflix’s system is that they hire out of work scriptwriters to tag each movie with a number of descriptive phrases. Correctly categorizing movies is more complex than this.

Supervised machine learning uses templates and reinforcement. The more the user picks this thing the more the user gets this thing. MATE is unsupervised machine learning. It doesn’t care how often a user does something, it cares about always making an optimal decision within an environment that it can compare to previously observed situations. Furthermore, MATE is a series of algorithms that I wrote and that I adjust after seeing how they react to new scenarios. For example, in the above Quatre Bras scenario, MATE originally suggested an attack on Red’s right-flank. This recommendation was probably influenced by the isolated Red infantry unit (1st Netherlands Brigade) in the Bois de Bossu woods.  After seeing this I added a series of hierarchical priorities with, “a flank attack in a woods (or swamp) is not as optimal as an attack on an exposed flank with clear terrain,” as a higher importance than pouncing on an isolated unit.  And so I, the designer, learn and MATE learns.

My main concern is that MATE must be able to ‘take care of itself’ out there, ‘in the wild’, and make optimal decisions when presented with previously unseen tactical situations. This is not writing an AI for a specific battle. This is a general purpose AI and it is much more difficult to write than a battle specific AI. One of the key aspects of the General Staff Wargaming System is that users can create new armies, maps and scenarios. MATE must make good decisions in unusual circumstances.

Previously, I have shown MATE’s analysis of 1st Bull Run and Antietam. Below is the battle of Little Bighorn in the General Staff AI Editor:

The battle of Little Bighorn in the General Staff AI Editor. Normally the MATE AI would decline to attack. However, when ordered to attack, this is MATE’s optimal plan. Click to enlarge.

I would like to expose MATE to at least thirty different tactical situations before releasing the General Staff Wargame. This is a slow process. Thanks to Glenn Frank Drover of Forbidden Games, Inc. for donating the superb Quatre Bras map. He also gave us maps for Ligny and Waterloo which will be the next two scenarios submitted to MATE. We still have a way to go to get up to thirty. If anybody is interested in helping to create more scenarios please contact me directly.

References

References
1 It was first described in Turing’s, “On Computing Machines with an Application to the Entscheidungsproblem,” in 1937 which can be downloaded here: https://www.cs.virginia.edu/~robins/Turing_Paper_1936.pdf. Also a very good book on the subject is Charles Petzold’s, “The Annotated Turing: A Guided Tour through Alan Turing’s Historic Paper on Computability and the Turing Machine.”
2 Yes, somebody has built one and you can see what Turing described here: https://www.youtube.com/watch?v=E3keLeMwfHY
3 Thank you Dennis Beranek for introducing me to the concept of ‘reasonableness test’. See https://www.general-staff.com/schwerpunkt/ for explanation
4 Part of the problem with Netflix’s system is that they hire out of work scriptwriters to tag each movie with a number of descriptive phrases. Correctly categorizing movies is more complex than this.

Wargame AI Continued: Range of Influence

In two previous blogs I wrote about how Artificial Intelligence (AI) for wargames perceive battle lines and terrain and elevation. Today the topic is how computer AI has changed ‘Range of Influence’  (ROI) or ‘Zone of Control’ (ZOC) analysis. Range of Influence  and Zone of Control are terms that can be used interchangeably. Basically, what they mean is, “how far can this unit project its power.”

One of the first appearances of range as a wargame variable was in Livermore’s 1882 American Kriegsspiel: A Game for Practicing the Art of War Upon a Topographical Map (superb article on American Kriegsspiel here).  Note that incorporated into the ‘range ruler’ (below) is also a linear ‘effectiveness scale’.

Detail of Plate IV, “The Firing Board,” from the American Kriegsspil showing a ruler for artillery range printed on the top. Note the accuracy declines (apparently linearly) proportional to the distance. Click to enlarge.

The introduction of hexagon wargames (first at RAND and then later by Roberts at Avalon Hill; see here) created the now familiar 6 hexagon ‘ring’ for a Zone of Control:

Zone of Control explained in the Avalon Hill Waterloo (1962) manual. Author’s Collection.

I seem to remember an Avalon Hill game where artillery had a 2 hex range; but I may well be mistaken.

Ever since the first computer wargames that I wrote back in the ’80s I have earnestly tried to make the simulations as accurate as possible by including every reasonable variable. With the General Staff Wargaming System we’ve added two new variables to ROI: 3D Line of Sight and an Accuracy curve.

Order of Battle for Antietam showing Hamilton’s battery being edited. Screen shot from the General Staff Army Editor. Click to enlarge.

In the above image we are editing a Confederate battery in Longstreet’s corps. Every unit can have a unique unit range and accuracy. You can select an accuracy curve from the drop-down menu or you can create a custom accuracy curve by clicking on the pencil (Edit) icon.

Window for editing the artillery accuracy curve. There are 100 points and you can set each one individually. This also supports a digitizing pen and drawing tablet. Screen shot from General Staff Army Editor. Click to enlarge.

In the above screen shot from the General Staff Wargaming System Army Editor the accuracy curve for this particular battery is being edited. There are 100 points that can be edited. As you move across the curve the accuracy at the range is displayed in the upper right hand corner. Note: every unit in the General Staff Wargaming System can have a unique accuracy curve as well as range and every other variable.

Screen shot showing the Range of Influence fields for a scenario from the 1882 American Kriegsspiel book. Click to enlarge.

In the above screen shot from the General Staff Sand Box (which is used to test AI and combat) we see the ROI for a rear guard scenario from the original American Kriegsspiel 1882. Notice that the southern-most Red Horse Artillery unit has a mostly unobstructed field of vision and you can clearly see how accuracy diminishes as range increases. Also, notice how the ROI for the one Blue Horse Artillery unit is restricted by the woods which obstructs its line of sight.

Screen shot of Antietam (dawn) showing Red and Blue ROI and battle lines. Click to enlarge.

In the above screen shot we see the situation at Antietam at dawn. Blue and Red units are rushing on to the field and establishing battle lines. Again, notice how terrain and elevation effects ROI. In the above screen shot Blue artillery’s ROI is restricted by the North Woods.

The above ROI maps (screen shots) were created by the General Staff Sand Box program to visually ‘debug’ the ROI (confirm that it’s working properly). We probably won’t include this feature in the actual General Staff Wargame unless users would like to see it added.

This is a topic that is very near and dear to my heart. Please feel free to contact me directly if you have any questions or comments.