Category Archives: Game Design

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

General Staff Features

6 Replies

General Staff is a direct descendant of the UMS seies which featured a suite of tools that allowed the user to create new maps, armies and scenarios. Our recent survey indicated that 73% of respondents felt that it was either ‘very important’ or ‘somewhat important’ for General Staff to have these abilities, too. Below is a flow chart of the five modules that make up General Staff:

Flow chart of General Staff. From the main screen the user can either create a new map, create a new army, combine a map and two armies into a new scenario or play a previously created scenario. Click to enlarge.

From the Main Menu the user can select:

The Create Map Module

This module provides all the tools that a user needs to create detailed, authentic-looking maps. The are numerous tiles that represent the eight different terrains (field, water, swamp, city, woods, bridge, road, fort). Additionally, the user can sculpt hills and ridges with the AI automatically adding ‘splash contours’. Rivers and roads are added using a Bézier curve tool.

After the map is completed the user can select the amount of ‘dirtying’ (map folds, coffee stains, age stains, etc.) to be added to the map.

The Create Army Module

Armies can be in either an hierarchical format (see below) or a flat format. A flat format is a data structure without layers of commanders. Next week we will be running a user survey to find if you have a preference for hierarchical or flat army unit structures.

Screen shot from UMS II: Nations at War showing a hierarchical army structure. There are four levels of command in this army structure: Army Group, Army, Corps and Division. Click to enlarge.

The original UMS had a flat army structure while UMS II had a hierarchical unit structure. For both systems an intuitive click and drag interface is provided for quickly creating, editing and saving armies.

Available unit types include: heavy and light infantry, heavy and light cavalry and heavy and light (horse) artillery. Headquarters and courier units are provided for hierarchical army structures.

Create Scenario Module

In the Create Scenario Module a user can combine any two previously created armies with a previously created map to create a new scenario. Mix and match to your heart’s content! The Napoleonic Imperial Guard against the Army of the Potomac’s First Army Corps on the Gettysburg battlefield! The battle of Marengo re-fought with Russian and Austrian troops! Obviously, you can also create historically accurate scenarios, too.

A Wargame 55 Years in the Making (Part 5)

4 Replies

In June, 2009 I successfully defended my thesis and was awarded a doctorate of computer science by the University of Iowa. What followed were some of the most productive years of my professional career. I designed, programmed, project managed and was principal investigator on:

MARS: Military Advanced Real-time Simulator (2009)

OneSAF is the “Semi Automated Forces” wargame / simulator used for training by the US Army. It relies on ‘pucksters’ (see pucksters in this blog) who are usually retired military officers who make all the moves for OPFOR (Opposition Forces), MARS provided an intuitive Graphical User Interface (GUI) for the modification and running of OneSAF scenarios.

Screen capture of the MARS project for the US Army. MARS was a front end to facilitate creating and managing scenarios run on the Army’s OneSAF military simulator. The ‘Magic Bomb’ option is the puckster’s term for ‘magically’ removing a unit from the simulation. Click to enlarge.

CAPTURE: Cognitive and Physiological Testing Urban Research Environment (2010)

While on the surface CAPTURE appears to be a standard ‘shooting gallery’ program it was actually designed to test and store data about how returning veterans saw targets, ‘spiraled in’ on targets and reacted. There were two parts to CAPTURE: the first allowed the tester to set up any particular scenario they wanted (top image, below) and the second part (bottom image, below) was run using a projector, a large screen, an M16 air soft gun with Wii remote and laser mounted to the barrel and an IR camera. CAPTURE was done for the Office of Naval Research (Marines).

Two screens showing the CAPTURE program. The top screen shows the interface for creating target scenarios. The bottom screen is one of the the shooting ranges generated by CAPTURE. Click to enlarge.

NexGEN Behavior Composer (2011)

