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

--