Category Archives: Wargames

The Wargame in the Viking Grave

The recent article, “A female Viking warrior confirmed by genomics,” which appeared in the American Journal of Physical Anthropology has started a firestorm of controversy in both academia and the international press. The New York Times wrote, “…the controversy has reignited a longstanding debate about the role of women among the Vikings, Norse seafarers whose exploits, from the 8th to the 11th centuries, are central to Scandinavian identity.” Some argue that the DNA testing, itself, was in error or that the bones of the Viking warrior were mixed up with bones from another grave since the original discovery of grave Bj 581 from the Birka settlement on the island of Bjorko by Hjalmar Stolpe and first reported in 1889. Nonetheless, what caught my eye – and probably yours as well – were these words from the original article:

“The grave goods include a sword, an axe, a spear, armour-piercing arrows, a battle knife, two shields, and two horses, one mare and one stallion; thus, the complete equipment of a professional warrior. Furthermore, a full set of gaming pieces indicates knowledge of tactics and strategy (van Hamel, 1934; Whittaker, 2006), stressing the buried individual’s role as a high-ranking officer.” – A female Viking warrior confirmed by genomics, American Journal of Physical Anthropolgy, Hendenstierna-Jonson, et. al.

I had to find out: what was the Viking wargame buried in grave Bj 581?

Illustration by Evald Hansen based on the original plan of grave Bj 581 by excavator Hjalmar Stolpe; published in 1889 (Stolpe, 1889). The red circle highlights the gaming pieces. Click to enlarge.

Reconstruction of grave Bj 581 drawn by one of the authors, Neil Price. Click to enlarge.

First, I contacted Dr. Rosemary Moore who teaches Roman Military History and Warfare in the Ancient Mediterranean (as well as Classics) at the University of Iowa. I studied under Dr. Moore in graduate school and she was also on my Doctoral Defense Committee. Dr. Moore is also a former Marine officer and enjoys World of Warcraft and wargames. She did some preliminary research and forwarded Game-Boards and Gaming-Pieces in the Northern European Iron Age by Helène Whittaker to me. In describing a female burial in the same Viking cemetery (Bj 523) Whittaker writes, “Grave 523 was an exceptionally rich burial which contained gaming-pieces of glass…” And, “The female burial in Grave 523 at Birka shows that gaming equipment could at times also be associated with high status female burials. It can accordingly be suggested that the occurrence of gaming pieces and game-boards in funerary contexts could refer specifically to male prestige and the values associated with military prowess and leadership, but at times could also express social status in general, both male and female.”

While unable to find an actual photograph of the game pieces from Bj 581, I did discover a reference to 27 antler game pieces from that grave located at the Statens Historiska Museum in Sweden. A bit more digging found this photograph of 27 bone / antler game pieces from the same museum and tagged as having been found at  Bjorko.

Twenty-seven bone/antler game pieces found in grave 624 at Björkö, Uppland Sweden Adelsö parish. From the Statens Historiska Museum, Stockholm. Click to enlarge.

While the above game pieces came from a different grave in the same cemetery, they are of the right number and material. Consequently, the game pieces in Bj 581 must have been very similar.

What did the board look like? This photograph of a game board from a 7th century Viking boat burial in Valsgärde, Sweden had similar pieces:

Game board discovered in a 7th century Viking boat burial in Valsgärde, Sweden. Click to enlarge.

So, now it looks like we’ve found the pieces and the game board. All that’s left is to identify the game, itself. The best guess is that this is the game Hnefatafl. There are a number of modern versions of the game (some using different pieces) though the original rules were never recorded.

The name of the game comes from the Old Icelandic words hnef (fist) and tafl (table). Fist-table sounds like a proper Viking game for warriors.

Creating Victory Conditions in General Staff

The General Staff Wargaming System provides users with the tools to create scenarios of their own design. These scenarios can be historical battles or they can be ‘what if’ scenarios (e.g. what if Custer had brought Gatling guns to the Little Big Horn or what if Robert E. Lee fought Wellington). To determine the victor of these scenarios or battles we need to have a predetermined set of Victory Conditions. Below is a screen shot of the Edit Scenario Victory Conditions screen:

The Victory Point editing screen in the General Staff Scenario Editor. Click to enlarge.

And below is a screen shot of the self-checking error function for setting Victory Points:

General Staff automatically checks for impossible victory conditions. Click to enlarge.

The General Staff Wargaming System is designed to give maximum flexibility to the scenario designer. It fully supports creating scenarios from 18th and 19th century armies and any map.

How to Edit Unit Speeds in General Staff

We recently had a series of very spirited discussions about the speed of units in various formations and across different terrain types during the Napoleonic Era in the Facebook Wargaming groups. A number of people were very kind to forward documents, tables and charts that had estimates of unit speeds. But, one thing that quickly became apparent was there was quite a bit of disagreement about, “how fast could a unit march,” in the 19th century.

Furthermore, we hadn’t even begun to talk about battles that took place in bad weather (the battles of Stone’s River and Fort Donnelson during the American Civil War come to mind).

The solution, obviously, was to allow the user (the scenario designer) to have complete control over these values. Consequently, we’ve added a very easy to use utility to facilitate editing and displaying unit speeds in various formations across different terrains.

Below is a video we created that demonstrates these utilities:

Announcing the Scenario Editor!

The Scenario Editor Module for General Staff allows the user to combine any two armies created in the Army Design Module with any map created in the Map Design Module and create a scenario or battle. In the screen capture before we’ve combined the Allied Anglo-Portuguese Army from the Battle of Albuera (May 16, 1811) as the Blue Army with Napoleon’s Imperial Guard as the Red Army and placed them on a map of our own design.

Screen shot of the General Staff Scenario Editor. Note that the time to deliver orders via courier between units is displayed. Click to enlarge.

Also, note that when you slick on a headquarters unit the route, distance and time that a courier will take to deliver orders to the next subordinate unite are displayed. This is just the beginning because General Staff is actually two wargames in one.

We will be posting a video showing off some of the new features shortly.



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]