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: