Chapter 3 - Why Play the Games - Information

  Why Play the Game
    
(and how to get the most out of it)

Information

The Geography of Wargames

The geographical information is usually obtained from a playing map, assuming that the game has one. Most do. Even those that don't have one often require that the player construct some type of playing surface. The Order of Battle is nothing more than a list of the units or entities that took part in the original event. The situational information is the scenario, that is, the set-up of the forces, the conditions of victory and any additional factors such as the state of the weather, etc. The dynamic potential information in a game represents the players' perception of the first three information elements in light of where they may go. The first thing a player generally does when he obtains any game is to lay it out and quickly digest geographic, Order of Battle and situational information. Computers have yet another advantage in this area in that a player can even more quickly take a look around, although computer wargames also hide a lot from the player.

Once the game is given a good looking at, the player then obtains what he is really looking for, the dynamic potential of the game: where the game might go, and what it might do.

There are certain things the gamer should be aware of when he attempts to obtain information from a game. We tend to look for more in a game than is there. This is rather typical of most people's relationship with printed matter. The attitude is "if it's in print, it must be right." Computers compound this because you can't even read the print carefully, the computer does some mumbo jumbo inside the box and gives you an answer based on who knows what. Without casting too many aspersions on my work or the work of others, I would like to offer the following cautionary advice when you are examining games.

Geography, as with most things, is very much subject to individual interpretation. There are two primary things to keep in mind when examining a geographical game map. First, it often has a grid, most often a hexagonal grid, superimposed over it. This means that each "cell" of geographical information is at least the size of a 16mm (diameter) hexagon. The normal "cell" of information in a traditional nongame map is normally smaller than a tenth of a millimeter (if you look closely at a map under a magnifying glass, you will see the little colored dots which the printing process uses to show where the water stops and the land begins). The second point is that in most historical situations, only very large ("gross") terrain features had any significant effect on operations. Thus, a great deal of detail on a map will often get in the way of providing an accurate simulation. The designer usually feels obliged to justify all of this detail. Often the gamer will be equally expectant that all of this detail be put to some use or otherwise why bother him with it. There is an unspoken assumption that only that which is essential is displayed. It is normally considered a bad design if information is included in the game that does not contribute to one's understanding of what is going on.

Given these two points in geography, it should in most cases be fairly easy for the game designer to represent the key geographical elements. The gamer should be aware that, if he is sufficiently well read in the subject of the game, he should expect that the geographical elements spotlighted in the written histories should also be represented in the game. If anything, the game will, in addition to confirming the importance of a particular piece of terrain, also show in more detail why the terrain was important. It is often the case that the game will show another element of the terrain that could have been important, but because it was not used, was not important in the original battle. An example of this is the Ardennes region of Belgium in 1940 and 1944. In 1940, the Germans dashed through the Ardennes with motorized forces, crossed the Meuse river and proceeded to cut off the bulk of the British and French armies in Belgium. In this case, the Ardennes was not an obstacle, although it certainly could have been. This was proven in 1944 when the Germans again attacked in the Ardennes, but this time they were not able to move right through because American forces were already there and fought tenaciously even though outnumbered. The Americans eventually stopped the Germans cold. Any historical simulation on the 1940 campaign would have to allow for the realistic possibility of the Germans being stopped in the Ardennes and then suffering the disadvantages of having to attack through that particularly rugged terrain.

Most designers, when they are dealing with terrain, go to one  or more maps and do little more than place a blank hex grid over the map, shine some light behind the map and the hex sheet and then trace the terrain features, making decisions on the spot as to what to include and what not to include. The only other decision is to make sure that the terrain is unambiguously distributed in the different hexagonal "cells." These terrain analysis decisions are made on the basis of historical experience. It takes a little practice, although looking at existing games and historical maps of the areas the game represents, will help.

