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.

FreeBasic

For Basic programs, I'll be using FreeBasic, at least until I'm motivated to do otherwise. (Say, if I discover that it sucks.) You can download it at the link, install it, and then invoke the compiler with "fbc".

If you see "Old Basic", that means we're dealing with some ancient stuff. GOTOs and line numbers, and probably ALL CAPS. (I won't type things in as all caps, though, because I find that tedious.)

To compile an "Old Basic" program, you'd enter:

fbc -lang qb progname.bas

The "-lang qb" is to imitate QBasic, which is the oldest extant dialect that I know of that will work with these dinosaurs.

Now, there's some advantage to using actual QBASIC: Old Basics were all interpreted--you had to pay big money for a compiler, which is why I learned assembler (time was cheap, money was dear). What that meant though, was that if your program crashed, you could look at it real time, fix it and go on. (This was somewhat unreliable, though, since certain actions would silently reset the variable pool.)

QB, I think, has the stop-n-go thing, but I'm not sure about that. It does interacively debug, though, and that can be a huge help in learning how the flow of a program actually works.

For now, though, I'm going to stick with FreeBasic. If I find a use for QB, I'll bring it up again.

Project: David H. Ahl's Basic Computer Games

When I was a kid, I begged and pleaded with my father to get me a computer, and--in a rather rare moment--he actually did. (Lesson that I realized years later: Always ask your parents for things that they want.)

I had a computer class in school, but within a week or two, I had a grasped the basics as if I had been born to them which, after a fashion, I had. Those first two days of instruction, along with a later day explaining the concept of pointers, were all I ever had.

I did have this book, though, called Basic Computer Games and its sequel More Basic Computer Games. Both were edited by Creative Computing magazine editor David H. Ahl, and many (most?) came from issues of that magazine (which I never read, heh). Roughly each pair of pages contained some explicatory text, a sample run, and the code for a game in a hard to read font. There weren't a ton of errors, though--credit where it is due to the editors and typesetters.

The coding in this book was highly constrained by the fact that it had to run in the wild west of the '70s and early '80s: It had to be Basic, and it had to be least common denominator Basic. Not everyone had a whopping 48K of RAM and a floppy disk that could store over 100 kilobytes of data like I did. Some folks were running offa 16K TSR-80s and cassette tapes.

Seriously, though, scaled for inflation, that Apple ][ cost more than anything I've ever bought or ever has been bought for me before or since, including musical instruments, my first cars, or my children's birthing expenses. The only exceptions would be my house and possibly one or two of my cars.

On the other hand, I bought most of the stuff I have using skills that began with this book. So, you know, there was a payoff.

Anyway, the code is really quite bad by any modern standards, and even by the professional standards of the time. But the programs were games, which made them interesting. I polished my skills by adding graphics, sound effects, variations on gameplay, and then by creating my own games.

And of course, managing the complexity of those games drove me to hate Basic (at least as it was) for its poor structure and the limited help it offered. Also it was slow. This drove me to learn Assembler, PL/I and Pascal. (And all this in turn led to my interest in programming languages.)

So one of my projects for this blog is to bring those games back, and revisit them in a number of ways (gameplay, design, architecture) in a variety of languages in the hopes that this will give an appreciation of history, progress in the programming world and a fun way to experiment with different languages in different environments.

I hope you enjoy them as much as I did.

Introductions

My first blog isn't really a good place for coding, so I've fired this one up.

It's sort of interesting that blogspot has so many good blog names taken up by bloggers who never made a post or who haven't made a post in years.

Anyway, I chose the name "Left Curly Brace" ironically. This style of coding, made popular by the badly designed and poorly spec'ed C language--did I mention I have strong opinions about this sort of thing?--has come to dominate the programming world. Any new language, if it's going to take off, has to look like a math teacher vomited.

{
if(!happy)
toughLuck();
}

I prefer the cleaner English of Pascal (or PL/I or BASIC):

if not happy then ToughLuck;

Smalltalk's a little stranger to read, but it makes good, logical sense:

(self happy) ifFalse: [self toughLuck].

Anyway, it's not just C's syntax that makes it awful--some day when I have time and am feeling feisty, I'll go through K&R and explain why it's so bad--and we'll be using left-curlies here because, hell, you can't hardly help these days. The curly braces won.

If you're going to be a good programming polyglot, you gotta be comfortable with the C-style.

I've got various projects I want to do, and that I want to make available to others for their use. Ultimately, I don't know how many languages I'll be using, but you can expect to see Pascal, BASIC, Smalltalk, PHP and Actionscript just for starters. Yes, even C is likely, as is C++.

I hope you'll find the entries interesting and useful.