Tag Archives: Gameplay

How Will You Play General Staff?

Every wargame that I’ve designed allows the user to adjust important variables such as leadership and morale and how they affect combat. Usually included is the ability to design your own armies, maps and scenarios as well. However, with the General Staff Wargaming System we’ve added a new feature: the ability to control the realism level before playing a scenario.

The General Staff Wargame has two basic levels of play:

Simulation mode uses HQ units and a chain of command that passes orders down from the General HQ to the sub-commander to the individual unit. How fast the unit responds to the orders are affected by the distance that the courier must travel and the Leadership Value of the HQs.  Simulation mode also employs a more detailed combat resolution model and tracks the actual number of troops in every unit.

An example of Simulation Mode: the path (red line) and time (16 minutes) it will take for a courier to travel from JEB Stuart’s HQ to Munford’s cavalry with orders. Click to enlarge.

Kriegsspiel mode does not have HQ units and friendly units are moved directly and immediately (no transmission of orders via couriers). The combat resolution model is simpler and units have a value of 1-4 displayed by the number of unit icons on the map.

Antietam in Kriegsspiel mode. Notice that there are no HQ units (so no couriers to deliver orders) and units are represented by 1-4 icons. Units in column have a ‘tail’ that indicates the unit strength. Click to enlarge.

In addition to the two game modes (Simulation and Kriegsspiel) there are three Scenario Options:

Order of Battle (OOB) displayed / not displayed. Enemy units with known positions appear dark; enemy units ‘on the map’ but with unknown locations appear grayed out. This, of course, gives the user complete knowledge of the enemy’s OOB and, more importantly, knows when units from certain formations are not directly observable.

A mock up of how the Order of Battle option will appear (note this image was created from screen captures of the Scenario Editor and the Sand Box). Click to enlarge

Only friendly units directly observed by the General HQ are displayed. All other friendly units fade at their last known location. Couriers bring in unit location updates, but they are outdated by the time they arrive.

Only enemy units directly observed by the General HQ are displayed. All other enemy units fade at their last known location. Couriers bring in unit location updates, but they are outdated by the time they arrive.

If both of these above options are selected (only friendly and enemy units that are directly observable by your commanding General HQ) you will be simulating the Fog of War that field commanders of the age of gunpowder experienced.

What General George B. McClellan could actually see at Antietam. Screen shot (General Staff Sand Box). Click to enlarge.

We would like to hear from you and get your opinion on what realism features you will use in General Staff:

A Tale of Two Wargames

I first conceived of General Staff as a very simple, introductory wargame that might be the first real wargame to be released for the Xbox (clearly, an under-served market). However, two things stopped this plan dead in its tracks: first Microsoft closed down the independent online games channel for Xbox and then, after being approached by a major wargame publisher, I was told that there was, “no market for wargames on the Xbox,” however a new version of my UMS series, could, “sell 25,000 units in its first year.”

So, I went back to the proverbial drawing board but I also asked you, the Grognards, what kind of a game you wanted. And here are the results:

Clearly, almost as many people want a simple, Kriegsspiel type game as want a complex military simulation.

After pondering this conundrum I had an epiphany: ‘simple’ wargames and ‘complex simulations’ actually share about 80% of the same code and data. Why not make a wargame that the user can decide which he wants to play? Sometimes people aren’t up for hours long complex simulations; other times people are.

Screen capture from General Staff showing the set up for ‘Simulation’ mode (note the button in the upper-left hand corner). Click to enlarge.

In the above screen capture the user has selected ‘Simulation’ mode. Note that there are headquarters units displayed. Headquarters play an important role in General Staff in simulation mode. All orders are given through the commanding general to the subordinate commander (via courier) and then (again via courier) to the actual unit. For example:

In this screen capture an order from Marshal Beresford will take 8 minutes of game time to be delivered to ths subordinate commander. (Click to enlarge)

It will take 8 minutes for the courier to ride from Marshal Beresford headquarters to the subordinate’s headquarters.

It will take an additional 6 minutes for a courier to deliver the order to the subordinate infantry unit. Click to enlarge.

Additional time (based on the headquarter’s Leadership value) will be added before the next courier is dispatched to deliver the order to the infantry unit. So for a command to go from Marshal Beresford, to Major General Stewart to Colborne’s Brigade will take a minimum of 14 minutes of game time plus additional time penalties based on the leadership abilities of Beresford and Stewart.