The game designer then plays the game with this hex grid map. If it feels right and he does it right, that's your map. Often, additional detail will be added purely for historical interest. These details may be things such as additional town names that were mentioned in most historical accounts or the names of other geographical features that either do not necessarily need names (the names of forests or mountains) or might be useful for the player as points of reference when playing the game.

Computer game designers generally use a scanner to copy the details of a paper map into a computer file that can then be edited to show what the designer wants to pop up onto the screen. Before scanner technology matured in the late 1980s, the programmer would painstakingly build a computer map with a "paint" program. The source would be a paper map, or even a wargame map on the same subject. Many computer game maps either use hexes to regulate movement and position (just like paper games). If the hex grid is not shown in the screen, it is implied. Some games give you the option of showing the hex grid or not.

The thing to keep in mind is that the game designer is not God. The game designer does not create terrain. He is merely supposed to represent it on paper. If he does it right, it will seem right to the player. If he does it wrong, you will sense this when you look at the map. To give you a better idea of the various ways terrain can be represented on a map, take a look at the Metz game map included in this book.

Order of Battle

Order of Battle information can also do with a bit of scrutiny on the part of the gamer. As with the game map, the Order of Battle information must be "aggregated" a bit. As with the map, the scale of the game determines how much detail will go into the Order of Battle. The larger the scale, the more similar all of the units become. On the lowest scales (tactical) a much larger amount of differentiation among units is usually necessary. No matter what the level, however, not every specific unit will be likely to show up in the game as an individual unit in the game. This is usually done partially for reasons of realism and partially for reasons of playability. Many small or otherwise functionally insignificant units are not necessary to the play of the game and thus the designer will not include them. If there are a number of such minor units included in the game, I would consider that to be sloppy design since they will get in the way of play, depriving the player of the ability to learn from the game. A great number of insignificant units has a direct effect upon playability and it is often a sign of good design when the number of playing pieces is kept to the minimum necessary to accurately represent the situation without unduly compromising historical information. Often, an effective compromise is to print a detailed Order of Battle in comparison to the actual Order of Battle used in the game.

Computer wargames have more options in this area. If the game has good Artificial Intelligence (AI), you can have a lot of small, but historically accurate, units running around. Good AI will relieve the player of the burden of telling each unit exactly what to do at all times. For example,

good AI would enable you to order a dozen or so related units (say, all the battalions of an infantry division) to attack in a certain direction until an objective is reached or a certain level of losses are taken. The AI would then apply tactics appropriate for the troops you are commanding and carry out the orders. You could then go on to the next group of battalions or attend to some more critical aspect of the game. Not all computer games have this feature and a major drawback of many computer games is trying to force the player to spend a lot of time dealing with many individual units.

The Order of Battle included with the Drive on Metz game is pretty representative of what you'll find in most games.

Situational Realism

Situational realism is pretty straightforward. Once the game provides the geography in the form of a playing map, the units involved in the form of playing pieces, any player can (and some do) create the situation (game) from the written sources. In other words, at this point the player could just open a book on the battle and use the game map and playing pieces without even looking at the game rules. Many players do this. Computer wargames have had to cope with this situation also (aside from the problem of computer users not wanting to read instruction manuals).

Many games, especially the smaller ones, have but one scenario and that is represented by the instructions for the game's one and only set-up. Any "what if?" activity on the part of the player is expected to come out of the actual play. As with any historical game, the players may start out as the original participants did, but rarely will they make the same moves as the historical antagonists and equally rarely will they come up with the same precise historical outcome (although often the side that won historically will usually win in the game). A more diligent designer will provide additional scenarios each of which will expand upon some aspect of the situation that could have easily been different. Often, there were additional units for either side that could have been present at the battle or units that were present that might not have been there or might have been present in different strength for the historical battle. In addition, units may have been deployed differently. All of these elements should be included in a scenario. The scenario section is also a good place to display a lot of purely historical information. See the Drive on Metz rules for a sample of what a scenario looks like.

