This game simulates the game of craps played according to standard Nevada craps table rules. That is:
- A 7 or 11 on the first roll wins
- A 2, 3, or 12 on the first roll loses
- Any other number rolled becomes your “point.”
- You continue to roll, if you get your point, you win.
- If you roll a 7, you lose and the dice change hands when this happens.
This version of craps was modified by Steve North of Creative Computing. It is based on an original which appeared one day on a computer at DEC.
As published in Basic Computer Games (1978):
Downloaded from Vintage Basic at http://www.vintage-basic.net/games.html
15 LET R=0
R is a variable that tracks winnings and losings. Unlike other games that
start out with a lump sum of cash to spend this game assumes the user has as
much money as they want and we only track how much they lost or won.
21 LET T=1
22 PRINT "PICK A NUMBER AND INPUT TO ROLL DICE";
23 INPUT Z
24 LET X=(RND(0))
25 LET T =T+1
26 IF T<=Z THEN 24
This block of code does nothing other than try to scramble the random number generator. Random number generation is not random, they are generated from the previous generated number. Because of the slow speed of these systems back then, gaming random number generators was a concern, mostly for gameplay quality. If you could know the "seed value" to the generator then you could effectively know how to get the exact same dice rolls to happen and change your bet to maximize your winnings and minimize your losses.
The first reason this is an example of bad coding practice is the user is asked to input a number but no clue is given as to the use of this number. This number has no bearing on the game and as we'll see only has bearing on the internal implementation of somehow trying to get an un-game-able seed for the random number generator (since all future random numbers generated are based off this seed value.)
The RND(1) command generates a number from a seed value that is always
the same, everytime, from when the machine is booted up (old C64 behavior). In
order to avoid the same dice rolls being generated, a special call to RND(-TI)
would initialize the random generator with something else. But RND(-TI) is not
a valid command on all systems. So RND(0), which generates a random number
from the system clock is used. But technically this could be gamed because the
system clock was driven by the bootup time, there wasn't a BIOS battery on these
systems that kept an internal real time clock going even when the system was
turned off, unlike your regular PC. Therefore, in order to ensure as true
randomness as possible, insert human reaction time by asking for human input.
But a human could just be holding down the enter key on bootup and that would just skip any kind of multi-millisecond variance assigned by a natural human reaction time. So, paranoia being a great motivator, a number is asked of the user to avoid just holding down the enter key which negates the timing variance of a human reaction.
What comes next is a bit of nonsense. The block of code loops a counter, recalling
the RND(0) function (and thus reseeding it with the system clock value)
and then comparing the counter to the user's number input
in order to bail out of the loop. Because the RND(0) function is based off the
system clock and the loop of code has no branching other than the bailout
condition, the loop also takes a fixed amount of time to execute, thus making
repeated calls to RND(0) predictive and this scheming to get a better random
number is pointless. Furthermore, the loop is based on the number the user inputs
so a huge number like ten million causes a very noticable delay and leaves the
user wondering if the program has errored. The author could have simply called
RND(0) once and used a prompt that made more sense like asking for the users
name and then using that name in the game's replies.
It is advised that you use whatever your languages' random number generator provides and simply skip trying to recreate this bit of nonsense including the user input.
27 PRINT"INPUT THE AMOUNT OF YOUR WAGER.";
28 INPUT F
30 PRINT "I WILL NOW THROW THE DICE"
40 LET E=INT(7*RND(1))
41 LET S=INT(7*RND(1))
42 LET X=E+S
.... a bit later ....
60 IF X=1 THEN 40
65 IF X=0 THEN 40
F is a variable that represents the users wager for this betting round.
E and S represent the two individual and random dice being rolled.
This code is actually wrong because it returns a value between 0 and 6.
X is the sum of these dice rolls. As you'll see though further down in the
code, if X is zero or one it re-rolls the dice to maintain a potential
outcome of the sum of two dice between 2 and 12. This skews the normal distribution
of dice values to favor lower numbers because it does not consider that E
could be zero and S could be 2 or higher. To show this skewing of values
you can run the distribution.bas program which creates a histogram of the
distribution of the bad dice throw code and proper dice throw code.
Here are the results:
DISTRIBUTION OF DICE ROLLS WITH INT(7*RND(1)) VS INT(6*RND(1)+1)
THE INT(7*RND(1)) DISTRIBUTION:
2 3 4 5 6 7 8 9 10 11 12
6483 8662 10772 13232 15254 13007 10746 8878 6486 4357 2123
THE INT(6*RND(1)+1) DISTRIBUTION
2 3 4 5 6 7 8 9 10 11 12
2788 5466 8363 11072 13947 16656 13884 11149 8324 5561 2790
If the dice rolls are fair then we should see the largest occurrence be a 7 and the smallest should be 2 and 12. Furthermore the occurrences should be symetrical meaning there should be roughly the same amount of 2's as 12's, the same amount of 3's as 11's, 4's as 10's and so on until you reach the middle, 7. But notice in the skewed dice roll, 6 is the most rolled number not 7, and the rest of the numbers are not symetrical, there are many more 2's than 12's. So the lesson is test your code.
The proper way to model a dice throw, in almost every language is
INT(6*RND(1)+1) or INT(6*RND(1))+1
SideNote: X was used already in the
previous code block discussed but its value was never used. This is another
poor coding practice: Don't reuse variable names for different purposes.
50 IF X=7 THEN 180
55 IF X=11 THEN 180
60 IF X=1 THEN 40
62 IF X=2 THEN 195
65 IF X=0 THEN 40
70 IF X=2 THEN 200
80 IF X=3 THEN 200
90 IF X=12 THEN 200
125 IF X=5 THEN 220
130 IF X =6 THEN 220
140 IF X=8 THEN 220
150 IF X=9 THEN 220
160 IF X =10 THEN 220
170 IF X=4 THEN 220
This bit of code determines the routing of where to go for payout, or loss. Of course, line 60 and 65 are pointless as we've just shown and should be removed as long as the correct dice algorithm is also changed.
62 IF X=2 THEN 195
....
70 IF X=2 THEN 200
The check for a 2 has already been made and the jump is done. Line 70 is therefore redundant and can be left out. The purpose of line 62 is only to print a special output, "SNAKE EYES!" which we'll see in the next block creates duplicate code.
Lines 125-170 are also pointlessly checked because we know previous values have
been ruled out, only these last values must remain, and they are all going to
the same place, line 220. Line 125-170 could have simply been replaced with
GOTO 220
180 PRINT X "- NATURAL....A WINNER!!!!"
185 PRINT X"PAYS EVEN MONEY, YOU WIN"F"DOLLARS"
190 GOTO 210
195 PRINT X"- SNAKE EYES....YOU LOSE."
196 PRINT "YOU LOSE"F "DOLLARS."
197 LET F=0-F
198 GOTO 210
200 PRINT X " - CRAPS...YOU LOSE."
205 PRINT "YOU LOSE"F"DOLLARS."
206 LET F=0-F
210 LET R= R+F
211 GOTO 320
This bit of code manages instant wins or losses due to 7,11 or 2,3,12. As mentioned previously, lines 196 and 197 are essentially the same as lines 205 and 206. A simpler code would be just to jump after printing the special message of "SNAKE EYES!" to line 205.
Lines 197 and 206 just negate the wager by subtracting it from zero. Just saying
F = -F would have sufficed. Line 210 updates your running total of winnings
or losses with this bet.
220 PRINT X "IS THE POINT. I WILL ROLL AGAIN"
230 LET H=INT(7*RND(1))
231 LET Q=INT(7*RND(1))
232 LET O=H+Q
240 IF O=1 THEN 230
250 IF O=7 THEN 290
255 IF O=0 THEN 230
This code sets the point, the number you must re-roll to win without rolling a 7, the most probable number to roll. Except in this case again, it has the same incorrect dice rolling code and therefore 6 is the most probable number to roll. The concept of DRY (don't repeat yourself) is a coding practice which encourages non-duplication of code because if there is an error in the code, it can be fixed in one place and not multiple places like in this code. The scenario might be that a programmer sees some wrong code, fixes it, but neglects to consider that there might be duplicates of the same wrong code elsewhere. If you practice DRY then you never worry much about behaviors in your code diverging due to duplicate code snippets.
260 IF O=X THEN 310
270 PRINT O " - NO POINT. I WILL ROLL AGAIN"
280 GOTO 230
290 PRINT O "- CRAPS. YOU LOSE."
291 PRINT "YOU LOSE $"F
292 F=0-F
293 GOTO 210
300 GOTO 320
310 PRINT X"- A WINNER.........CONGRATS!!!!!!!!"
311 PRINT X "AT 2 TO 1 ODDS PAYS YOU...LET ME SEE..."2*F"DOLLARS"
312 LET F=2*F
313 GOTO 210
This is the code to keep rolling until the point is made or a seven is rolled.
Again we see the negated F wager and lose message duplicated. This code could
have been reorganized using a subroutine, or in BASIC, the GOSUB command, but
in your language its most likely just known as a function or method. You can
do a grep -r 'GOSUB' from the root directory to see other BASIC programs in
this set that use GOSUB.
The rest of the code if fairly straight forward, replay the game or end with a report of your winnings or losings.