11-UP PATIENCE
by Colin Gooch
from ZX Computing Oct/Nov.1984

CARD CORNER - PATIENCE III

This issue, Colin Gooch presents us with
his version of "eleven-up" Patience.


Card games are often good starting points for micro
simulations. In particular Patience games are good for they
are already designed for one player. I find programming them
a fascinating insight into the working of the brain. It is
amazing how many factors we take into account when we so
simply look at a card and decide that it will "go". The same
decision may well take several subroutines each involving
several variables and loops.

Criticism is sometimes levelled at such simulations that
they are pointless because you can just as easily use a pack
of cards. That may be true, but it has many parallels in
other branches of life ... Why get out the vacuum cleaner
when it might be just as quick to use a brush? Anyway a
table to play on is not always available, and if you are ill
in bed it's much easier to balance a Spectrum on your knee
than a large tray.

One major decision to take is to decide just how much we
allow the computer to do. It would be quite easy to write a
program and simply watch the Spectrum play by itself. It's
best, I believe, to allow the player to do quite a lot, but
to reject faulty inputs. With an actual pack of cards you
can go back and correct your error if for instance you
misread a heart for a diamond. You cannot do this without
breaking into a program so it is best to avoid the problem.
At the same time we need to allow unwise but not illegal
moves.

I hope you enjoy the intricacies of long strings of cards
...

Happy programming.

			Ray Elder


11 Up Patience

This is one of the simplest of the great family of patience
games, and depends entirely on the run of the cards, but it
can still be quite frustrating and will practice your powers
of mental arithmetic!

Nine cards are dealt out and you must endeavour to get rid
of the rest of your cards by covering either pairs of cards
that total 11 or a run of J,Q,K. If you can't go you may
deal one card on the centre. If you are still stuck then you
must resign.

The first thing that we must do before programming a card
game is to decide on the presentation of the cards. A nine
by five block of print positions will allow for a very
realistic layout but unfortunately restricts the number of
cards that can be shown in full to a maximum of two rows of
four (or five if you omit gaps between). This game needs a
display of nine cards and to allow for an attractive deal I
have made a five by seven matrix the order of the day. This
means that the pips on the cards are not in quite the
traditional places but I think they are still acceptable.

The cards are represented in memory by five characters and
are held in a main string P$ in which they are dealt and
shuffled. Each card is made up of a first character giving
its 'name', the next two its value, the next the suit and
finally the colour.


Program operation

When loaded the program will auto run and set up the
graphics using line 1760 onwards. The main program will then
'RUN'.

The first operational line is 1020 which produces two
defined functions to locate the printing of the cards to x
and y coordinates. The main loop, which is quite long,
starts at 1040. It first of all gives you the choice of
instructions held in lines 1600 onwards, then initialises
some variables - line 1710 - and sets up and shuffles the
pack in lines 1400 and 1490.

Line 1060 will print out a hand using the card printing
subroutine at line 1250. You're then asked to input your
move. The lines from here up to 1210 check that this is a
valid combination. If all is well then your move is printed
and we loop back to the beginning. If it is a faulty input
you will be asked to enter again. If you have run out of
cards or resigned you will be directed to the end game
routine at line 1510.

The Spectrum keeps track of what cards are dealt by using an
array R$. I have done this rather than using the SCREEN$
function to read the value as '10' is a U.D.G. which this
will not recognise.

The subroutine to print out the cards runs from line 1250.
It breaks down the card into its various components (the
string slicing ability is excellent for this purpose) and
uses these to print the correct card, the place being given
by the two defined functions. Picture cards are shown as
letters.


Main variables

A        counts out cards in deal
CD       cards played
FA       temporary flag
N        for-next loops
T        total value of cards to cover
x,y      position on screen
z(x)     values derived from Z$
A$,B$,D$ setting up pack
C$       card being printed
E,F$     components of C$
P$       pack
R$(x)    cards dealt
Z$       your move
T$       title
U$       instructions


Memory

This program will easily fit into 16K.

All that remains now is to type it in. Debugging should not
be difficult. If you get 'funny' cards then your error is
almost certainly from line 1250 onwards. If it's rejecting a
legitimate move then its in the main loop ... have PATIENCE
and it'll all be OK.!


--
Another Fine Product transcribed by:
Jim Grimwood (jimg@globalnet.co.uk), Weardale, England
--
