Re: ti-83 basic programming / poker


On Fri, 28 Oct 2005 jawon81@xxxxxxxxx wrote: 

hi everyone i am in the process of programming a texas holdem game for
the ti-83 graphics calculator.  i am using their basic programming
language.


  Yay! Good for you!

so far i have been able to randomize the cards and output them to the
screen, here is the basic code for what i've been able to accomplish so
far:

LBL Z:
randint(1,52)->a  // Hole
randint(1,52)->b  // Cards

randint(1,52)->c
randint(1,52)->d // Flop
randint(1,52)->e
randint(1,52)->f // Turn
randint(1,52)->g // Rivers

So far so good. At some point you'll want to get rid of those superfluous closing parentheses. :)

IF a=b or a=c or a=d or a=e or a=f or a=g or
b=c or b=d or b=e or b=f or b=g or c=e or c=f
or c=g or d=e or d=f or d=g or e=f or e=g or
f=g
THEN
GOTO Z
ELSE


  Ick!  First of all, tangentially, it seems like you're not aware that

    IF X:GOTO Z
is superior to
    IF X:THEN:GOTO Z:END
for reasons besides simply taking less memory. Executing a GOTO inside a
block terminated by END will mess with the interpreter's stack; it will
keep expecting an END to finish the THEN block.

  Here's the advice you really wanted, though:

    {A,B,C,D,E,F,G->L1
    SortA(L1
    IF (not(min(AList(L1:GOTO Z

where 'AList(' is the "delta List" operation, option 7 under LIST->OPS.
This code says: Put all seven cards in a list, and sort them in ascending order. This puts any duplicate cards next to each other. Then,
we simply take the differences of adjacent cards; if any of the differences are zero, then we have one or more duplicate cards.

  But that's really not the way you want to do it, I think. It depends
on whether you want to allow card-counting or not. If not, your way
is OK, if tedious --- each deal will consist of seven cards picked
completely at random from the deck. But if you do, then you need some
way of remembering which cards have already been dealt.
  The simplest solution, I think, is to code what you'd do in real life
--- take the deck, shuffle it, and then pick the first seven cards.
You can do that like this:

    seq(I,I,1,52->L1
    rand(52->L2
    SortA(L2,L1

Now L1 contains a random permutation of the integers between 1 and 52.
Then it's just

    L1(1->A
    L1(2->B
    ...

Or you could just forget about A,B,... and use the indices into L1 directly. Perhaps have a pointer D for "top of deck," like this:

    1->D
    // do a hand of poker
    D+7->D
    IF D>45:THEN
    // reshuffle the deck
    1->D
    END


if x=1:output(1,1,"As") 

  Modulo arithmetic is your friend. :)

[...] 
so now the next step is for me to program the different strengths of
the hands also taking into consideration all the different aspects of
texas holdem poker.

now i could keep on writing the program but it will be very tiresome to
program in all the different combinations of winning hands because
there are so many different combinations of the 9 different hands in
poker.  for instance a 5c6c7c8c9c is a straight flush and so is
2c3c4c5c6c.  this would probably result in about thousands of line of
code and programming this is basic can become very annoying at best.

Well, it's going to involve a certain amount of tedium, because poker is a pretty arbitrary game. But you can certainly cut down the work by using the techniques I've already demonstrated. For example, to see whether the player has a flush showing, it's

    0->T                    // no flush found yet
    {A,B,C,D,E,F,G->L1
    iPart(L1/13->L1         // compute the suits of the cards
    IF 0=L1(5:1->T
    IF 3=L1(3:1->T
    IF not(T:THEN
      1/(L1-1.5->L1
      IF -2=L1(5:1->T
      IF 2=L1(3:1->T
    END
    IF T:THEN
      Disp "FLUSH
    ELSE
      Disp "NO FLUSH
    END

This is another reason you might not want to use A,B,C,... to hold card values --- you'll want a lot of scratch variables to hold the results of
these tests.
For hands such as one pair and straight, you'll need to have the variable hold not just 0 or 1, but a number whose magnitude indicates
the strength of the hand --- two aces beats two jacks, for example. The
mapping from hands to numbers is obvious in those two cases, but it might
require some thought for a hand like full house.


hopefully when i get the program working i will be able to add graphics
and even make the game networkable between other plays via the cable :D

I'd say skip the graphics. Basic is bad at graphics even for "dumb" games like Snake and Skiing, and it's a lost cause when it comes to "smart" games like poker. You'll be spending too many cycles on processing the hands to worry about drawing things to the graphics screen.


  Hope this helps. Feel free to post if you get stuck; I like TI-83
programming. ;)

-Arthur
.

Relevant Pages

  • Re: What s your favorite article ...
    ... Many of you are just beginning to play a game I consider to be the ... This comes from the fact people can play this game far worse than any ... Low or small cards dominate this game and will crush any ... Many starting hands, such as three to a flush look very attractive, ...
    (rec.gambling.poker)
  • RE: LPIC passing percentage?
    ... The birth of the Altair and Imsai using the Intel 8 bit 8080 ... Dropping your first punch card deck on the floor and having ... resort the entire deck of 500 cards because you did not ... Programming my first computer in my first language ...
    (RedHat)
  • Re: cooperative multitasking: how to deal with "READLN"
    ... someone else's) bus management protocol. ... you'd have to buy 485 cards. ... and you don't want the extra programming ... The hardware does everything for you, ...
    (comp.lang.pascal.borland)
  • Re: Graphics Cards
    ... Microsoft DirectX MVP, ... > and I am thinking about switching to one of theses ... ... > I don't know much about game programming, but I am interested to learn it, ... > cards could have on the programming side of things. ...
    (microsoft.public.win32.programmer.directx.graphics)
  • Re: Infinite Loops and Explicit Exits
    ... Early programming used among other things, cards. ... > carryover from assembler since there really is not way to do it in ... > contort yourself to be able to call a subroutine and declare, ...
    (comp.lang.cobol)