Aiming the Cannon - COMPUTE!'s SECOND BOOK OF

But you still haven't decided how to aim the cannon!

Rotation seems like the way to go. Could you rotate the cannon so it can be aimed in any direction? Maybe. But why not just use the joystick to choose one of eight directions, and fire by pressing the fire button? Wherever it's pointing is where it aims. It will take only a little trial and error for the player to learn to aim fairly precisely. However, rotating cannons will mean we have to have as many different cannon shapes (eight, to be exac't) as there are possible directions to aim. Every decision has a cost.

But wait a minute. In the real world (remember, this is partly a simulation) cannoneers also have to determine range.

They control range by deciding the elevation of the gun and changing the amount of gunpowder in the charge. You could control that by . . .

.

Forget it. This is a game, not an artillery textbook. If you're a cannoneering purist, you might want to go through the agony of programming all the math. But you'd better find another purist to play it, because the game will be complex and slow. As far as I'm concerned, I'll let an imaginary cannoneer figure the elevation and charge. As long as the player selects the correct horizontal aim, the cannonball will automatically go just the right distance. Another victory for the simple approach.

Movement

There are other play mechanics to worry about. First, the movement of the enemy ships. Do they stay in the same place, or do they move around? Do they always appear in the same locations every time you play, or are their positions randomly chosen?

There are many different options, but my choice would be

I

this: The program will define twenty or so areas, each of which might hold a ship. By defining these areas, you can be

sure none of the ships will overlap. However, you'll start with

P

only five enemy ships. The program will randomly decide which areas should be used to produce an arrangement that's

slightly different from the time before. That will help keep the

I

game interesting and challenging.

If you were programming in machine language, it would be a simple matter to assign each ship an individual course around the castle and then let it move in a regular pattern. At machine language speeds, you could keep a dozen ships moving without slowing down the game. In BASIC, however, each individual ship movement would slow things down. And since I just decided this will be an all-BASIC game, you can't have the ships move.

At least, not constantly. Anything that happens constantly adds to the amount of time that passes after the program has checked for the player's instructions and before it checks again.

The less often the program checks for the player's instructions, the slower and less responsive the game will feel. Too much of that, and it isn't a fast-action game anymore!

But you can have occasional movement of the ships, and the story provides a perfect excuse. The current of the river always pushes the ships downstream, but as the tide flows up- river, the current moves the opposite direction. The tide flows twice each day, once in the daytime and once at night. When the tide flows, the ships swing around so they are on the up- river side of their anchors. When the tide ebbs and the river's current takes over, the ships swing around to the downriver side of their anchors.

That means that half the day all the ships will face one way, and half the day they'll face the other. It's a simple change, but it adds to the completeness of the milieu. It sup- ports the story, and it adds to the realism of the simulation.

Controlling the Boat

In a two-phase game like this, it's good if the two phases can be controlled in a similar way. For instance, you can let the same key that rotates the cannon also rotate the boat. Press the Cursor Left-Right key and the boat rotates counter- clockwise. Press the fire button, and the boat leaves behind a mine.

2 2

That takes care of directions and mine-laying, but what about movement through the water? You need a third control, to give the boat speed. We could steal a page from Joust and let the oars move each time we press a certain key-the space bar, for instance. Each time you press the bar, the boat surges forward a little ways in the direction it's pointing. If the boat is going against the current, the surge is weaker; if it's going with the current, the surge is much greater. And if you don't row at all, the boat will drift in the direction of the current. If the boat leaves the screen, it's gone.

That's one solution. If I was working in machine language, it's the one I'd probably use. There is a simpler choice, however. You could use a joystick throughout the game. Dur- ing the cannon phase, pushing the joystick in any direction makes the cannon rotate, and pressing the fire button makes it fire. In the boat phase, however, the boat moves in the direction the joystick points, and keeps moving in that direction as long as the joystick is pushed. The button lays mines.

his

has the virtue of being simpler; also, since the boat can only move in either four or eight directions (depending on whether you allow diagonals) you need to have only one boat shape for each direction. Thus, programming and play will be much easier.

It was important to aim the cannon in many different directions, because the cannon couldn't actually move. But since the boat can move around, having only four directions available isn't necessarily a serious limitation. And you can still keep the tidal drift in both versions.

The Planning Outline

