First Steps

by Mark Hutchinson


Issue 20

Mar/Apr 86


<< Prev Article



WRITE A GAME continued

In the first WRITE A GAME article, I had promised to show you how the 'FINISHED' and 'AGAIN?' boxes shown in the algorithm would work. This had to be left out of that article but I will include it now.

When you have set up the introductory display screen, it is best to wait until the user has fully finished reading as it can be annoying to move on to the next screen before you have read the first. However, waiting for user response does break the program flow and 'delay' or 'wait' statements are sometimes best, especially if it is a display tutorial that can be LISTed and analysed later. These delay statements take the form


where NUMBER is any value that is suitable for your program.

If you do want user response then probably the simplest way is to monitor keyboard response. The following example will correspond to the 'FINISHED' box.

110 POKE 764,255 : REM *** This sets the 'last key pressed' location to a no-key pressed condition.
120 IF PEEK (764)=255 THEN 120 : REM *** Keep looking to see if any key is pressed.
130 ?"THANK YOU" : REM *** PEEK (764) is less than 255, i.e. a key was pressed.

To use the 'AGAIN?' box, the computer must be supplied with a specific answer. In this case PEEK (764) will have to be 43 for Y(es) or 35 for N(o). Any other response should send the computer back to look at the keyboard again.

100 ? "SAME AGAIN?"
110 POKE 764,255: REM *** Clear register.
120 IF PEEK(764)=43 THEN GOTO YES: REM *** Subroutine.
130 IF PEEK(764)=35 THEN GOTO NO
140 GOTO 120: REM *** Look again.

Another way to do this is to look directly at the input. As some users tend to input "YES" while others input "Y", it is necessary to look only at the first letter of the input. Thus you need only DIM the string to one character, saving on memory.

100 DIM A$(1)
110 INPUT A$
120 IF A$="Y" THEN GOTO YES: REM *** Subroutine.
140 ? "TRY AGAIN":GOTO 110

There are other ways. to do this, but these are about the simplest.

Let's go on now to some feedback from the first column. I received a letter from Steven Wayne of Palmers Green. Steven, who does some teaching, told me that I should explain what all the POKEs are for and should use REM's more often. I had hoped that readers would avail themselves of the PAGE 6 offer of 'Mapping the ATARI', but if not then I will gladly run over the listing again.

Line 5010 - POKE 559,0, as described in the text, will switch off the screen and allow the computer to run faster. The screen will also appear fully drawn when switched on again. POKE 710 is one of the colour registers used instead of SETCOLOR.

Line 5015 - POKE 752,1 will turn off the cursor. POKE 559, 34 will turn on the screen.

Line 5040 - again POKE 559,0 to switch off screen. POKE 712,34 another colour register (I have no idea why I also used a SETCOLOR statement here!). POKE 756,226 sets the characters to lower case, and POKE 752,1 to swich off the cursor.

Line 5060 POKE 559,34 - switch on screen.

So much for the first part of the game. This issue I have provided some additional routines in Listing 1 which should be added to the first part of the game in issue 18. I hope that you read the last 'FIRST STEPS' column about LOCATE, as the program makes use of this command. The keyboard entry is looked at (lines 1010-1100 and 2010-2100) and then compared with the associated screen location. The value of the screen location is then checked to see if it contains 'X' or 'O'. If it does then the choice must be made again. If not, the relevant character is printed in the square. To make life easier, I made the line listings with exactly a 1000 difference (aren't I good to you?). All you need do is change the line number and then X$ to O$ and hit RETURN.

Remember that the program is not complete and will be added to in future issues.

Did any of you try your hand at changing the introductory screen which appeared in the first part of the listing in issue 18? I recieved a letter from Cliff Winship, who went to a lot of trouble to try writing his own introductory program. I tried my hand at augmenting his work so some lines were not in Cliff's original program but I hope, after all his hard efforts, that you type in his program which is Listing 2.

The next issue will look at how we can check to find out if a player has won, and how to tie in this test with the two programs in this issue.

Now for next month's homework. I want some simple subroutines to allow the computer to pick a square (HINT. How about my article in issue 19?) and also to store and check previous choices. I hope that I will not have to write this routine myself. Let's hear from you.

Write to Mark Hutchinson at P.O.BOX 123, BELFAST, BT10 ODB