Detailed information about a unit in Simulation mode. Even the number of volleys remaining are tracked. Click to enlarge.

Lastly, the leadership of Colborne’s Brigade is used to calculate how quickly the unit will act upon the received orders. This is an example of the detailed Simulation mode for General Staff.

However, in Kreigsspiel mode,  all headquarters units are removed and the user issues orders directly to the units that immediately respond to the commands.

General Staff in Kreigsspiel mode. Note the button in the upper left-hand corner, headquarters units have been removed and unit strength is either 1,2,3 or 4.

Also, all unit information except a simple value (1-4) is ignored. Kriegsspiel mode is the simple, introductory wargame that I originally envisioned.

 

Video Demonstrating the Scenario Design Module!

Below is a video describing how to use the Scenario Design Module for the General Staff Wargaming System. Yes, it really is that simple: just combine two armies previously created in the Army Design Module with a map created in the Map Design Module and create a new battle scenario.


Also, there’s a gameplay surprise in this video!

Gameplay Survey 1: Unit Complexity.

When I first started thinking about designing General Staff I envisioned a simple game that was almost chess-like in parts and that was designed to introduce novices to wargames. I thought that the Xbox would be the ideal platform.

After talking to two major digital wargame publishers I was told:

There is absolutely no wargame market for the Xbox and it was idiotic to even think that there was.

Traditional wargame buyers want more complex games; not introductory games.

Wargame buyers (can we just say Grognards?) still fondly remember UMS, UMS 2 and The War College (UMS 3) and would certainly support a major update.

Consequently, I have had to readjust my thinking about the gameplay and design of General Staff. Maybe the wargame you want to buy is different from the wargame that I was planning on making. To better understand what exactly customers want from General Staff I’m going to be posting a series of surveys about very specific gameplay and design issues. I’m going to lay out the pros and cons of the various options and then I’m going to ask you to please vote and give me feedback.


Simple unit details:

My original design called for a very simple unit structure. Other than a number of bookkeeping variables (such as location, facing, speed, orders, etc.) the only values that we would store were the unit’s type and strength.

The screen captures below show examples of this design.

Screen captures of various unit types and facings in General Staff. Note that unit strength is obvious (1,2,3 or 4). Click to enlarge.

The rules on unit type and strength are:

  1. In any given square there can be a maximum of 4 artillery units, 3 cavalry units or 2 infantry units.
  2. Different unit types cannot occupy the same square.

Advantages of a Simple Unit Structure:

There is a very appealing simplicity to this system. The user can immediately see the strength of forces at any location. As a unit takes losses the number of symbols displayed in the square are decremented until the unit, itself, is removed.

Less data is required to create a scenario.  But, the real problem is trying to assign values to variables like ‘morale’, ‘experience’ or ‘leadership’. Inevitably, these are just value judgments.

It presents a simple and less intimidating interface (no names, ‘strength bars’, etc.) for beginners.

Visually it fits right into the Napoleonic and Victorian topographical battlefield map engravings style that I want to emulate. I, personally, am greatly enamored by this style and would love to maneuver units on these incredible contoured maps:

Bataille de Molino del Rey : 1ere Position [y] 2éme Position (1820) .From: Biblioteca Virtual del Patrimonio Bibliográfico. A superb example of 19th century battlefield map engraving. Click to open link in new window.


Complex unit details:

How much information can we store about every unit on the map? The only limit is the size of available storage; in other words, on modern computing devices, there are no real limits. Below is screen shot (with explanations) of the variables used to calculate combat results in UMS II: Nations at War.

Unit variables used for combat resolution in UMS2. Click to enlarge.

Among the most likely variables to be included in the unit structure are: unit name, leadership value, morale level, strength, fatigue and unit type.

Advantages of a Complex Unit Structure:

Theoretically, the more data you have the more accurate the simulation. Obviously, this depends on the accuracy of the data but as long as the variables are relevant to the simulation and your model is good, the more variables the better.

Simply having a more detailed model with a lot of unit variables may help to sell more units to Grognards.

Disadvantages of a Complex Unit Structure:

More data has to be researched, compiled and entered into the Create Army Module (see here).

This data needs to be displayed in a way that doesn’t overload the user. Below is a screen shot of some tests that I did for an earlier version of General Staff:

Screen capture showing one method of displaying information about a unit. In this case the stored values include Melee attack value, maximum range, ranged attack value, strength, unit quality, formation, morale and fatigue. Click to enlarge.

Screen capture showing one method of displaying information about a unit. In this case the stored values include Melee attack value, maximum range, ranged attack value, strength, unit quality, formation, morale and fatigue. Click to enlarge.

Inevitably, at some point the scenario designer has to make some very arbitrary decisions about a unit’s morale and leadership values.

What is the maximum strength of a unit? Remember we’re talking apples (artillery) and oranges (infantry divisions) here. What does the value ‘strength’ actually mean? Is it the number of men in the unit? Clearly 50 men in an artillery battery have more ‘strength’ than 50 men in a line infantry company. Is there some other modifier (perhaps ‘unit type’) that is necessary to convert a unit’s strength to its combat power? And, what if a scenario designer creates a unit with a strength of 1,000 while other units have values of, say, 10? Will this be an unstoppable behemoth on the battlefield?


So, now it’s time for you to make your feelings known about these issues. Simple or complex unit data structures? What information should be stored about each unit?


You input is very important to us. Please feel free to give us more feedback either via the online form or by emailing me personally at Ezra [at] RiverviewAI.com

A Wargame 55 Years in the Making (Part 2)

After The War College I created a couple of non-wargames including Online Mysteries, a massive multiplayer online mystery game that was written for AOL’s WorldPlay. WorldPlay was envisioned to be a 3D online world populated with avatars. It was similar in concept to Second Life but, like a lot of great ideas, was ahead of its time. AOL shut WorldPlay down before most of the games, including Online Mysteries, launched.

Mysteries Unlimited screen shot (Windows) was a massively multiplayer online mystery game created for AOL/WorldPlay (click to enlarge).

Mysteries Unlimited screen shot (Windows) was a massively multiplayer online mystery game created for AOL/WorldPlay (click to enlarge).

By 2000 the game publishing industry  was going through another convulsion of consolidations, buyouts and contractions. Publishers were producing fewer games but the ones that were being created had large teams, long development cycles and massive budgets. The days when an independent developer could pitch a game idea, get an advance and then develop it outside of a publisher’s studio were gone. And the last thing that the big publishers were interested in were wargames.

Over the previous fifteen years I had received inquiries from active duty military and Pentagon project managers about my wargames (known as Commercial Off The Shelf, or COTS, in Pentagon-lingo) and if I would be available to consult on various wargaming projects. Unfortunately, I was lacking a key prerequisite for this: a doctorate. I returned to academia, first to a small local college where I also taught computer game design and in 2003 I was accepted in the computer science PhD program at the University of Iowa (one of the oldest computer science departments in the world).

Before I ever set foot in MacLean Hall (the home of the Department of Computer Science at the University of Iowa) I knew what I would spend the next six years of my life researching and studying: tactical and strategic AI (I would eventually coin the phrase ‘computational military reasoning’ to describe this field).  What I soon discovered was that very little work had ever been done in this research area. What was even more surprising was my discovery that most ‘professional’ military wargames (i.e. wargames used by the US Army, NATO, England, Australia, France, etc.) had absolutely no AI whatsoever. Instead, they employed ‘pucksters’ (usually retired military officers) who made all the moves for OPFOR (Opposition Forces, AKA ‘the enemy’) from another computer in another room.

Pucksters, or humans (usually retired military officers) who make the decisions and moves for enemy (or OPFOR) units during a wargame.

Pucksters are humans (usually retired military officers) who make the decisions and moves for enemy (Opposition Forces = OPFOR) units during a wargame. Note the sign OPFOR & EXCON (Exercise Control) over the puckster’s work station.

To earn a doctorate at an American ‘Research One’ university requires 90 graduate credits (about 30 classes), a GPA > 3.5 (out of 4.0) and passing three major examinations. The first examination on the road to a doctorate is the Qualifying Examination (or Q Exam as everyone calls it). The topic of my Q exam was “An Analysis of Dimdal’s (ex-Jonsson’s) ‘An Optimal Pathfinder for Vehicles in Real-World Terrain Maps’.” This is the area of computer science and graph theory known as ‘least weighted path algorithms’. GPS devices and Map apps use a least weighted path algorithm, except they’re only interested in roads; they don’t consider terrain, slope and other things (that are important to a military unit maneuvering on a battlefield).

