Minecraft Forums

Redstone 5-card draw Poker

This thread is going to be where I post my work. Each point of progress will be documented and posted here. Of course, more people that comment on it will get the work done faster! I don't have a lot of time to work on it between full-time work and full-time school, but I will work on it when I can and let you guys know here what's going on!
I'm always happy to answer any questions, so let loose! I may not be the best around, but I do what I can.

Planned features:

• Winning Detection
• Cards given through named items(As chosen in the poll of the other thread)
• ~May do redstone screens displaying winner and what hand the winner had.
• Cards are drawn through a fully redstone run design, based on D-Flips and T-Flips working together to allow each bit to only be selected once. The selection will be done with a 6 bit binary randomizer.

Current Progress:










Standard Legend:
Stone: Card circuit, determines what has been drawn previously.
Stone Slabs: Ladders/bussing
Lime Green Wool: Master Reset line
Purple Wool: 6 bit HopDrop based randomizer
Hardened Clay: 6 bit B2D Decoder
Light Blue Wool: Locked-Repeater based RAM.
Orange Wool: Drawn Card suits.
Yellow Wool: Drawn Card numbers.
Bricks: Spacers blocking two Redstone currents from touching.
Cyan Money/Betting circuitry.
Pink Dealing circuits.
Magenta: Hand RAM


Hand Calculations:
Black Wool: VUA's (HC, Pair, 3K, 4K, Flush)
Lime Clay: Up/Down Comparator
Green Wool: Left or Right Double Comparator


(Highest to Lowest in rank):
Black Clay: Straight Flush
Green Clay: 4K
Cyan Clay: Full House
Light Blue Clay: Flush
Brown Wool: Straight
Pink Clay: 3K
Orange Clay: 2P
Yellow Clay: Pair
Purple Clay: High Card

Players:
Blue Wool: Player 1
Red Wool: Player 2
Blue Clay: Player 3
Red Clay: Player 4
Iron: 'Blue' Players 1,3
Gold: 'Red' Players 2,4
White Wool: 'Wool' Players 1,2
White Clay: 'Clay' Players 3,4

Trivia:

• There are a total of 2,598,960 different possible Poker Hands.
• A hand is often referred to as first the 'High Card' the hand possesses, and THEN the combinational hand it makes up. For example, a 'Royal Flush' is simply an Ace-high Straight Flush. A 9-high Straight beats an 8-high Straight, although they are both of the same rank.
• The Poker Ranks are done in order of least probable (Straight Flush 2x10^-7%) to most probable(High Card 50%)
• So far, I have spent approximately 35 hours(As of 10/8/13) of actual construction on this project. That does NOT include research or planning. It DOES include building/testing circuits before actually placing them in the design.

First progress! I only had 1 hour today, so I didn't get a whole lot done.

I built the card system which allows each card to be picked once, and only once. This system will hold the last output(The card) until a new input is entered.
On top of that, like I have stated, the cards will be chosen based on a 7-bit binary randomizer, which will be decoded to select a card. Instead of trying to go through that entire process of disallowing certain numbers to be outputted, I allow it to run however it wants, and build into the circuit a way to get past that. There would normally be two options in that case:
1) I can connect all 'drawn' circuits to a re-draw.
2) I can allow the circuit to 'forward' it's selection to the next card.

Pros/cons
1) Keeps validity of the random/Is EXTREMELY slow and time consuming. It's only about 4-5 seconds difference, but that adds up quick.
2)MUCH faster/ Reduces 'true' random... By a VERY small amount. For the next draw, 1 card will have about a 1/262,144 greater chance of being chosen instead of a different card.

In case you couldn't tell, I decided to go with #2.
Here are pictures of today's progress:

Got 3 hours in today!

First off, I used a design from munin295, made at request. This design is a selective item sorter. I won't be using it until later, but I built it in the world, and here is the picture:
Secondly, I named the items!
Next up was the 6 bit randomizer(Purple) and the B2D decoder(Red).
In the second picture, you see that the decoder goes further than the line of cards. That is because a 5 bit output has 32, and a 6 bit has 64. However, I only need 52. Therefore, the other numbers are still decoded, however they are all connected back to the randomizer to 'draw again' in the case one of the non-cards are chosen.
The third picture is a random card chosen.
Last but not least for the day, I built the ladders the redstone signals use to carry the outputs upward. In front of these ladders are droppers, which will later be used to handle the items. The card numbers are the yellow signals. The orange ones are the suits. These have to be separated for use later, while handling the hands.

Quote from Rockster160

You might want to take a look at -- it's much faster. Speed is going to be important for something that may have to iterate multiple times for each card draw.

looks pretty cool so far! As far as speed goes, it sounds like you have it pretty much figured out, though a faster decoder will always help it run faster if it needs to.

