Je suis en train de faire le TP du jeu plus ou moins dans le cours de programmation en c et il m'arrive une toute petite bricole, probablement une erreur de débutant ou un concept que je n'ai pas saisi.
Je m'explique : le jeu marche très bien, j'ai implémenté 3 niveaux de difficulté qui fonctionnent également. Mon seul souci est qu'en cas de défaite, si on choisi de recommencer, le programme repart sur le même nombre mystère et n'en génère pas un nouveau alors qu'il le fait après une victoire.
J'ai besoin d'un oeil extérieur pour voir ce que j'ai raté svp.
Voici mon code :
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int main(int argc, char *argv[])
{
const int MIN = 1;
int nombreMystere, guess, retry = 1, compteur = 0, MAX, essaiMax, modeJeu, level;
do
{
//Presentation
printf("Bienvenue dans le jeu du nombre mystere!\n");
//Choix difficulté
printf("Choisissez un niveau de difficulte : 1 = Easy / 2 = Medium / 3 = Hard\n");
scanf("%d", &level);
//Configuration nombre maximum & essais maximum
switch(level)
{
case 1:
MAX = 100;
essaiMax = 8;
break;
case 2:
MAX = 1000;
essaiMax = 20;
break;
case 3:
MAX = 10000;
essaiMax = 50;
break;
default:
//Pour les petits malins
printf("Apparemment vous n'avez pas le niveau minimum requis pour jouer a ce jeu.\n");
printf("Essayez quelque chose de plus simple, je sais pas moi,\n le velo par exemple.\n");
printf("Par contre faites gaffe, mettez bien un casque et des roulettes,\n sinon vous allez vous faire mal.\n");
return 0;
break;
}
//Generation nb aleatoire entre 1 & MAX selon choix precedent
srand(time(NULL));
nombreMystere = (rand() % (MAX - MIN +1)) + MIN;
do
{
//Enonce
printf("Trouvez le nombre compris entre 1 et %d :\n", MAX);
scanf("%d", &guess);
printf("\n");
compteur++;
//Comparaison reponse / solution & compteur de coups
if(guess == nombreMystere && compteur == 1)
{
printf("Du premier coup? Quel talent!!");
printf("Voulez-vous rejouer?\n 1 = Oui / 0 = Non\n");//Nouvelle partie
scanf("%d", &retry);
compteur = 0;
}
else if(guess < nombreMystere && compteur < essaiMax)
{
printf("Le nombre mystere est plus grand! Essayez encore!\n");
}
else if(guess > nombreMystere && compteur < essaiMax)
{
printf("Le nombre mystere est plus petit! Essayez encore!\n");
}
else if(guess == nombreMystere && compteur < essaiMax)
{
printf("Bravo! Le nombre mystere est bien %d!\n", nombreMystere);
printf("Vous avez trouve la solution en %d coups.\n", compteur);
printf("Voulez-vous rejouer?\n 1 = Oui / 0 = Non\n");//Nouvelle partie
scanf("%d", &retry);
compteur = 0;
}
else if(guess != nombreMystere && compteur == essaiMax)
{
printf("Vous avez perdu!\nLe nombre mystere etait %d.\n", nombreMystere);
printf("Voulez-vous rejouer?\n 1 = Oui / 0 = Non\n");//Nouvelle partie
scanf("%d", &retry);
compteur = 0;
}
}
while(guess != nombreMystere);
}
while(retry == 1);
return 0;
}
J'espère avoir été clair dans mes explications et je vous remercie d'avance pour le coup de patte!
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!
Bonjour ! Je ne sais pas si c'est l'explication du problème, mais l'initialisation de la suite aléatoire ne doit pas être refaite à chaque fois, il faut le faire une fois pour toutes au début. Donc ce que tu as placé à la ligne 47 devrait être placé à la ligne 9.
Merci de ta réponse. En fait, mon but est de rejouer une partie différente à chaque fois, sans avoir à relancer le programme, c'est pourquoi je ne suis pas ta solution. Ce que je cherche, c'est à recommencer avec un nouveau nombre en cas de défaite. Comme expliqué lors de mon premier post, ça se passe correctement en cas de victoire mais pas en défaite. Mon soucis doit donc provenir de la ligne 83 et suite.
Pour info, ne surtout pas mettre la génération du nombre aléatoire dans la deuxième boucle while, sinon le nombre mystère change à chaque tentative. Ce qui peut être assez rigolo, j'en conviens, mais quand même, c'est pas gentil!
Merci encore d'avoir jeté un oeil dessus
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!
Si tu retrouves le même nombre à chaque fois, c'est que nombreMystere n'a pas été modifié. La seule ligne qui le modifie est ligne 48 ; en fait, il n'est pas passé par la ligne 48 du tout en recommençant.
A ton avis, par où est-il passé ? Tu peux utiliser un débogueur pour t'aider, et exécuter le programme pas à pas (avec un nombre de coups max = 1 ou 2 pour que tu perdes rapidement). Tu vas voir l'erreur tout de suite.
PS : t'as une jolie boucle infinie si tu rentres par exemple "5a" comme nombre
JérémieBOZANT a écrit:
Bonjour robun,
Merci de ta réponse. En fait, mon but est de rejouer une partie différente à chaque fois, sans avoir à relancer le programme, c'est pourquoi je ne suis pas ta solution. Ce que je cherche, c'est à recommencer avec un nouveau nombre en cas de défaite. Comme expliqué lors de mon premier post, ça se passe correctement en cas de victoire mais pas en défaite. Mon soucis doit donc provenir de la ligne 83 et suite.
Pour info, ne surtout pas mettre la génération du nombre aléatoire dans la deuxième boucle while, sinon le nombre mystère change à chaque tentative. Ce qui peut être assez rigolo, j'en conviens, mais quand même, c'est pas gentil!
Merci encore d'avoir jeté un oeil dessus
srand(time(NULL)) ne va te générer aucun nombre aléatoire. Il initialise le générateur aléatoire. La génération aléatoire c'est le rand() qui le fait.
Ce code là te retourne les mêmes valeurs aléatoires :
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int main(void){
srand(time(NULL));
for (int i = 0 ; i < 2 ; i++)
printf("%u\n", rand());
srand(time(NULL));
for (int i = 0 ; i < 2 ; i++)
printf("%u\n", rand());
}
1193897653
1076995305
1193897653
1076995305
Petite explication : rand() n'est pas du vrai aléatoire. C'est ce qu'on appelle du pseudo-aléatoire. ça utilise une fonction mathématique (e.g. ax+b mod n) pour générer une suite de nombre, à partir d'un seed. Par exemple, si le seed est 23, ça pourrait faire 23 -> 42 -> 12 -> ... .
Pour illuster, tu peux remplacer le srand(time(NULL)) de mon exemple par srand(42). Je peux te garantir que tu vas obtenir les deux nombres suivants en sortie aléatoire : 71876166 et 708592740
Le time(NULL) renvoie un temps en seconde (c'est le temps en seconde qui s'est écoulé depuis une certaine date dans les années 70). De ce fait, sauf si tu lances ton programme deux fois par seconde, a priori tu devrais trouver des valeurs différentes entre chaque appel de ton programme à time(NULL). Par contre, ça n'a pas de sens de réinitialiser srand avant chaque appel à rand(), à cause de ce que j'ai dit plus haut : si tu fais plus de 2 appels par seconde à srand(time(NULL)), tu vas te retrouver avec les mêmes valeurs aléatoires.
D'où la remarque de robun de mettre srand(time(NULL)) au début de ton programme. Ici ça n'a pas un grand impact car l'utilisateur passe plus d'une seconde à deviner a priori, mais dans d'autres programmes tu pourrais avoir des soucis.
- Edité par potterman28wxcv 20 novembre 2017 à 17:17:26
Merci pour tes explications. Ce que je ne comprends pas, en revanche, c'est pourquoi le nombre change en cas de victoire? C'est vraiment ça mon problème.
Si je relance une partie après avoir gagné, le programme repart bien du début de la première boucle do-while et le nombre change. Pas en cas de défaite. Donc pour résumé, pourquoi la ligne 48 modifie le nombre mystère seulement en fonction du résultat de ma partie?
Certes, j'ai mis un nombre de tentatives assez élevé pour pouvoir trouver aisément mais au cas où je souhaite le rendre plus ardu, un retry ne devrait pas me relancer la même chose exactement.
Edgarjacobs, ne t'en fais pas, je pensais bien finir par simplifier le code à terme, mais en débutant que je suis, je préfère suivre les procédures bien lourdes pour intégrer les bases et apprendre à les alléger par la suite.
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!
Merci pour tes explications. Ce que je ne comprends pas, en revanche, c'est pourquoi le nombre change en cas de victoire? C'est vraiment ça mon problème.
Si je relance une partie après avoir gagné, le programme repart bien du début de la première boucle do-while et le nombre change. Pas en cas de défaite. Donc pour résumé, pourquoi la ligne 48 modifie le nombre mystère seulement en fonction du résultat de ma partie?
Après avoir gagné, le programme repart bien du début de la première bouche while.
Qu'en est-il quand tu perds ? Où repars-tu ? Utilise un débogueur
Ou si tu ne veux pas t'en servir, utilise le débogueur du pauvre : met des printf partout pour savoir où le programme passe ! Mais ne reste pas bloqué à lire le code ; modifie ton code, expérimente avec jusqu'à ce que tu trouves ce qui ne va pas.
Pour info, je n'ai pas vu l'erreur de moi même non plus ; il m'a fallu exécuter ton code de mon côté et expérimenter. C'est toujours comme ça en informatique, les erreurs ne sont jamais évidentes - à toi de tester et retester tout ce qui te semble évident jusqu'à ce que tu trouves la faille.
- Edité par potterman28wxcv 20 novembre 2017 à 17:45:53
Je viens de faire quelques essais mais pour l'instant rien de probant. Je vais continuer à manipuler, comme je fais depuis le début et comme tu me le conseilles .
Puis apprendre à me servir d'un débogueur tant qu'à faire!
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!
Je viens de faire quelques essais mais pour l'instant rien de probant. Je vais continuer à manipuler, comme je fais depuis le début et comme tu me le conseilles .
Puis apprendre à me servir d'un débogueur tant qu'à faire!
Oui ça peut être une bonne occasion d'apprendre à se servir d'un débogueur Tiens nous au jus !
L'erreur est facile, mais si tu la trouves par toi même t'auras fait les premiers pas dans l'apprentissage du déboguage Quand on code on passe plus de la moitié du temps à déboguer et à tester, donc autant te dire que ça va beaucoup te servir plus tard
- Edité par potterman28wxcv 20 novembre 2017 à 18:01:33
Ou si tu ne veux pas t'en servir, utilise le débogueur du pauvre : met des printf partout pour savoir où le programme passe ! Mais ne reste pas bloqué à lire le code ; modifie ton code, expérimente avec jusqu'à ce que tu trouves ce qui ne va pas.
Pour info, je n'ai pas vu l'erreur de moi même non plus ; il m'a fallu exécuter ton code de mon côté et expérimenter. C'est toujours comme ça en informatique, les erreurs ne sont jamais évidentes - à toi de tester et retester tout ce qui te semble évident jusqu'à ce que tu trouves la faille.
Ah, ça me fait plaisir de lire ça ! Ce que tu viens de dire, je crois que c'est le plus important à retenir quand on apprend à programmer. Ton message, il faudrait l'encadrer dans toutes les salles de cours d'informatique...
-----
Sinon, je viens de faire tourner le programme et de regarder comment il marche, et j'ai trouvé l'erreur moi aussi. Du coup je te donne un indice. Tu sais qu'il y a quelque chose de louche dans la boucle des lignes 84-89. Eh bien, dans cette boucle, fais afficher l'état des variables, surtout des variables qui pourraient servir à la reprise ou non du jeu (qui dépend de la ligne 91)...
Merci pour les indications. J'ai pas encore tout à fait trouvé mais appremment, ligne 91, quand on valide un "retry", il affecte également la valeur 1 à "guess", si j'ai bien compris. Donc il considère que la partie n'est pas finie tant que je n'ai pas trouvé le nombre mystère, c'est pourquoi il ne sort pas de la boucle. Le problème viendrait donc du premier "while". Je pense que je ne suis plus très loin.
Je débute vraiment dans le code donc certaines choses me sont encore obscures et je veux savoir si j'ai bien saisi ce que m'a dit mon débogueur (celui de code::blocks, pour info).
L'un de vous deux peut-il juste me confirmer si je suis en bonne voie ou si je me fourvoie? Pas besoin d'indications en plus, il faut effectivement que la solution vienne de moi.
Merci beaucoup de votre aide jusqu'à maintenant en tout cas!
- Edité par LordOfTheSlips 21 novembre 2017 à 15:22:38
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!
Merci pour les indications. J'ai pas encore tout à fait trouvé mais appremment, ligne 91, quand on valide un "retry", il affecte également la valeur 1 à "guess", si j'ai bien compris. Donc il considère que la partie n'est pas finie tant que je n'ai pas trouvé le nombre mystère, c'est pourquoi il ne sort pas de la boucle. Le problème viendrait donc du premier "while". Je pense que je ne suis plus très loin.
Je débute vraiment dans le code donc certaines choses me sont encore obscures et je veux savoir si j'ai bien saisi ce que m'a dit mon débogueur (celui de code::blocks, pour info).
L'un de vous deux peut-il juste me confirmer si je suis en bonne voie ou si je me fourvoie? Pas besoin d'indications en plus, il faut effectivement que la solution vienne de moi.
Merci beaucoup de votre aide jusqu'à maintenant en tout cas!
- Edité par LordOfTheSlips il y a 26 minutes
Oui tu es sur la bonne voie.
Si ça peut t'aider, faut que tu voies les variables comme des "cases mémoire", et non comme des variables au sens mathématique du terme. Je pense que c'est peut être cette notion qui te pose problème.
int a = 5; // a vaut 5
a = a + a; // a vaut 5 + 5 = 10
a = (a + 3) * 2; // a vaut (10 + 3) * 2
scanf("%d", &a); // l'utilisateur rentre un nombre.. e.g. 42
a = a + 2; // a vaut maintenant 42 + 2 = 44
Une variable n'est modifiée que lors des affectations, et lors des scanf. Nulle autre part n'est une variable modifiée.
En particulier, il n'y a aucune relation entre "rentrer un retry" et "modifier guess à 1". C'est deux choses complètement indépendantes. Dans mon exemple, si je fais un scanf("%d", &b), ça ne modifiera pas la valeur de a.
Prends un bout de papier, un crayon, et exécute "à la main" le deuxième do..while . C'est à dire que tu notes les valeur de toutes les variables, et à chaque ligne tu notes les changements de valeur - fais comme si c'était toi le langage C, et répond à ces questions :
Quelle ligne modifie la variable guess ? Quand tu dis que guess a été affecté à 1, d'où vient ce 1 ? Que se passe t'il alors à la ligne 91 ?
C'est exactement ce que j'avais compris mais je ne vois pas encore où est l'erreur.
Je vais tenter avec la méthode papier/crayon, effectivement puisqu'il n'y a que ça que je n'ai pas essayé et effectivement, ça devrait d'une part me donner un bon réflexe, et d'autre part me faire réfléchir plus efficacement.
Je te tiens au courant de la suite.
Merci pour ta disponibilité encore une fois
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!
C'est exactement ce que j'avais compris mais je ne vois pas encore où est l'erreur.
Imagine que nombreMystere est 42, et que je rentre 18 lors de ma dernière tentative : que vaut alors guess ? guess est-il différent ou égal à nombreMystere ? Le programme va t'il reboucler à la ligne 50 ou à la ligne 10 ?
- Edité par potterman28wxcv 21 novembre 2017 à 18:36:26
J'ai enfin réussi. Effectivement, je ne faisais pas reboucler au bon endroit. J'ai enlevé tous les retry des if/else pour n'en placer qu'un seul après le premier while. J'ai aussi dû mettre un "break" dans le dernier if/else pour que le programme marche comme je le souhaite, mais je ne sais pas si c'est une bonne pratique.
Encore une fois un grand merci pour votre patience, votre aide et vos explications!
Je chanterai vos légendes partout où je passerai en France et en Navarre et par delà les 7 Mers!
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!
En fait je pensais à une rectification beaucoup plus simple, mais après tout, tu as peut-être raison de réorganiser les boucles.
Quand j'ai essayé ton programme, j'ai juste ajouté une ligne pour que ça marche. En effet, la ligne 91 fait reboucler tant que 'guess' est différent de 'nombreMystere'. Donc il y a deux situations :
─ Si on a gagné, c'est que 'guess' est égal à 'nombreMystere', donc on sort de la boucle 50-91. Ensuite, tout dépend de la valeur de 'retry' : si elle vaut 1, l'ordinateur génère un nouveau nombre et on rejoue une partie, sinon le programme s'arrête.
─ Mais si on a perdu, 'nombreMystere' n'est toujours pas égal à 'guess' (eh oui !), du coup on reste dans la boucle 50-91, donc il ne change pas de 'nombreMystere'.
Pour rectifier ça, il suffit d'affecter 'nombreMystere' à 'guess' après qu'on ait perdu. J'ai donc ajouté, entre la ligne 85 et la ligne 86, ceci :
guess = nombreMystere ;
Tout simplement ! Et là ça marche : je viens d'essayer.
(Le secret, c'est de comprendre l'erreur avant de la rectifier.)
Grâce à toutes vos explications, j'avais bel et bien fini par comprendre que je restais coincé dans cette boucle à cause du nombreMystere qui n'était pas égal à guess, donc rebouclage ligne 50 au lieu de ligne 10. Effectivement, ta solution est beaucoup plus simple, mais je préfère réorganiser les boucles dès le départ pour avoir un programme plus "propre", après tout, ça lui enlève 2 tests
Je vais par la suite simplifier les tests comme l'a suggéré edgarjacobs car cela va alléger le code et être plus digeste.
- Edité par LordOfTheSlips 22 novembre 2017 à 9:43:00
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!
J'avais tenté de créer une variable "perdu" et de rajouter une condition, mais je n'ai pas trouvé comment organiser correctement. Je m'approchais de ta solution, cependant, je n'obtenais pas le résultat escompté. Effectivement, ta réponse est simple et limpide!
Je vais clore le topic et vous remercie encore une fois grandement pour l'aide apportée et les encouragements!
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!
J'avais tenté de créer une variable "perdu" et de rajouter une condition, mais je n'ai pas trouvé comment organiser correctement. Je m'approchais de ta solution, cependant, je n'obtenais pas le résultat escompté. Effectivement, ta réponse est simple et limpide!
Je vais clore le topic et vous remercie encore une fois grandement pour l'aide apportée et les encouragements!
Pas de souci C'est toujours un plaisir d'aider ceux comme toi qui sont curieux et débrouillards !
En dernier conseil, te casse pas trop la tête en programmation. Il ne s'agit pas d'écrire "la meilleure solution", mais bien d'en écrire une qui marche dans un premier temps, et de la raffiner au fur et à mesure.
D'ailleurs, il parait qu'une étude a montré qu'avec une bière on est plus productif en informatique, vu qu'on restraint moins nos idées et on essaie plus de choses.. Mais voilà faut surtout pas se casser la tête à écrire les choses les plus jolies possibles. Ecrit ce qui te passe par la tête, compile, essaie, et vois si ça fait ce que tu veux ou pas
Au lieu de supprimer des parties de code, tu peux aussi les commenter (rajouter // au début de chaque ligne). Comme ça si tu changes d'avis, tu peux les réutiliser par la suite. Puis une fois que t'as codé ce que tu veux, tu fais un peu de nettoyage. Plus tu coderas, et plus t'auras la bonne intuition du premier coup ; mais avant ça, faut faire ce qu'on appelle du trial & error jusqu'à ce que tu tombes sur quelque chose qui marche.
Bon courage pour la suite du cours !
- Edité par potterman28wxcv 22 novembre 2017 à 11:43:13
Alors si il faut boire de la bière pour être efficace, je vais rapidement devenir un programmeur de talent!
Bourré h24, certes, mais de talent quand même!
Mais rassure-toi, ce n'est pas le principal conseil que j'ai retenu dans tout ce que tu m'as dit.
Là je peaufine pour le mode 2 joueurs et bizarrement je retrouve le même souci avec pourtant les mêmes lignes (sauf le scanf pour donner le choix au Joueur 1 à la place de rand()). J'ai tenté d'affecter une variable nombreMystere2Joueurs pour cette séquence mais rien n'a changé.
J'ai peut-être simplement une erreur de syntaxe je n'ai pas encore vérifié. Mais je vais bien trouver!
Bon appétit!
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!
C'est toujours un plaisir d'aider ceux comme toi qui sont curieux et débrouillards !
Pareil !
Programmer en C : plus ou moins.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!
As soon as we try to force-feed different problems within an application to a single specific programming paradigm, we’re not thinking creatively and we’re not working efficiently!