Basic Training

by Tom Hudson

Welcome back to BASIC Training, where we're in the process of writing High Seas, a game based on the old paper- and-pencil favorite, Battleship. So far, we've examined the overall program flow and the format we'll use to store game data in the computer. This issue, we're going to look at the routines needed for the human player: ship placement and shooting.

Where's the fleet?

Obviously, the first routine we should think about is the human player's ship placement. After all, this must be done before the shooting starts, so let's get to it.

Before flowcharting the routine, we should think about what must be done to verify correct positioning of the player's ships.

First, the computer must ask the player to position each of the five ships (destroyer, submarine, cruiser, battleship and carrier). It's a good idea to remind the player of the length of each ship.

The actual placement of the ship can be done by simply requesting the bow and stern coordinates for each ship. In High Seas, the bow and stern terms are interchangeable and are merely used to find the ship's endpoints. For example, in Figure 1, the destroyer's endpoints are B1 and B2, and the battleship's endpoints are E8 and H8. Having the endpoints, the computer can easily calculate the intermediate points. This is also a "user-friendly" way to accept the ship placement data, since the player doesn't have to furnish all the coordinates of each ship.

Naturally, in order for the user to enter the coordinates easily, the computer must accept them in the letter-number format discussed last issue. The letter can range from A to J, and the number from 0 to 9. Any invalid entries must be rejected, and the user given another chance to enter them correctly.

As each ship's endpoint coordinates are entered, the computer must check to be sure the ships are placed on the grid orthogonally. That is, they can't be placed diagonally. In Figure 2, the cruiser and destroyer are placed orthogonally, but the carrier is placed diagonally. This is an invalid placement, so the computer must ask for the carrier's endpoints again.

The computer must also check to be sure that the ship in question will fit between the endpoints. For example, the aircraft carrier, which is five positions long, will not fit between Al and A3, which allows only three positions. Similarly, the destroyer (two positions) won't fit correctly between coordinates D3 and F3, which are three positions long.

The ships can be placed in any configuration the human likes, but no overlaps are allowed. In Figure 3, for example, the battleship is placed from coordinate F3 to F6. If the human attempts to place the carrier from coordinate D5 to H5, it would overlap the battleship at coordinate F5. This is obviously an invalid ship placement, so the human would receive a prompt to enter the carrier's coordinates again.

As long as the ships do not overlap, there are no restrictions on ship placement. Figure 4 shows one possible setup, which is rather unorthodox-and invites disaster. The ships are so close that a near-miss on one ship will almost certainly hit another. Feel free to use such ship placements with High Seas; my artificial intelligence routines are equipped to take ruthless advantage of such tactical flaws.

Well, that takes care of the conditions well have to take into account when coding the human's ship placement subroutine. Figure 5 shows a detailed flowchart of the logic needed for this routine. Note that the mainline code sets certain parameters for each ship and then calls the subroutine, which accepts placement input and verifies its validity.

If you look at ANALOG Computing issue 23's BASIC Training, you will see that the flowchart in Figure 5 was shown as a single block, labeled "SET UP PLAYER'S FLEET." We've simply looked at the same process in greater detail, as if we were looking through a magnifying glass.

Commence firing!

Now we come to the heart of the human player's routines, the one which allows the player to shoot at the computer's ships.

In the original Battleship, each player called out a single grid coordinate. The other player would call out "miss" if the shot missed, and "hit" if the shot hit a ship. Once all the positions on a ship had been hit, the ship was considered sunk, and the player who owned it informed the other player which ship had been sunk. Once one player had lost all of his ships, the game was over.

High Seas uses the same rules, except that the computer will act as referee, automatically checking for destroyed ships on both sides.

For the human player's shooting routine, there are only two important restrictions. First, the shot (given in standard letter-number format) must range from A to J in the letter portion and from 0 to 9 in the number portion. Second, the shot must be fired at a coordinate which has not been shot at before.

Last issue, we mentioned CG0 (the computer's ship placement matrix) and CG1$ (the string which holds shooting information for the computer's ships). The human's shooting routine will affect these data areas, as shown in Figure 6, the detailed human shooting flowchart.

As you can see in Figure 6, each position in the CG1$ string is used to record hits and misses (see last issue's BASIC Training for more on this).

If the shot was a hit, the computer finds out which ship was hit and adds one to a damage counter. Then, depending on the ship's length, the computer checks to see if the ship has been hit enough times to sink it. If so, a "sink counter" is incremented and checked for five sunken ships. If five ships have been sunk, the game is over-with the human winning.

So far, we've looked at the human side of High Seas and have seen how the human can win. Next issue, well start looking at what the computer will do to defend itself. And it won't be a pushover!