"Second Guessing the Greatest Generals in History"

Home | Outline | Construction | Contact | Join | Signin

How to Make War

How to Design a Module

So you want to design a module? This will require a combination of research, judgement, and creativity.

The first step is to select the module you'd like to design and click the volunteer link. This is hard work so choose a module that is of special interest to you. If someone is already working on a module you can volunteer to assist them. If you are the first to volunteer, you can enlist others to assist you.

Once you are approved you will be given special editor access to the console where you can create and edit the module components.

Overall, designing a module entails:

  • Designing the formations (TO&E) for each of the belligerants in the battle.
  • Designing one or more map sets where the battle is fought.
  • Writing exclusive rules that cover unique aspects of the battle.
  • Designing several scenarios to represent the entire battle and smaller parts of it.
  • Playtesting the scenarios.

All module editing is done through the console. Click on "Console" in the main menu and signin with your registered email/password.

You will see a tree on the left side and a panel on the right. Clicking on an item in the tree on the left side will show either information or an edit form on the right, depending up on whether or not you have permission to edit that item. After you make changes in the form, select "Save" from the menu to save your changes to the database.

In many cases, your changes will cause some documents to be invalidated, meaning that the next time a user selects the document to view it will be regenerated. This can be a slow process in some cases, taking several minutes, so after you are done with your changes you should view the documents affected by your changes both to check their correctness and to regenerate them for other users.


Formations represent the tables of organization and equipment (TO&E) of the two or more nations involved in the battle.

Weapon and Unit types

Because many armies have used the same equipment, often you will be able to use the previous work of others. For example, since WWII most countries use American or Russian equipment. And for WWII, most of the equipment has already been designed.

But if you need to design new weapon and unit types you will need to research the equipment and use your judgement to translate that into game terms.

Weapon and unit types are represented as XML specifications.

Formation Types

Unlike weapon and unit types, formations (companies, battalions, regiment/brigades, and divisions) vary considerably from one country to another and from one period to another. While it is possible that you will be able to use previous work to design the formation types for your module, it is more likely that you will need to design your own. But even then you can use other formation types as a starting point and a guide.

Ideally, a formation type will represent a general type of formation such as an armor division or an infantry battalion. But in some cases you may need to distinguish individual divisions if their organization is unique.

Formation types are represented as XML specifications.

As far as practical, formation types should follow historical tables of organization and equipment (TO&E) and orders of battle. However, some abstraction is necessary for playability. Focus should be primarily upon acurately representing combat vehicles. Noncombat vehicles are represented by support units. The goal with support units is to model their number but not their precise nature or structure. Thus, for example, ambulances, recocery vehicles, and supply trucks are all included as support vehicles.

Some platoons consist of mixed vehicles. The most common examples are infantry or towed guns and organic transport. Often, though, reconnaissance platoons contain a mix of tanks, scouts, and their transport. There is a maximum of four units per platoon.

There is a maximum of ten platoons per company, 26 companies per battalion and 10 battalions per regiment due to the numbering scheme.

  1. Start with the official TO&E.
  2. Modify to fit the constraints of the model (e.g. simplify platoons to one or more counters and companies to no more than 9 "platoons" plus hq).
  3. Model combat formations, not administrative formations. For example, US should have "task forces" that mix mech and armor.
  4. If the platoons of a "company" are usually distributed as independent units, include in the hq company (e.g. air defense).
  5. If the platoons of a "company" or "battalion" are attached to other formations in combat, distribute them in the formation, e.g. the Russian tank battalion to the mech battalions.
  6. Every vehicle that is not included as a combat vehicle should be added to "support" units so that total vehicle count is accurate (e.g. signal, maintenance, medical, and NBC).
  7. All battalion, regiment, and division HQs should include a staff unit.


A formation represents an actual historical (or hypothetical) unit such as the 8th infantry division and is based on a formation type. Adding a formation to a module will generate counters and formation charts for that unit. Taken together, the module formations describe the order of battle from which units will be drawn to play the scenarios.

