Version imprimable
moi, plus simplement, je suggérerais une option qui :
- permettrait de voir les cartes "tenues" par l'ordi
- afficherait une petite fenêtre dans laquelle s'afficherait le "raisonnement" de l'ordi avec sa décision.
un mode style "debug".
Comme ça, n'importe quel utilisateur peut le déclencher autant de fois qu'il veut, et s'établir sa propre statistique de "bonne foi".
et tout ça sans rentrer dans des trucs complexes, bi-machines, évaluations, source code, etc etc..
bonjour souviron,
votre approche peut certes convenir pour donner confiance au joueur mais s'il utilise systématiquement le "debug" ça lui donne un avantage certain sur le long terme et donc enlève tout l'intérêt du jeu ;)
Merci en tout cas à tous ceux qui ont tenté de m'apporter une réponse même si j'ai tentance à chercher la petite bête :mrgreen:
mais sans qu'il ait à regarder le code source (que la plupart ne comprendront pas) c'est bien le seul moyen fiable pour l'utilisateur.... :DCitation:
Envoyé par pragmatique
tu demandais la preuve. C'est la seule en laquelle moi en tous cas je croirais...
Si un vendeur de voitures te dis que sa bagnole ne consomme que 4l aux 100 en ville, et fait du 240, tu le crois sur parole ? tu le crois avec la notice ? ou tu essayes la voiture ?
Salut,
La discussion m'a paru intéressante, et je me permet d'y apporter mon petit grain de sel.
En effet, l'utilisateur humain qui était méfiant quand tu lui a dis que le programme ne "trichait" pas, pourquoi serai-t-il satisfait quand tu lui dira mon programme utilise une technologie de cryptage avancée utilisant une intéraction sur 3 serveurs différents ... Il sera toujours méfiant.
Donc, tu moment ou on joue contre une machine, c'est qu'on peut émettre des doutes quand à sa bonne foi (hum hum, la bonne foi du programmeur bien sur ^^)
Donner le code source n'est pas une bonne idée, pour 2 raisons :
-Si c'est pas un programmeur, il pigera rien et doutera encore et toujours.
-Si c'est un programmeur, il pourra analyser ton jeu, et y trouver des failles et des lacunes.
Sans parler du fait qu'il pourra encore se méfier parce que il ne sera pas sûr que la version que tu utilise ne diffère pas de la version donnée.
Pour résumer, du moment ou l'utilisateur viens utiliser ton programme, il y a une part de risque qu'il assume.
a+
Bonjour 'readln' (programmeur delphi/pascal ? :mrgreen:),Citation:
Envoyé par readln
Oui je pense qu'on peut résumer la situation de cette manière car la solution théorique apportée par la cryptologie est difficile a mettre en pratique (surtout à cause de la nécessité d'un "tiers de confiance" qui nécessite ... d'avoir confiance en quelqu'un au moins :aie:).
Je vais donc éviter de gaspiller mon énergie à vouloir convaincre ceux qui verront dans leur défaite un complot mondial visant à déstabiliser leur ego :mrgreen:
Citation:
Envoyé par souviron34
:(Code:
2
Salut à tous :)
Je me permet d'ajouter mon grain de sel si vous le permettez :
S'il s'agit d'un "jeu" où les données "joueurs" et les données "computeur" sont définies à peu près aléatoirement (genre poker quoi), pour moi peut importe que le programme "triche" ou ne triche pas... du moment que statistiquement, j'ai autant de chance de gagner que l'ordianteur.
Donc même si l'ordi se sert de sa toute puissance pour tricher vilainement et zieuter dans la main du pauvre joueur, mais que pour pas que ce soit grillé, il contrebalance en se faisant perdre lui même, et bien cela ne change rien pour l'utilisateur !
Il y a des méthodes statistiques très fines permettant de déterminer avec précision si il y a plus de chance d'un côté que de l'autre.
Donc même si l'ordi se laisse une touuute petite chance de gagner en plus, cela peut se voir, et si cela ne se voit pas, et bien ya même pas besoin d'en tenir compte tellement ce sera "fin" (et à moins que tu fasse 1 000 000 000 000 000 expériences :aie:).
Et tu sais pas comment on fait pour évaluer statistiquement les sorties ? Pas grave, j'aurais tendance à dire que c'est celui qui accuse ton logiciel de tricher qui devrait le prouver :)
Sinon, il n'est pas possible à mon sens de prouver qu'un logiciel ne triche pas !
Imaginons que ce ne soit pas ton algorithme qui triche, mais que tu utilise la fonction random (truquée) d'une class que tu aurais crée ! Ou alors que....
Ou alors que tu a fabriqué ton propre bios et que... x) c'est sans fin.
Et même si tu essayais de le prouver avec des méthodes statistiques, il y a toujours moyen de faire plus fin, plus prècis, plus d'expérience...
Du coup pour moi la bonne démarche a utiliser est la présomption d'innocence, c'est vrai tant qu'on a pas prouvé que c'était faux.
Encore une fois, rien ne prouve que lorsque le mode débug est activé, ça ne désactive pas le mode triche... Ca n'apporte donc rien du tout.Citation:
Envoyé par souviron34
De plus, il est assez probablement in envisageable de dévoiler la stratégie et les algos d'un tel jeu s'il y a le moindre enjeux financier..
Imaginons un jeu d'argent où théoriquement, les chance gain/perte sont à 50/50. Et maintenant, supposons que le jeu soit légèrement biaisé pour arriver à 49.9 / 50.1. On ne pourra rien dire en observant les statistique, puisque c'est dans la "marge d'erreur", et pourtant on obtient un jeu rentable pour le "casino". Un simple observation statistique n'est donc pas acceptable..Citation:
Envoyé par cs_ntd
La marge d'erreur est aussi petite que l'on veut.
Il est vrai que la plupart du temps on se satisfait avec des marges de 1% (99% de chances pour que ce soit vrai), mais on peut diminuer cette marge autant qu'on veut.
Après pour que les tests représente quelquechose de concret, il faut augmenter les tirages.
Par exemple, si on prend une série de 0 et de 1:
.Code:00110101
L'échantillon ici n'est pas assez significatif pour dire que cette sortie est aléatoire à 1% près, et cela même si des résultats de tests le disent.
Après si on prend un échantillon de 1000 chiffres, cet échantillon est suffisament représentatif pour pouvoir affirmer quelque chose à 1% près (suivant les tests).
Donc si on veut être sûr de quelque chose à 0,000001% près, il suffit d'augmenter le nombre des sorties, etc etc.
Il n'y a pas vraiment de limites "mathématiques", après, c'est sur que si l'on veut tester une sortie de 1 milliard de milliard de chiffres, ça risque d'être plus compliqué que de traiter 1000 chiffres.
Oui mais il ne s'agit pas d'un jeu de hasard pur. Comment estime tu cette chance de gagner ? Les éléments du jeu peuvent être parfaitement aléatoires, c'est le comportement de l'ordinateur, qui, aidé par une connaissance frauduleuse, fait que tu perds. Pour autant, ce n'est pas parce que tu perds qu'il y a nécessairement tricherie.Citation:
Envoyé par cs_ntd
Effectivement, si l'aléatoire ne rentre pas en ligne de compte, c'est moins évident, bien que tu dises(et à ce moment la, il y a moyen de le vérifier).Citation:
Les éléments du jeu peuvent être parfaitement aléatoires
Sinon, je suppose (car il n'est pas donné beaucoups de détails sur ce que le pc va faire), je suppose qu'il y a moyen d'estimer le comportement "standard" de l'ordinateur, càd le comportement si celui-ci ne triche pas. (Je le suppose, sinon c'est dur de dire que l'ordi triche ou ne triche pas...).
A partir de la, il faut trouver une manière de quantifier son comportement, et voir si le comportement obtenu se rapproche du comportement théorique.
Mais là ça reste assez théorique, probablement que ça ne peut pas s'appliquer "tel quel" sur le modèle. Pour ces choses là, c'est presque tout le temps du cas particulier donc c'est pas évident de raisonner comme ça...
Toujours est-il qu'il est possible de mesurer si il y a un écart significatif entre 2 comportements, aléatoires ou non, la difficultée étant de quantifier les comportements de manière à ne pas fausser les résultats...
Edit :
Prenons un exemple en physique : la chute libre d'un coprs sur la terre (objet soumis qu'a son propre poids).
Il y a un modèle théorique qui permet de trouver la position, la vitesse en fonction du temps, etc..., ce n'est pas un comportement que l'on peut qualifier d'aléatoire.
Malgré tout, si l'on fait des expériences, on ne trouvera pas exactement ce qu'avait prévu le modèle, cela du a des imprécisions de mesures, frottements, etc...
Et cependant, en moyenne, si l'expérience n'est pas biaisée (objet soumis qu'a son propre poids), on vériefiera le modèle théorique, et ce avec une marge d'erreur bien sur.
Mais si effectivement l'objet est soumis à une autre force que son poids (si petite soit-elle), il y a moyen de le détecter, en multipliant les expériences et en affinant les tests.
On retombe sur ce que je disais précedemment.
Au fait, tu proposes quoi pour vérifier que c'est alléatoire ?Citation:
Envoyé par cs_ntd
Il existe un paquet de tests, certains étant plus simple à mettre en oeuvre que d'autres : http://www.math-info.univ-paris5.fr/...urs/ts/ts.html, http://www.u707.jussieu.fr/biostatgv/tests.php, http://fr.wikipedia.org/wiki/Test_(statistique).
Pour tester des séquences binaires : les tests DIEHARD, http://csrc.nist.gov/groups/ST/toolk...ats_tests.html (pour le détail exact de ces tests, avec les explications (mais en anglais) : http://csrc.nist.gov/publications/ni...800-22rev1.pdf).
Mais laissons donc à celui qui accuse l'ordi de tricher le soin de prouver ses dires ;)