Acey-Ducy: New Basic

As if often the case, code using modern styles is more efficient, but one often ends up writing more of it anyway to either improve the user experience or to create code that's more maintainable, reusable or robust.

Modern good practices, for example, require variable declaration. So that's extra code that needs to be written. But when I redid Acey-Ducey in the New, it found an error that had come over from the old. That is, I had mispelled a variable. In old basics, the environment was no help finding misspellings, since if you meant "M" but entered "N", it would just assume N was a new variable.

But look at this main loop:

WHILE (GameOver=0)
?"You now have ";Bank;" dollars"
?"Here are your next two cards "
A=DrawCard
B=DrawCard
If A>=B then Swap A, B
? "First card ===> "+CardText(A)
? "Second card ==> "+CardText(B)
?:?

SELECT CASE GetBet(Bet, Bank)
   CASE PlayerBet
      C = DrawCard
      ? "Third Card is "+CardText(C)
      if ((C>=A) AND (C<B) AND (Bet>0)) or (Bet<0) then ?"You win!!!" else ?"Sorry, you lose."
      if (C>=A) AND (C<B) then Bank += Bet else Bank -= Bet
      GameOver = (Bank <= 0)
   CASE PlayerPass
      REM Do Nothing
   CASE PlayerQuit
      GameOver = 1
   END SELECT
WEND

Ah. Much better. You can see exactly how things go.

Line numbers are terrible; initially I replaced them with labels so that "GOTO 260" was "GOTO DRAW2CARDS". That's somewhat better, but of course, on of the principles of top-down structured programming is to have one entry point and one exit point.

Doing this did remind me why I don't program in Basic much if I can help it. FreeBasic doesn't exactly match Microsoft Visual Basic and, of course, VB.NET is an entirely different beast. But all Basics have this combination of "Do whatever you want. We know what's best" that makes them irritating. (Pascal, by comparison, insists you follow a consistent pattern, no matter how stupid.)

Here's the full code. Note that I started out with an enumerated type for the game states which, I think, benefits readability. A lot of Basics don't have enums.

ENUM GameStates
 PlayerBet
 PlayerPass
 PlayerQuit
 Unknown
 END ENUM

REM ***SUBROUTINES USED IN PROGRAM ***

Function DrawCard as Integer
Return Int(rnd(1)*13)+2
END FUNCTION

Function CardText(Card as Integer) as String
SELECT CASE CARD
CASE IS < 11: Return Str(Card)
CASE 11        : Return "Jack"
CASE 12        : Return "Queen"
CASE 13        : Return "King"
CASE 14        : Return "Ace"
CASE ELSE      : Return "Error!"
END SELECT
End Function

Function GetBet(ByRef Bet as Integer, Bank as Integer) as GameStates
DIM S as String
DIM GS as GameStates = UNKNOWN
While (GS = Unknown)
Input"What is your bet? (0 to Pass, Q to Quit)";S
Bet = Val(S)
IF LEFT(UCASE(S),1) = "Q" THEN
   GS = PlayerQuit
ELSEIF Bet = 0 THEN
   ?"Chicken!!"
   GS = PlayerPass
ELSEIF Bet > Bank THEN
   ?"Sorry, my friend, but you bet too much."
ELSEIF Bet <>0 THEN
   GS = PlayerBet
   END IF
 WEND
RETURN GS
End Function


REM ***END SUBROUTINE SECTION ***

PRINT Tab(26);"Acey Ducey Card Game"
PRINT TAB(29);"New Basic Redux"
?:?:?
?"Acey-Ducey is played in the following manner "
?"The Dealer (Computer) deals two cards face up"
?"You have an option to bet or not bet depending"
?"on whether or not you feel the card will have"
?"a value between the first two."
?"If you do not want to bet, input a 0"

INIT:
DIM Bet AS INTEGER = 100
DIM Bank AS INTEGER = 100
DIM AS INTEGER A, B, C
DIM Response AS STRING
DIM GameOver as Integer = 0

WHILE (GameOver=0)
?"You now have ";Bank;" dollars"
?"Here are your next two cards "
A=DrawCard
B=DrawCard
If A>=B then Swap A, B
? "First card ===> "+CardText(A)
? "Second card ==> "+CardText(B)
?:?

SELECT CASE GetBet(Bet, Bank)
   CASE PlayerBet
      C = DrawCard
      ? "Third Card is "+CardText(C)
      if ((C>=A) AND (C<B) AND (Bet>0)) or (Bet<0) then ?"You win!!!" else ?"Sorry, you lose."
      if (C>=A) AND (C<B) then Bank += Bet else Bank -= Bet
      GameOver = (Bank <= 0)
   CASE PlayerPass
      REM Do Nothing
   CASE PlayerQuit
      GameOver = 1
   END SELECT
WEND

if Bank <= 0 then ?"Sorry, friend, but you blew your wad." else ?"Yay! You still have money left!"
Input "Try again (YES or NO)";Response
if Response="YES" then GOTO INIT
?"OK, hope you had fun!"
END

I see now that I left a GOTO in at the end with GOTO INIT.

I went through a phase of being allergic to GOTO as all reformed spaghetti programmers must, but ultimately I think clarity rules above all. If getting rid of the GOTO would make code harder to read, then leave it in. For the past 20 years, though, it hasn't been a case of removing GOTOs but putting them in.

So, I've had only two cases where I've added GOTOs because they improved the clarity the code, and both of those were before exceptions had made it into the language I was using.

