This is the beginning of a paper I'm currently trying to finish. It deals with wargames, weather, and black box technology. When you get to the end of what's posted, I hope you'll understand why I'm sharing it with you. In its long and storied history, wargaming has struggled with the ways in which the rules of any given system can best model strategy and tactics. Post-WWII games have perhaps wrestled with this problem more so than previous generations as a result of the computer and an increasing reliance on it to perform even more complex calculations. In addition to better simulation of hidden knowledge, the computer has freed users from the drudgery of routinized tasks. The result of this has created programming code that creates what is known as the “black box” effect. This so-called black box handles the processing of data and events the user does not need to be concerned with as they are not as critical as their outcome. This has allowed for any number of effects, but the cost comes at the full knowledge of what the rules of the game simulate and why. The result has lead to the rise of games more concerned with maneuvers and movement than position and planning the closer one moves towards real-time simulations. Abandoning the table top for the computer makes sense in many situations. That said, such games short circuit the ability to train for long-term planning. To prevent this, an optimal strategy bridges the black box divide by incorporating the digital with the analog. An admixture of technology and sand table planning helped shape the way in which wargames were conducted from WWII on. This is not to say the war was the start of such fusions of human and computer activities of the militaristic variety, but that the ear is a starting point for the urgency in speeding up information processing for both wartime and peacetime use. The faster one can crack a code, the sooner (and longer) it can be exploited. Or, expressed in another way: the engineering of complex systems like Germany’s Enigma machine. The intricacies of the mechanism included a black box that stumped Allied code breakers who were unable to decipher messages even with their own room-spanning computers of the era. The drudgery of the computations the Enigma’s extra gear allowed the Axis to communicate without needing to risk errors due to human calculations, assuming both machines were set to the same parameters. The result is months of time saved. In short: economics. Planning missions or exercises can take months or years of effort. In part, it is the need for intelligence that extracts the highest cost. Why, then, would a military wish to employ simulations that are fettered with minutiae? An obvious answer would be to have fewer casualties in war and again the need for the black box provides another answer. In essence, it is a cheat to forego any need to deal with tasks that could otherwise distract the participants (which could result in their becoming casualties). Exercises based on historical missions also test if it is possible to do better, examine what went right/wrong, and as tools to train soldiers or officers in proven military doctrine. When protocol and troop composition are emphasized more than how to work the simulation, the black box comes in handy. Defining the Black Box and its Function The reasons for wanting a device like the black box are all well and good but they do not help pin down what it is. A crude definition is that one puts stuff in to the black box and receives something else out the other end. For the user who does not need to know anything about the programs’ operation, the black box takes care of the details while letting a user focus on a broader view. The black box is not as mysterious as it sounds, especially if one could access the code and see what it is that is going on inside. Calculations that take place within the object are outside of the program user’s purview. In effect, they happen off screen. The sole purpose of the black box seems to be as a method for overcoming any learning curve associated with the simulation, model, or game. By this, it is meant the user does not have to focus on minutiae to make the program work as expected. In Game Development Essentials: Game Artificial Intelligence, John B. Ahlquist and Jeannie Novak note that the events that lead one to develop black boxes are “those that encompass well-defined problems and repetitive behavior” (105). Again, drudgery works its way into the argument. Well-defined problems would be those in which the programmer knows the same result will happen every time that particular black box is accessed, such as a “start” button which runs several different modules that make up the simulation. Another way to think of the black box is as the bulk of the rules that serve as the bounds of the system (or systems). Simulation users are likely to think that the few controls they have access to are the rules, but this is not the case. Consider all the contingencies that would need to be programmed into a model in order for it to function properly. Some rules can even contradict one another when they come into contact. To this end, the black box is more than just the majority of the rules; each instance also contains contingencies so the program runs smoothly (or, like it is supposed to). The hierarchy of rules, if one is so inclined. What makes the black box ultimately useful goes back to what Ahlquist and Novak meant in regards to repetitive behavior. Anyone who has tried their hand at programming a computer can attest to how unwieldy – and boring – code can get if one must recode a commonly called function every time it is needed in a program. The Enigma machine is a good example of this with its extra cog that kept the Allied code breakers so frustrated. Describing it as a black box with a repetitive behavior, Ahlquist and Novak note that it is best suited when “a single behavior is repeated” (105). The cog is a physical manifestation of a subroutine that works time and again on a problem as it is called upon to parse strings of data to be manipulated. During WWII, punch card programming represented the norm. Tape memory banks were used, but in order to feed a computer a program, one had to literally feed the code into the machine one card at a time. How does a programmer reduce the amount of time needed to encode and run a machine when there are so few machines around and time is the overriding commodity governing when and if access is possible? Subroutines. As one moves away from cryptography, the subroutine also finds value in climate/weather models as well as ballistics, both of which are important in understanding how and why computer games operate. Other than code breaking, WWII saw the need for accurate weather predictions and optimal firing solutions. Weather models are extremely complex. As Myanna Lahsen explains in “Seductive Simulations? Uncertainty Distribution Around Climate Models,” “because of limited observational data and computer power, GCMs [general circulation models] break the atmosphere into a manageable number of blocks (grid boxes) and calculate relevant processes within each block” (emphasis mine) (900). It does not help mission planners if they find out that it will be cloudy over their proposed target ten days or more after the event. Missiles require inborn guidance controls to adjust their courses and atmospheric conditions can affect trajectories. Lots of subroutines in the code can help compensate for this. Like the weather models, it comes down to simple economics. Not only do subroutines lower the memory required for the program, but they also make it faster to compile and execute, which has a monetary value in terms of time produced and hours spent in production. With missiles, there is almost no time between launch and target, making the speed of calculations all the more important. Applying this to a simulation, it leads to simultaneity, or real-time feedback. Using an analogy of the black box as the computer equivalent of oil, it becomes clearer how the economics works for the favoring of this device in models. A gallon of gas is roughly the equivalent to 8.4 years of human labor. As Don Ihde observes in “Models, Models Everywhere,” that “calculations which would take hundreds of mathematicians decades of time, can now be done in manageable, finite periods of time” (79-80). Imagine trying to calculate the weather patterns in a grid system where each grid and its planes affect the next, which affects the next, and so on throughout the region being studied. Meteorologists have to know how their models work and what formulae are being used to generate the results. This renders the program as not a black box (more about this later); that said, it works in the same way. The end result is that conscious effort to adjust for any emerging patterns or changes are no longer required as the black box handles most calculations, making them akin to oil in their labor-saving capacities. A Very Brief History of Wargames and Their Growing Complexity While it may seem obvious, it bears mentioning that this class of games is old. Gary Gygax and Jeff Perrin say as much in the introduction to Chainmail (first published in 1971). Chess, checkers, backgammon, and go, to mention but a few, are all games of and about war. Gygax and Perrin note that “chess is so abstracted that it is barely recognizable as a wargame” (5). The same applies for the board games mentioned above. Along with those that use miniatures, like Kriegsspiel, Chainmail, and Warhammer, they are effectively systems of perfect information. What this means is that players effectively know everything about their opponent’s forces. Up until the invention of computer-based wargames, there was no way to effectively mimic hidden knowledge without either using methods such as a double-blind simulation which separated opposing sides with screens or multiple rooms, hidden game boards, pen-and-paper accounting, and an impartial third party to act as moderator for these methods. Where backgammon and Kreigsspiel differ from the others is that they use an element of random chance. Such uncertainty not only increases the complexity, but also attempts to mimic the conditions that could provide a tactical advantage to either side that otherwise is too difficult to account for. Even with this addition, the games before WWII are part and parcel the reign of perfect information. Knowing how the rules work and what can be done with the pieces available provides an insight into the random chance system’s workings, which means a simulationist can skew things to his advantage. To compensate for the possible manipulation of the system as well as greater fidelity to reality, greater complexity is added to the system. The post-WWII American military took advantage of simulations and models as a method for training soldiers and for testing and refining the tactics of the day. This consisted mainly of sand tables and miniatures as well as a few in the guise of board games. In 1972, a disturbing trend was noted in a RAND Corporation of the various simulations used by the different branches of the US military. Entitled Models, Simulations, and Games – A Survey, Martin Shubik and Gary D. Brewer ask “If these people do not know what their models are supposed to do, who does?” (17). Few, if any, of these were digital and thus had no black boxes to absorb the bulk of the rules and minutiae that might have interfered with the lessons to be learned. For what can be reasonably assumed as obvious choices, most military exercises are surprisingly low-tech as muscle memory is conditioned for reflexive actions that increase speed and accuracy. Furthermore, as James Gleick reports in The Information, that Claude Shannon showed that a computer could play a game of chess and that “they must reason, as Shannon saw, along something like human lines” but in “1952 he estimated that it would take three programmers working six months to enable a large-scale computer to play even a tolerable amateur game” (265-6). Is it any wonder that the military was a bit confused by their models? Taking a step back, H.G. Wells’ Little Wars was influenced by Kriegsspiel but departed from its forerunner by abandoning a grid. In effect, Wells’ game is a continuation of the evolution of the Prussian wargame (he admits as much in the game’s appendix). Estimated, vectored movements became the heuristic with the removal of the board. Gygax and Perrin continued this in Chainmail, as did designers of more recent incarnations (Warhammer, Flames of War, and Dystopian Wars to name a few). In a foreword to Skirmisher Publishing’s reprint of the book, Gygax admits that “Little Wars influenced my development of Chainmail,” showing how long the black box stayed out of wargaming altogether for as long as it did (xxi). Rules had to be added to govern firing arcs, the use of tape measures, and the use of three-dimensional terrain. Still, there was no black box as players had to learn how to handle the fuzzy aspects of how much force to use when firing a toothpick artillery piece or where to drop simulated weapons fire. The rules are such that players fire then measure to see whether their opponents are in range, the accuracy of the attack due to distance, and if the actions are allowed by the rules. Enter the grid-based board games. If chess is too abstracted to be useful as a training tool, then what about a modified chess game that integrates modern units, dice, and a headquarters unit as the equivalent of the king? This is Tactics, which, according to Roger Smith in “The Long History of Gaming in Military Training,” was a game created by Charles Roberts, while “awaiting his commission in the army” and later revised by Avalon Hill as Tactics II in 1958 (8). Like chess, pieces had different strengths, but they were not limited to specific types of movement. The game compensates for this by applying various rules to limit or restrict movements through different types of terrain. As far as board games go, this was an early attempt of post-WWII war games to achieve fidelity of reality. The clouds of war could not loom on the horizon forever, however. Or, in the case of the post-WWII set, there was an inherent lack of battlefield conditions that could completely thwart the problem of perfect information. Unlike a card game where the backs of cards are all the same, scenarios not only could not prevent players from keeping track of an opponent’s resources, but with a bit of deduction, it is possible to know how his resources are deployed. There is no black box to handle hidden information. Worse still, the only use of weather in these games is on movement and morale, not on the player’s visibility (though it can affect a unit’s). According to Michael J. Varhola in Little Wars, it was so influential for modern wargames that Avalon Hill’s use of concealment rules in Squad Leader are a parallel (vi-vii). The problem with this is that even in Advanced Squad Leader, the game that is arguably the capstone of the table top board games, treats weather as a method for modifying movement, chance to hit targets, etc. The chief rule for weather illustrates the point with the following wording: “The Weather Chart is consulted only once prior to both setup of, and purchase for, any DYO [Design Your Own] scenario where research into weather conditions is insufficient to describe the weather. Otherwise, weather conditions are always considered Clear in the absence of any weather SSR [Special Scenario Rule]” (emphasis in original) (E7). Weather in table top games only affects units, not players and the only counter is to know the rules in their entire nuance to get the most out of the simulation.
After fixing some mistakes and what seems like some auto-correcting features, the full paper, including abstract and works cited came out to 31 pages in length and 9,961 words. References to Pit and Chainmail appear somewhere near the end. If anyone would like to see the full paper, I'll gladly show it to you.
What is this paper being written for? Magazine? College? Looks lke you have done a good job explaining how strategy computers and board calculations are both relevent. At least thats what I got from it. Very informative, is the rest of the paper covering anything else about our favorite hobby? I'd like to see this sometime.
It ended up being 28 pages long, excluding nearly a full page abstract (single-spaced), and 2 pages for the works cited. It only needed to be 6 pages long. That said, I was the only undergrad in a grad-level course and didn't think the standard length for undergrad papers would work. I posted the entire thing on my Facebook page, edited of course, for anyone on my friends list to read. At the moment, I'm wondering if I should hold off releasing the whole thing on the off chance it's publishable.
That's not a bad idea. I've done some graduate research for a class and I'm thinking of touching up the paper and adding a little more information to see if I can have it published in a religious journal or two.
As big boardgamer I never miss listening to the podcast "The Dice Tower". This podcast is huge in the boardgaming world and one that anyone that has an interest in boardgames should at least checkout. One of the segments each week is by a guy named Geoff Englestein and it deals with the math and sciences behind games; really interesting stuff. Geoff also just started his own podcast called Ludology which is a longer version of his DiceTower segment. You should send him your paper as this is right up his alley. Who knows, it may open a door or two. http://www.thedicetower.com/thedicetower/index.php http://www.ludology.net/