Now, if you were to wander into the ivied halls of academic computer science  (like MacLean Hall) and inquire of a tenured faculty member how to calculate the fastest path between two points on a sparse grid they would almost certainly reply to you, “Dijkstra’s algorithm.”  Dr. Dijkstra invented his algorithm in 1956 and it works like this: first calculate the distance between every point on the map and every other point on the map. Then figure out the fastest path. Yeah, it’s that obvious, and painfully slow. In fact, it’s so slow that it isn’t used for GPS or game AI. In computer science we us ‘Big O’ notation to describe how fast (or slow) an algorithm takes to run. Dijkstra’s algorithm runs in O(|V|2). This means that as the number of vertices, or points on the map, (that’s the |V| part) increases, the time it takes for the entire algorithm to complete goes up by the square of the number of vertices. In other words, as the map gets bigger the algorithm gets a lot slower.

Dimdal, and I and most of the gaming world do not use Dijkstra’s algorithm, Instead we use A* (pronounced ‘A Star’) which was designed in 1968 primarily by Nils Nilsson with later improvements by Peter Hart and Bertram Raphael. Below is an example of A* used in General Staff (note that the algorithm doesn’t look at every point on the map, just ones that it thinks are relevant to the problem at hand). A* runs in O(n) time.

A screen shot of A* algorithm running. The green areas are where the algorithm searched for a least weighted path, the brown line is the shortest path (mostly following a road).

A screen shot of A* algorithm running. The green areas are where the algorithm searched for a least weighted path, the brown line is the shortest path (mostly following a road).

Graph showing the difference between Dijkstra's algorithm and the A* algorithm. The blue line that increases rapidly shows that Dijkstra's algorithm gets much slower as the map gets bigger. A* is not affected as much by the size of the map.

Graph showing the difference between Dijkstra’s algorithm and the A* algorithm. The blue line that increases rapidly shows that Dijkstra’s algorithm takes much more time as the map gets bigger. A* (the green line) is not affected as much by the size of the map.

As part of my research into computational military reasoning I made further modifications to A* to take into effect the slope of the terrain (which can affect speed of some units), the range of enemy units (OPFOR ROI, e.g. areas controlled by enemy artillery) and to avoid enemy line of sight (LOS). My MATE (Machine Analysis of Tactical Environments) project used all of these options:

A slide from my presentation to DARPA showing how my modified A* avoids enemy range of weapons.

A slide from my presentation to DARPA showing how my modified A* avoids enemy range of weapons. The likelihood of taking casualties is indicated by the darkness of the red coloring.

While working on General Staff I came up with a new optimization of the A* algorithm which I’ve called EZRoadStar. EZRoadStar first looks at the roadnet and attempts to utilize it for rapid troop movement. Only after ascertaining how far using roads will get it to its goal does the algorithm look for nonroad paths. EZRoadStar is much faster than traditional A*; especially for wargames and military simulations.

An example of the EZRoadStar least weighted path algorithm. What's the fastest way point A to point B (the yellow line)? Taking the road, of course. This algorithm looks at a battlefield like a commander and utilizes the roadnet first before looking at other options. Click to enlarge.

An example of the EZRoadStar least weighted path algorithm. What’s the fastest way from point A to point B (the yellow arrow)? Taking the road, of course. This algorithm looks at a battlefield like a commander and utilizes the roadnet first before looking at other options. Click to enlarge.

Well, this wargame may be 55 years in the making and it looks like describing some of the key things that went into it may take almost as long. Clearly, I’m going to have to continue this story with yet another post. We’ve just barely scratched the surface of my work on wargame AI. The next installment will (hopefully) cover algorithms for ‘the five canonical offensive maneuvers’ (i.e. The Envelopment Maneuver, The Turning Maneuver, Penetration, Infiltration and Frontal Assault. These are the algorithms that are ‘under the hood’ of General Staff. If any of my readers would like to know more about these topics (links to my published papers on the subject or whatever) please drop me a line at Ezra [at] RiverviewAI.com.