Designing Computer Games

The Spec

Keep in mind that a computer does what you tell it to do not what you want it to do. Unlike people (some people, anyway) you can't just tell a computer what you want done and expect your request to be carried out. Computers require explicit instructions. These are called computer programs, or computer software. The terms program and software are often used interchangeably.

Programmers make their living by turning someone elses need for a computer to do something into a program that will make a computer do what is requested. The programmer, however, requires precise (or at least unambiguous) directions from the user of the program. In this case the user giving direction is the game designer. These directions are delivered in the form of a "specification" or "spec."

Specs come in many different forms. On one extreme you have many pages of flow charts (boxes of different shape connected by solid and dotted lines) showing which data goes where and does what. These flow charts are accompanied by equally voluminous instructions on how to set up data files (lists of information), what formulas to use and how the processed data should look when it is presented to the user (on the computer screen or printer). On the other extreme you have some verbal instructions accompanied by a few notes scribbled on a piece of paper. My approach to a spec is somewhere in the middle, as I have found that the flow chart approach gets ignored (at least a lot of detail gets ignored) by the programmers while the other extreme leaves the programmer confused and inclined to invent whatever he needs and hope that it's what the user meant.

Naturally, I'm going to push my own personal version of what I think a spec should be, if only because it's a system I have used successfully for many years with dozens of different programmers. I count my approach a success because most of the programs worked well and most of the programmers are either still working for me or at least return my phone calls. What we are describing here is a spec for a computer wargame, any computer wargame.

The spec is divided into three parts.

Input/Output

First comes the I/O (input/output). In plain English, this means what the user sees on the screen (output) and what commands the user can give to the program to obtain a desired result (input). This is often called the "look and feel" of a program. The easiest way to prepare this is to do a mock up on the computer screen. These days, one of the many "paint" programs are used to, literally, draw ("paint") the various proposed screens. Some years ago I used a program called Demo (clever name, eh?) to build screens. The advantage the Demo program had was that you could make the controls on the screen active, to bring up additional screens and similar things. I stopped using Demo when I realized that for my purposes (my programmers didn't need THAT much direction), a much simpler method would suffice. So I just typed up what the input and output screens would look like. Games use more complex screens, often with lifelike terrain, vehicles or people on them. These don't have to be shown realistically, a simple notation will do. The important thing is to let the programmer know what will generally go where on the screen.

When you think about it (it's a good idea to think while specing a program), there are not that many screens involved in most games. There might be a lot of different graphics put on the screen, but this is just popping a new picture on to the same screen. Yes, that's one of the secrets of computer wargame design, move and vary a small number of items to make it look like a whole lot. Just like real life.

Databases

The foundation of any automated model are its databases. There are several database types which must be used in a computer wargame. Their use is similar to the use of this data in a manual wargame.

Terrain- The terrain database can safely follow the conventions used in the manual model, even to the extent of using the same cell structure and terrain information used in each cell. There is rarely any justification for the extreme detail found in many digitized terrain systems.
Order of Battle- List of units to be used in the model and the capabilities they need for interaction with the other elements of the model. Unlike a manual wargame, you can safely use a lot more data because the computer has a lot of capacity to crunch numbers without even breathing hard.
Attrition Tables- What happens to weapons and targets when weapons are used. This is the combat results tables (CRTs). Computer games can use more complex and multiple CRTs.
Terrain Effects Tables- Effects of terrain on units. Effects can be more complex and detailed than in manual games.
Victory Conditions Tables- Goals of units or groups of units.
Supply Tables- Supply holdings and consumption for various units.
Doctrine (AI) Tables- Artificial Intelligence Capability. Rules for unit behavior. SOP's for combat and movement. Tables for command control and panic for various units. Leadership behavior, etc.
Other items- Any other items that the user feels are needed for the model.
Scenario Tables- Specify which of the above items are to be combined into a particular battle situation. Preferably kept in a library (on the computers hard disk) that the user has easy access to with an editor and report generator.

Internal Model Procedures

Otherwise known as algorithms in computerspeak. The manual model does not translate directly to an automated version. Some adjustments and design modifications must be used.

Positioning on terrain- Generally use x,y coordinates system. This is easier to implement on a computer and will give you roughly the same accuracy as the hex based manual models.
Combat activity- Follow a sequence of play very similar to that used in the manual model. Higher speed and automatic operation of a computerized wargame combine to give appearance of simultaneous activity. Operations generally take place in alternating fractions of a second (for each phase in the sequence of play).

Detect- Use sensors to determine if enemy forces are present and/or within range of weapons.

Check for Damage- Can be enemy caused or from operational causes. If Damaged, Physical Effects- Degradation of system performance. Psychological Effects- Modify troops will to continue operations.

Fire or Flee- System analyzes situation. If logic, or psychological effects, dictate, system withdraws from combat. Otherwise, continue.

Record actions in "Diary" Database for report generation.

Repeat Above- Continue until end of time period allotted for operations, or victory conditions specify ending operations.

Victory calculation- Done continuously and with great accuracy, although user may want to see probability of victory at certain points in the run.
Scenario Deployment- Much more rapid than in the manual model. A good user interface allows the player to rapidly explore many aspects of the game with great ease of use and accuracy.
Scenario Generation- Using an electronic library of scenario building blocks (maps, unit organizations, doctrinal SOP's, etc.) the user can quickly build new scenarios or edit existing ones. The edit function also allows building blocks to be created or edited.
User Reports- These can also be edited as to format by the user. The principle items a user would generally require would be,

OB Status- Starting and finishing status of units.

Terrain View- Which terrain configuration was used (Large/small scale via zoom).

Victory Status-What the player is allowed to know, given intelligence constraints and other factors, about how close either side is to victory.

I/O Routines- How to handle interaction between model and user. The user must be able to easily modify the following program instructions. This is done by setting up the routines in table format and programmed to prevent the user from doing anything that would crash the system. If the user does anything unintentionally silly, the system will simply display these actions on the screen, allowing changes to be made and their results observed until the user is satisfied.

Movement-A combination of, historical movement capabilities, based on field tests and experience. SOP's (Standard Operating Procedure) for movement, right out of the book. Limiting factors, primarily psychological factors that don't make it into the field manuals or peace time soldiers knowledge.

Combat- Similar to movement. In this case applies to the servicing of weapons.

Intelligence- How much information of their own and enemy force

does each side have at start and during each intelligence cycle time period. This time period is based on how long it historically took for new information to reach the commander and be acted upon.

Other- As needed.