I'll take a look at that. Thanks again!
Although, I run each layer at the same time. The circuit that limits the signals takes longer than the randomizer and decoder. Each line of the decoder is run at once. The average time is about 3-4 seconds to draw. On top of that, it's actually not too often that it has to reiterate.
There are only two cases:
A ) When 1 of the 11 non-cards are drawn. (17%)
B )When a card is drawn that has already been drawn AND every card of the same suit higher than it has been drawn. (Uhh... Depends on the cards that have been drawn.)
Although I'll admit- I'm not against faster.

EDIT:
That's the most obvious design for a decoder I've ever seen. I actually use that in many of my password doors. I cannot believe I never thought of using that as a decoder...

This is exactly why I'm posting this online while I'm in progress. I love seeing other ideas of how to do things better. I have a tendency to just do things so that they work. I don't spend a lot of time in efficiency. I try to, but get bored of it. Thanks for the help!

Updated!
Took me an hour to re-design the decoder, but it's done! Thanks again, Munin!

Also- I want some opinions on this. Should I leave it as 2 player, or attempt to make it 4 player? Dealing the cards isn't too bad... But the winning detection MIGHT be massive.
The way winning detection works: it compares two hands, and tells you which one is better. I was originally planning on having 3 sections. 1-2, 3-4, and then the winner of those two compared one last time. Another option(Much slower, but much more compact) is using another few layers of RAM, and doing the same thing (1-2,3-4,winners) automatically on 1 field of the comparisons. I'm not sure how I could do it, but I think I would be able to figure it out.

What do you guys think?

Built a new component! The first part of the winning detection process.

It is a VUA. Vertical Unary Adder.
What a Unary Adder does, is basically sort numbers. Unary is, essentially, Tick marks.
For example, ||| = 3. ||||| = 5A Unary Adder will take a number of signals, and convert them to Unary. So, if given |0|0|, it will change them to 00||| instead.

Now, how can this be useful? Normally, it isn't. However, the way the RAM is going to work, it is going to assign each card a position in your hand(1-5). Lets say you are given 3, 6, J, 3, A. The Unary Adder will, take the positions of the two 3's, and put them together. 3, 3, 6, J, A.
Essentially what this is doing is telling us how many of each card we have, therefore giving us the possible hands: High Card, 2 of a Kind(Pair), 3 of a Kind, and 4 of a Kind. In the future, these will be referred to as follows: HC, Pair, 3K, 4K respectively. It also detects whether the player has a flush. The orange lines are connected to their own set of VUA's. If the VUA detects a '5 of a kind' with suits, it is called a flush!
Since I am rebuilding most of the components and attempting to make them more compact, I am having to change a lot. The VUA was one of them. It was previously 3 wide and not stackable. It took me about 20 minutes to rebuild that design. However, I needed it to be stackable, as the size of... Well, just about everything else, is going to be 3 blocks per cell. I spent about 40 minutes trying to make it stackable, to no avail. I then spent another 60 or so minutes trying to make it 2 wide... This time, I got it!

Enough blabbering. Here's the pictures!
1.5 more hours, mass produced the RAM and VUA's. This is the beginning of Player 1 and Player 2's hands.

Last post of the day-
Got about 2 more hours in! Didn't have time to post it earlier though. I left in a rush.

I built the next part of the hand calculation- the 2-pair(2P) detector. (Brown) This previously functioned partly as the Full House detector as well! Unfortunately... It got confused and thought that a 3K was also a Full House... I fixed that today, with a small circuit that over-rides other signals if a higher one is received. (Black... For now. Needs to be recolored.)

I also finished off the VUA's for all 4 players! That's right, I decided(On my own- since nobody responded) that there will be 4 players. On top of that, they will each have their own hand calculators.

1 hour:

• Re-Built bottom of VUA's, sorted lines, stacked into the over-ride circuit.
• Built Flush detector
• Built Pair, 3K, and 4K detectors

Im excited xD

Hey guys! Sorry I haven't posted in a few days. I've been really sick and busy. :S

Got about an hour and a half in today.
Built the Pair, 2P, 3K, 4K, Full House, Straight, and High Card detectors.
Refer to original post for color legend.

Alrighty! Got another hour in this morning before school. Bussing, bussing, and a little more bussing.

First of all, I fixed the straight detector. No pictures because it's hard to actually notice. Basically, I un-inverted the original signals, split up each different straight, and inverted those signals at the end. This will detect any and all straights.

Next up, I sorted and bussed the hands in descending order. First picture is the bussing up, second picture is calculating the final hand, the Straight Flush, and the last picture is the line up of all the hands in descending order.

