Bonjour, j'ai codé il y a quelques jours un jeu de labyrinthe qui se crée aléatoirement et dont il faut sortir en se procurant une clé.
Je vous invite a l'essayer et a me dire ce qui vous a plus et surtout ce qui ne vous plait pas !
L'arrivée c'est la case rouge et le petits diablotins sont la pour vous gener
Comme moi aussi je m'intéresse aux labyrinthes en ce moment (c.f. ma signature), j'ai testé ton labyrinthe. De manière générale, cela fonctionne bien, même si au premier essai il est resté bloqué à l'initialisation du labyrinthe.
Quelques remarques sur le jeu en général:
Je trouve le jeu un peu petit (taille des images); je l'aurais fait plus grand.
Les ennemis bougent bizarrement, est-ce voulu ?
Dommage qu'il n'y ait pas de menu.
Quelques remarques sur le code:
Tu fais une sorte de mélange C-C++, bizarre et dommage.
L'abus de variables globales est dangereux pour la santé
Une fonction ne devrait pas faire plus de 60-80 lignes. Découpe plus ton code en petit morceau. C'est plus facile à relire.
Manque un peu de commentaires, tout n'est pas très clair dans ton code
Pourquoi include iostream & cstdlib ??
Sinon, je le redis, ton programme fonctionne bien, peut-être manque-t'il un peu d'originalité.
Pour ce qui est de la taille des cases, je les aurais bien faites plus grandes mais je ne voulais pas faire d'arrière plan défilant (en fait je voulais plus voir si j'arrivais à faire un labyrinthe que faire un vrai jeu, et je pense que ça se voit...) tout en voulant garder la possibilité de faire des grands niveaux.
Pour ce qui est du déplacement des ennemis, il est tout simplement aléatoire (ils choisissent une direction et ils la suivent s'ils le peuvent, sinon ils restent où ils sont).
Pour ce qui est des variables globales, j'ai vu quelque part dans un livre que j'ai feuilleté qu'en C++ on évite de faire des "#define" mais qu'on utilise plutôt des entiers constants déclarés globalement... je ne sais plus quoi penser...
Pour ce qui est des include, j'ai tout simplement oublié de les enlever car je m'en suis servi pour faire des cout pour tester certaines choses...
Pour ce qui est du manque de découpage en fonctions, c'est vrai que j'ai un peu abusé, mais comme j'étais parti sur un simple générateur de laby, le code du jeu s'est rajouté par-dessus... et c'est vrai que c'est pas bien beau...
Par contre je ne vois pas trop où je mélange C et C++ et je te serais reconnaissant de me citer quelques exemples pour que je puisse à l'avenir soigner ce problème. Merci d'avance !
Enfin, avec tes conseils et un peu de motivation, je verrai si je ne pourrais pas en faire un vrai jeu plus propre avec menu et gestion des scores (peut-être en fonction du temps...)
Pour ce qui est des variables globales, j'ai vu quelque part dans un livre que j'ai feuilleté qu'en C++ on évite de faire des "#define" mais qu'on utilise plutôt des entiers constants déclarés globalement... je ne sais plus quoi penser...
Les deux sont à consommer avec modération mais le deuxième (trucs global) devrait être utilisé le moiiiins possible (sauf en cas d'exception)... disons seulement qu'utiliser des variables global est une mauvaise habitude...
Altarapp.com - Applications, Code Snippets, API Wrappers et etc, le tout en C# le plus clair du temps!
Peux tu me dire quelles formules tu as utilisé pour générer tes labys ?
Pour ma part, j'ai également fait des générateurs de laby :
- un générateur/solveur de laby de grande taille, qui exporte des BMP
- un laby 3D appelé Klostro Laby, qui donne mal au coeur
regarde ma signature
Pour ce qui est des variables globales, j'ai vu quelque part dans un livre que j'ai feuilleté qu'en C++ on évite de faire des "#define" mais qu'on utilise plutôt des entiers constants déclarés globalement... je ne sais plus quoi penser...
Les deux sont à consommer avec modération mais le deuxième (trucs global) devrait être utilisé le moiiiins possible (sauf en cas d'exception)... disons seulement qu'utiliser des variables global est une mauvaise habitude...
Ben, pour des classes à sémantique de valeur genre les classes de vecteur pour DirectX, je trouverais ça naturel d'avoir prédéfini comme constantes globales le vecteur nul, et les vecteurs de bases x,y,z.
La mauvaise habitude dangereuse c'est les variables globales utilisées non pas en tant que constante, mais en tant que données nécessaires au programme, alors que paramètre de fonction.
Ben, pour des classes à sémantique de valeur genre les classes de vecteur pour DirectX, je trouverais ça naturel d'avoir prédéfini comme constantes globales le vecteur nul, et les vecteurs de bases x,y,z.
La mauvaise habitude dangereuse c'est les variables globales utilisées non pas en tant que constante, mais en tant que données nécessaires au programme, alors que paramètre de fonction.
hm ouais, d'accord avec toi
Altarapp.com - Applications, Code Snippets, API Wrappers et etc, le tout en C# le plus clair du temps!
Pour ce qui est des variables globales, j'ai vu quelque part dans un livre que j'ai feuilleté qu'en C++ on évite de faire des "#define" mais qu'on utilise plutôt des entiers constants déclarés globalement... je ne sais plus quoi penser...
Pour ce qui est du manque de découpage en fonctions, c'est vrai que j'ai un peu abusé, mais comme j'étais parti sur un simple générateur de laby, le code du jeu s'est rajouté par-dessus... et c'est vrai que c'est pas bien beau...
Par contre je ne vois pas trop où je mélange C et C++ et je te serais reconnaissant de me citer quelques exemples pour que je puisse à l'avenir soigner ce problème. Merci d'avance !
Je reviens juste sur ces 3 points, car ils me semblent essentiels pour bien programmer.
Variables globales
La question n'est pas d'utiliser des #define ou des const int (Encore que mieux vaut la 2ème solution). Le but c'est d'utiliser aucun des 2. Chez toi les variables globales sont constantes ce n'est donc pas trop grave. Mais le mieux encore c'est de faire sans. Ca rend le code plus compréhensible. Et tu es maîtrises entièrement tes variables ce qui n'est pas le cas ici.
Fragmentation du code
Même pour un "simple" générateur de labyrinthe on devrait par principe, séparer les tâches à effectuer en sous-tâches et ainsi de suite. Surtout que plusieurs taches sont identiques à une valeur prêt dans tes fonctions. Mieux vaut en faire une sous-tache, ça rendra le code plus lisible et maintenable. Est-ce que tu comprendras encore tout ce que fais ta fonction dans 3 mois, 1 an ? Simplifie en découpant, ca rend plus clair.
Melange C - C++
En fait n peu partout.
Tu utilises stdlib => C et iostream => C++
Tu utilises des fprintf => C et des bool => C++ sur la même ligne
...
Autres choses à améliorer
Ne jamais utiliser exit(blablabla). C'est réservé au cas où la suite du programme risquerait de faire des dégats irréparables en continuant. En gros c'est l'arrêt d'urgence et uniquement l'arrêt d'urgence.
Utilises des break dans tes boucles. Tu fais énormément d'itérations pour rien.
Tu peux enregistrer tes niveaux dans des fichier, cela te permettrai:
- De faire beaucoup plus de niveaux en moin de code;
- De modifier tes niveaux en un rien de temps
- De créer un éditeur de niveau;
Enfin voila comment j'ai pensé pour ton jeu.
Au revoir
Je tiens à spécifier que l'utilisation des constantes est excellente et qu'elles sont normalement globales... les seuls cas où les constantes ne le sont pas c'est lorsqu'elles appartiennent à une classe.
Je préfère voir des constantes auto-documentées dans le code plutôt que des nombres et des lettres un peu partout.
// lorsque que notre niveau de ressource atteint le niveau critique
if RessourcesRestantes < 5
Message("Le niveau des ressource est affreusement bas, vous devez construire plus de batiments d'exploitation.");
// c'est moins clair et moins lisible que
if RessourcesRestantes < NIV_RES_CRITIQUE
Message( MES_RES_CRITIQUE );
Je me fou de ce que c'est le niveau critique, tout ce que je veux savoir c'est où s'en va le code... Ce qui permet en plus de pouvoir modifier la constante facilement pour passer de 5 à 6 je n'ai qu'à aller voir où je déclare mes constantes et changer le niveau.
Sans oublier que si vous vérifiez le niveau critique à plusieurs endroits vous serez content de pouvoir le modifier aussi rapidement.
Les constantes NE SONT PAS des variables et tout ceux qui me sorte l'argument invalide du const_cast je vous répond d'avance que c'est de la malprogrammation!
Je suis donc POUR les constantes apportant une précision et une compression du code.
Testez mon jeu !
× 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.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html