NexGEN Behavior Composer was another front-end project for OneSAF. Enemy units in OneSAF use scripted AI behavior written in XAML. These AI scripts often contained errors. NexGEN allowed the puckster to select a behavior from a hierarchical tree structure (top image, below) and click and drag it to a composing canvass where a series of behaviors could be joined together (bottom image, below). The artwork for the behaviors was done by my old friend, Ed Isenberg, who has worked with me on games since the ’80s.

Screen shot of NexGEN Behavior Composer which facilitated creating OneSAF behaviors by clicking and dragging behavior icons. Click to enlarge.

Screen shot of NexGEN Behavior Composer which facilitated creating OneSAF behaviors by clicking and dragging behavior icons. This is the hierarchical tree structure of behavior primitives. Click to enlarge.

And example of a OneSAF behavior composed of NexGEN behavior icons. Click to enlarge.

A series of behaviors have been placed together to create a complex behavior (a unit fires, conducts reconnaissance, waits for one minute, moves and then occupies a position). Click to enlarge.

MATE: Machine Analysis of Tactical Environments (2012)

Funded by a DARPA (Defense Advanced Research Project Agency) research grant (W911NF-11-200024) MATE added a new level of battlefield analysis to the TIGER project. Building on the previous nine years of research MATE had the capability of generating a series of ‘predicate statements’ that described the battlefield and then using them to construct a hypothetical syllogism that resulted in a precise Course of Action (COA) for BLUEFOR (US forces). MATE then output this COA as an HTML file and automatically launched a browser to view the COA. MATE was designed to be available to commanders in the field via a small handheld device like a tablet. It was able to perform battlefield analysis in less than 10 seconds.

Consider this real-world situation from the Battle of Marjah:

Given the same data that the commander had in the above video MATE returned this COA (complete with unit paths and ETAs):

MATE’s analysis and COA for the Battle of Marjah: a right-flank envelopment maneuver with two infantry platoons while a fixing force of the mortar platoon and a third infantry platoon kept the enemy’s attention. Click to enlarge.

To see the entire MATE analysis and COA results for the Battle of Marjah click here. (this will load a PDF of MATE’s HTML output on a new tab).

Unfortunately, about the time that I demonstrated MATE to DARPA a series of unfortunate events occurred that were to change my life. The United States Congress passed the Sequestration Transparency Act of 2012. This resulted in a 10% across the board cut in all federal spending. DARPA seemed especially hard hit and they stopped all funding for 4CI (Command, Control, Communications, Computers and Intelligence) research. Only a few years after receiving my doctorate, specifically so I could be the Principal Investigator on government funded 4CI research, I was out of a job.

Without any research funding, and not wanting to relocate I returned to the University of Iowa as a Visiting Assistant Professor teaching Computer Game Design and CS1. I love teaching. And I am extraordinarily proud of receiving the highest student evaluations in the department of Computer Science but I didn’t have as much strength as I used to have. I found myself out of breath and exhausted after a lecture. And then my kidneys began to inexplicably fail.

In 2013, because of the efforts of superb doctors Kelly Skelly and Joel Gordon at the University of Iowa Hospital, I was diagnosed with a very rare and usually fatal blood disease, AL amyloidosis. In 2014, thanks to the Affordable Care Act, I was hospitalized for 32 days, my immune system was purposely destroyed and I received an autologous bone marrow / stem cell transplant. This was followed up by a year of chemotherapy. Being severely immunocompromised I have contracted pneumonia six times in the last two years. Now, against the odds (and I’m a guy that deals with probabilities a lot so I’m being literal) I’ve completely recovered. My kidneys and lungs are permanently damaged but I’m not going to die from this disease. But, it also means I can’t teach anymore, either.

Luckily, I can still sit at a desk and write computer code. General Staff is my return to writing a commercial computer wargame and it will be the first commercial implementation of my tactical AI algorithms that I have been developing since 2003.

I need to produce a game that you grognards want. And, that means next week I will be posting a new gameplay survey to pin down exactly what features you want to see in the new game. As always, please feel free to contact me directly (click here) if you have any questions or comments.