Though few game-players have access to computers or familiarity with programming techniques, the third-person or "judge" concept is known to most boarclgamers. The coordination of hidden/simultaneous movement, the execution of player-prepared combat instructions, the keeping of accurate records, and the general regulation of play according to game rules are all functions of a third-person, implemented at microsecond speeds by computer programming. The machine becomes a playing tool rather than an opponent - as many try to program in the case of chess-playing computers.

Naturally, the more complicated a game you play, the more sophisticated an instructional package required. This "package" or "program" must specify EVERY detail which the machine is expected to monitor since computers do nothing for which they have not been previously programmed or built to do - many are not built with the ability to multiply or divide, for example.

The simplest, most habitual item of play will require careful attention otherwise it will not be noted in the programming and will not be accounted for in the operation of the machine. Thus the initial work may be quite extensive but the product will eliminate much confusion and error plus allow face-to-face play between two or more players using many desirable simultaneous rulings without undue paperwork.

But such preparations do not exclude the gamer unfamiliar with data processing as much program development comes before actual instructional work can begin. Programmers refer to the process by which the actual job of the program to be written is listed in plain English as "systems analysis" and such specifications are often handed to the data processing departments by those generally uninformed about actual program. A job must be done and someone determines what this job requires, passing along these requirements to programmers who develop computer instructions to carry out these specifications. This work is ideally suited to the person who will use the program though not necessarily write or test it since programs and data processing departments are generally the servants of departmental needs outside programming.

The job of a good program or data processing department is to make the work of other departments easier. This is the exact attitude with which I approach the subject of game-playing using computers even given the "practical" objections to everyday use of such an idea by most game enthusiasts. Even if you never get !he chance to use such a program, the details of planning one should teach one quite a bit about game design in general and the operation of the human mind.

The actual programming consists of drawing a step-by-step diagram of the logical flow of the program - flowcharting - then a use of a specific symbolic "language" to transfer this pattern into instructions for the machine. The "coding" is then transferred to punched card formats and run through a special program which assembles the symbolic language into machine-language (binary patterns of electrical circuitry), checking it for proper formatting and certain general instructional rules. Once this is completed, the program is tested using data prepared to check all possible branches within the program (plus any error conditions for which the program is designed to test - illegal card formats on data being fed into the program, for example). Only after all this is the program ready for actual use an intended by the original specifications. However, as only the systems work will be of immediate interest and value to most gamers, there is no need to go deeper into the charting, coding and testing of programs; for the systems work on a wargamers program will more than suffice to illustrate the work required to develop such an instructional package.

First of all, a game to be played must be decided upon since there is no guarantee that we can develop a compact progrim to use for all boardgames - why this is true will become evident as we investigate the requirements for a program of this nature. For the purposes of this article, choose your own game favorite and merely try to apply the ideas I am about to present to it as the procedures for ANY program will remain the same even if the program does not.