Each module will have at least two formations (one for each player) but may have many formations. Although a precise order of battle is possible you should be careful not to force the player to construct redundent counter sets merely for the sake of having correct identification numbers. Instead, as far as practical, you should provide representative formations that can be reused from one scenario to another.

Formations are represented as XML specifications.


Obtain 1:25k or 1:50k topographic maps of the battlefield either in printed or electronic form.

If you are working with printed maps, use a pencil and ruler to divide up the topographic map into AxB mm rectangles. Write the column numbers across the top and bottom and the row numbers across the left and right side. Each rectangle will represent a single game map and the corss index of column and row indicates the position of the game map within the mapset. Print out a scaled map template onto a transparency to overlay the printed map.

If you are working with electronic maps, use a graphics editing program like Adobe Illustrator or Photoshop to superimpose a hex grid at the scale over the map.

In either case, use the map scale to calibrate the hex grid to the map to five hexes (hex center to center) per kilometer.

Print out several blank maps.

For each game map:

Take a blank map and write on it the map the name of the mapset and the column/row of the map within the mapset.

Place the transparency on a rectangle on the topographic map.

Using the contour elevation markings, judge the elevation of each hex on the transparency and record that on blank map.

Using the terrain markings, judge the type of terrain of each hex and record that on the blank map.

When all hex elevations and terrain types have been recorded, transfer this information to the console.

Judge elevation by the hex center unless special circumstances dictate otherwise.

Look for elevation numbers and mark those hexes first and then follow elevation lines to mark others and then fill in between them.

Judge waterways first by where the hex center falls and then adjust these where the flow is more ambiguous.

Make sure waterways flow down, judging by the lower elevation on a hexside.

When I am done with a map page I paste in a big yellow C/R (where C is the column and R is the row) over the red "1/1" in hex 0101 to show that it's done and help me reference where I am.

Also, when you go to enter the map data you will see that there is a 0 row and column. This represents the edge of the map. I add these to the map notes hanging on the edge to remind me. For boards that connect with others, you can copy these (e.g. 0 row from the map above, 0 column from the map to the left. For the first maps (left and top) you can either estimate these from the map or just repeat the first row, column elevations and terrain.

W (waterway), T (dirt road), and R (paved road) are suffixed by two digits. The first digit indicates the level (1, 2, 3) and second digit indicates the direction. For a road, this is the direction from the center point that the road follows. For a waterway, it is the direction from the hex center to the waterway hex side. Numbering begins with 1 at the southeast hex side.

So R21 would be a road (level 2) from the center to the southeast hex. W34 would be a river (level 3) along the north west hex side.

R (ridge) and B (bluff) have single suffix digits that indicate the direction of the hex side like a waterway.

Create a map set for the module. Indicate the number of rows and columns of map pages in the map set. For each map page above create a map page under the map set and record the information. A game map page is automatically generated and any changes you make on the console will be reflected in the generated map pages.

Once you are done, print out the entire map set in b/w and look for errors. Common errors are mismatch on map page borders and incorrectly entered elevations. Sometimes these errors are obvious but correct errors whenever they are found.

Finally, construct your maps for playtesting.

Exclusive Rules

Exclusive rules should be minimized but often there are unque aspects to a particular battle or war that require special treatment. Any rules that are unique to the module but general to the scenarios of the module should be explained in the exclusive rules.

Use the Microsoft Word format, provided in the template rules. Use Dropbox to share this file. If you are able, you can generate a pdf from the Word file and upload it to the module; if not, get help to do this.


The whole point of designing a module is to create one or more scenarios that can be played.

You should provide a range of scenarios from small actions representing one small part of a battle that can be played quickly to monster scenarios that cover the entire battle or war that the module represents. The more options you give players, the more likely that they can find something to fit their interest and time available.

Scenarios are represented as XML specifications.


Finally, be sure to put some effort into playtesting. You should have chosen a subject of special interst to you and this is your chance to take your creation for a test run. Get your buddies to help out.

Use your playtesting experience to develop designer and player notes to add to the exclusive rules. But also make suggestions for standard rules improvements.

Map Sets
Formation Sets
Scenario Replays
How to Design a Module
Design Notes



Copyright © Armchair Brigade