Game When You See One
Data Structure
atively easy to understand, and the data representation of the board and pieces makes good sense.
For a hand/eye game, we'd have to take a lot of time to explain complex shape and animation routines that have little to do with the design of the game itself. In an adventure game, the data structure is more intricate, since part of the fun of these games is that the struc-ture of the puzzle is not immediately obvious. In both hand/eye and role-playing games, these complexities can distract from the real heart of any game: the evaluation procedure that selects the program's move and interprets your response.
Every game has a data structure, a way to communicate with the user, and a procedure to evaluate which moves to make. These correspond to the aspects of a game as it is played; different games emphasize different parts of a program. An emphasized data structure may reflect position or strategy; a high amount of communication pushes the hand/eye coordination aspect; and puzzle-solving emphasizes the evaluation of the user's moves and the program's selection of its own moves. They are the same ingredients in all three instances-just mixed differently for the different types of games.
The challenge to a game designer (or any programmer) is to create a data structure that accurately represents the field of play, moves, and program status, and that helps the program run smoothly with a minimum of code.
The Go-Moku program, for example, builds up the variable Board from three simple elements:
const N = 19;
type
Boardtype = (Empty, Cross, Nought);
Indextype = 1 .. N;
var
Board: array[Indextype,IndextypeJ of Boardtype;
Translated, this means the board is a 19 x 19 grid, where each square in the grid may hold the value called "Empty," "Cross" (X), or
"Nought" (0).
It takes a great deal of thought to design good data structures. In Turbo Bridge, for instance, we'll see that we have two problems to represent: the cards that the players actually have, and the cards they claim they have through their bids.
Evaluation
User Interface
Data structure is the logical organization of information about the board, playing pieces, the moves, and winning or losing. For example, in a chess game we might have a record variable for each square on a chess board, like this:
Square = record
Piece : boolean;
King : boolean;
end;
Then we could create an array [1..64] of type Square, and be able to track whether any particular square holds a piece, and if that piece is a king.
Depending on whether our program can make efficient use of this particular data structure, it might be a good way to organize a chess game.
The heart of any strategic computer game is the evaluation function.
This is the part of the program that examines possible moves, weighs them against a set of rules for good and bad moves, and selects from among them.
The ability to look ahead, or search, is crucial to strategic computer games. Three different search techniques are used in Turbo GameWorks.
• In the Go-Moku program, we use no search, and instead rely solely upon the evaluation function. This method is simple, but the eval-uation function must be very reliable for it to be effective.
• In the Chess program, we use a brute force search, which means that we analyze all possible moves to a fixed depth.
• In the Bridge program, a brute force search would be too time-consuming. We therefore use a selective search, which means that we analyze only some of the possible moves. Deciding which moves to analyze can be difficult; designing a reliable selective search can thus be a challenge. The Bridge program also shows how to handle unknown information (for example, when each player knows his or her own cards but not those of the opponent.) User interface is an element that every game designer must consider to make a game interesting to play. Admittedly, you can write a chess game that prints its moves out line by line on a printer-but it's far more entertaining to draw a board on the computer screen and move the chess pieces from square to square as you watch. A good user
And They're
Off!
interface will allow the user to concentrate on the game rather than on communicating with the program.
The screen 110 in Turbo Gameworks is a compromise between the delightful and the expedient. You can display Turbo games on any IBM PC monitor, with either a monochrome or color card installed.
Game pieces are represented as text characters instead of in graphics.
This is especially apparent in the Turbo Chess game.
Because of the nature of strategy games and the importance of the evaluator functions, Turbo Gameworks spends a minimum amount of time (and code) on 110. In every Turbo game program, however, 110 is handled in an easily identifiable section of the program. If you want to modify Turbo Chess, for instance, to display graphic chess pieces, go right ahead. Turbo Graphix Toolbox may help you there.
A game may be simple in concept and complicated in programming and execution; or it may be complicated in concept but elegantly simple in data structure and evaluation function. For a person who enjoys discovering the internal logic of games, Section II of this man-ual should help you understand more about what makes Turbo Games tick. For the person who just wants to play-you can simply read Section I and start playing!
Go-Moku Rules
Let's take a look inside the Turbo Go-Moku program. Besides letting you in on our program design, this chapter will help you develop chapter takes the Turbo Go-Moku program apart module by module.
A computer program cannot real~v think on its own; you have to tell it exactly what to do. But you clearly cannot tell it what move to make from every possible board position; even in a deceptively simple game like GO-Moku, the first five moves can be made in 5,962,870,725,840 (that's five trillion) different ways! So if each series of five moves were to take up, for example, twenty bytes of storage, we would need a 100 gigabyte machine for our program - more than the storage capacity of a mainframe computer. Clearly, we must give the program some general rules of thumb that can be used in every possible situation. Deducing the rules of thumb is the first step in intersection next to those four is empty, the program should place a piece on this open grid intersection. This prevents the opponent from winning on the next move. It appears that the first rule is the most important of the two, because it is better to win than to simply prevent the opponent from winning.
What else can we think of? After you have played the game a number of times, you will probably notice the importance of an open 4. An open 4 is four pieces in line, with empty grid intersections on both ends. No matter where your opponent places the next piece, a 5-in-line is inevitable on the following move. Just as powerful, but occur-ring less frequently, is the combination of two different 4s, each with one available empty grid intersection.