The following was written for PAXsims by Dr. James Sterrett, Directorate of Simulation Education (DSE), U. S. Army University.
The Directorate of Simulation Education (DSE) at the Command and General Staff College (CGSC), U.S. Army University spent mid-March through early June 2020 to prepare for, and then to conduct or support, three elective courses online using commercial wargames. This article outlines our key lessons learned, and then discusses some details of what we did.
In total, the class events we ran totaled 10 different games, each running from 2.5 to 8 hours, each preceded by at least one 3 hour preparation session. In addition, many of these involved numerous internal trainup sessions with each game, plus many trial runs of many games to assess their suitability for use, or in testing VASSAL modules we built for some of these games. For around 9 weeks, from 30 March through 2 June, we averaged one 3-hour online wargame session a day, for testing, preparation, or classes.
We ran wargames for 3 different courses:
Bitter Woods for the Art of War Scholars Program (2x 4 hour classes)
Aftershock for the Defense Support to Civil Authorities elective (1x 3 hour class)
Eight games for History in Action, which we teach in collaboration with the Department of Military History. (8x 3 hour classes)
Top lesson 1: Online wargaming works, but it’s harder than live. Compared to running wargames live, it requires more manpower, time, effort, and technology from both students and faculty.
Top lesson 2: Success requires scaffolding. Don’t assume students are ready with their technology or that they understand the online engine. Plan for on-call tech support during every class. Plan to explicitly teach both the online engine, and the game itself in that engine.
This is the most surprising outcome to us. Several of us had prior experience with VASSAL and were not very fond of it; we are now converts. VASSAL proved to be simple, reliable, effective, and made lower demands on computing horsepower and networks – and it is free. In addition, it was an easier and more powerful tool to make new game modules for.
(Read the detailed section for a more nuanced view of some of the other options.)
Test your tools in online classroom settings before committing to them.
Our initial impressions of tools were frequently overturned after gaining more extensive experience with them in testing.
Ease of use beats flashy presentation.
The more you can minimize the friction of using the online game tool, the more effort you can put elsewhere. This is why VASSAL became, unexpectedly, our favorite application.
Running a wargame online needs more manpower than running the same game live.
Running wargames live, a skilled facilitator can sometimes run 2 or 3 games. Online, you must have one facilitator per game. When teaching the game, you must have one person doing the instruction while another monitors a chat window for questions and puts them to the instructor at appropriate moments.
In addition, we found we needed to have a separate person as dedicated on-call tech support, every time. Although a few classes did not turn out to need tech support, most did, and dedicated tech support meant that the game facilitators could keep the games running while the students with tech problems got helped.
Running a wargame online requires a higher level of skill across the facilitators than running the same games live in one room.
Running wargames live in one room, one person can be the expert whom the others can rapidly turn to for help. Running online, everyone is necessarily in separate rooms, and even with side-channel communications, the question and answer interchange is much slower. Each facilitator needs to be an expert.
Keeping the game moving is harder online due to the limited communications.
Live, you can see what students are doing. You usually know who is thinking, who is confused and needs help, who is done making a move. Online, you usually have no idea. Is the student silent because they are thinking? Confused and lost? Conferring with their partner? Done but forgot to announce it? Done, and announced it, but failed to activate their microphone or had some technical issue? When do you break in to ask, possibly breaking their concentration and creating more friction?
Everything takes longer online.
Your game is hostage to hardware issues beyond your control.
A bad internet day makes for a bad class day. Students come with widely varying degrees of computer savvy. They also come with widely varying quality of equipment. We had one student whose computer was a low-powered laptop around a decade old, which created frequent technical issues. Another used a Surface tablet, which had no direct technical issues, but the small screen caused usability problems.
Ideally, each participant should have least 2 large monitors.
A reasonably modern computer, preferably with at least one large monitor, and, ideally, with two or more large monitors, definitely worked best. Multiple monitors enabled placing documentation and chat windows on one screen while placing the main game map on the other.
Those with only one monitor, especially if on a small screen, found themselves constantly paging between windows and struggling to manage limited screen space.
Some students and faculty took to using a high definition TV as a second monitor, which worked well.
Technology in More Detail
Ideally, we would have done extensive R&D into both a wargame engine and into a communications solution. However, we rapidly determined that Blackboard, which the Army already had on contract, provided a communications system that was both sufficient for our purposes and that students already knew how to use. While not perfect (the interface for splitting students into small groups can be a pain to use), Blackboard worked well for us. Specific features we came to rely on:
The ability to break students into breakout groups, and to have instructors move easily between breakout groups. Each breakout group was one game. Also, we could easily recall all the breakout groups into one room when it came time to return to group discussion.
Screen sharing to assist in teaching the games. While the shared screens were sometimes very fuzzy (which we worked around by zooming in when details were important), the shared screen allowed us to direct people’s attention to the item currently under discussion. In a perfect world, the game engine itself would provide a means of directing attention.
Multiple chat lines: Direct 1 to 1 chat, alongside breakout room chat, alongside group discussion chat, all at the same time. The major feature we wanted, and did not have, was a direct chat line between any subset of people without creating a new breakout room – so that 3 or 4 people on the same side could coordinate their strategy and tactics, for example. We worked around this by having students use their cell phones.
We spent several weeks testing online game engines, both for running games and our ability to modify or create new games.
As noted above, several of us had prior experience with VASSAL and did not have a high opinion of it. However, those opinions were based on the state of VASSAL in the later 1990s, when it was relatively new. VASSAL has improved a lot in the last 20 years, and those improvements are a great credit to its volunteer coding team.
VASSAL is not the prettiest or slickest engine out there. However, it had several decisive advantages:
Highly reliable, it worked on all the equipment students brought into the classes.
Free, while every other solution required either the instructors, or everyone, to buy software.
Easier for students to learn than other systems.
It was significantly easier for our team to make new or modified modules in VASSAL than in other systems.
Presented the widest variety of ready-to-go games relevant to our courses.
Because it is built from the ground up to support wargames, VASSAL’s standard interaction set is tailored to supporting wargames. The other engines seemed, to us, to have standard interactions best suited to running Euro games or role-playing games (which those other engines chase because those are much larger markets!)
VASSAL doesn’t enforce the rules. We thought this would be a weakness, but when the computer enforces the rules, it prevents the facilitator from fixing mistakes – and with first-time players, it’s very handy to let the facilitator see and do anything they want.
Two key workarounds we used with VASSAL:
Normally only one player can join a specific role. However, if everyone who is going to join that role does so simultaneously, you can pack many players into one role, permitting a small team of students to play the same side while maintaining fog of war. Note that this feature is not officially supported.
Most modules that had fog of war also included a “Solo” player who could see everything, so we used this as a facilitator role. We modified the Triumph & Tragedy module to include this as well. Without the ability to see through the fog of war, the facilitator cannot effectively answer questions and solve problems.
Tabletopia was our initial favorite, with a slick interface and great presentation. Our favorite feature is the ability to see the “hands” of the other players, which makes it really easy to direct attention – “Look at the Blue Hand”. Tabletopia is browser-driven and thus is platform independent, which is a great plus. It is also the only way to play 1944: Race to the Rhine online, which we very much wanted to include in our history course.
However, Tabletopia also had some problems. Running a multiplayer game requires that at least one player has a paid account ($9.99/month), and the Terms of Service for game creation included language that we were wary of. In testing, it was much more difficult to make a new game in Tabletopia than in VASSAL, and essentially impossible to modify an existing game we had not made. We could not figure out how to enforce fog of war in a blocks game in Tabletopia.
The great surprise came when we used it in class. We expected students would find the interface simple. However, students found Tabletopia confusing to use and said they preferred VASSAL. Students with weaker computer hardware or slower internet connections found Tabletopia crashed or refused to start.
While we may use Tabletopia again in order to use the excellent Race to the Rhine, we also know we need to figure out how to work through its issues first.
Tabletop Simulator (TTS) has a very large following, but we wound up bouncing off it. The large number of possible interactions means it also has a large number of controls and possible customizations. We found it confusing, and the physics model got in the way of ease of use as pieces bumped into each other. A friend who likes it admitted it takes at least 10 hours to get comfortable with TTS, which is longer than we can afford to spend for classes. In addition to these issues, TTS is a $20 purchase.
Roll20 is built to support role-playing games. Unlike the other options mentioned here, Roll20 includes fairly robust voice and chat communications. It’s reasonably simple to set up a new game in Roll20 as well.
Roll20 fared well in initial testing, and thus became a strong candidate for running Matrix games. However, in full testing, its communications fell apart under the load of around a dozen people. In addition, we ran into significant issues with allocating permissions to move pieces; as far as we could tell, players needed to join so they were known to the game room, then leave, so the GM could make permissions changes, then rejoin, which seemed like an overly complex dance to go through under time pressure in a class with students.
We suspect that our inexperience with the tool is key in some of these problems and intend to retest Roll20 in the summer. In addition, we know of others who have used Microsoft Teams and Google Sheets to run Matrix games.
No Computer Games – Why?
We avoided computer games for several reasons:
Students would need to buy them, and potentially need to buy many games for one class.
Many games of interest run on only a subset of student computers (only Windows, or only high-end Windows computers, for example).
Each computer game has its own interface to learn, on top of learning the game system, increasing the training overhead needed to get to the learning for the class; this is particularly an issue for our history class.
In many cases, understanding the games’ models is an essential component to learning the wider lessons of the class. In our experience, this is harder to do with computer games, whose models are obscured in comparison to manual games. (This is the price paid for the computer doing the heavy lifting of the model; the payoff of the computer is that it does that work.)
We are not adamantly opposed to computer wargames; we use them in our Simulations Lab during live instruction, and are investigating using them in some courses this fall in DL. However, in the short timeframe we had, the above complications were sufficient to rule them out.
Teaching the Games
In all cases, we learned that it works best to:
Provide a 15 minute introduction to the game at the end of the prior class. Students won’t learn the game from this but the overview helps them learn better from the rules and videos in step 2.
Provide the rules and tutorials as homework. YouTube tutorials were very popular with students, when they existed. Students will not learn the game from these but they will come armed to steps 3 and 4 with a better framework.
Provide a practice session. We routinely ran a practice session the afternoon before class. These lasted 3 hours (the same duration as the class) and included the full teaching script plus playing the game. We warned students that this was partly internal trainup, so they knew to be patient with periodic digressions as we worked out unexpected wrinkles. Because they actually play the game, students learn the game in these. If you control the groups, distribute the students who came to the Practice session across the class day student groups. As time went on, we learned to have internal trainup sessions before the official Practice session, so that our people were ready to run a game on their own in the Practice session.
Teach the game at the beginning of class. We find it always helps to begin by identifying the sides and their victory conditions, because you can tie all the game mechanics in the game back to them.
We establish up front that we will not teach all the details of the game, and thus many of these will pop up as they become relevant. We try to warn people if they are going to hit a special case, and if somebody winds up in a bad position because of a rule not previously explained, we will try to come to a reasonably fair adjustment so they are not unfairly punished by an unknown rule.
Doing all this requires facilitators who are experts on the game, as noted earlier.
We find that putting students into pairs on a given side works well in most cases. Two will tend to plan together, each can compensate for the places where the other finds things confusing, and provide moral support where one sometimes feels confused and alone. Three on a team, however, sometimes means one gets left out.
Teaching the Courses
Bitter Woods for the Art of War Scholars Program
The Art of War Scholars Program is a highly select group of CGSC students who engage in a wider-ranging and academically more rigorous course of study, focused on studying the art of warfighting through a combination of seminars and research focused on the operational and strategic military history of the past century. Each student must write a thesis in the CGSC Master’s of Military Art and Science program.
Dr. Dean A. Nowowiejski, the instructor for the Art of War Scholars Program, wanted the wargame to do three things: introduce the students to wargaming, introduce the terrain of the Battle of the Bulge to students for a follow-on virtual staff ride, and to examine the dilemmas facing the Allied forces in reducing the Bulge.
To support this, we need a game simple enough for new wargamers to play effectively, that covered the Bulge in enough detail to gain an appreciation for the terrain and forces involved, and that could be made to start later in the battle in order to cover the reduction of the Bulge.
We selected Bitter Woods for having the best balance of both a simple system (using only the basic rules) and the ability to run the Battle of the Bulge into January 1945. The runners-up were GMT’s Ardennes ‘44 and MMP’s Ardennes. Ardennes ’44 is more complex and Ardennes is out of print, the latter being a key criterion when we made the selection in January 2020 and expected to run the event live.
In order to highlight the dilemmas in reducing the Bulge, we created a scenario that began on 27 December 1944, and also modified the existing Bitter Woods 22 December ’44 start point to cover the entire map, both accomplished with assistance from LTC William Nance, PhD, of the CGSC Department of Military History. After testing both of these, we concluded that the dilemmas showed up best on 22 December, as Patton’s forces begin to arrive. This start point also made a better set of dilemmas for the Germans, as their offensive is not out of steam on 22 December, leaving them with difficult choices about how to protect their flanks while aiming for victory. We divided the twelve students into three separate game groups that executed simultaneously. We had teams of 2 on each side in each game, and each team was split between a northern and a southern command.
Dr. Nowowiejski told us that the Art of War Scholars students would be prepared, and he proved correct. This group of top-flight students, all very comfortable with technology, had no technical issues. In addition, while we ran the game, LTC William Nance moved through the 3 game rooms, offering both historical commentary and acting as the high command for both sides to ping students with questions about their plans in order to ground those in the wider concerns of their historical counterparts. This left Dr. Nowowiejski free to circulate through the groups, observe the students, and discuss wider points with them.
Dr. Nowowiejski had students discuss their plans and operational assessments with the entire class at the end of each of the two 4 hour classes, for a mid-point and final AAR. As the students in the various Allied and German teams uncorked radically different plans, this provided a chance to compare possible courses of action and outcomes for both sides. Students did find they had more units than they could easily control, but this produced useful discussions on the difficulty of integrating tactics into operations. Overall, Dr. Nowowiejski judged the event “very successful” and hopes to have us run it, live or on VASSAL, next year.
Aftershock for the Homeland Security Planner’s Elective
We have run Aftershock in person several times in the past for Clay Easterling and Joseph Krebs’ Department of Joint & Multinational Operations Homeland Security Planner elective course. Much of the course examines higher level legal and policy issues. Playing Aftershock in the middle breaks this up, and also serves as a reminder of the practical impact of the plans and policies they are discussing. Students regularly name it their favorite part of the course. Now we needed to run it electronically…!
No computer version of Aftershock existed. The designers, Dr. Rex Brynen and Thomas Fisher, readily granted us permission to create a version in VASSAL, and Curt Pangracs of DSE spent around two weeks creating and testing the module in time for the course.
There were 33 students in this elective, divided into pairs for each of the 4 teams in the game, making a total of 4 games run in parallel. Four of us from DSE ran the games, while a fifth stood by for technical support, ensuring the two instructors could circulate between the three sessions to observe and discuss.
We knew that this course tended to have a solid proportion of officers with low levels of experience with computers. Because of this, we set the Aftershock module up with two participant roles: the Facilitator, who controlled everything on the board; and the Observers, who could not change anything, but could see everything and call up the supporting documentation. This matched the way we often run the game in person, where the facilitator can keep the game moving by running the board and presenting the players with the next decision. We figured that with some of the students being less technical, making the students Observers would allow them to concentrate on making decisions instead of trying to puzzle out how to make the game execute their intended course of action.
We had far more technical issues than we expected, possibly because the larger number of students – nearly three times the number in any of our other groups – meant there were more opportunities for problems. As a result, in each of the four games, the facilitators wound up using the backup plan of streaming their VASSAL screen of Aftershock out to some of the students who could not otherwise see the VASSAL screen. This is far from ideal, as those students reliant on the stream could not control the view, and the Blackboard shared screen is often fuzzy, but it was better than not seeing the screen at all.
Despite the technical issues, students found the exercise very useful, and the instructors named it “a highlight of the course”. As one student wrote in their AAR, “Finally a time at CGSC where we are truly talking with one another to get something done and seeing the results of our decision”.
However, a key lesson here is that the event would have gone a lot more smoothly if we had conducted a readiness check at the end of the prior class session, just to make sure that everybody had VASSAL installed, could load the Aftershock module, and could join the online session – and then to help those who could not, so their troubles were fixed before the main event.
History in Action is a joint elective taught by DSE and the Department of Military History, run with the aim of teaching military history through wargaming, and also teaching a better understanding of wargaming through learning the history. Knowledge of history should inform both playing and assessing the game. Equally, playing the game should help better understand the history; while wargaming can’t let you walk a mile in someone’s shoes, it can let you walk ten feet in their socks. In prior years, DSE’s partner in this class was Dr. Greg Hospodor, but he moved away and we now partner with Dr. Jonathan Abel, and were also assisted by LTC William Nance, PhD, when he was available.
To be selected for this course, a game has to pass all of these tests:
It has to be a good game – fun is the hook, though it isn’t the point.
It has to be available for our use (some that pass the other criteria are out of print, or, for online, have no online implementation).
We have to be able to teach and run it within the 3 hour class time while leaving time for discussion.
It must be dripping with history. It has to highlight unique aspects of the historical event it covers, so it both helps teach that history directly, and further helps teach when compared to the other games in the course. This tends to rule out many less complex games because they wind up being functionally generic. For example, if the game system doesn’t help drive home the difference between commanding World War 2 armor divisions and Napoleonic cavalry divisions, or treats the employment of the Roman manipular legion as little different from that of the Macedonian phalanx, then it doesn’t drive the learning we are looking for.
While in past years we tried to sequence the games according to a theme or timeline or the scale of the actions, our test sessions in early April convinced us that we should sequence the games in order of probable complexity to students. While we began with the list of games we use when teaching the course live, but some of them were not available online, while others we would like to use were. We used, in order:
Battle for Moscow (The 1941 drive on Moscow)
Napoleon 1806 (The Jena/Auerstadt campaign)
1944: Race to the Rhine (The Allied drive across France, with a logistics focus)
Drive on Paris (Schlieffen Plan and Plan XVII in 1914)
Strike of the Eagle (1920 Soviet-Polish War)
Triumph & Tragedy (The struggle for Europe, 1936-1945)
Fire in the Lake (Vietnam War)
Nevsky (Teutonic Knights vs Novogord Rus in 1240-1242)
In each 3 hour class, we began by teaching the game, then we ran it in parallel student groups until there were 45 minutes remaining. The next 30 minutes or so were spent in discussions, and the final 15 minutes or so were spent introducing the next game in the class. Between classes, students were assigned material on the history behind the next game, rulebooks and tutorials to learn the next game, and a graded AAR sheet to fill out on the game just played. The AAR sheet asks for paragraph-length answers to these questions:
What was your plan/COA going into the game?
How did your plan/COA work?
How did the game illustrate the specific contextual elements of the period?
Was the game effective in conveying these contextual elements? How or how not?
What did you learn about warfare in the game’s time period? What surprised you?
What specific lessons can you draw from this game to apply to the future?
We were very pleased with student learning in the class. Student AAR papers were full of observations on things they had learned about history, about wargaming, and that they could carry forward to future assignments. As one student wrote in their end-of-course feedback, “more than anything the course provided context and examples that I can use in the future when explaining the challenges at the operational level of warfare”. Success! However, we did have to overcome various issues along the way.
We intentionally began with Battle for Moscow, the simplest game, to ensure we could also teach VASSAL in the same class. This generally paid off, as subsequent games utilized, at most, a few more features of VASSAL each time, and thus the learning curve was well controlled and students seemed comfortable with VASSAL most of the time. This process worked poorly when we jumped to Tabletopia for Race to the Rhine in class session 3, and then back to VASSAL for session 4 and beyond. Some of our issues with Tabletopia likely stem from our assumption that its interface was easy enough to need little direct training, and to the ways in which it is different from VASSAL. Equally, we had a slight uptick in trouble with the VASSAL interface in class session 4, perhaps because the students had been out of touch with it for a time.
We began inviting students to our internal prep sessions once we realized they might be able to attend. Students who had the time to attend these were normally much better versed in the game than their peers. We, in turn, had to recall that those unable to attend the optional prep session should be assumed to have a good reason! We also learned to spread the students who attended the prep sessions across the student groups. Arranging the student teams ahead of time, and publishing them for students, also helped, as some student teams would strategize ahead of the class.
This course charted the middle ground in the level of technical issues. All the students were comfortable with technology, but some had poor internet connections or weak computers, including the roughly ten year old laptop mentioned earlier. This led to those students losing connection to VASSAL or Blackboard. When using Tabletopia, weaker internet connections and weaker computers completely failed. Just as we all have learned that internet meetings go better when everybody turns off their video feed, opting for systems, such as VASSAL, that made less intensive use of network and computing power proved better in practice.
Online wargaming works, but it is more effort than live, because:
Test your technology thoroughly and ensure you have support on hand to run it.
Running wargames online will require a higher level of expertise from all of your facilitators, of technology and the games.
Running wargames online will require more preparation from students, both in learning the game and ensuring their technology is ready.
BoardGameGeek (description) and VASSAL (module) links for all the games mentioned:
Today, James Sterrett made a presentation to the Military Operations Research Society’s wargame community of practice on teaching wargame design at the US Army Command and General Staff College. James is Chief of Simulations and Education in the Directorate of Simulation Education at CGSC, and a periodic PAXsims contributor.
This lecture will feature a discussion of game design within the context of professional military education. DEPSECDEF Work talked to the need to incorporate wargaming into the formal military education system. One approach to executing this issue is to offer a course in wargame design to students at multiple levels of professional development. However, questions on how to implement this approach remain: At what point(s) within an officer’s career should they be exposed to wargaming? What aspect of wargaming should be emphasized? What level of proficiency is desired? What portions, if any, of the remaining curriculum should be dropped or modified to accommodate this requirement?
While the lecture wasn’t recorded, you’ll find his slides here. For previous discussion on this same topic, see his earlier (January 2017) blogpost.
PAXsims is happy to post this request for feedback on behalf of Dr. James Sterrett, Directorate of Simulation Education (DSE) at the US Army Command & General Staff College (CGSC). Comments may be left below or emailed to him directly.
Michael Dunn and I are creating a Fundamentals of Wargame Design elective at CGSC. This course will first run in the spring of 2017, in two iterations. We seek constructive feedback on our course concepts while we still have a little time to correct course.
The students in this course will be U.S. Army Functional Area 57 (FA57 Simulation Operations) officers, plus other interested students attending CGSC. FA57 students will take the complementary elective on Exercise Design at the same time.
Students taking this course will design and create a prototype manual wargame. By doing this, we intend them to learn not only the process of designing a wargame, so they can design other games later, but also to begin to come to grips with the art of wargame design. In addition, we believe that designing wargames will make them better users of wargames, more aware of the design decisions behind the curtain and better able to select the best tool for the task they may have at hand.
We are still debating if it is better to have students do the project alone, or in small groups.
Thus, our current overarching Learning Objective is:
Apply the wargame development process. Application will include:
Students will learn the process of developing a wargame by creating a workable draft prototype. Students will demonstrate the prototype in class along with a presentation explaining their logic for its design choices.
We define “wargame” very broadly, relying on both Peter Perla’s definition:
“A warfare model or simulation in which the flow of events shapes, and is shaped by, decisions made by a human player or players during the course of those events.” (Peter Perla, The Art of Wargaming, p. 280, 2012 edition)
…and on the Army Modeling & Simulations Office’s definition:
“War game: A simulation game in which participants seek to achieve a specified military objective given pre-established resources and constraints”
Thus, we are not limiting the course to Title X wargames, or research wargames, or testing wargames, or Military Decision-Making Process Step 4 Course of Action Analysis Wargaming, or any other subtype… from the perspective of this course, all of these fall inside the big tent of wargaming.
Inevitably, we are operating within constraints of space and time.
We will have at most 16 students per class, and must plan each class being full.
The course will consist of 12 session, each 2 hours long. There will be 2 or 3 sessions per week and the course will last for 4 to 6 weeks.
We recognize up front that we have limited time, and this necessarily limits the quality of the product the students can produce. We have no expectation of a polished, publication-ready project. Instead, the aim point is a workable first draft, with parts in place and comprehensible logic behind them, which would form the basis for ongoing testing and iterative design if more time were available.
Our high level view of the design process is shown below. We intend the students to complete at least one round of design and testing. More would be ideal, but a single round is the necessary minimum.
For our classes, we are treating all wargames as being a system of systems, in a “STARS” model, with those systems being:
Space structuring assets’ positional relation to each other
Time structuring both movement, combat, and decision opportunities
Assets that players control
Resolution of how assets interact
Systems that tie the other four systems together
An overview of our current plan for each of the sessions; this overview will be followed by a more detailed look at sessions 1 and 2.
Introduction to the course and its objectives; explain the project they must complete; introduction to game design process, which is their roadmap to completing the project; and to the STARS model.
ModellingSpace: Discussion of terrain modelling; includes direct examples: hexes, squares, areas, terrain boards, point-to-point, tracks, non-spatial maps. Examples of multiple types in use at once. Issue of scale – need to set to key decision loop and how scale then drives other considerations
ModellingTime: Discussion of turn structures; includes direct examples. How turn structure dictates decision structures and C2 during play; how it relates back to the spatial model.
ModellingAssets: Various ways of modelling commanded assets from the very detailed to the very abstract: tracks & points to subsystem modelling. Numerous direct examples.
Modelling Effects: Various ways of resolving the outcome of actions: CRT, dice pools, opposed die rolls, card draws, card play; modifiers for modeled factors.
Quick Intro To Basic Probability – computations for dice, multiple dice, competing dice, cards with and without replacement; CRTs vs dice pools vs cards.
Putting It All Together: Overarching design paradigms: imposing limits (or not!) on player control of own forces through systems.
Testing & Iteration: Introduction to testing, blind testing, and sorting through feedback.
Consultation & Testing Time – in the classroom.
Consultation & Testing Time – in the classroom.
Final project presentations
Final project presentations
In addition to their other requirements, students in this elective will be required to participate in 75% of the Brown Bag Gaming sessions that are held during the elective, in order to increase their exposure to a variety of wargames and design approaches.
We are considering requiring additional student reading, with titles under consideration being Perla’s Art of Wargaming, Sabin’s Simulating War, and Koster’s Theory of Fun. The potential problem is the lack of time; one potential way around this is to assign a chunk of each to one or more students, and make them responsible for a summary to the class on their piece.
Session 1 in more detail
The room is set up with the games before students arrive and students are expected to have read the rules before the class begins.
10 Minutes: Introduction to the class and similar initial admin
45 Minutes: Play a wargame. We are currently leaning towards Frank Chadwick’s Battle for Moscow, with the expectation that students will complete 3 or 4 turns. Battle for Moscow includes a large number of features we can draw on in subsequent discussion, and is in print through Victory Point Games.
10 Minutes: Break. Students are asked to come up with one change they would make to Battle for Moscow in order to improve it, and to return from the break ready to explain, briefly,
What the change is
Why the change improves Battle for Moscow
Why the improvement makes Battle for Moscow better for a specific purpose
15 minutes: Selected students present their changes. We point out that by going through this thought process, all of them have made the step from players/consumers to designers/creators. Now let’s look at the process.
We intend to select students to comment in class discussions (at least initially – balancing this against getting a wide discussion is important), instead of using volunteers, and to use a different selection mechanism each session. Thus Day 1 would be rolling 1 die, Day 2 rolling multiple dice, Day 3 pulling names from a hat without replacement, Day 4 calling on them by date of rank, and so on; possibly even handing them the cards to bid on who speaks next in the manner of Friedrich. The intent is to ensure the students experience some of the resolution mechanisms we will discuss in sessions 5 and 6, even though some of the demonstrations may take place after session 6.
30 minutes: Present and explain the development model, the STARS model, and the project they will each undertake.
Assignment for session 2:
Come up with your initial concept and email it to the instructor. Answer these questions:
What do you want this wargame to do?
What role will the players have?
What are the key decisions/dilemmas/problems they must wrestle with?
What significant assets will they control?
What kinds of interactions are important?
What kinds of terrain influence those interactions?
How frequently do the players make major decisions?
Start your research: Find and read something relevant to your project.
Session 2 in more detail
We expect each of sessions 2 through 8 to be split roughly in half. In the first half of each session, we will show and discuss various relevant examples. In the second half, students will brainstorm and discuss ideas applying the day’s focus to their project.
Session 2 covers Space.
Opening question: How would you map Wall Street?
A strictly spatial map of Wall Street is great if you want to move troops through it. However, you might also need to map conflict on Wall Street by financial connections, personal connections, Internet links, political influences, and so on. Which of these are more important to model depends on what you want to model.
For the rest of the initial hour of the class, we expect to present, with examples:
Miniatures terrain as direct representation, with a discussion that typical Digital Terrain Elevation Data is essentially the same approach
Hexes and squares, including grain effects
Zones of Control
Areas (including Guns of Gettysburg for incorporating Line of Sight into the area model)
Things inside hexes, squares, and areas
Things on the edges of hexes, squares, and areas
Point to Point
Maps that are not “real space” – VPG’s High Treason courtroom; Sierra Madre’s High Frontier ΔV map (we are looking for more good examples here!)
Why space and time inter-relate:
Scale sets the timing of decisions in conjunction with the Time model
Units per space on the map defines force density model and can be used to create traffic issues
During their break, students are asked to think about how they will model space in their project.
For the second half of class, we discuss student’s initial model concepts.
Assignment for Session 3:
Refine your intended model of space. Start working on your map. (We will provide files and printouts for hex paper, and access to Paint, Powerpoint, and Photoshop.)
Continue your research: Find and read something relevant to your project.
Dr. Long started his talk (slides here) by noting the challenge of teaching Army officers—who might be used to operating in more certain and clearly-defined contexts—about the fuzziness and uncertainty of the world at the strategic level. He argued that lecturing “at” officers was often not a very effective way or promoting critical thinking about such topics.
The game therefore emerged out of using more interactive methods to promote discussion about the role of the Army Chief of Staff and the importance of budget, investment, research, and deployment issues. In it, players make decisions about investing and maintaining various types of force, and potentially forward deploying these to several different strategic theatres. Different forces have different costs, and different capabilities in different environments (major combat, irregular warfare, peacetime operations). There are also costs associated with building and refitting forces, deploying and maintaining these, investing in research & development, and gathering intelligence about the opponent’s interests and assets. A commercial version of the game—Future Force (2011), designed by Jim Lumsford—is available from HPS Simulations.
In addition to the slides linked above, this article from Developments in Business Simulation and Experiential Learning 38 (2011) provides a very good overview:
When Army officers are promoted to the rank of Major, they become field grade officers with the responsibility of planning, organizing and leading large unit formations, working on high level staffs and running the Army day to day. The “Future Force” game is an experiential learning simulation designed to introduce them to the complexity of supporting the current force in its world-wide missions while simultaneously designing and shaping the force for all possible mission profiles for the next 20 years. Played early in their change management curriculum, the game provides a common frame of reference for further detailed technical lessons. This paper describes the game design process from conception to application.
I was particularly impressed by the explicit way in which he addressed curriculum integration and practical constraints such as available time (a point I’ve often made myself).
All-in-all it was an excellent presentation, and it is a shame there was not more time to discuss it.
(UPDATE: Added link to commercial version of the game.)
About a month ago, Rex kindly posted CGSC’s draft Stability Operations requirements documents. Expecting a handful of replies, we were hit by a large wave of responses, both at PaxSims and elsewhere. We are busily reworking the draft in light of the feedback.
THANK YOU to everyone who responded. We truly appreciate the time and effort you put in to assist us. Also, THANK YOU to Rex for posting it!
The various replies have proven helpful in four ways:
1) Design commentary
Number of Actors: Modeling the number of actors involved in stability operations emerged as a common theme in the commentary. We were trying to incorporate this and are working to strengthen and clarify it.
Flexibility emerged as a common theme as well. The community agreed that the game needs to foster a deeper understanding of conducting stability operations, that any simulation used should be descriptive rather than prescriptive in its nature and strongly instructor-driven. Implicit in this is the assumption that the instructor must have as much control and flexibility of the simulation as possible. We strongly agree with this, and thought it was codified in our documents; this is an area we are working hard to clarify.
2) We received a number of suggestions of simulations to look into, including GEMSTONE, PSOM, IW TWG, Athena, SENSE, and the Oz Wargame Integration Toolkit. We’ve already had demonstrations of some of these are and working on demos for the rest; some we have seen in the past but they have grown new capabilities. Even when we can’t see how to utilize them directly, it is always useful to see others’ design concepts. PAVE (part of TRAC-MRO’s IW TWG) is soon to undergo a closer look to see if we can modify it to meet our needs.
3) We made connections with organizations we hadn’t known existed, such as the TRADOC Analysis Center’s Modeling and Research Office (TRAC-MRO) and the Peacekeeping and Stability Operations Institute. TRAC-MRO’s office is less than 500 meters from us, but neither of us knew the other existed.
4) We thought we had made the exercise structure and POI clear, but a variety of comments demonstrated that we did not. If PAXSims readers didn’t understand it from our documents, then we clearly need to improve the description!
Deputy Chief, Simulations Division
Digital Leader Development Center
US Army Command & General Staff College
If any readers still have comments or suggestions that they would like to make, have a look at the original post (linked above) and add your comments here.
One of the discussion contributors has been Graham Longley-Brown, who offered the insights below. His graphic couldn’t be included in the comments section, so I’ve reproduced the whole thing here as a blogpost.
The diagram above is a ‘Campaign Tree’ process I developed for a ‘Hybrid Warfare Tactical Wargame’ at our Land Warfare Centre. This supports training for company HQ and/or battalion HQ commanders and staff. It addresses some of the points discussed – and it works! The concept is simple: the Training Audience (TA) move through the Campaign Tree from vignette to vignette along a path determined by their own decisions and actions. Vignettes are played out in real-time and use a real-time (largely kinetic) simulation. The TA decisions and actions taken – under pressure – during each vignette are adjudicated by Excon SMEs and dictate the path taken to the next vignette on the Campaign Tree. The periods between vignettes are modelled using a soft factors simulation and last from 3 – 8 weeks. Hence the consequences of the actions taken by the TA during the vignettes, combined with their ongoing Concept of Operations and decisions taken in response to injects and events fed in by Excon are played out during the longer time periods. The solid lines show one path through the Campaign Tree (with associated TA and Excon briefings) but obviously any path is possible.
The process integrates two simulations, both adjudicated and moderated by Excon ‘Rainbow Cell’ SMEs. MEL/MIL injects are used as required to bring out Teaching Points; these are, in the main, pre-considered but can be dynamically scripted. Likewise the vignettes are pre-considered and pre-loaded in the real-time simulation but can be modified just before going live depending on the TA plan during the preceding time period and can be executed however Excon deems appropriate. The diagram doesn’t show AARs, information flows etc – it’s just the bare bones concept.
Although I think this is quite a simple concept it’s hard work to pull all the elements together in the space of a 1-day training event that spans most or all of an operational tour deployment in game time. But it works…
The thing I love most about it is that it allows the TA to create their own narrative; it’s their actions that determine the path through the Campaign Tree – their story. Hence they are more likely to internalise lessons learned. Check out Peter Perla and Ed McGrady’s Naval War College article “Why Wargaming Works“ for more on why a created narrative, as opposed to a presented narrative is so strong a learning mechanism.
The process is also very flexible. Delete the soft factors sim and insert a board game if you like. Run it all using just deterministic Military Judgement.
So what? Paul makes the point very well that the GCSC requirement assumes a computer simulation solution that can do everything. I don’t think such a sim exists, or will do in the near future. A more flexible approach is needed that integrates a number of simulation methods and exercise processes. Paul’s ‘Right answer’ of a ‘family of games (decision-centric tools) where the students use a variety of small, purpose focused games to get at specific aspects of the problem‘ is spot on. Rex’s ‘preselected teachable moments‘ are encapsulated in various places in the Campaign Tree, and lessons learned are reinforced by the narrative created by the TA themselves. In summary, I suspect that the GCSC solution will need some innovative thinking rather than assuming (hoping?) that someone will come up with a sim that walks on water.