awesome. It looks like you're in top gear now Philip. i like the placement of the characters so their hands rest on the trim around the table. We'll keep that exactly so you don't have to change the x and y positioning, but I'll have to modify the characters so their lower body shows them in a seated position. Don't want them looking like they are legless. Except for the pirate with the peg leg of course. lol.
Do you want me to make more player info windows like this one? If you think you'll use them I'll finish them up and send them your way.
If anyone has any thoughts, please feel free to comment. The idea is to tap your character or an opposing player to see their character's icon and get chip information etc. Obviously the cards you see on your opponents will be the back face only. I don't believe there is a plan to allow players to fold their cards face up at this time. Generally that is only allowed, when it's allowed at all, during "heads-up" matches.
@Rexcarsalot I send you a mail tomorrow about some thoughts I have. Unfortunaly I have to go to bed now. Late here and it's a early morning tomorrow
tatiangMember, Sous Chef, PRO, Senior Sous-ChefPosts: 11,949
Really enjoying the graphics and videos so far.
Just a minor comment that at least from my American-centric point of view the 43.000 $ looks strange. I would expect to see $43,000 with the dollar symbol at the front/left and a comma between thousands.
yes, good catch. What you're looking at is just an unedited draft. I actually had a finished version somewhere, but decided not to go digging to deep for it. I'm a yank myself, so that's definitely something that would go away during the finished product, as would the decimal. Those numbers would all be programmed in GS as opposed to me just typing in some nonsense and calling a night.
Obviously, the card faces would also change to the updated style if we decide to go with this concept.
I just want you to see the video update #3 It´s not of the gameplay. It´s a preview of the poker hand calculator The problem with this is that I have a struggle to make it compare which hand is best. It could decide which hand is better(For example that flush is better than a pair) but can´t decide that a pair of kings is better than a pair of queens. So that´s what I need to fix. Right now I´m working with some animations in game. For example so when the player folds the player actually throws in the card with is arm. Right now they are just sitting there Hope you keep continue looking on this thread for more updates. This game going like a fast train now
cool! it looks indeed like a fast train now if you dont have anything (no pairs or something) then its a not winning hand. but if nobody has anything the winner is the player with the highest cards so you still can win, cant you? cant wait to see animation!
I'd probably just do this, though (assuming four players):
Set winningPlayer to 1 Set winningHand to player1Hand If player2Hand > winningHand Set winningHand to player2Hand Set winningPlayer to 2 If player3Hand > winningHand Set winningHand to player3Hand Set winningPlayer to 3 If player4Hand > winningHand Set winningHand to player4Hand Set winningPlayer to 4
The problem with this is that I have a struggle to make it compare which hand is best. It could decide which hand is better(For example that flush is better than a pair) but can´t decide that a pair of kings is better than a pair of queens. So that´s what I need to fix.
If you have an attribute for the value of the card, which you appear to have, surely it's fairly simple? 1-10 + 11 for Jack, 12 for Queen, 13 for King, 14 for Ace and then a simple comparison? It would seem that working out what hand they have (i.e. pair, flush, straight etc) would be the hard part?
I have no idea what I'm talking about though, really.
@tatiang That I´ve understand that I have to do like that when I have a value. But you say that I´ve assigned every possible hand a value, that´s the problem. I don´t have a value really. You may want to check the code of it. It´s a bit complex actually. Just send me a pm if you want to have a look
That's correct. Highest card wins in the event no players have a pair or higher. If more than one player has the same hand, for example PLAYER 1 has Ah Kh Qh Jh 9s and PLAYER 2 has As Ks Qs Js 9h then it's a split pot. Both players would split whatever amount is in the pot, since the winning hand is HIGH CARD ACE.
*EDIT
I should probably also note that in this case: (P1) Ah Kh Qh Jh 9s vs (P2) As Qs Js 9h 8d, player one wins because of his highest two cards: Ah Kh vs player two's highest two cards, As Qs. In any event, it's the highest 5 card hand which wins, not necessarily the highest single card.
I got to thinking earlier about a post I made several months ago discussing (somewhat inebriated at the time if I remember correctly) the Bill Chen Formula (for starting hand selection) and how it applies to poker and how it could theoretically be applied to programming a poker game, specifically for the Pirate Poker GS project.
As incoherent as my post may have been, it turns out I wasn't too far off.
You, and anyone else interested in the theory and practical application of poker programming, should check out this PDF. I came across today when revisiting my idea. I thought I'd cross reference my theory and see if anyone else had applied it somehow, and they had.
It's possible there is something in there which may help you. Either way, it's an interesting read. Even I understood most of it, equations not withstanding.
I found the problem of assessing and then comparing poker hands to be too interesting to resist - something so easily done in almost any programming language, and yet so challenging in GameSalad.
I spent all evening ploughing through the code necessary to ascertain what hand is being held, with some... interesting results. I've got straight flush, four of a kind, full house, flush, straight all sorted, and have three of a kind, two pairs, a pair all being identified. The latter group highlight the problem you seem to be having, and I scratched my head for a while trying to work out how to overcome it.
Take some sample hands, ignoring suits:
5 8 5 4 3 5 6 5 4 3
This one is easy to calculate - both are pairs, one is a pair with a high card 8, one with a high card 6. The one with the 8 wins.
5 6 5 4 3 5 6 5 4 2
Here we have to delve deeper into the hand. Both have a pair of 5s, both have a high card 5, both have a 2nd highest card of 4. So it comes down to the 3 or the 2 to decide the hand.
Now this can be programmed fairly easily - if longwindedly. I got a few rules into doing so before a far simpler way occurred to me. It's gone 3am here now, so I may be being reeeeaaaalllyy stupid, but...
Take any two hands that are both the same type of hand. If they aren't the same type of hand, then one will obviously beat the other. Assuming you've given each card a value between 1 and 14... Add the hands up.
Hands will be equal until they're not. And at that point one hand will win.
5 8 5 4 3 = 25 5 6 5 4 3 = 23
5 6 5 4 3 = 23 5 6 5 4 2 = 22
If by some fluke both have the same hand down to the last card, the numbers will be even and that hand is drawn.
Then it's just a matter of a bubble sort like tatiang suggested, if it's more than 2 players.
Does that make sense?
Now I just need to test things thoroughly tomorrow and then if it looks good, work out what to do with a poker hand calculator...
tatiangMember, Sous Chef, PRO, Senior Sous-ChefPosts: 11,949
edited January 2014
@Armelline, that seems like a smart way to do it. The only problem I see is that it's possible for two hands to have the same sums but different high cards:
5 5 8 2 3 = 23 5 5 6 3 4 = 23
In that case, the top hand wins even though their sums are equal.
Similarly, I believe you could find two hands that have sums that indicate the wrong hand winning:
@Armelline, that seems like a smart way to do it. The only problem I see is that it's possible for two hands to have the same sums but different high cards:
5 5 8 2 3 = 23 5 5 6 3 4 = 23
In that case, the top hand wins even though their sums are equal.
Similarly, I believe you could find two hands that have sums that indicate the wrong hand winning:
5 5 J 2 K = 36 5 5 J 10 Q = 43
In my implementation the following logic applies:
Check if both hand types are equal If both hand types are equal, check the value of the hand (i.e. four tens vs four fives) If both hand values are equal, check which has the high card If both high cards are equal, do the maths
That might not have been clear. I have it only doing the sums, realistically, for two pairs, three of a kind, pairs, high card.
I'm using the following variables as I calculate the type of hand held:
Hand Hand Value High Card
Only after each of these have been checked would the adding up take place.
Your second example might still fall foul to this though. Will have to wake up a bit more :P
@Armelline you are on to something, but adding the card values won't work for the reasons @tatiang stated (and you are discovering). But perhaps multiplying will -- if you multiply in a certain way.
I heard once that prime numbers have an interesting property that if you multiply them together, they will yield a unique number. So, if you represent each card value with a prime number, and then multiply them together, you will get a unique number that represents that particular hand (and only that hand). The first 13 prime numbers are 2,3,5,7,11,13,17,19,23,29,31,37,41 (Source: http://www.mathsisfun.com/prime_numbers.html). You could use them to represent the value of each card, starting with 2 and ending with Ace.
(Note: This would also be how to test for which touches are pressed.)
Well realistically there are very few occasions when high card isn't enough to calculate.
Straight flush/straight - not applicable - high card wins. Four of a kind - not applicable - highest kicker wins. Full house - not applicable - higher three wins, else higher two wins. Two pairs - not applicable with a very small modification - highest first pair wins, else highest second pair wins, else kicker wins.
Obviously there can be draws too, but they are calculated the same way.
The hands where the winner isn't obvious are three of a kind, a pair, and high card/flush.
For three of a kind, addition can work. If it has come down to the last card, then four cards are equal and it's just a matter of comparing the last card. This can be done by identifying the last card (tedious) or just adding both hands up.
So there are only two hand types that require any real effort to compare - a pair and high card/flush.
For a pair, we know that two cards are the same and can be discounted. If the non-hand high card is the same in both hands, that leaves only two cards to compare. Again, addition can work, unless I'm being super-short sighted today.
So the only situation where there is any actual complication in calculating the winning hand is when there are five different cards on the table. Will ponder but I strongly suspect it can be broken down in a similar way. Bottom line is it can be brute forced with enough if statements, but there must be a better way of doing it than that.
Edit: Okay, with some experimentation I've found some examples that yield inconclusive or incorrect results using just addition.
13 11 12 5 6 = 47 13 9 12 11 2 = 47
10 9 7 5 6 = 37 10 9 7 8 2 = 36
I have a horrible feeling a bubble sort might be the best way to do this, and would certainly work, but I refuse to give up just yet
Perhaps if you take the total of each hand, subtract the high card, we can totally discount the high card anyway, so we're only dealing with 4 cards here.
Calculating it with four cards has got to be easier than five, right?
tatiangMember, Sous Chef, PRO, Senior Sous-ChefPosts: 11,949
@RThurman I didn't know that about primary numbers but when I need to have unique sums I use binary numbers to present each value and then any given sum is a unique representation of the values that combined to form it.
For example: Super strength: 1 Invisible: 2 Can fly: 4 Shoots webs: 8 Shield: 16
So a superhero with a sum of 11 (1+2+8) would have super strength, invisibility, and could shoot webs.
Though I plan to continue trying to work this out, it occurs to me now that the problem is actually moot. It seems a pretty safe assumption that any poker game is going to be sorting the cards into order anyway, as part of the play of the hand. Even if the player chooses to override the auto-sorted order, the code is still going to be in place to sort the hand from highest to lowest card.
As such, the problem isn't really a problem. The hand will be sorted, so the calculation of the winning hand between two high card hands becomes trivial.
There's no point trying to avoid a bubble sort, as one will be taking place anyway. (And doing one at the start would allow me to strip out a solid 40% of my hand calculation logic too, now that I think about it...)
So assuming a bubble sort, and given the conditions I outlined above for calculating winning hands for the various hand types, is there anything left other than optimising?
Edit: Okay, got a reasonably small algorithm to sort the five cards into order. Now to find out if I'm right!
@tatiang -- that's cool. So adding numbers in powers of 2 will always create a unique number too. I learn something new every day.
@Armelline -- I honestly don't know the first thing about poker hands. But couldn't having a unique number (either summed or multiplied) for each hand be used to determine the best hand? Couldn't a unique number be used to test for every kind of hand? And if the cards dealt don't actually make a hand (they are random) couldn't the sum tell which player has the highest ranking cards?
@Fajaljp -- you have an interesting challenge here. I am very interested in how you manage to solve it in GameSalad.
Okay, I've got a working hand calculator that I'm pretty sure correctly calculates the winner of all hands, but will need some testing!
I was going to stick it on the Arcade but so many hoops to jump through... (Still happy to do that so everyone can test it but just cannot work out how to get it to publish to the arcade...) Is there a moderator who would like to volunteer to road test it and poke around for any obvious errors? My preference would be @tatiang but I trust you all!
*Please note though that I made it bit by bit and that the code can almost certainly be tightened up and reduced.*
Also, I set out to solve this as a different kind of problem to tatiang and RThurman, so my method is very different. I have no idea if theirs would be more efficient or easier.
The cards for player 1 are displayed at the top, the cards for player 2 below that.
Cards are dealt starting with player 1, then player 2, one at a time. There should be no duplication of cards.
Next to each set of cards are two buttons:
* The top button sorts the cards. As soon as the cards are sorted, the value of the hand is calculated. Hands are ranked on a scale of 1-8, with 8 being straight flush and 1 being a high card only hand.
* The bottom button displays the result of the hand calculation. If you click on this button, it will set all cards in the hand to 0. This should only be done BEFORE sorting the cards.
Clicking on any card will increase the value by 1.
To change the suit of a card, hold down key 1-5 for player one's cards, or key 6-0 for player two's cards, and press h s d c for the desired suit.
In order to compare hands, BOTH hands must be sorted by manually clicking the buttons. This ofc could be automated in a real game, but I wanted to force the steps while I was making it.
The winner is displayed in the box found bottom-middle.
Things to note:
All aces are counted as 14, and there is no 1.
I've forced timers into the sorts which could be removed to speed them up in a real game.
The suits don't always sort properly, but since they play no part in the calculation of the hand I didn't bother to fix it. If it's a flush, they're all the same anyway. If it's not a flush, they're irrelevant.
All cards can be manually changed, but there are no safeguards in place. You can set cards to 1 and to more than 15 which will screw up some of the comparison logic, so don't do that. Make any changes to cards BEFORE you sort the hand.
Please screenshot and post ANY mis-calculated hands! That way I can check if it's an error in my rules or an error in my overall logic.
Lastly, although the logic behind the grunt work here is all solid, as far as I can tell, I've had to take some more longwinded ways due to the fact that there isn't actually a game behind it. The logic could definitely be tightened if adding it to a real game.
@Armelline -- I honestly don't know the first thing about poker hands. But couldn't having a unique number (either summed or multiplied) for each hand be used to determine the best hand? Couldn't a unique number be used to test for every kind of hand? And if the cards dealt don't actually make a hand (they are random) couldn't the sum tell which player has the highest ranking cards?
You may be right. But I reject this idea when I was planning how to approach this on the basis that a) my maths isn't that good, and I'd have better results tacking it as a logic problem rather than a maths problem and b) there are a LOT of possible hands. I worried that I'd have to calculate way more hand values than is practical. My guess is your way is either super-efficient or requires insane amounts of preparation. If each possible hand is yielding a unique number, you'd presumably need to track all those unique numbers to ben able to compare them. But would A A A K Q yield a lower number than K K K K 2? If you're making each card value a prime, and multiplying them, presumably the second would have the lower value but is in fact the winning hand. If you're tracking every possible hand, so know that the unique number for K K K K 2 beats the unique number for A A A K Q, then you're looking at a mind-boggling number of comparisons.
The hand calculator is finally done and it´s working 100% now, at least when I have tested it like 50 times Now it´s only one major thing to do then I´m done with the main mechanics of the game and you could start pass n play Then it´s this order to do. 1:Finish the animations, details(Exit to menu etc) 2:Make everything around the game(Menu, charcater select, help menu etc) 3:Try to implement the async.
As you see it´s much left to do but the biggest parts is done so I think it will go pretty fast in the future. I will try to give you a preview this weekend
You just might get me into playing poker with this one. I never liked card games much (probably because my aunts bored me with it when I was younger) but this is awesome.
Did you think this project was dropped, then you were wrong. Me and Rex is working hard on this to get it realeased as soon as possible. But it was a while since I updated this thread so I thought I would give you sneak peak at the character selection scene
Comments
Do you want me to make more player info windows like this one? If you think you'll use them I'll finish them up and send them your way.
If anyone has any thoughts, please feel free to comment. The idea is to tap your character or an opposing player to see their character's icon and get chip information etc. Obviously the cards you see on your opponents will be the back face only. I don't believe there is a plan to allow players to fold their cards face up at this time. Generally that is only allowed, when it's allowed at all, during "heads-up" matches.
I send you a mail tomorrow about some thoughts I have. Unfortunaly I have to go to bed now. Late here and it's a early morning tomorrow
Just a minor comment that at least from my American-centric point of view the 43.000 $ looks strange. I would expect to see $43,000 with the dollar symbol at the front/left and a comma between thousands.
New to GameSalad? (FAQs) | Tutorials | Templates | Greenleaf Games | Educator & Certified GameSalad User
yes, good catch. What you're looking at is just an unedited draft. I actually had a finished version somewhere, but decided not to go digging to deep for it. I'm a yank myself, so that's definitely something that would go away during the finished product, as would the decimal. Those numbers would all be programmed in GS as opposed to me just typing in some nonsense and calling a night.
Obviously, the card faces would also change to the updated style if we decide to go with this concept.
It´s not of the gameplay. It´s a preview of the poker hand calculator
Right now I´m working with some animations in game. For example so when the player folds the player actually throws in the card with is arm. Right now they are just sitting there
Hope you keep continue looking on this thread for more updates. This game going like a fast train now
if you dont have anything (no pairs or something) then its a not winning hand. but if nobody has anything the winner is the player with the highest cards so you still can win, cant you?
cant wait to see animation!
✮ FREE templates at GSinvention ✮
✮ Available for hire! support@gsinvention.com ✮
I'd probably just do this, though (assuming four players):
Set winningPlayer to 1
Set winningHand to player1Hand
If player2Hand > winningHand
Set winningHand to player2Hand
Set winningPlayer to 2
If player3Hand > winningHand
Set winningHand to player3Hand
Set winningPlayer to 3
If player4Hand > winningHand
Set winningHand to player4Hand
Set winningPlayer to 4
New to GameSalad? (FAQs) | Tutorials | Templates | Greenleaf Games | Educator & Certified GameSalad User
I have no idea what I'm talking about though, really.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
That I´ve understand that I have to do like that when I have a value. But you say that I´ve assigned every possible hand a value, that´s the problem. I don´t have a value really. You may want to check the code of it. It´s a bit complex actually. Just send me a pm if you want to have a look
That's correct. Highest card wins in the event no players have a pair or higher. If more than one player has the same hand, for example PLAYER 1 has Ah Kh Qh Jh 9s and PLAYER 2 has As Ks Qs Js 9h then it's a split pot. Both players would split whatever amount is in the pot, since the winning hand is HIGH CARD ACE.
*EDIT
I should probably also note that in this case: (P1) Ah Kh Qh Jh 9s vs (P2) As Qs Js 9h 8d, player one wins because of his highest two cards: Ah Kh vs player two's highest two cards, As Qs. In any event, it's the highest 5 card hand which wins, not necessarily the highest single card.
I got to thinking earlier about a post I made several months ago discussing (somewhat inebriated at the time if I remember correctly) the Bill Chen Formula (for starting hand selection) and how it applies to poker and how it could theoretically be applied to programming a poker game, specifically for the Pirate Poker GS project.
As incoherent as my post may have been, it turns out I wasn't too far off.
You, and anyone else interested in the theory and practical application of poker programming, should check out this PDF. I came across today when revisiting my idea. I thought I'd cross reference my theory and see if anyone else had applied it somehow, and they had.
http://paginas.fe.up.pt/~prodei/dsie11/images/pdfs/s3-4.pdf
There's plenty of code in there which you may be able to draw from, plus loads of great general knowledge info and equations you may find useful.
Intresting. I will see if I could use that in any way
It's possible there is something in there which may help you. Either way, it's an interesting read. Even I understood most of it, equations not withstanding.
I spent all evening ploughing through the code necessary to ascertain what hand is being held, with some... interesting results. I've got straight flush, four of a kind, full house, flush, straight all sorted, and have three of a kind, two pairs, a pair all being identified. The latter group highlight the problem you seem to be having, and I scratched my head for a while trying to work out how to overcome it.
Take some sample hands, ignoring suits:
5 8 5 4 3
5 6 5 4 3
This one is easy to calculate - both are pairs, one is a pair with a high card 8, one with a high card 6. The one with the 8 wins.
5 6 5 4 3
5 6 5 4 2
Here we have to delve deeper into the hand. Both have a pair of 5s, both have a high card 5, both have a 2nd highest card of 4. So it comes down to the 3 or the 2 to decide the hand.
Now this can be programmed fairly easily - if longwindedly. I got a few rules into doing so before a far simpler way occurred to me. It's gone 3am here now, so I may be being reeeeaaaalllyy stupid, but...
Take any two hands that are both the same type of hand. If they aren't the same type of hand, then one will obviously beat the other. Assuming you've given each card a value between 1 and 14... Add the hands up.
Hands will be equal until they're not. And at that point one hand will win.
5 8 5 4 3 = 25
5 6 5 4 3 = 23
5 6 5 4 3 = 23
5 6 5 4 2 = 22
If by some fluke both have the same hand down to the last card, the numbers will be even and that hand is drawn.
Then it's just a matter of a bubble sort like tatiang suggested, if it's more than 2 players.
Does that make sense?
Now I just need to test things thoroughly tomorrow and then if it looks good, work out what to do with a poker hand calculator...
And sleep. Must remember to sleep.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
5 5 8 2 3 = 23
5 5 6 3 4 = 23
In that case, the top hand wins even though their sums are equal.
Similarly, I believe you could find two hands that have sums that indicate the wrong hand winning:
5 5 J 2 K = 36
5 5 J 10 Q = 43
New to GameSalad? (FAQs) | Tutorials | Templates | Greenleaf Games | Educator & Certified GameSalad User
Check if both hand types are equal
If both hand types are equal, check the value of the hand (i.e. four tens vs four fives)
If both hand values are equal, check which has the high card
If both high cards are equal, do the maths
That might not have been clear. I have it only doing the sums, realistically, for two pairs, three of a kind, pairs, high card.
I'm using the following variables as I calculate the type of hand held:
Hand
Hand Value
High Card
Only after each of these have been checked would the adding up take place.
Your second example might still fall foul to this though. Will have to wake up a bit more :P
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
I heard once that prime numbers have an interesting property that if you multiply them together, they will yield a unique number. So, if you represent each card value with a prime number, and then multiply them together, you will get a unique number that represents that particular hand (and only that hand). The first 13 prime numbers are 2,3,5,7,11,13,17,19,23,29,31,37,41 (Source: http://www.mathsisfun.com/prime_numbers.html). You could use them to represent the value of each card, starting with 2 and ending with Ace.
(Note: This would also be how to test for which touches are pressed.)
Straight flush/straight - not applicable - high card wins.
Four of a kind - not applicable - highest kicker wins.
Full house - not applicable - higher three wins, else higher two wins.
Two pairs - not applicable with a very small modification - highest first pair wins, else highest second pair wins, else kicker wins.
Obviously there can be draws too, but they are calculated the same way.
The hands where the winner isn't obvious are three of a kind, a pair, and high card/flush.
For three of a kind, addition can work. If it has come down to the last card, then four cards are equal and it's just a matter of comparing the last card. This can be done by identifying the last card (tedious) or just adding both hands up.
So there are only two hand types that require any real effort to compare - a pair and high card/flush.
For a pair, we know that two cards are the same and can be discounted. If the non-hand high card is the same in both hands, that leaves only two cards to compare. Again, addition can work, unless I'm being super-short sighted today.
So the only situation where there is any actual complication in calculating the winning hand is when there are five different cards on the table. Will ponder but I strongly suspect it can be broken down in a similar way. Bottom line is it can be brute forced with enough if statements, but there must be a better way of doing it than that.
Edit: Okay, with some experimentation I've found some examples that yield inconclusive or incorrect results using just addition.
13 11 12 5 6 = 47
13 9 12 11 2 = 47
10 9 7 5 6 = 37
10 9 7 8 2 = 36
I have a horrible feeling a bubble sort might be the best way to do this, and would certainly work, but I refuse to give up just yet
Perhaps if you take the total of each hand, subtract the high card, we can totally discount the high card anyway, so we're only dealing with 4 cards here.
Calculating it with four cards has got to be easier than five, right?
Wanted to buy: Sortable arrays.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
For example:
Super strength: 1
Invisible: 2
Can fly: 4
Shoots webs: 8
Shield: 16
So a superhero with a sum of 11 (1+2+8) would have super strength, invisibility, and could shoot webs.
New to GameSalad? (FAQs) | Tutorials | Templates | Greenleaf Games | Educator & Certified GameSalad User
As such, the problem isn't really a problem. The hand will be sorted, so the calculation of the winning hand between two high card hands becomes trivial.
There's no point trying to avoid a bubble sort, as one will be taking place anyway. (And doing one at the start would allow me to strip out a solid 40% of my hand calculation logic too, now that I think about it...)
So assuming a bubble sort, and given the conditions I outlined above for calculating winning hands for the various hand types, is there anything left other than optimising?
Edit: Okay, got a reasonably small algorithm to sort the five cards into order. Now to find out if I'm right!
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
@Armelline -- I honestly don't know the first thing about poker hands. But couldn't having a unique number (either summed or multiplied) for each hand be used to determine the best hand? Couldn't a unique number be used to test for every kind of hand? And if the cards dealt don't actually make a hand (they are random) couldn't the sum tell which player has the highest ranking cards?
@Fajaljp -- you have an interesting challenge here. I am very interested in how you manage to solve it in GameSalad.
I was going to stick it on the Arcade but so many hoops to jump through... (Still happy to do that so everyone can test it but just cannot work out how to get it to publish to the arcade...) Is there a moderator who would like to volunteer to road test it and poke around for any obvious errors? My preference would be @tatiang but I trust you all!
*Please note though that I made it bit by bit and that the code can almost certainly be tightened up and reduced.*
Also, I set out to solve this as a different kind of problem to tatiang and RThurman, so my method is very different. I have no idea if theirs would be more efficient or easier.
Copy sent to @Fajlajp!
Instructions:
The cards for player 1 are displayed at the top, the cards for player 2 below that.
Cards are dealt starting with player 1, then player 2, one at a time. There should be no duplication of cards.
Next to each set of cards are two buttons:
* The top button sorts the cards. As soon as the cards are sorted, the value of the hand is calculated. Hands are ranked on a scale of 1-8, with 8 being straight flush and 1 being a high card only hand.
* The bottom button displays the result of the hand calculation. If you click on this button, it will set all cards in the hand to 0. This should only be done BEFORE sorting the cards.
Clicking on any card will increase the value by 1.
To change the suit of a card, hold down key 1-5 for player one's cards, or key 6-0 for player two's cards, and press h s d c for the desired suit.
In order to compare hands, BOTH hands must be sorted by manually clicking the buttons. This ofc could be automated in a real game, but I wanted to force the steps while I was making it.
The winner is displayed in the box found bottom-middle.
Things to note:
All aces are counted as 14, and there is no 1.
I've forced timers into the sorts which could be removed to speed them up in a real game.
The suits don't always sort properly, but since they play no part in the calculation of the hand I didn't bother to fix it. If it's a flush, they're all the same anyway. If it's not a flush, they're irrelevant.
All cards can be manually changed, but there are no safeguards in place. You can set cards to 1 and to more than 15 which will screw up some of the comparison logic, so don't do that. Make any changes to cards BEFORE you sort the hand.
Please screenshot and post ANY mis-calculated hands! That way I can check if it's an error in my rules or an error in my overall logic.
Lastly, although the logic behind the grunt work here is all solid, as far as I can tell, I've had to take some more longwinded ways due to the fact that there isn't actually a game behind it. The logic could definitely be tightened if adding it to a real game.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Who knows though, my brain is fried right now
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Wish me good luck and I hope to be done in a week(hopefully sooner)
Now it´s only one major thing to do then I´m done with the main mechanics of the game and you could start pass n play
Then it´s this order to do.
1:Finish the animations, details(Exit to menu etc)
2:Make everything around the game(Menu, charcater select, help menu etc)
3:Try to implement the async.
As you see it´s much left to do but the biggest parts is done so I think it will go pretty fast in the future. I will try to give you a preview this weekend
Lump Apps and My Assets
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Did you think this project was dropped, then you were wrong. Me and Rex is working hard on this to get it realeased as soon as possible. But it was a while since I updated this thread so I thought I would give you sneak peak at the character selection scene
