A Die Class that implements Crap…I mean ‘Craps’ in Java ….

I took a step back from cards and decks to see if I could design and build a crap game using some object-oriented design. To play the game, we roll two die. The result is determined by the sum of the two rolls….a number between two and 12. Put simply, seven and 11 means the roller “won,” any other result is some form of push or loss…”snake eyes [2]” and “box cars[12]” usually equate to a bust. We can make up specific rules when we implement the game itself, or change them on the fly. The key concept here the abstract data type I built – Class Die.

Lets think about what a die IS and what it DOES. In computer science terms, we’re going to build a virtual die based on my observation/interpretation of these aspects of this object. For a game of craps, I’m concerned with the die’s current status, that is, what is face up on this hypothetical die right now? What is face up if I create a new one out of thin air? What is face up after I roll it? Compared to a Card, a Die object is relatively simple. While a card has a suit and rank, a die only has a face value. The important thing to consider is that when we roll it, one, two, three, four, five and six should occur with a relatively even distribution – as close to random as we can get. How we determine a random number in this range, how we determine that a computer-generated number is “random” at all is beyond the scope of this discussion; for now …assume that the Java Virtual Machine can in fact do this. We can create another program later to test it, say… a million times and see how evenly the JVM can emulate randomness.

Here are the “body parts” of the Die I created – “face up” I used an integer and called it “state”…to create a new Die I initialized it to have one be face up. Since I need to read the face, I created a “print state” method. Of course, a “roll” method was created — which will change the state (or not! 1/6th of the time….) I also buiis lt a function that will immediately return the current state (to whatever interface needs to use it) as an integer; this is fast and useful once an actual game using dice is built – common coding standards would ask that we call this a “get[State]”
There are probably a few other things a die has and does, in fact, we should have an ability to put the “state” where we want it; a “set” procedure…in terms of the game; this would presumably be some sort of cheating, so we left it out. For now…anyway here is the abstract data type:

package die;
import java.lang.Math;
import java.util.*;
//this is a WIP!!
public class Die{
int state;
public Die(){
state = 1;
}
public void printstate(){
System.out.println(state + " is face up");
}
public int roll(){
int a;
Random roll = new Random();
a = 1+Math.abs(roll.nextInt()%6);
state = a;
return a;
}
public int getstate(){
return state;
}
}//end Die

The way I built this, a main program will have to create two instances of “Die,” roll them, determine a sum and evaluate/output the result. The class above neatly and concisely provides everything we need to play the game. In the code we will create dice using a statement like this- “Die the1st = new Die();” Let’s take a look at what happens when this line is executed.
the = or assignment operator will move from right to left…so the 1st thing that happens is the cpu allocates memory for it (which shouldn’t cost much more than the memory needed to store one integer 16…perhaps 32 bits (???)…the “new” keyword also pulls the constructor method seen above, which will initialize it to have “one” be “face up” …in the class above — Die(){state=1;}

Then we will create a second die, everything I just said will happen again. In the game, we’re gonna roll ’em and figure out what happens. As we build the main class, we will use printState() and getState() frequently to verify that our dice are behaving like we would expect real dice to. Remember, we are creating them in a strictly abstract sense, we can’t hold them, look at them or actually roll them…so we need to poke and prod at these dice as the game goes … debugging the code if anything out-of-the-ordinary happens.

Later we will take a look at the entire source code; for now lets consider some key moments in a single round of craps. The player rolls, he either wins or loses, so we start by calculating the sum.

mydie.roll();
mydie1.roll();
sum = mydie.getstate()+mydie1.getstate();

The above sum tells us what happened. I added a Boolean method to the Die class to determine victory and a branching-if-then-else method to print what happened …

//this is in the main class
currentstack = currentstack - betamt;
if(won(sum)){
System.out.print(" WINNER ");
currentstack*=3;
}
else if(sum==2 || sum == 12){
System.out.print(" OUCH!! ");
currentstack=0;
bust = true;
}
else{System.out.print(" LOSER ");}

Don’t worry too much about the specifics; it should be easy enough to see that, in pseudocode

SUBTRACT the players bank by how much they BET
IF the player WON
MAKE Notification, increase their money
ELSE the player LOST
IF the player rolled SNAKE EYES or BOXCARS
Make Notification, player BUST
IF the player rolled some other value
Make Notification, reduce their money

The rules I used are arbitrary, essentially we want something good to happen if the roll a seven or 11, something bad to happen if not…and something REALLY BAD to happen if they roll a two or 12. As it is set right now, “snake eyes” or “box cars” leads to player bust- in this case they lose everything and the game is over. Winning triples their money, as written and the game continues provided the player has more than $1 to play with. I’ve yet to decide exactly what happens, but really it doesn’t matter. The design allows for any rules regarding what you get if you win, what you don’t get if you lose, how badly you can lose, if/when the player can choose to quit and if/when the cpu will decide to end the game.
the class method “won” is fairly straightforward. TRUE will be sent back if the condition is met.

public static boolean won(int s){
return(s==7||s==11);
}

In the next installment, I will decide on some actual rules, show some sample outputs of the game in progress along with some research to see if the Java Virtual Machine is, in fact, emulating the rolling of two die by writing a special use-case in which we’ll roll each die a million times and see how normalized the randomness really is.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.