Tag Archives: Units

Gameplay Surveys 1 & 2 Results.

We just ran two Gameplay Surveys to find out exactly what kind of units and unit structures you wanted to see in General Staff and the results are in. We especially wanted to know, in general terms, if you wanted us to create a classic Kriegsspiel game or a very detailed military simulation like UMS, UMS II and The War College.

Well, here are the results and they’re not what we expected:

48%: I prefer simple unit data; just the unit type and unit strength.

52%: I want to include as much detailed information about a unit as possible.

In other words, about half of you want a simple game and about half want a very detailed game. I must admit, I had to think about this for a while, but I’ve finally come up with a solution. This really isn’t about gameplay, it’s about the information that is stored about each unit and how the information is used for combat resolution. When an army is created using the Army Design Module all the required information will have to be added and stored within the unit data structure. However, when a user selects a scenario to play, the user will be able to decide if they want to play the ‘classic Kriegsspiel‘ or ‘complex simulation’ version.

The half of respondents that want detailed information about units requested the following information be stored for each unit:

Unit Name. For historical or informational purposes such as, “Chasseurs à Cheval Garde” or “Battery B 4th US Artillery.”

Unit Type. Such as, “Heavy Cavalry,” or “Field Artillery.” See below for more survey questions about pre-designed unit types.

Unit Strength. A numeric value of the number of men in the unit. However, in the ‘classic Kriegsspiel‘ version this value would simple be the numbers 1-4 and shown by the number of unit icons displayed (see below):

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.

Unit Leadership. A value from 1-10 representing ‘poor’ to ‘superb’ leadership values. This will be displayed as a graph in the game. This value is used in the combat equation and to calculate how fast a unit responds to orders.

Unit Quality. A value from 1-10 representing ‘poor’ to elite’ unit quality values. This will be displayed as a graph in the game. This value is used in the combat equation and to calculate how fast a unit responds to orders.

Unit Morale. A value from 1-10 representing ‘poor’ to ‘elite’ morale. These values will change during the game in response to the results of the unit’s combat. This value will be displayed as a graph in the game and is used in the combat equation.

Ammunition Level. A value indicating the number of volleys remaining for the unit. In the ‘classic Kriegsspiel‘ version of General Staff units have unlimited ammunition.

Our next series of survey questions asked what unit types would you like to see. The following unit types will be available in General Staff:

Infantry (line infantry), Light Infantry (including skirmishers), Cavalry, Light Cavalry (including lancers), Field Artillery, Horse Artillery, Headquarters (see below) and Supply Trains.

We next asked if users wanted a ‘flat’ or ‘hierarchical’ army structure. The hierarchical army structure allows for a Corps → Division → Brigade type structure. Headquarters units will be included and orders will be transmitted via couriers. Users overwhelmingly wanted a hierarchical structure:

88% of users want a hierarchical army structure.

Lastly, we asked you about screen resolution.

75% of users were happy with 1440 x 900 screen resolution.

We understand that 25% of users want a higher resolutions and we’ll do our best to accommodate them.

Feedback from users is very important to us. We want to create the wargame system that you want to buy. If you have other questions or comments please don’t hesitate to contact us here.

Gameplay Survey 2: Army Structure.

6 Replies

This week’s survey will wrap up our questions about units and armies and after tabulation work can begin on the Create Army Module. General Staff is a simulation of 18th and 19th century warfare. We hope to use the same engine for an Ancient and Modern wargames as well.

We have just three survey questions:

What unit types should we include in the Create Army Module? Armies will be created by clicking and dragging unit icons from a pallet; consequently we need to know in advance what the ‘pre-designed’ unit types will be.

Will the armies have a hierarchical structure (e.g. Division → Brigade → Regiment) or a ‘flat’ structure (i.e. units do not belong to a superior command structure but, rather, can be given orders without consideration to other units).

What is your preferred screen resolution? We’re thinking of writing for 1440 x 900 resolution. Does anybody have a problem with this?

[os-widget path=”/drezrasidran/gameplay-survey-2-army-structure” of=”drezrasidran” comments=”false”]

Gameplay Survey 1: Unit Complexity.

9 Replies

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:

In any given square there can be a maximum of 4 artillery units, 3 cavalry units or 2 infantry units.
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.

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?

[os-widget path=”/drezrasidran/gameplay-1-unit-complexity” of=”drezrasidran” comments=”false”]

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 3)

4 Replies

The goal of my doctoral research was to create a suite of algorithms that were capable of making ‘human-level’ tactical and strategic decisions. The first step is designing a number of ‘building block’ algorithms, like the least weighted path algorithm that calculates the fastest route between two points on a battlefield while avoiding enemy fire that we saw in last week’s post. Another important building block is Kruskal’s Minimum Spanning Tree algorithm which allows the computer to ‘see’ lines of units.

I use terms like ‘see’ and ‘think’ to describe actions by a computer program. I am not suggesting that current definitions of these terms would accurately apply to computer software. However, it is simply easier to write that a computer ‘sees’ a line of units or ‘thinks’ that this battlefield situation ‘looks’ similar to previously observed battlefields. What is actually happening is that units are represented as nodes (or vertices) in a a graph and some basic geometry is being applied to the problem. Next week we will use probabilities. But, at the end of the day, it’s just math and computers, of course, don’t actually ‘see’ anything.

Examples of how Kruskal’s Minimum Spanning Tree algorithm can be used to separate groups of units into cohesive lines. These figures are taken from, “Implementing the Five Canonical Offensive Maneuvers in a CGF Environment.” by Sidran, D. E. & Segre, A. M.

