Dans l'état actuel du code, une main égale à celle de l'adversaire n'est pas une victoire (vu que je cherche à avoir une main strictement supérieure). ceci dit, ça ne sera pas bien difficile à changer (un > en un >= _ou plutôt un “non <”_ sur scratch).

Edit, parce que je n'ai rien commenté dans mon code : pour comparer la valeur d'une main à une autre, je stocke chacune des mains sous la forme :
la valeur de la combinaison
les cartes représentatives de la combinaison (dans l'ordre décroissant)
les autres cartes (dans l'ordre décroissant)

Les valeurs de combinaison étant elles aussi décroissantes (de 9 pour quinte flush à 1 pour rien du tout), il me suffit ensuite de comparer les deux listes : dès que l'un est strictement supérieure à l'autre, la main est meilleure.

Exemple : 7♥ 7♦ 7♣ 10♠ 2♥ sera stockée : 4 pour brelan, 7, 7, 7, 10, 2.
Si en face j'ai : K♣ K♠ A♥ 8♠ 3♥, ce sera stocké : 2 pour paire, 13, 13, 14, 8, 3 (11 pour valet, 12 pour dame, 13 pour roi, 14 pour as sauf dans une suite décroissante 5 4 3 2 1)
On constate dès le début que 4 > 2 donc la première main gagne.

Maintenant si la première main était : K♥ K♦ A♠ 8♣ 4♦, stockée 2, 13, 13, 14, 8, 4, les premiers chiffres sont égaux, les seconds aussi, etc jusqu'aux derniers qui permettent de dire que la nouvelle main gagne. Pour une égalité, il faut donc que les 6 entrées des deux listes soient égales.

tu t'es servi de moins de variables que moi mais je n'ai pas pu m'empêcher de compter le nombre de ligne des 2 programmes (pour determiner le nom de la main) et waouh , le mien représente a peu près 1/3 de la longueur du tien ! ça me rassure sur mes progrès ^^ et j'en profite aussi pour te dire que l'idée des boutons m'est venu suite au remix que j'avais fait sur le clavier synthe record ^^ le rapport n'est pas évident mais jusqu'à ce que tu postes le test pour fabriquer la note, je n'avais jamais eu l'idée d'attribuer un chiffre en particulier ( sans passer par un ordre croissant de 0à 1à 2 etc) à une variable ID propre au lutin. Et sur le poker, j'ai essayé d'attribuer aux ID des noms pour palier au fait qu'on ne peut pas utiliser le nom des costumes. ça n'a peut-être l'air de rien mais pour moi c'est une maîtrise supplémentaire sur l'utilisation des clones.

Juste un truc sur la méthode Monte-Carlo : statistiquement, il est possible que de temps en temps, ça donne un résultat aberrant : trouver une probabilité de 100% de victoires pour une paire de 3 ou de 100% de défaite pour un brelan d'as, parce que les 1000 tirages n'auront pas du tout été représentatifs (par exemple tous les mêmes(la probabilité que ça arrive est de 1 / 1533939 ^ 1000 (*), donc risiblement faible, mais non nulle)). Une amélioration possible serait déjà de faire en sorte de ne pas pouvoir tirer 2 fois la même main, mais je ne suis pas sûr que les instructions supplémentaires que ça représente n'allongent pas significativement le temps de calcul, faut que je teste. Une autre possibilité c'est bien sûr d'augmenter le nombre de tirages : par exemple 3000, ça fait 1s de réflexion pour l'AI, c'est pas énormissime. Mais là, c'est ton choix

Donc évidemment on ne peut pas s'y fier à 100%, mais je pense que c'est quand même une bonne base.

(*) Pour rigoler, c'est de l'ordre de 1.5 x 10 ^ (-6186).

Itharius wrote:

tu t'es servi de moins de variables que moi mais je n'ai pas pu m'empêcher de compter le nombre de ligne des 2 programmes (pour determiner le nom de la main) et waouh , le mien représente a peu près 1/3 de la longueur du tien ! ça me rassure sur mes progrès ^^ et j'en profite aussi pour te dire que l'idée des boutons m'est venu suite au remix que j'avais fait sur le clavier synthe record ^^ le rapport n'est pas évident mais jusqu'à ce que tu postes le test pour fabriquer la note, je n'avais jamais eu l'idée d'attribuer un chiffre en particulier ( sans passer par un ordre croissant de 0à 1à 2 etc) à une variable ID propre au lutin. Et sur le poker, j'ai essayé d'attribuer aux ID des noms pour palier au fait qu'on ne peut pas utiliser le nom des costumes. ça n'a peut-être l'air de rien mais pour moi c'est une maîtrise supplémentaire sur l'utilisation des clones.

Héhé, pour les clones, je suis content de t'avoir été utile

Pour la longueur : oui, j'ai vu ça… Bien joué ! (Cependant, mais ça reste à vérifier, je pense que le mien est plus rapide car il ne teste que ce qui lui est utile. Si c'est effectivement le cas, je pourrais me rattraper aux branches en disant que je cherchais à optimiser l'exécution plus que l'écriture du code… Sinon… bah ça m'apprendra à chercher à me compliquer la vie )

quand j'ai cherché à écrire le bloc pour savoir le nom de la main, je galérais, j'essayais d'utiliser des éléments imbriquer dans des éléments de liste… et puis j'ai créer les 5 variables c1,c2,c3,c4 et c5 et là tout a été d'une étonnante simplicité.

ça y est je me suis fait un petit remix de ton projet où on peut rentrer les valeurs des cartes , l'interface peut-être meilleure et je vais pas le publier pour avoir modifier 5 lignes de codes mais ça va être d'enfer , je vais vérifier/comparer tout les chiffres de wikipédia ^^

par exemple 3000, ça fait 1s de réflexion pour l'AI

en fait tout dépend certainement de la puissance de l'ordi parce que moi le premier resultat tombe en 2secondes, le deuxieme en 20 secondes et le 3eme en 476s ^^

Ah oui, la puissance joue pour le coup…

Sinon, j'ai fait une grosse màj sur mon projet pour mieux tenir compte des conditions de jeu :
Dans les mains testées aléatoirement :
- si la main est un brelan, on repioche les 2 autres cartes
- si c'est une double paire, on repioche la dernière
- si c'est une paire, on repioche les 3 autres cartes (j'avais trouvé un site où il était mathématiquement montré que c'était mieux que garder une grosse carte avec une paire, faut que je remette la main dessus)
- si on n'a rien, alors :
- si on est à une carte de la couleur, on repioche ladite carte
- idem si on est à une carte de la suite
- sinon on repioche tout ce qui est en-dessous du valet.

C'est assez grossier, mais ça donne une idée de comment un humain pourrait tenter d'améliorer sa main. Du coup les probabilités calculées tiennent compte du fait qu'une repioche a été possible. A voir si ça change beaucoup les résultats…

Par contre, ça me fait un bloc assez obèse en conditions

j'ai testé les 2 premières lignes sur ta version précédente.

1 brelan de 2 vaut 95% de chances de gagner, sur wiki, c'est écrit qu'un brelan gagne a 99.3%
j'ai essayé 2 paires 92% contre 97.2 pour wiki

je n'ai pas encore testé la version amélioré.
de toutes façon, j'ai une idée plus précise de comment utiliser ces %
il y a 2 cas à distinguer, l'ordi est-il le dealer ou non ?

Si l'ordi est le dealer sa probabilité de checker sera égal à son % de chance de perdre, le % de victoire représentera le % de chance de bet.
si l'ordi n'est pas le dealer ou si le joueur a raise, je vais mettre le % de fold au % de chance de perdre. je ne sais pas encore comment je vais déterminer le % de call et raise (check et bet si l'ordi n'est pas le dealer). peut-être si le % de chance de gagner est sup à 50% (ou 30% ?) je ferais la différence entre (le % de chance de victoire-50) pour le raise ?
ce sera un premier essai, je sais déjà qu'il faudra que je trouve un coefficient pour pondérer tout ça mais l'idée est là.

Me reste encore le problème de la mise à envisager un nombre de blind ou de % du tapis de départ laisse trop facilement deviner la main de l'ordi donc peut-être qu'en ce qui concerne la mise, je vais laisser ça tel qu'actuellement.

en effet, le bloc monte carlo est beaucoup plus long sur la version 2 ^^
je crois avoir bien compris le principe et je suis vraiment tenté pour l'intégrer. Je vais devoir modifier et adapter plusieurs choses.
je n'ai pas intégrer la valeur de la main dans la liste de la main je pense même que pour que ce soit plus rapide, il vaut mieux que je crée une nouvelle variable plutot que de redevoir vérifier la hauteur de la main, mais je vais quand même essayer dans un premier temps sans nouvelle variable.

Il faut que je crée un autre paquet de cartes ou seul les cartes de l'ordi sont retiré sinon celà avantagerai évidemment l'ordi.

je ne m'étais pas du tout dit que c'était comme ça qu'on pouvait calculer la force de la main, je pensais qu'il fallait trouver des formules pour chaque cas particulier. faut que je réussisse à réutiliser mes propres blocs, personne ne semble avoir remarqué une erreur de jugement sur la victoire entre les mains finales donc j'espère que tout mes algos sont justes.

Un projet de strip poker , vous savez POUR LES ENFANTS !!!

j'ai utilisé un mannequin de prêt à porter pour retoucher graphiquement et simuler les phases de strip. Je pense qu'il n'y a rien de vulgaire, on peut en voir autant en faisant ses courses dans un centre commercial donc j'espère que c'est bien compatible avec scratch ( j'ai bien vu des jeux sur scratch ou on habille et déshabille des mannequins en dress up donc bon, j'espère qu'il n'y aura pas de problême).

Après il y a toujours un risque d'addiction avec les jeux de hasard mais bon je comprend si tu estimes qu'il y a un problème, tu peux signaler le topic ou le projet et je suis prêt à me plier à l'avis de l'équipe de scratch.

MAJ:

Implémentation de l'approche Monte-carlo pour évaluer la main de l'ordi et influencer le choix de paroles de l'ordi avant le changement des cartes.
j'ai choisi un test sur 1000 mains, sur mon ordi ça prend 3 secondes avant que les cartes du joueur ne s'affichent, j'espère que ce temps d'attente ne sera pas trop pénalisant ou rebutant pour certains

il faut désormais que je réfléchisse à cette idée de réserve monétaire ainsi qu'à conditionner l'attitude de l'IA en fonction du nombre de cartes changées par le joueur pour la phase 2.

j'ai remarqué un problème au moment de l'annonce du resultat des mains,on dirait que parfois le message qui annonce la main du joueur est répétée deux fois. ça n'a pas vraiment d'incidence (normalement) sur le déroulement du jeu mais il faudra que je trouve comment supprimer ce glitch.

Vos retours , comme vos idées sont attendues

SBissay wrote:

Ah oui, la puissance joue pour le coup…

Sinon, j'ai fait une grosse màj sur mon projet pour mieux tenir compte des conditions de jeu :
Dans les mains testées aléatoirement :
- si la main est un brelan, on repioche les 2 autres cartes
- si c'est une double paire, on repioche la dernière
- si c'est une paire, on repioche les 3 autres cartes (j'avais trouvé un site où il était mathématiquement montré que c'était mieux que garder une grosse carte avec une paire, faut que je remette la main dessus)
- si on n'a rien, alors :
- si on est à une carte de la couleur, on repioche ladite carte
- idem si on est à une carte de la suite
- sinon on repioche tout ce qui est en-dessous du valet.

C'est assez grossier, mais ça donne une idée de comment un humain pourrait tenter d'améliorer sa main. Du coup les probabilités calculées tiennent compte du fait qu'une repioche a été possible. A voir si ça change beaucoup les résultats…

Par contre, ça me fait un bloc assez obèse en conditions

je viens de comprendre que c'est la main testée aléatoirement qui est repiochée et non la main de l'ordi qui reste figée. Je croyais que cétait la main de l'ordi ou tu avais trouvé comment évaluer la main en prenant en compte une possible repioche.
Je cherche donc le moyen d'évaluer la force des mains tirage pour les éventuelles suite ventrales et bilatérales. Une idée ?

A priori, rien n'empêche d'employer la même méthode

Si on peut changer de 0 à 5 cartes, ça fait :
0 cartes : circulez, y a rien à voir
1 carte : 5 possibilités différentes
2 cartes : (5 2) = 5! / (2! * 3!) = 120 / 12 = 10 possibilités
3 cartes : 10 possibilités aussi
4 cartes : 4 possibilités
5 cartes : 1 possibilité.

Donc 30 cas différents. C'est problématique, vu que si 1000 tirages + comparaison prennent un tiers de seconde, ça fait quand même 10 secondes de réflexion… J'ai peur que diviser par 10 (100 tirages par test) ne soit plus vraiment représentatif… A tester, tiens ! (Surtout que ça prendrait une seconde, donc franchement acceptable).

Sinon… si tu as une idée précise de combien de cartes (et lesquelles) retirer selon les situations, ça peut franchement accélérer le processus et rendre le Monte-Carlo viable à nouveau.

j'étais parti chez ma maman et j'y ai pensé en cours de route d'appliquer également une approche via monte carlo. Et puis c'est devenu confus dans ma tête. Pour les bilatérale, il y a 8 chances sur 47 de réussir soit 17% comme le dit wikipedia, 4/47 pour les ventrales soit 8.5%. Mais que faire de ces chiffres ou du résultat qui sera donné de la main non changée par le test monte carlo ? Comment passe-t-on de 50% de chance de tirage junk à 99.6% de chance de victoire avec une suite ? je voudrais réussir à avoir un chiffre qui marquerait le potentiel des mains tirages, ça ne pourrait ni être les 50% attribué au tirage carte haute , ni les 99% d'avoir réussit à faire sa couleur ou sa suite. il faudrait pouvoir multiplier ou mettre en relation les % de chances d'augmenter sa main mais je vois pas trop quelle formule peut s'appliquer

(pourquoi 5 possbilités différentes pour une carte ?)

Alors je parlais de tester tous les changements de cartes possibles, donc ici il y a 5 cartes différentes, donc ça fait 5 possibilités.

Sinon, pour tes probabilités de victoire, fait un arbre et tu verras que c'est évident :
si tu as 83% de chance d'avoir un junk, lequel à 50% de chance de victoire, et 17% de chance d'avoir une suite qui gagne 99% du temps :

50% : victoire
/
83% : Junk
/ \
. 50% : défaite
\
\ 99% victoire
17% : suite /
\
1% défaite

La probabilité de gagner est de 83/100 * 50 / 100 + 17 / 100 * 99 / 100 = 41.5% + 16.83 % = 58.33%

j'ai parlé de toi à ma maman tout à l'heure, je lui ai dit que tu étais très pédagogue celà ne cesse de se confirmer ^^

J'en suis très flatté. Sincèrement.

selon moi l'arbre n'est pas complètement juste



50% victoire
83% junk /
(pas tout à fait vrai il faut aussi inclure \50% defaite
les possibilités de paire mais dans un premier temps
je vais ne pas en prendre compte)
/ 99% victoire
x% victoire /
/ \17% suite \1% defaite
. 50% victoire
\ 83% junk /
^ (100-x) % / \50% defaite 99% victoire
| \17% suite /
c'est cette main dont je veux calculer la “force” \1% de defaite


et donc le calcul est (X)% x83%x50% + (X)%x17%x99% + (100-x) %x83%x50% + (100-x)%x 17%x 99%

le raisonnement est-il bon ?

je suis très motivé à faire un cas à part pour les tirages couleurs,et les 2 types de suite. même si ça allonge les blocs et le tps de calcul pour ces cas là, j'ai vraiment envie que mon IA en fasse des cas à part à étudier.

j'ai également fait quelques tests sur des mains aléatoires avec un monte carlo 100, la marge d'erreur peut atteindre les 7% de différence, ce n'est pas si énorme mais bon c'est clairement pas aussi valide qu'un tests sur 1000 mains.

Hmm, je ne vois pas à quoi servent ces états (x) et (100 - x) que tu as introduits…

Donc je ne vais pas pouvoir juger de la qualité du raisonnement avant d'avoir eu ton explication

Par contre, tu as bon sur le calcul, si l'état (X) est effectivement là pour une bonne raison, alors la probabilité de victoire est ce que tu as écrit (la flemme de recopier).

Edit : au moment d'appuyer sur envoyer, je me suis dit que tu voulais peut-être intégrer la probabilité de victoire de la main avant changement, d'où ce x. Si c'est bien ça, je suis au regret de te dire que non, ça ne fonctionne pas ainsi… Tel que tu l'as fait, ça signifierait que la main que tu as avant le changement jouerait sur la probabilité de tirer telle ou telle carte… Enfin, ça reste “vrai”, au sens que :
(X)% x83%x50% + (X)%x17%x99% + (100-x) %x83%x50% + (100-x)%x 17%x 99%
= (83% x 50%) x (X% + (100 -X)%) + (17% x 99%) x (X% + (100 - X)%) (on met en facteurs les membres sans X)
= (83% x 50%) x (100%) + (17% x 99%) (100%) (on simplifie par X
= ce que j'avais calculé auparavant.

Donc, ça ne sert à rien !

Plus sérieusement, tu peux vouloir intégrer la probabilité de gagner de la main avant changement, mais de manière plus utile en mettant par exemple en place une probabilité de ne pas changer de cartes (qui pourrait dépendre de la force initiale de la main).

Exemple : si ma main gagne 40% du temps, et que je décide de ne pas changer de cartes (pour bluffer, par exemple) avec une fréquence de 1/2 fois la probabilité de gagner de ma main (en adaptant, bien sûr, on ne change pas une main où on gagne 99% du temps) :

40% : victoire
/
20% (= 1/2 * 40%) : je ne change pas de cartes.
/ \
.Main initale 60% : défaite
\
\
\ 99% : victoire
\ /
\ 17% : flush
\ / \
\ 80% : je change 1% : défaite
| \
| \ 50% : victoire
| \ /
| 63% : junk
| \
| 50% : défaite
|
| 70% : victoire
| /
20% : paire
\
30% : défaite

J'ai rajouté un troisième cas (la paire) pour montrer plus en détail.

Dans ce cas, ma probabilité de victoire est de :
20/100 * 40/100 + 80/100 * 17/100 * 99/100 + 80/100 * 63/100 * 50/100 + 80/100 * 20/100 * 70/100
(ce qui vaut 57.864% si mes calculs sont bons).

Ce qui est marrant, c'est que si on appelle X la probabilité de ne pas changer de cartes (ici 20%), alors le calcul devient :
0.4X + (1-X)(0.6233) = 0.4X + 0.6233 - 0.6233X = 0.6233 - 0.2233X
Et dans ce cas précis, c'est une droite décroissante, donc il est plus rentable de toujours changer ses cartes (hors bluff).