I've gone into a lot of detail in order to show you what the thought process can be like and the reasons for some decisions. But from now on, so that this chapter doesn't become the whole book, you'll move much more quickly through an outline of the decisions that need to be made. You can use this outline for almost any arcade game plan.

Play mechanics. What does the player control in the game, and how? (In this case, it's a cannon and a boat, both controlled with a joystick, as well as cannon fire and mines.)

Simulation. In what ways does the game correspond to real-world activities? To what degree can you duplicate reality without making the game too complex to play? (I decided to

let the cannon aim, but not determine range, and to let the player use the joystick to move the boat in only four possible directions.)

Milieu. What is the setting? What is on the screen besides the moving figures? This is more than just decoration. If you have an airplane game, clouds drifting across the screen add to the illusion of reality. It makes the player feel more like he's really flying. (In this game, make the flow of the river left to right. That means that the banks of the river will be across the top and bottom of the screen. By using character graphics, you can PRINT each shore in a single string. The castle will be right in the middle, but because the TV screen is wider than it is tall, the castle will be rectangular too. It will be a top view, as a bird sees it.)

Missiles. This is a generic term. The player's figure is the screen object whose movement the player controls. Once a missile is launched, however, the player has little or no control over it. The missile can be the ball in a football or baseball simulation, the bullet in a shoot-out, or even the player-figure's fist if it can be "launched" against an enemy. (The only missile used is the ball fired by the cannon, which goes straight in the direction it's fired until it either hits an enemy ship or goes off the screen.)

Collisions. What happens when the player-figure bumps into something on the screen? The figure can respond to the object in several ways. The object might be

....

Transparent. The figure just keeps going as if the object weren't there.

A wall. The figure can't move any further toward the object but can slide along it.

A tar baby. Once the figure touches the object, it's stuck.

A bomb. Touching the object is deadly.

A billiard cushion. Touching the object makes you bounce off at an angle.

A balloon. When you touch the object, it disappears, but you're unharmed.

The same responses are possible for missiles.

During the boat phase, for instance, the shore and the castle are walls (the boat can slide along them). However, the enemy ships are tar babies: When you touch one, you stick until you lay a mine and release yourself. The ships are then

marked, and at the end of the nighttime phase all the mines explode at once.

During the cannon phase, the cannonball treats the ships as balloons-they explode when the ball hits them. However, in this particular game, I decided to make the castle and the shore act like balloons too. The player, by clumsy aiming, can destroy the castle and the shoreline. In such a case, when he goes to the shore to replenish his supplies, the shore might not be there anymore. And if he's really clumsy, he can even help the enemy finish off his own castle.

But what about the enemy's cannonballs? To save programming headaches, don't actually show those cannonballs. Instead, from time to time a randomly selected, character-sized piece of the castle will explode and disappear, leaving bare rock behind. It can be assumed that an enemy cannonball hit that spot.

Reward and punishment. Games are like life. You obey the rules so that good things will happen. The most common reward is the score-it gets higher each time you do the good things (like blasting the enemy out of the water). There are other rewards, too, however, such as story awards. There are also puzzle awards. Just solving the problem on one level, so you can finish it, is rewarding. The best games have scores, story rewards, and puzzle rewards too.

In this game, if you don't ever get the enemy ships, they'll wipe out your castle. If you do get them, you get points and eventually complete the screen by forcing the enemy ships to go home or by sinking them all. The scoring is fairly complex. Every time one of your castle blocks is destroyed, you lose points; if one of your cannon is blown up, you lose the cannon and a lot more points. However, you get some points just for staying alive and for the number of cannonballs you have left at the end of a game.

Communication. The player needs a lot of information during the game. Did my missile hit its target? Did the enemy score a hit against me? Which object do I control? What in the world am I supposed to do?

The single most useful tool you have in communicating with the player is sound. Different sounds mean different things-and you don't have to be watching a particular spot on the screen to get the message.

However, explosions and movement also communicate.

I

You'll also use displays of numbers on the screen to tell the player his score, as well as numbers or little pictures (icons) to

show how many lives the player has left. You'll want in-

I

troductory and closing screens to convey more involved mes- sages or tell part of the story in words.

In this game, you might decide that a popping sound says

1

that the cannon has been fired or the mine has been attached.

A low boing says that a piece of the castle has been blown up.

A swishing sound tells the player that the tide is about to change, an explosion says that a ship has been hit, and a much louder and longer sound (followed by a glug-glug sound) conveys the message that a ship has sunk. Sad or happy music is used to signify defeat or victory.

Win-lose conditions. The game has to end sometime, even if only on a current level. You have to decide what conditions end the game and then check from time to time to see if those conditions have been met. The simplest way to do this is to have a variable-XX, for instance-that usually has a value of 0. Then, in any subroutine that has the power to end.

the game (usually a collision subroutine or a timer subroutine), XX is set to 1 for defeat and 2 for victory. A line in the main loop reads ON XX GOT0 900,920. That jump will occur only when it's time for the game to end. But because it executes only from the main loop, it's much easier to end any FOR- NEXT loops you might be in at the time.

In this game, a player can lose when all four cannons or the entire castle is destroyed, or if all ammunition and mines are used up without destroying the entire enemy fleet. You can win by scoring a certain number of cannonball hits against the enemy or by sinking a certain number of ships or by staying alive until the enemy runs out of ammunition.

Levels. Computer games tend to go on forever. When you

meet the win conditions, the game starts over, but it's harder.

m

This allows a novice to get the hang of the game without get- ting instantly destroyed, while more experienced players still

find higher levels more challenging.

I

In the early levels of the game, for instance, the enemy will have less ammunition, the player cannot blow up parts of

his own castle, and there are fewer enemy ships, so the enemy

I

fires less often and the player can blow up all the ships more

easily. In addition, the enemy cannot hit the player's cannons.

I

Ideas end Applications

These features are changed with each level, however, until at expert levels the player doesn't have enough ammunition to survive. He must pick some ammunition up from the shore and bring it back. On higher levels the player will also find that there are as many enemy ships as can fit on the screen without overlapping, that the player can damage himself, that the cannons can be blown up, and that the current in the river is stronger. The list can go on and on.

Animation. If you're particularly ambitious, there are a lot of extras you can add to enhance realism. These things don't actually affect the play of the game, but they do make it more fun. Simple animation of figures is easy enough, using either sprites or custom characters, and it can be done with almost no degradation of playing speed.

However, you can also add much more complex animated sequences when play action is stopped. These are like small movies that help support the story (like the opening sequence of Donkey Kong in which the gorilla carries the kicking girl up the ladders) or make the milieu complete and believable (like the riderless ostrich in ]oust, that must make its way offscreen after the knight is defeated). The game would play just as well without these extra sequences, but some of the fun would be gone.

Translate the Plan into a Program

You've jotted down your ideas, you've play-tested the game in your imagination, and you're satisfied. Now you're ready to go to work on the program itself.

The first step is to design your video. How large should the castle be? The screen is 22 characters wide and 23 charac- ters high. Subtract a row at the top and the bottom for the shoreline; also subtract a column at the right which you won't use because PRINTing characters in the rightmost position on a line can mess up the lines below. Then decide how big the castle and river (and boat) should be.

In this case, you decide that the castle should be four characters high and six characters wide. Each corner tower will be a two-by-two square, and each cannon will be a custom character. The player-controlled boat will also be made up of custom characters, as will the enemy ships. They will be PRINTed on the screen as strings. They will usually face either left or right, and all the ships change direction together, which

Ic!ecrs a n d Applicct~ons

greatly simplifies animation of the direction changes.

To make all of this work, you need to map video memory and design your character set tables before you even begin to program. It involves lots of tedious calculation, changing dots into bits and bits into decimal numbers and so on, but it will pay off in the end.

Setting Up the Main Loop

You should design the program so that the main loop does as little as possible. The less the main loop does, the more often it repeats and the faster the game plays.

Your game will be a little more complex because it has two main loops, one during daylight phase and one during the nighttime phase. A timer decides how long each phase lasts.

Both main loops must check, from time to time, to see if the time is up and the tide should change or the phase should end.

What needs to be in the main loop? It should always con- tain the routine that gets instructions from the player. In the daylight phase, check first to see if a cannon was fired. If yes, jump to the subroutine that carries the cannonball to its target, where there either is or isn't an explosion. In machine language, you could let a player start aiming or firing the next cannon while the previous cannonball was still moving, but in BASIC it's better to make the player wait for the cannonball to hit before letting him fire again. BASIC would lose too much speed trying to d o it all at once.

If the player didn't say to fire, check to see if he wants to aim. If so, jump to the subroutine that moves the cannon.

Dans le document COMPUTE!'s SECOND BOOK OF (Page 29-46)