Caught LOTS of bugs. Lucky to get them early on. First off, the left side players, when I flipped them, I messed the bussing up. Full Houses were caused by 4K + Pair instead of 3K + Pair. 3K and 4K themselves were flipped. (Which is why the first error escaped me until now) A couple backwards repeaters. (Thanks WorldEdit!) As well as a few others which I have forgotten...
I think I spent approximately 1 hour fixing bugs, and another hour or so copying the hand calculations to the other players as well. Now all 4 players have their hands calculated and sorted/outputted into order of rank.

Pictures!
First up, example hand(Full House)
Next three pictures are simply angles of the entire thing. In FAR rendering distance, this time!

EDIT: Also switched the B2D from Red to Hardened Clay. Red and Blue Wool/Clay will be used as players.

Quote from Rockster160

Caught LOTS of bugs. Lucky to get them early on. First off, the left side players, when I flipped them, I messed the bussing up. Full Houses were caused by 4K + Pair instead of 3K + Pair. 3K and 4K themselves were flipped. (Which is why the first error escaped me until now) A couple backwards repeaters. (Thanks WorldEdit!) As well as a few others which I have forgotten...
I think I spent approximately 1 hour fixing bugs, and another hour or so copying the hand calculations to the other players as well. Now all 4 players have their hands calculated and sorted/outputted into order of rank.

Pictures!
First up, example hand(Full House)
Next three pictures are simply angles of the entire thing. In FAR rendering distance, this time!

Front:

Iso:

Top:

In my experience its always better to catch bugs like that beforehand, and not after it's all done and you already built around it lol. It's been a while since I checked in, and it's looking really good!

1.5 more hours.
Changed the Decoder from Red to Hardened Clay. Red/Blue Wool/Clay will be used as players in the future.

Designed two new circuits: Up/Down Comparator, and Left or Right double Comparator.
(Please help me with these names! I'm sure they have real names and I have NO idea what they could be!)

Up/Down Comparator has two inputs and two outputs. If one input is on, then the same output is on. If both are on or both are off, there is no output.
This checks to see any draws that the players might have. For example, if they both have a Pair, then it deletes the fact that they have Pairs and goes on to check the High Card.

The Left or Right double Comparator is similar in the fact that it has two inputs and two outputs. Inversely, it does NOT check to see if the Up/Down both exist. The Up/Down comparator makes it so only 1 input can be activated at a time.
It's a stackable mechanism that passes on to a lower level the fact that it has ANY input at all. Input 1 OR input 2 (different players, same hands) will deactivate ALL outputs below that level.
So, let's say one player has a 9-high 3K, the other player has a Ace-high 2P. The 3K out-ranks all the other hands and likewise, those hands will not be allowed to pass. The single highest signal will succeed through.
It's a little hard to explain. Sorry if that was confusing.

Pictures!
The first one is the two comparators. Lime Clay is the Up/Down, Dark Green is the Left or Right Double.
The second is the two circuits added on to one side of the system.
The third is the new Progress.

Quote from Jmal116

In my experience its always better to catch bugs like that beforehand, and not after it's all done and you already built around it lol. It's been a while since I checked in, and it's looking really good!

I definitely agree! I'm glad I caught them this early. It would have been a pain to have to go back and find them later. :S

I always try to do extensive tests to make sure everything up to that point is working the way it should.

Got an hour in today. Little bit of bug-fixing with the Left or Right Double. Also added on two outputs to it that simply carry on the old signals. I just realized I forgot one part- I need to make the winning player's signal cancel out the losing player's, so the hands don't get mixed up or combined.

Then I made some huge busses, beginning the winner vs winner signals. I had to make them a little bit higher because I need the room on the front of the RAM for the game play module later.

One picture today, an update of what the final piece currently looks like:

Another hour and about 45 minutes in today, unfortunately, about 30 minutes in, the world spontaneously corrupted and deleted itself. Luckily, I make a manual back-up every time I save. SO! I didn't lose too much. I managed to rebuild what I had built in about 15 minutes, in the next 15 minutes, recolored the busses. The last 45 minutes I spent bug-fixing. I found a strange piston bug that kind of causes a BUD, but as far as I can see, it's more or less unpredictable. It's extremely annoying. =/

So, today's progress:
Built in the winning detection cancellers. This makes it so the hand that is carried on to the second stage of winning detection is only the single player's hand that won the previous check.
Then I connected a bunch of stuff that I didn't finish connecting last time.

Finally, pictures:

Got about 45 minutes between yesterday and today. Had a bunch of things distracting me. I tried to build a comparator from either side that works like the Left to Right comparator. Honestly, I failed. I couldn't focus well enough and had to stick with what I had. I re-routed the current 1-2 Player lines underneath the 3-4, then connected them all up in the same fashion as before. They I built a little blocker to control the winning signals.
Here's the pictures: