For some time now, I have read with great interest, the exchange of articles between Sam Mustafa, Bill Haggart, and others in MWAN. In something akin to the wargaming world's version of the Federalist and Anti-Federalist Papers, they have discussed the relative merits of two approaches to wargame design.
Bill seems to advocate more of a "serious" approach arguing that, while wargaming may be for fun, if it is to be truly historical in nature, rules design must be supported by sufficient research. Bill asserts, we must also strive to understand what simulation really means and how to apply its concepts in game design.
Sam, on the other hand, states that we cannot truly hope to "simulate" anything on the wargame table. Game rules fall on a spectrum of control versus chaos according to the individual desires of the designer. The bottom line, he exhorts, is "Does it feel right?"
The authors have been quite adept in their reasoning and I've enjoyed their articles. For what it's worth, I'd like to weigh in on this subject with what I believe are some relevant insights. You see, I'm a simulation engineer.
"A what?" I hear you say. Yes, that's right, a simulation engineer. For nearly nine years I have designed, built, and run computer simulations of various military satellites (those things they stick on top of rockets and launch into orbit for communications, early warning, navigation and the like). For someone who, since 1975, has played wargames and tinkered with rules design, this has been something of a dream job. Simulation - real bonafide simulation - after all, seems to be the ideal by which wargames are measured.
Right off the bat, let me say the nature of the job prohibits me from going into too much detail. Even though my work right now is largely unclassified, naming specific companies or providing details on specific space vehicles would require me to go through an approval process for this article. The result would be that I might get published sometime in the year 2015. Still, I believe I can provide some interesting, generic examples of the issues involved in satellite simulation design, as well as the similarities and differences to what we see folks trying in the miniatures gaming world.
This is a big, multi-faceted subject. So please bear with this crusty old "sim" veteran while I try to described how we build and use simulation in this part of "the real world".
LIFE IN "THE MOD"
"Dream Job" status aside, forget any notions of glamour here. I spend my days, with a few colleagues, in a closet that's shielded from electromagnetic radiation in a building somewhere on a military base (no radio reception here). Space is at a premium in our room module or "mod" as we call it. My desk is buried under "software user's manuals" and "orbital operations handbooks". Overhead are shelves full of various books on computer operating systems, programming, databases, math, and physics.
A computer monitor also sits on my desk. It's linked to the "test machine" that sits at my feet. As its name implies, this is a computer that I use to build and test updates and modifications. It's "off-line" (i.e., not connected to anything else) so if something goes wrong, it's not a big deal. In the back room are the "cps machines" - the computers that can ship the data output of our simulations to any of our several users. We strictly control what goes into this equipment, hence the need for off-line test machines.
In this business, simulation is done on computers. Do not confuse cause with effect however. It's not true simulation because we use computers. We use computers because our simulations are complex enough to require them; because no human could possibly make all the calculations necessary in the time required. Even if one could, the potential for error would be extremely high.
Simulation can be used for many purposes, from training to analysis to attempting to predict the future. Where I work, we use simulation for testing out new satellite control systems, training new personnel, and rehearsing mission control crews for launch and onorbit operations. Satellites are expensive items. When you factor in the launch vehicle, their cost ranges from a hundred million to nearly a billion dollars each. With this kind of money involved, everyone in the business agrees that it's a good idea to practice a few times before you try to launch one.
With so much riding on the line, our simulations must meet certain requirements and provide certain capabilities in order to be valued and trusted by our customers. Our simulations must be:
- Accurate to the level required by users
- Validated and verified as being accurate
- Able to interface with actual command and control equipment Usable for a variety of training and rehearsal scenarios
- Reusable for the same scenario many times with predictable results Reliable, maintainable, expandable, and cost efficient Available when needed and as often as needed
These requirements mean our work in the sim shop deals with a myriad of questions and problems. Some of these will be familiar to most wargamers. Others may be quite new.
A QUESTION OF ACCURACY
Wargamers might refer to this as "realism". For us in the satellite world, it's a matter of necessity. If our simulation is not accurate, it can't be used. In the simulation business, the accuracy of a product is termed its "fidelity". A simulation's fidelity may range from "low" to "medium" to "high" or anywhere in between. Even within the simulation world though, there's some argument as to what constitutes a particular level of fidelity. What's more, with something as complex as a satellite, you may have varying fidelities for different parts of the simulation.
In fact, a satellite simulation (as with most others) is broken up into many smaller simulations. Each of these is termed a "model". We have models for propulsion, orbit, attitude control, temperature, electrical power, and on and on. There is also a model that takes into account the positions of the sun and Earth, sun radiation intensity, positions of certain reference stars, and so on. This is termed the "Environment" model.
Each of the models in our simulation, in turn, has many components and each of these components may have a different level of fidelity depending on user requirements.
The term "user requirements" crops up a lot in our business. Of course, we'd like to put in the highest level of fidelity possible in every component of every model in our simulation. But, this is where the "cost efficiency" part comes into play. As in any business, we have to put the most effort toward the most important things. This means some components are simulated at a higher fidelity than others.
The high level of complexity in a satellite simulation means that fidelity is sometimes a difficult thing to explicitly define. Do you mean the fidelity of a particular component, model, or the simulation as a whole? Even from one component to the next, the idea of level of fidelity may mean something different.
Consider the temperature of an Apogee Kick Motor (AKM). This is a very large rocket engine on some satellites used to boost them into their final orbit. When an AKM fires, its temperature trend may look something like the time-based curve shown in Figure 1.
Figure 1. Apogee Kick Motor Temperature Trend during Firing
Figure 2. Possible Solutions to Modeling AKM Temperature
The fidelity of our simulation can be measured by how closely we match this curve. But there may be various solutions we could provide (see Figure 2). Each may provide advantages and disadvantages.
One solution may match the real curve precisely, but only over a short range. This solution would be acceptable if the user only wanted to view the particular temperature data over that range of time.
A second solution may not match the temperature curve as closely over the narrow range mentioned above, but it may consistently be close over the entire range of time. If the user wants to view the thruster temperature over this range it may be the better soliition
Yet another possibility is to use some combination of the two solutions to provide the closest fit to the curve over both ranges. This however may be extremely difficult to implement or may cause difficulties under other conditions.
Compare this to an electrical power switch. Its position is either on or off. It doesn't take much to achieve perfect fidelity on a single switch. However, fidelity for the electrical power simulation may also be measured by the number of switches simulated, how many of them respond to commands, and whether total power load is calculated correctly for given switch configurations. Particular training scenarios may require the addition of extra switches that aren't on the real vehicle so that we may "break" components.
If you examine the examples of the temperature trend and the electrical switch, you will see that a simulation can be thought of as representing two groups of things: states and processes. The on-off position of a switch is a state. So is the temperature of a thruster at any given point in time. The trending of thruster temperature, however, is a process.
Just accurately representing states isn't much of a simulation, though. Even representing changes in states barely qualifies as low fidelity simulation (in fact there's a better term for this sort of thing that we'll discuss later).
The real meat of simulation lies in representing the processes that control the states of the various components. Of course, to do this, you have to understand those processes and have a way of describing them. In most cases, this involves mathematical equations. Each equation is not a process itself, but rather, is a way of describing a process.
We do not pluck these equations out of thin air. There are verifiable laws for how things like orbital mechanics and thermal dynamics work (most of them worked out by great scientists such as Newton, Kepler, and others). As the saying goes, we're standing on the shoulders of giants. The important thing here is, since these processes are understood, the accuracy of our representation can be measured against that understanding.
Therefore, out of a necessity to represent processes, our simulations have become complex mathematical models. Chess has been called "the game of kings". Where I work, simulation is the game of mathematicians and physicists. All of us in the mod combine some level of math and physics knowledge with satellite technical expertise and computer programming skills.
Accurately representing processes and states of isolated components still isn't enough though. To get the level of fidelity desired in this business, we must go further.
DYNAMIC VS STATIC
I mentioned states and processes. If we only simulate a single state of a component, we would call it "static simulation". If, however, we include a process that changes the state over time, we have a "dynamic simulation" (dynamic means changing after all). There is another aspect of dynamic sim however, and that involves simulation components or models having an impact on the behavior of other components and models.
Consider our example of the Apogee Kick Motor. The AKM is big, taking up a large portion of the satellite structure. When it fires it generates a lot of heat energy in addition to its thrust. Where does all this heat go? Much is expelled out the exhaust nozzle with the gas from the burning fuel. A good portion, however, is emitted from the engine casing in the form of electromagnetic radiation - infrared to be exact. This "heat radiation" influences the temperatures of the other parts of the space vehicle over time causing what is called a "Heat Soak". The delayed effect on each of the temperature curves is called hysteresis (See Figure 3).
Figure 3. Vehicle Heat Soak after AKM Fire
Another good example of interaction between models would be the effect of sun radiation (environment model) and the vehicle orientation (attitude model) on temperature trending (thermal model) and the solar array currents (electrical power model).
If our simulation is to be highly dynamic, and thus high fidelity, it must reflect such interactions between components and models. As our examples imply, to reflect such changes and interactions accurately we must take into account yet another factor - time.
A QUESTION OF TIME
In our simulations, time is God. Everything is referenced to time, and for a good reason. Many activities in satellite operations are time critical. A typical satellite may travel at several kilometers per second in its orbit. At this velocity, being off by half a second can have a big impact on the vehicle's position. In satellite operations, everything is linked to Greenwich Mean Time (often called "ZULU Time"). This means we sim engineers must continually consider two times: "real" time (i.e., ZULU time) and simulation time.
Our simulator times things down to the millisecond (one thousandth of a second). A good term for this level of precision is "time resolution". This is the smallest quantity of time in which events (i.e., changes of state) can occur. Put another way, time resolution determines how quickly and how often component states may change.
If there is not enough time resolution, it may affect the simulation's accuracy. For instance, if a real process changes a voltage over a period of milliseconds, but my simulation only updates once per second, then the situ's accuracy is less than it should be.
However, precision itself does not guarantee accuracy. Say a process only significantly changes a voltage every ten seconds. Then, having a simulation with a resolution of one millisecond doesn't help you much for that model.
As I mentioned earlier, everything in satellite operations is linked to ZULU time. This means our simulator must have a very important capability. It must be able to perform all its process calculations and all necessary updates to component states at least as fast as real time. In other words, we must synchronize simulation time with real time. There are also occasions in training or rehearsals when we must run faster than real time. Certain rehearsals "compress" a two or three day period into a single day, skipping over insignificant things so they can focus on important events. In these cases we must "fast forward" to the next event and then synch the seconds of our future time with real time.
A serious limiting factor to being able to run in real time or to go fast forward is the processing capability of the computers we use compared to the number of calculations that the simulation requires to be performed per millisecond. Perhaps this sounds familiar to you. It should. It's the old "Realism vs Playability" issue.
Simply put, the higher the fidelity of our simulation, the more calculations required, and thus the more processing capability required. Add up all the calculations for all the processes, for all the components, for all the models in the simulation of a single satellite, and you get a LOT of calculations. This can sometimes overwhelm the best computers.
But for us, "playability" (i.e., processing capability) is not separate from "realism" (i.e., fidelity). If our simulation cannot synchronize with real time, it's not accurate (and our users will definitely let us know). Satellite operations take place in real time, thus, so must training and rehearsals. This is why I always get a laugh when any wargame designer argues that realism is more important than speed of play. In truth, they're BOTH part of the same thing - fidelity.
Even though all simulations are time dependent, there are different ways for simulations to link events to time. This is another source of argument in the simulation community.
TIME DRIVEN VS EVENT DRIVEN
There are two approaches to linking simulation events to time. The first is called "time driven" simulation. In this approach, each time increment (say millisecond), the simulation checks or "queries" all the different models and components to see if they need to have a change of state (see figure 4).
While some in the simulation community advocate this approach, in truth, it's a very inefficient way of doing things. This is so because each of these queries takes time to perform whether or not every component has a state change every millisecond.
Figure 4. Time Driven Simulation
Incidentally, most wargames that I've observed, seem to use this time driven concept. Each turn you check to see if some troops move, then check to see if some fire, then check to see if some test morale, and so on.
In the mod, we use what is called an "event driven" simulation. In this approach, each change of state (i.e., event), regardless of what it is or what model it belongs to, is given a time tag and inserted into the "time queue". The queue is simply a waiting line, like the line you stand in at a fast food restaurant. As each millisecond ticks off, the computer asks a single question, "Is the next event in the queue scheduled to take place right now?"
If the answer to this question is, "Yes," the computer then finds out what that event is, executes it, then immediately asks the same question for the next event in the queue. In this way, all events for a particular time are executed before simulation time increments. Many milliseconds may tick by with no events at all, but as soon as one arrives with events timetagged for it, things start happening (Figure 5).
The strength of this approach is readily evident. No processing time is wasted. Only the things that need to be checked are checked. Also, keeping track of a time queue is something computers do really well.
Figure 5. Event Driven Simulation
If anyone ever manages to successfully implement an event driven wargame, I'll be the first in line to get it. In fact, someone almost pulled off something very similar. George Jeffrey came up with an idea called the "Variable Length Bound" sometime back. Some of his ideas are outlined in an article in Courier issue #85. What he calls a "Future Events Chart" is simply another name for a time queue. Unfortunately, from what I've read, he wasn't able to implement it in a way that was truly usable in a tabletop game. That doesn't mean it was a bad idea, the tools just weren't yet available to implement it.
Sam Mustafa's reasoning that everything, even retreating, takes time has also caught my interest. Sam's point of view on this is somewhat "event driven" I think.
So, if we are able to create a simulation that is accurate (within user requirements), dynamic, event driven and able to run in real time, have we done enough? Not quite. It must be able to produce results that match what we expect, over and over again.
PREDICTABILITY AND REPEATABILITY
We have a motto here in the sim shop, "Boring is good." I wonder how many wargame designers would make this boast for their rules? It's true, though. In our use of simulation (remember, we support test, training, and rehearsal), we don't want any surprises and neither do our customers. Our simulation of any event must have predictable results. Additionally, we must be able to precisely repeat those results as many times as called for. The last thing our customers want is the simulation introducing unknown factors into their tests or rehearsals.
Consider the spin precession. This is a relatively complex maneuver done to tip a spinning satellite to a new orientation with respect to Earth and the sun. Since the vehicle is spinning, thrusters must be turned on and off at precise times within the spin period or else the vehicle will either tip the wrong way, or just end up wobbling.
There are several initial conditions to consider: initial attitude and spin rate of the satellite, starting fuel levels, vehicle mass properties, thruster locations, and orientations, etc. We must also take into account the number of thruster firings (pulses) and the timing that will be commanded. For any given set of initial conditions, number of thruster pulses, and pulse timing, the simulated space vehicle must achieve the predicted attitude target, within a small degree of error. The target must be hit consistently no matter how many times you repeat the simulated maneuver with these initial conditions.
This brings up the question, "If all you're trying to do is consistently match expected results, why go to all the trouble of using equations to define processes? Why not just directly modify the states to achieve the expected results?" There are two good answers to these questions. First, just modifying states (what we call "painting data points") isn't really simulation. Second, if we can define processes in our simulation, and have the results match known satellite performance, then there is a high level of confidence that our simulation will accurately represent events for which the results have not been observed on the real vehicle. In other words, our simulation will be able to predict future events and thus be usable for analysis and training of even more things.
A few years ago, we were helping one of our customers rehearse how to resolve a possible problem with a space vehicle's central processor (its computer "brain"). When the processor "dies", the vehicle loses all attitude control. Half way through the second day of the rehearsal, the same thing happened on the real satellite. The remainder of the rehearsal was canceled while the mission control team hurried off to troubleshoot the problem. The next day they came back and thanked us. Our simulation was so accurate, that they quickly recognized the problem on the real vehicle and knew exactly what action to take. For a simulation engineer, it doesn't get any better than that!
Predictability is true for simulations of satellites, aircraft, or even weather. Even though small changes in initial conditions or subsequent inputs may result in drastically different final results, those results will always repeat if the conditions are repeated. In this limited respect, chess is arguably a better simulation than most wargames. Given the same initial conditions and the same moves made in the same order, the end result is always the same. But then, this is why I seldom play chess any more. Boring is NOT good in wargames.
COMPLEXITY VS SIMPLICITY
Everything I've mentioned so far may make simulation sound like an impossibly hard thing. Well, simulating satellites is hard, but not all simulations are this complex. It all depends on user needs. User requirements are the first things we consider in simulation design. It's a simple question, "What do you want to accomplish with this simulation?"
Consider a simulation used to analyze a waiting line (i.e., a queue). The user requirement is only to analyze queues. It doesn't matter if the queue is in a bank, a movie theater, or a fast food restaurant. In other words, the process that people are waiting for doesn't matter. What matters are things like the type of queue, the possible behaviors of people entering the queue (in terms of when they entered, which line, and so on), and the length of time required for the service they are waiting for. This makes for a simple simulation indeed (but one still complex enough to require a computer).
It turns out, there are two major types of queue, single and multiple (Figure 6). It also turns out that a single queue is always faster, regardless of how many tellers, ticket agents, food servers, or whatever there are.
Figure 6. Types of Queue
This can all be figured out from a simple simulation that accurately reflects only the needed processes and is repeatable for any given set of initial conditions. It also helps that the simulation is simple enough that a computer can run it much faster than real time, thus allowing multiple tests of different initial conditions in a short time.
Other simulations, such as those assisting in analysis of high-speed events, may be required to run slower than real time - sort of a slow-motion replay.
USER INTERFACE VS SIMULATION
You won't see any pewter miniatures or terrain tables here in the mod. It's all numbers. To be sure, our computers can provide graphical displays, but that's largely a matter of what's called "user interface". A user interface, in part, helps humans visualize what's going on and allows them to interact (i.e., input changes to data) with the simulation. User interface is not to be confused with the simulation itself. Once initial conditions are set, the simulation itself can run with complete independence from the outside world.
You may also have noticed that I have made no mention of "scale". This is because everything we do is in one-to-one scale. With the computing power at our disposal, there's no reason to try and do it any other way. There are very few simulations I know of that scale things down. Most of these involve wind or water tunnels and scale models of actual aircraft or ships. These simulations can get away with scaling things down because air and water molecules are so small their interaction with model airplanes or ships is nearly identical to their interaction with real craft of the same type.
Where you will see scale is in the "zoom" feature of some user interfaces' graphical displays. You can zoom in for a close view of the object you're simulating, or zoom out for a wide-angle view. Perhaps you've seen this feature in some computer games.
The inability to "zoom" in or out is a major disadvantage in miniature wargames. Since the size of our gaming tables is limited, we end up shrinking the horizontal ground scale (usually in disproportion to the vertical) to make our battles fit. Of course, as Sam Mustafa points out, this can cause all sorts of problems when we start moving our troops around. All in all, a terrain table full of miniatures is a pretty clumsy user interface. But let's be clear about this, a user interface is not a simulation.
We have two different user interfaces on our simulators. The first includes the keyboards, monitors, and sim engineering interface on our computers. We sim engineers use these to build, test, and monitor the simulation - to see into the simulation's "guts".
The second interface is actually the command control equipment used by our customers. Our simulator outputs what is called a "telemetry stream". This is simply a repeating cycle of ones and zeros containing all the health and status data from the simulated satellite. Our customers' systems recognize this signal and display it on their computer screens. They can also send commands just as if they were doing so to a real satellite.
Most mission control centers don't have fancy 3-D graphical displays of what's going on in orbit. Their computers display cluttered spreadsheets of data. The movie "Apollo 13" is a pretty good example of what things have been and continue to be like in most control centers. As I've said before, this business is all numbers.
Most importantly, though, the folks in the mission control centers have absolutely no insight into the inner workings of our simulation. All they see is the output. As far as they're concerned, the data they're seeing could be from a real satellite. In fact, there have been times when the folks in charge of rehearsals haven't told the operators they were working with a simulation. But, you can be sure the folks in charge know, and you can be just as sure they wouldn't use our simulations if they weren't confident in them.
VALIDATION AND VERIFICATION
"...the quality of simulation is completely dependent on the quality of the information used and how `accurately' the simulation mimics it."
- -- Bill Haggart, "Our Unique Hobby" MWAN Issue #131
I'm originally from Missouri where the motto is, "Show me." The same motto applies to our simulations as far as our customers are concerned. We must be able to prove that our simulations are valid and demonstrate that they actually work.
From the very start, we help ensure the validity of our simulation by going to the right sources of data for our design. Such data includes the precise configuration and mass properties of the space vehicle, as well as all the control logic in the satellite's on-board computer. This data is generally obtained from the space vehicle factory, and comes in "handbooks" consisting of six or seven two-inch thick volumes.
We must also include data on processes controlled by the laws of physics. This, as mentioned earlier, largely comes in the form of mathematical equations. While some of the equations are fairly simple, most others are not. But they are all widely known and accepted as valid ways of describing physical processes.
The important aspect with all this data is that it is measurable and verifiable. When the Orbital Operations Handbook for a particular space vehicle says that the thrusters are in particular locations and pointed in specific directions, there's very little room for argument. These things have been measured to a high degree of accuracy on the real space vehicle. When we build a simulation of a satellite, we are using physical laws and measured properties of the thing we are simulating.
Once built, we test our simulation against data obtained from the real space vehicle. In this way, we can actually measure our sim's fidelity. We test, tweak, and retest until we get its behavior to match that of the real vehicle.
There's one more thing we do to validate our simulation, because (and I think Sam will get a chuckle from this) it must "feel right". We call this a "gut check" or more properly, validation. But for us, the real question is, "To whom should it feel right?"
The first answer is the vehicle technical advisors (T.A.s). These are people who work for the space vehicle factory and have been involved with particular satellite programs for decades. They know everything there is to know about their vehicles and have been involved in every launch and helped troubleshoot every problem. If these folks look at the output of our simulation and say, "That feels right," we know we've done our job.
The second answer is, "We sim engineers." We can have an accurate, dynamic simulation, but it may not be the most efficient possible from the design perspective. All through the design, development, and test process we are checking to make sure our simulation is the most elegant and efficient design it can be. This involves making use of good programming technique and what is called "object oriented" design.
Each component in our simulation is often referred to as an "object". This means that, in computer programming terms, the component is defined in a self-contained manner. Its characteristics, states, and rules for interacting with the outside world are grouped together. An object may be duplicated and may also belong to a larger "class" of objects that behave in a similar fashion. Processes that many objects use are defined once and reused, rather than being defined again and again for each new object.
SO WHAT ABOUT WARGAMES
If you've made it this far, you're probably thinking something like, "GAAAAH!"
If so, well, you're right. This is a lot of stuff to get your arms around. Perhaps you'll have a little sympathy for this poor author. My job's a blast, and I love it. But after a long day at work, the last thing I want to do when I get home is simulate something. I just want to push a few miniatures around on the table and roll a few dice.
But, having come this far, 1 suppose I owe you one last bit. After all, this stuff started with a discussion of whether or not wargames are or should be simulations. As I mentioned at the start of this article, I don't have all the answers. I'm sure you could find another sim "expert" to dispute every point I've made. But let me offer a few opinions
There is, as I see it, a sizable difference in the simulations we build in "the mod" from supposed "historical simulation" games. We base our satellite simulations on verifiable laws of physics and measurable properties of the things we simulate. All of the "historical simulations" I've seen are based on anecdotal information found in history books (i.e., the opinions of historians or observers). But, if you're trying to simulate "real" events, opinions don't make a good basis for the simulation, no matter how many historians you cite in your bibliography.
While some may attempt to use factory data on various weapons, they run into a great deal of trouble when trying to explicitly quantify even a few of the factors involved in warfare. Surely, there must be some physical processes controlling what happens in a battle, but there simply are no quantified "Newton's Laws of Warfare". While there are generally accepted concepts, such as the "Principles of War", we have yet to discover the mathematically quantifiable laws governing battles and the psychology of soldiers.
Let's be clear about this difference. Simulations use quantifiable data and process definitions (equations or logic) known to be at work in the thing they're trying to simulate. Do you know of a single set of wargame rules that does this? I don't.
Wargame rules rather, tend to start with a desired result or pattern and then try to make up a mechanism that will lead to that result. There is little or no actual data to support the process chosen, only data to support a particular end result. If the result is correct, it's assumed the process must be good. In fact, there is not even necessarily a consistent set of controlling processes. States of units are modified to match desired results without regard for process. As I mentioned, we in the mod call this "painting data points".
But, if your process definitions are not consistent with the thing to be simulated, you don't have a simulation.
A better term might be "emulation" or mimicry. It matters not that the underlying processes aren't the same as for the thing to be mimicked, the designer of an emulation doesn't care. It's all smoke and mirrors anyway.
The important difference here is in ability to predict results for which there is no experience or data. Since a simulation models the actual processes that lead to known results given a certain set of inputs, it can be used to experiment with different inputs. There is a reasonable expectation that it will yield results close to the simulated thing's behavior, because it's based on the same laws that control what is being simulated. This is one of the real values of simulation, the ability to predict events yet to be observed.
Another difficulty I see in wargames is in user interface. If our purpose in wargaming is to effectively simulate warfare in some form, why are we using an interface as clumsy and expensive as pewter miniatures on a terrain table? A lot of time is spent painting all those little guys that has absolutely no influence at all on the fidelity of the simulation!
The answer to this is easy find. Wargamers want to see everything that goes on. What we really desire is interactive theater. The players are a combination of spectator and actor while people who design and run games are the directors. You can see them at any convention, the Cecil B. Demilles, the Steven Spielbergs, and yes, even the Ed Woods.
To say that doing historical research and citing our sources will help us have better wargames may indeed be true. However, I think this misses the biggest issue with wargame rules, and the biggest opportunity.
In my opinion, too many sets of wargame rules fail the test of "elegance of design" - that internal gut checking the designer performs to ensure his product is efficient and sound.
This approach is not unique to simulation, but spans everything from computer programming to architecture. It should be a prime consideration regardless of whether or not a game designer aspires to build or use simulation. I've seen plenty of apparently wellresearched, well-documented games that are clumsy, inconsistent, and unplayable.
This is also why I'm such a big fan of Wally Simon's work. In his publication, the PW REVIEW, he has been unafraid to test a game (even his own) to the point of failure and then point out the flaws in its design for all to see. Such honesty is essential if wargame design is ever to improve. This may be a hard pill to swallow for folks who are trying to sell their designs, but, if we can survive with this level of honesty in the simulation world, surely wargame designers can as well.
Can wargames utilize simulations? Sure. But, simulations and games are not always the same thing (If they are what is baseball simulating?). Do current miniatures wargames simulate real warfare? You've got to be kidding. They emulate warfare; mimic it. Could wargames simulate aspects of real warfare? Maybe, but only if more of warfare's controlling processes can be understood. Such a simulation is not likely to succeed on the game table though, without extreme attention to elegance and efficiency of design.
Could wargame rules benefit from the same design methodologies used in simulation? Perhaps yes, because these are the same methodologies used successfully for many other designs. This is why I think some of Bill's arguments are not without merit. We can learn something from simulation design methodology, even if our games are not simulations. I do believe that being a simulation engineer has made me a better wargame designer (tinkerer?) and being a wargamer has made me a better simulation engineer.
Should we be more serious about our wargames and advertise them as historically researched activities? Or, should we just admit we're playing with toy soldiers for entertainment? Somehow, I think there's room for a little of both in our hobby.
In the end, perhaps we shouldn't worry too much about whether or not wargames are or should be simulations. We may do better to ask ourselves what we want out of a particular design and then use whatever techniques best meet those desires.
Like Sam, I personally look for my games to produce a result that feels right to me. I've largely abandoned adherence to scale in favor of perspective. Like Wally, I look for interesting rules mechanisms and then try to mesh them together into a playable game. Like Bill though, I'm not afraid to learn from "real world" design techniques - especially if this helps me have more fun with my toy soldiers.
Back to MWAN # 132 Table of Contents
Back to MWAN List of Issues
Back to MagWeb Magazine List
© Copyright 2004 Legio X
This article appears in MagWeb.com (Magazine Web) on the Internet World Wide Web.
Other articles from military history and related magazines are available at http://www.magweb.com