Write A Game
Due to the fact that the Editor needs this article
right away (no rest for the wicked!), I have had no response as yet
about issue 20. This issue finishes the game, at least my part of
it, and any response will be published in the next edition.
In this issue I have included the full listing
that we have been working on. Study it carefully, and beware of the
NEW in line 3030 - SAVE your listing first! I have made changes in
the listing for this edition to include a 'WIN' screen. Notice in
line 5010 the W$. This is used to store the name of the player
currently playing. The winner will be the last person to choose a
position on the board and his name will be stored in W$.
Line 3100 counts the number of choices and when
the maximum of 9 appears without a win taking place, the game is
drawn. I had originally used a variable (C) here to check when the
computer recognises the game is drawn. For instance, if C=8 at the
start of the test will the computer recognise a drawn game after the
next choice? Or will C have to equal 9 at the end of the last
choice? I picked the latter method and, as usual, forgot to delete
C. Well spotted Cliff.
In line 130 I did not need to test 'IF CO=1'. IF
CO on its own means 'if CO does not equal zero'. Similarly, line 140
uses 'IF NOT CO' to test if CO equals zero. Notice in line 110 that
I did not need to use 'THEN GOTO 4000' only 'GOTO 4000'. If you look
at line 4020 you will notice control characters to position the
text. I could have used POKE or POSITION just as easily, but this
would use lots more memory.
The subroutine at line 3000 checks the eight
possible ways of having a winning line, i.e. three vertical, three
horizontal and two diagonal. Again I have used LOCATE and compared
the figures stored in the squares.
You may also note that, for a change, I have used
the OPEN and GET statements to look directly at the keyboard. You
could always have used this during the choice of squares, however,
if you had made a mistake or wanted to change your mind there is no
way to do this as the program just runs on. Unless of course you
include an "Are you sure" prompt.
As I mentioned in the last issue, I am not going
to write a subroutine for the computer, but have included a few
REM's to give a small hint on how to tackle it. All the details are
available over the past few issues, or you could write your own
subroutine.
I have been fiddling about with this game during
the writing of this column and some mistakes had crept in. I have
spotted most of them, but you might find some I missed. It is near
impossible to find all of your mistakes. This is why it is a good
idea to lend out a few copies to friends. They will see the game
through fresh eyes and hopefully spot any errors.
As you can see from the listing, the game is
wholly in Basic and uses lots of variable comparisons, yet, when
played, the game is not noticeably slow for all this. Because I
wrote the program originally as an example of how to write a simple
game and not as an example of advanced programming, the graphics are
not very good. But then again this leaves room for your imagination
to work!
The strange thing about 'Write a Game' has been
the shortage of mail I have received since it started. Now that it
is over I will need some suggestions from readers about future
topics. You know the address so why not write? If you don't know the
address it's : Mark Hutchinson, BAUG Software, P.O. BOX 123,
BELFAST, BT10 0DB
top