So, here? Nah, it's not necessary, but it's not "harmful" here, and we don't need to spend more time on it. This does point out the difference between modifying existing code versus designing anew.

I think it's also why programmers usually prefer to start over rather than try to make old code work. This little 100 line program has a few confusing parts in it. When you get into 10,000 lines or more, it can be hard work.

Acey-Ducy: Old Basic

Here's a good example of how the BCG books were inspiring. Acey-Ducey is not a bright game; it would never work in Vegas. Basically, two cards are dealt and you are to guess whether a third card will land between those two cards. But of course, it's easy to win by not betting much when the cards are close together--or betting negative, even, which the program lets you do--and betting a ton when you have a sure thing.

But it's a card game! In 100 lines of code! So, if you can do Acey-Ducey what else can you do? The original author was Bill Palmby of Prarie View, Illinois. Let's look:

(Note that for PRINT I use the question-mark. The interpreter changed them to "PRINT"s back in the Apple days but since I'm using a compiler, they stay "?"s here.)

10 PRINT Tab(26);"Acey Ducey Card Game"
20 PRINT TAB(15);"Creative Computing Morristown, New Jersey"
21 ?
22 ?
23 ?
30 ?"Acey-Ducey is played in the following manner "
40 ?"The Dealer (Computer) deals two cards face up"
50 ?"You have an option to bet or not bet depending"
60 ?"on whether or not you feel the card will have"
70 ?"a value between the first two."
80 ?"If you do not want to bet, input a 0"
100 M = 100
110 Q = 100
120 ?"You now have ";Q;" dollars"
130 ?
140 Goto 260
210 Q = Q + M
220 Goto 120
240 Q = Q - M
260 ?"Here are your next two cards "
270 A=Int(14*rnd(1))+2
280 If A<2 Then 270
290 If A>14 Then 270
300 B = Int(14*rnd(1))+2
310 If B<2 Then 300
320 if B>14 then 300
330 If A>=B then 270
350 if A<11 then 400
360 if A=11 Then 420
370 if A=12 then 440
380 if A=13 then 460
390 if A=14 then 480
400 ?A
410 Goto 500
420 ?"Jack"
430 Goto 500
440 ?"Queen"
450 Goto 500
460 ?"King"
470 Goto 500
480 ?"Ace"
500 if B<11 then 550
510 if B=11 then 570
520 if B=12 then 590
530 if B=13 then 610
540 if B=14 then 630
550 ?B
560 Goto 650
570 ?"Jack"
580 Goto 650
590 ?"Queen"
600 Goto 650
610 ?"King"
620 Goto 650
630 ?"Ace"
640 ?
650 ?
660 Input"What is your bet?";M
670 if M<>0 then 680
675 ?"Chicken!!"
676 ?
677 Goto 260
680 if M<=Q then 730
690 ?"Sorry, my friend, but you bet too much"
700 ?"You have only ";Q;" dollars to bet"
710 Goto 650
730 C=Int(14*RND(1))+2
740 if C<2 then 730
750 if C>14 then 730
760 if C<11 then 810
770 if C=11 then 830
780 if C=12 then 850
790 if c=13 then 870
800 if c=14 then 890
810 ?C
820 Goto 910
830 ?"Jack"
840 Goto 910
850 ?"Queen"
860 Goto 910
870 ?"King"
880 goto 910
890 ?"Ace"
900 ?
910 if C>A then 930
920 goto 970
930 if C>=B then 970
950 ?"You win!!!"
960 goto 210
970 ?"Sorry, you lose."
980 if M<Q then 240
990 ?
1000 ?
1010 ?"Sorry, friend, but you blew your wad."
1020 ?"Try again (YES or NO)";A$
1030 if A$="YES" then 110
1040 ?"OK, hope you had fun!"
1050 END

It's sort of hard to read, isn't it? One thing to pick up, from line 930, is that "between" means equal or greater to the lower bound. So, you can't lose on the low side if the low card is a deuce. Also, if the cards are one apart (and they can be), you can bet negative, and only lose if you match the low card. But that's a separate issue. Let's just break down the code:

Lines 10-80: Intro/Help

Lines 100-110: Variable initialization. I think setting "M" is superfluous, since the value is never used, but since M appears in the code before the user sets it... I dunno, I didn't think any environments at the time would care.

Lines 120-130: Your status update. How much money you have left. This is, strangely, only called when you win. When you lose, you're forced to guess how much money you have left.

Lines 140-240: Sets your wins and losses. This is a very weird place for this and probably how it came to pass that the loss doesn't show your bank while the win does. This money should be added or subtracted in the 910-1050 code block.

Lines 260-650: The bulk of the program, this "draws" the cards and prints them out. Note that the two blocks of code are nearly identical. Also note that the code draws and redraws the cards until A comes out being less than B.

Lines 660-710: These take in the bet and make sure the guy doesn't bet too much, though it doesn't prevent him from betting a negative.

Lines 730-900: Just like lines 260-650, these "draw" a card and print them out. It's kind of cute, but did you notice the code checks to see if the random number it generates is between 2 and 14, and re-runs it if not? I'm pretty sure that's because the RND function was not consistent across platforms. (Basic was poorly spec'ed and liberally grown.)

Lines 910-1050: Test to see if the player wins or loses, and if the game is over because he lost all his money. Note there's no clean exit for a winner.

So, to me, the fasicnating thing is that, even at 100 lines, this program is way longer than it needs to be. Next post, I'll compact it down.