Dynamic Potential

The dynamic potential of the game is the sum total of the players' overall perception of the game, particularly after examining its main elements. The rules are often fairly standard. This rules standardization is a common convention among designers, primarily to make it relatively easy for the gamer to play (and the designer to design). Each game does require a certain amount of special rules that will cause the player to expend a certain amount of energy to absorb. Computer wargames follow the same pattern, with similar sets of commands and menus used in a great many games (often from the same publisher, or designer).

"Reading" games rather than playing them is quite common. Always has been. Many gamers "collect" games. They buy them, but never play them. This does not mean that they are not used. Quite often, the hobbyist will spend several hours with the game. The usual procedure is to lay out the map, examine the pieces, read the rules and scenarios and perhaps place the pieces on the map, but that is generally as far as it goes. The player has been satisfied with experiencing the dynamic potential.

By dynamic I mean how and to what limits the various elements of the game may be manipulated. Every historical situation has this dynamic potential. Most history books or films are presented as a linear rendering of what went on, so there is no potential for exercising this dynamic. A game, of course, is just the opposite. Its elements are meant to be exercised and a player will often do this in his head with the aid of the game components.

In terms of player interaction, there are three types of games: the one or two-player game (by far the most common), the multiplayer game and the role-playing game. Each of these has a different dynamic potential. What I spoke about above was primarily the one or two-player game. The multi-player game has a markedly different dynamic potential in that you are not only playing against a historical situation, but also against a group of individuals. This group (three or more people) creates a dramatically different dynamism in the game as the individuals are less restricted by the game situation because so much of the activity is dependent not on the game system but the cooperation of one or more of the other players. For this reason multi-player games tend to be essentially simpler in their mechanics than the traditional two-player game. There are very practical reasons for this.

Since more people are playing, the sequence of playing for any individual causes every one of the other players to wait until that sequence is finished. If the total time it takes for every player to get through his sequence of play is too long, most players will lose interest. This is not to say that realistic multi-player games are not available. It is just that the dynamic of the game is against it. Thus, the dynamic of an individual gamer examining a multi-player game is normally considerably less than that of a two-player game. This is not the case with multi-player games played on remote computer systems like GEnie, private BBSs (Bulletin Board Systems), Prodigy or Compuserve. As these games are computerized and player actions (nearly) simultaneous they are quite lively and addictive. The down side is the price: six dollars an hour and up (except for some games on Prodigy, which has a low flat monthly fee, but has a dismal selection of offerings).

Role-playing games, on the other hand, have considerable dynamic potential when viewed by an individual player. This is one reason for such games' popularity. Most role-playing games to date, however, have been almost exclusively fantasy or science fiction in nature. This is mainly because the first successful role-playing game published (Dungeons and Dragons) just happened to be based on a fantasy-type situation (mostly the medieval influenced Middle Earth world created by Tolkien). The essence of the role-playing game is that one player, the gamesmaster, does most of the work. The other players have a relatively simple "menu" of activities in which they may partake. These activities are generally restricted to movement and responding to whatever the gamesmaster throws at them. The gamers' responses take them into rather extensive rule booklets which consist primarily of charts and tables. The charts and tables, as any charts and tables, are crammed with information. An appropriate analogy would be a class in auto mechanics in which the instructor, using a demonstration engine, continually made certain components of the engine malfunction and then challenged the students to go through their manuals as well as their previous experience to come up with the most efficient solution to the problem he had created. Historical role-playing games have been tried. In 1979, Commando and NATO Division Commander were published. A few other followed in the 1980s. The RPG concept applied to wargaming subjects never really caught on. There are some military oriented computer RPGs, with more in the works all the time. But, again, fantasy beats reality in the market place even when a computer is used.

prev.gif (1183 bytes)  Chapter 3 Introduction

next.gif (1198 bytes)  History


  Table of Contents

  Chapter 3 Table of Contents