When you and I look at a map of a battle we immediately see the opposing lines. We see units supporting each other, interior lines of communication, and lines of advance and retreat. The image, below, shows how the program (in this case, TIGER, the Tactical Inference Generator which was written to demonstrate my doctoral research) ‘sees’ the forces at the battle of Antietam. The thick black line is the ‘MST Spine’. You and I automatically perceive this as the ‘front line’ of the Confederate forces, but this is a visual representation of how TIGER calculates the Confederate front line. Also important is that TIGER perceives REDFOR’s flanks as being anchored (that is to say, BLUE does not have a path to the flanking objective, the tip of the green vector, that does not go through RED Range of Influence, ROI, or Zone of Control).

Figure 1. TIGER screen shot of ‘flanking attribute’ calculations for the battle of Antietam (September 17, 1862, 0600 hours). Note the thick black line that repres ents the MST spine of REDFO R Group 0, the extended vectors th at calculate the Flanking Goal Objective Point and BLUEFOR and REDFOR ROI (red and blue shading). REDFOR (Confederate) has anchored flanks.

TIGER screen shot of ‘flanking attribute’ calculations for the battle of Antietam (September 17, 1862, 0600 hours). Note the thick black line that represents the MST spine of REDFOR Group 0, the extended vector that calculates the Flanking Goal Objective Point and BLUEFOR and REDFOR ROI (red and blue shading). REDFOR (Confederate) has anchored flanks. From, “Algorithms for Generating Attribute Values for the Classification of Tactical Situations,” by Sidran, D. E. & Segre, A. M.

Now that TIGER can see the opposing lines and recognize their flanks we can calculate the routes for implementing the Course of Action (COA) for various offensive maneuvers. U. S. Army Field Manual 3-21 indicates that there are five, and only five, offensive maneuvers. The first is the Penetration Maneuver (note: the algorithms for these and the other maneuvers appear in, “Implementing the Five Canonical Offensive Maneuvers in a CGF Environment.” by Sidran, D. E. and Segre, A. M.) and can be downloaded from ResearchGate and Academia.edu.

The Penetration Maneuver is described in U.S. Army Field Manual 3-21 and as implemented by TIGER. Note how TIGER calculates the weakest point of REDFOR’s line. From, “Implementing the Five Canonical Offensive Maneuvers in a CGF Environment.” by Sidran, D. E. and Segre, A. M. Click to enlarge.

The next maneuver is the Infiltration Maneuver. Note that to implement the Infiltration Maneuver, BLUEFOR must be able to infiltrate REDFOR’s lines without entering into RED’s ROI:

The Infiltration Maneuver as described in U.S. Army Field Manual 3-21 and as implemented by TIGER. Note how TIGER reaches the objectives without entering into REDFOR ROI. From, “Implementing the Five Canonical Offensive Maneuvers in a CGF Environment.” by Sidran, D. E. and Segre, A. M. Click to enlarge.

The next maneuver is the Turning Maneuver. Note: in order to ‘turn an enemy’s flanks’ one first must be able to recognize where the flanks of a line are. This is why the earlier building block of the MST Spine is crucial.

The Turning Maneuver as illustrated in U. S. Army Field Manual 3-21 and in TIGER. From, “Implementing the Five Canonical Offensive Maneuvers in a CGF Environment.” by Sidran, D. E. and Segre, A. M. Click to enlarge.

Certainly the most complex offensive maneuver is the Envelopment Maneuver which requires two distinct movements and calculations for the attacking forces: first the attacker must decide which flank (left or right) to go around and then the attacker must designate a portion of his troops as a ‘fixing force’. Think of an envelopment maneuver as similar to the scene in Animal House when Eric “Otter” Stratton (played by Tim Matheson) says to Greg Marmalard (played by James Daughton), “Greg, look at my thumb.” Greg looks at Otter’s left thumb while Otter cold-cocks Marmalard with a roundhouse right. “Gee, you’re dumb,” marvels Otter. In an envelopment maneuver the fixing force is Otter’s left thumb. Its purpose is to hold the attention of the victim while the flanking force (the roundhouse right) sweeps in from ‘out of nowhere’. In the next post I will show a real-world example of an Envelopment Maneuver created by my MATE (Machine Analysis of Tactical Environments) program for DARPA.

The Envelopment Maneuver as shown in U. S. Army Field Manual 3-21 and as implemented in TIGER. From, “Implementing the Five Canonical Offensive Maneuvers in a CGF Environment.” by Sidran, D. E. and Segre, A. M. Click to enlarge.

Lastly, and obviously the maneuver of last resort, is the Frontal Assault:

The Frontal Assault Maneuver from, “Implementing the Five Canonical Offensive Maneuvers in a CGF Environment.” by Sidran, D. E. and Segre, A. M. Click to enlarge.

All that I’ve done in this post is show some of the things that the TIGER program does. What I haven’t done is show how the algorithms work and that’s because they are described in the papers, below. Obviously, this is a subject that I find pretty interesting, so feel free to ask me questions (you can use the Contact Us page).

It is my intention to incorporate these algorithms into the General Staff wargame. However, I’ve been told by a couple of game publishers that users don’t want to play against a human-level AI. What do you think? If you’ve read this far I would really appreciate it if you would answer the survey below.
[os-widget path=”/drezrasidran/survey-11-27″ of=”drezrasidran” comments=”false”]

Papers that were cited in this post with download links:

“An Analysis of Dimdal’s (ex-Jonsson’s) ‘An Optimal Pathfinder for Vehicles in Real-World Terrain Maps'”

In PDF Format

“Algorithms for Generating Attribute Values for the Classification of Tactical Situations.”

In PDF Format

“Implementing the Five Canonical Offensive Maneuvers in a CGF Environment.”

In PDF Format