The areas of major concern will be: conversion of the gameboard into machine memory locations to keep track of the position of playing pieces; identification of playing pieces and their various factors; records-keeping procedures; instructional patterns for executing the rules of the game such as movement and combat; decisions as to what paths to follow if illegal conditions arise; methods for entering player instructions during the play of the game as well as reporting game conditions to players such as troop losses, discovery of enemy positions, etc. All of these will have to be identified and stored using alphanumeric codes (letters, numerals and special symbols such as: *&#@?!+'%$~/ generally numbering about sixty-three characters in all).

PLAYING BOARD

Generally some sort of grid system is available in a boardgame be it hexes or squares-where there is none, one should be developed but this will, by its very nature change the game to some extent. Assuming we have such a grid, it already has its own letters and numerals which identify the horizontal and vertical or diagonal rows of squares, etc. Simply refer to each square in the machine by its board grid identification - AN or BB5 - thus transfering from board to machine and vice-versa will be facilitated by similarity of reference points. But the physical board allows units to be stacked up and their factors are plainly visible to the naked eye. A machine does not afford us this convenience, so space must be left in the machine to allow stacking and identification of units and their factors. That is, one physical square may require many machine locations to allow storage of information which we see and (as I noted would be the case) take for granted. But this will depend on the size of the memory and the decisions made for storing information about each side's forces, i.e., you may choose to refer to a table of units (your Order-of-Battle) which has been loaded into the machine rather than actually reserve lots of space in the machine for playing board space.

In this way, the number of locations needed to identify a playing surface hex or square will be equal to the number of units you can theoretically stack there times the number of locations needed to identify ONE unit. The difference becomes more apparent with more knowledge of programming, but the general concept of retaining space for such things should be clear enough.

Once this is established, you will want to allow a few more locations per hex to identify terrain within the hex since there is no directly ascertainable means of doing this without a code of some sort which the machine can utilize. For example, you might allow one location/hex for each type of terrain possible for the game, then plug in a mark to indicate such is present in the hex, i.e., if you have seven types of terrain factors, you will need seven locations. However, a "cleaner" method would be to use one location and merely develop codes which identify COMBINATIONS of terrain, e.g., let us say that rivers, woods, roads and cities are coded 07, 14, 64, 77 respectively BUT a combination of two might be a 52 or whatever else you may decide that woods and river OR roads and city may mean. You are limited by the number "63" in all single location codes since there are sixtythree possible codes for one location - to divert for a moment to explain: due to the technology of a computer, binary arithmetic is used and 6 "bits" or electical sensors represent one location so that if all are "on" we have the binary number 111111 which equals 63 - this is then broken down into two groups of three 111 111 which represent the numbers 4 2 1 so that if all are on a binary 63 becomes a code of 77 or 4 + 2 + 1 and 4 + 2 + 1 (a 54 code is 101100 where 0 is off and 1 is on).

This however is more the concern of coding than systems work, however, certain limits do exist - you cannot demand one location to be able to hold more than 63 different codes as we have seen AND all specifications regarding reservation of memory for playing board use means that these areas cannot be conveniently used for anything else - a complex game will undoubtedly mean a need for a larger memory capacity.

PLAYING PIECES

As mentioned above, a code for each piece is probably the best way to identify it in the machine as it is the best way to play-by-mail. In fact, thinking of play-by-mail requirements is the best way to envision the needs of a computer play (though the latter will still be more complex). In PBM you must be rather accurate and specific and must give locations for all units which move - in more advanced games. actual paths of movement may he used and combat alternatives may be included.

But essential to all PBM is an Order-of-Battle sheet which lists all available units - this may have to be reproduced within the machine with several locations for recording combat and movement factors as well as unit identification and any special unit options within the rules. Such basic identification can be about the same as the units probably have as physical pieces, e.g., a French cavalry unit of regimental number 85 (say a Napoleonic game and make it a cuirassier unit) might be identified as FCU85 for French Cuirassier unit 85th Regiment. Then the locations for movement factors, etc. can be planned BUT remember that ALL information about each unit must be stored if you expect to call upon it during the game.

Even though you have the pieces stored in the machine, you and your opponent will need boards in front of you to keep similar track of positions as the machine reports each turn's results. We are still considering the machine as just another tool rather than expecting it to be an opponent - perhaps an impossible expectation with today's technology.

RECORDS-KEEPING

What do you wish the machine to keep track of? Answer this question and you'll have this part of your planning solved. But losses and playing positions seem to be the minimum as you cannot get along without knowing what units you have (and how strong) plus where they are on the board - although an interesting option might be to delay this information from turn to turn if you assume each player is NOT a direct commander of each unit and is directing a large-scale operation from some distance. It may be several turns until actual details of the previous turns arrive at "Headquarters" and such lapses of time can be simulated by storing up such reporting procedures until a certain number of game turns have passed - the machine can keep track of this, of course.

Perhaps losses can be kept track of in the space reserved for OB information but you will want some separate storage for reports to you (unless you desire full OB reports every turn or so). Thus you see how the simple fact of knowing where things are and what they are worth takes up a good deal of space within the machine apart form instructions to the play of the game.

REPORTING RESULTS

Along with the above records is, as mentioned, reports of what has happened to the moves and combats you have initiated. If you are using simultaneity, you will want to know how the comparative actions of you and your opponent faired. For example, you may decide to allow information about enemy positions only within certain distances from your own units - this can be accomplished by the machine but it requires a good deal of programming to identify an enemy, record its distance from your units, decide whether it is "seen" or not and then have the machine report its position (and possibly strengths, too) if it qualifies. The formats of these reports must also be developed and space reserved for assembling each line of print, e.g., say a machine can print 132 characters across a sheet, then you must reserve at least one location for each character wide you want you print line, filling this area with data, printing a line, filling it with the next line, printing, etc. - also leaving instructions for skipping to the head of the next sheet when you reach what you wish to be the bottom of the page. But the idea should be plain enough, the machine will NOT tell you what is is doirig unless you allow for this in the program itself.

INSTRUCTIONS FOR PLAY

Here we come to the most complex part of the program and planning: converting game rules into machine operations. This is very much a programming problem, but the pattern of play must be established and rules must be set down for reactions to certain game conditions, e.g., what if you have two units moving to the same place on the same turn - do you allow enemy units in the same hex OR do you allow one side to have the instantaneous edge and alternate this edge every turn in a random fashion OR do you even allow friendly units to move into or through certain friendly held areas? These are game rules which the systems analysis must present for planning by the programmer - to carry an example out a bit further: perhaps you could allow a person to select the order in which he wants his moves made, then have them numbered, then have these orders executed in staggered fashion - one by one player then one by the next, etc. until the moves are completed.

This example illustrates how you can emphasize a player concentration on certain areas of the board even while his opponent may have the edge in movement for that turn - if the edge doesn't help him guess the important battle areas, and it can't, then it is almost unimportant in the largescale operations of the game for it can be overcome by alternating the edge each turn and by planning carefully for this. Such an edge is, overwhelmingly present in a game without simultaneous movement but the computer gives us such simultaneity and helps limit such and helps limit such luck factors, replacing them with strategic and tactical skills on the part of the players involved.

Instructions will probably be entered by means of punched card formats so codes will have to be established to represent these instructions - perhaps one card per unit moved or ordered into some combat situation or combat condition (if it does not happen to be moved). Along with this will be the need to update instructions in the machine for what to do with a unit which is attacked if it has not been directly ordered on that turn - such contingency planning can be located in memory within the aras reserved for identification of units and their factors (considering these sealed ordeis (codes) via cards as the game progresses). A unit without instructions may have to follow preprogrammed rules, known to both players, of course - but this is understandable and only logical though you may program the machine to stop and indicate such an "error" or oversight exists and allow instructions to be entered (without telling the player TOO much about what faces his unordered unit). Many possible ways of handling these problems can be considered - this is a prime example of the concerns which systems work for such a program demands.

Thus, you can see the wealth of non-programming work which exists - though the programmer does his own systems work as he makes an overall plan of attack for translating these finished specifications into machine executable instructions.

Admittedly it seems like lots of preparation for what amounts to seconds of work (even minutes of work when playing without the machine). But the program is able to handle all contingencies (or should be) so you are actually trying to plan a series of instrucitons for allowing the machine to react to any situation (legal or illegal) which might present itself because of the deliberate or accidental actions of the players - the machine even has to double-check the players to be sure they have entered legally coded information unless you wish to risk complete blunders and machine failures due to irrelevant data or data outside the range of the program.

But once the program is operational, you can count on a complete turn of almost ANY level of complexity taking up no more than a few seconds of machine time. What will still take time is the process of each player's decisions as to what he will do (then the coding of these decisions onto cards - off course, this can be speeded up by precoded cards for predictable situations).

Imagine being able to carry out the moves of a game and record all that is happening in under 20 seconds! A full game in machine time could take no more than 10 minutes (for thirty turns) and the fewer the pieces involved, the more comprehensive the instructions and the more the machine can be left to decide. Human intervention between major decision- making will be radically limited - eventually you will be thinking about designing a game meant to be played on a computer exclusively simply because the time to play it physically would be prohibitive. But in the meantime the time spent in coding instructions to the machine (longer than instructions to a judge perhaps and only perhaps) will be more than made up for by the time it takes to actually make the moves and carry out the combats and report the results - all of which are micro-second machine functions.

Again this use of a computer (any for that matter) may be impossible for most game-players to attain but I feel it is more than interesting theory. It is a possibility for some if not for all, and the systems work alone can be a valuable training exercise in accounting for all variables in a game - planning ahead as the machine requires you must, will sharpen a player's ability for physical face-toface play without a machine and it will undoubtedly make one a better PBM player - given skill in the military are of boarclgaming as an obvious requirement since understanding programming or systems work does NOT insure you understanding play of a game or vice versa - they are mutually exclusive activities which I have tried to begin to unite by presenting those who have the playing skill with some understanding of the programming skills. Who knows, if enough interest can be generated, we might be able to start a small group of programmers and interested players and actually develop such a program as I have been describing only in very general terms. 1, personally, would be most interested in hearing from anyone so inclined and 4uite willing to expand upon the technicalities, as I see them, of such programming through more articles or personal contacts.