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.
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.
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.
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:
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.
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.
Disadvantages of a Complex Unit Structure:
More data has to be researched, compiled and entered into the Create Army Module (see here).
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