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.
Overview
User
Documentation
Table of Contents
Chapter 7 Contents