V�rification pour un jeu en C++

Bonjour a tous !

J'�tais en terminale S cette ann�e avec option info et j'ai appris le C++ tous seul depuis plusieurs ann�es maintenant.
Pour mon projet de fin d'ann�e j'ai fait un jeu en C++ qui m'a permis de d�crocher un petit 20 coef 2 :roll: :mouarf:

Mon projet se trouve ici https://github.com/wistifer/jeu_isn

Cependant, malgr� la bonne note que j'ai eu je voulais me tourner vers des d�veloppeurs en C++ plus exp�riment�s pour avoir un avis sur mon programme qui est sans doute un peu maladroit :?

J'aimerais donc savoir ce que vous pensez de ce que j'ai fait sur l'organisation, les classes et si vous avez des conseils pour optimiser mon code :roll:

J�esp�re que github marchera bien je n'ai pas encore l'habitude de l'utiliser ...

Merci d'avance pour tous vos conseils n�h�sitez pas !!

Alex

Salut

J'ai test� vite fait sur linux.

� la compilation, il y a quelques erreurs :
- pour les include c'est / et non \ donc il faut mettre #include <SFML/graphics.hpp> et non #include <SFML\graphics.hpp> dans les .h
- il faut ajouter #include <cmath> au d�but de decor.cpp

Pour l'ex�cution, il manque les dossiers Jeu/Jeu/graphics/hero et Jeu/Jeu/graphics/ennemi.

Je n'ai pas trop regard� le code sinon...

Effectivement merci 8O ...
J'ai corrig� ces petites erreurs c'est bon !

Ok, �a compile mieux.

Au niveau du gameplay, c'est un peu �trange : il y a 3 ennemis au d�but et plus rien ensuite.

Au niveau du code, je n'ai pas trop regard� l'organisation des classes mais d�j� tu as des fuites m�moires. Par exemple dans Ennemi::updatePerso tu fais un Collision * test = new Collision; mais tu ne fais pas de delete. Et au final, je pense que tu n'as pas besoin de pointeur, un Collision test; suffit. Pareil pour vector<Ennemi*> * tabPerso dans loadPerso : pas besoin de pointeur. D�clare une variable statique vector<Ennemi> et passe-la en param�tre de fonction par r�f�rence vector<Ennemi> & tabPerso.

Mais sinon, pour un lyc�en qui a appris tout seul, c'est pas mal du tout. Continue comme �a.

Merci de t'�tre pench� sur mon programme et pour ces conseils !!

Citation:

---

Au niveau du gameplay, c'est un peu �trange : il y a 3 ennemis au d�but et plus rien ensuite.

---

effectivement je vais changer �a :?

Citation:

---

un "Collision test;" suffit.

---

�a semble mieux pour g�rer les fuites je comprend je pensais qu'il ballait mieux cr�er un pointeur d�s qu'on en avait l'occasion mais �a semble plus logique ainsi 8O

Citation:

---

D�clare une variable statique "vector<Ennemi>"

---

je n'y avait pas pens� c'est plus pratique merci beaucoup !

Hello, tr�s rapidement en vrac c�t� code C++

- Balle::getDirection n'est pas const-correct, pareil pour l'autre getter. Pareil dans les autres classes.
- Balle::getCollision. C'est bizarre de renvoyer le r�sultat par param�tre sortant. En plus, ce n'est pas n�cessairement plus performant. Accessoirement, pr�f�re une r�f�rence � un pointeur : quid si l'utilisateur se plante et te passe un pointeur nul ? Avec une r�f�rence tu dis clairement: "you shall not pass". Ce probl�me de plein de pointeurs qui auraient dus �tre des r�f�rences est assez r�current.
- Constructeur par d�faut de Balle: est-ce que cela a vraiment du sens � ce que ce constructeur existe
- Balle::Balle(sf::Vector2f const a, bool dir): C'est plus gros que 2 int un Vector2f? Si oui, il peut �tre pr�f�rable de le passer par r�f�rence constante. A voir.

- typedef.h: Ne jamais mettre de using namespace dans un .h. Cf la FAQ
- typedef struct {...} Nom;: C'est du C �a. En C++, c'est plus simple: struct Nom{...};
- pr�f�re les enum class du C++11 aux enum

- beaucoup trop d'includes inutiles dans Decor.h (et ailleurs) -- �a fait inclusions magiques comme si tu ne savais pas pourquoi tu inclus quel fichier.
- vector<vector<int>> n'est pas une structure efficace pour stocker une structure carr�e. Pr�f�re une classe d�di�e avec une seule allocation et o� tu redistribues les coordonn�es pour "d�linairiser" si je puis dire. Exemple ici: https://github.com/LucHermitte/ticta...actoe.cpp#L182

- Decor::getMap n'a aucun effet: tu modifies une variable locale (un param�tre pris par copie est une variable locale) pour lui donner une adresse, qui restera donc locale. La fonction est-elle bien n�cessaire? Puisqu'elle ne marche pas, c'est qu'elle ne doit pas �tre utilis�e. Ne fait pas des getter pour le plaisir d'en faire. Fais-en uniquement si tu en as besoin ailleurs.

- lecture des fichiers: toujours tester les r�sultats des lectures et des ouvertures de fichiers en cas d'erreurs. Sinon tu vas traiter des donn�es qui n'ont aucun sens et ne rien y comprendre. La FAQ en parle je crois.

- Decor::loadMap() m�riterait un d�coupage en sous-fonctions. Typiquement le switch devrait �tre une fonction � part.

- Ennemi: beaucoup trop de pointeurs bruts: R�sultat tu as une fuite de m�moire derri�re la variable test -- cela aurait d� �tre un objet sur la pile. Pour les balles, tu aurais d� employer des std::unique_ptr je soup�onne. M�me chose pour les Hero, d'ailleurs cela sens la duplication de code � plein nez. Essaie de factoriser si tu peux -- les fonctions virtuelles t'aideront pour permettre de sp�cialiser les points de variation.
- Pas s�r que tu aies besoin d'un constructeur par d�faut pour Ennemi

Merci beaucoup pour tes remarques !!

J'ai quelques questions..

Citation:

---

Balle::getDirection n'est pas const-correct,

---

Qu'est ce que tu entends par const correct et pourquoi ? :?

Citation:

---

Accessoirement, pr�f�re une r�f�rence � un pointeur

---

Il faudrait donc une r�f�rence comme �a ?

Code:

---

void getCollision(Collision &test);

---

Citation:

---

C'est plus gros que 2 int un Vector2f?

---

Comment je peux savoir �a ?

Citation:

---

Pour les balles, tu aurais d� employer des std::unique_ptr je soup�onne.

---

Je n'ai pas encore tr�s bien saisi la diff�rence entre les pointeurs et les unique_ptr mais je suis en train d'y travailler :roll:

Citation:

---

Essaie de factoriser si tu peux

---

J'ai d�j� essay� de factoriser au maximum mais le probl�me est que certaines fonctions prennent des param�tres diff�rents et je ne peux donc pas ... Si tu vois des solutions je veux bien que tu me dises :roll:


En tout cas merci encore de m'avoir �clair� sur ces points je vais reprendre un peux mon code !! :mrgreen:

- A propos de const-correct: ta fonction d�clare qu'elle pourrait modifier l'objet sous-jacent. Ca doit exister, mais je n'ai pas de bon lien sous la main
- https://cpp.developpez.com/faq/cpp/?...apres-leur-nom
- https://isocpp.org/wiki/faq/const-co...overview-const

- Oui pour la r�f�rence, mais j'ai m�me envie de dire que le plus efficace serait probablement

Code:

---

Collision getCollision() const;

---

- Au sujet du type plus gros que 2 int: en lisant la doc, en faisant des test, en affichant son sizeof, en regardant s'il porte une charge utile de type m�moire allou�e, etc

- > "J'ai d�j� essay� de factoriser au maximum mais le probl�me est que certaines fonctions prennent des param�tres diff�rents et je ne peux donc pas ... Si tu vois des solutions je veux bien que tu me dises "

tout le code qui est identique devrait �tre factorisable d'une fa�on ou d'un autre. Cela va tr�s probablement signifier que tu vas devoir extraire plusieurs fonctions: des fonctions pour les choses identiques, et des fonctions pour les choses diff�rentes.


PS: avec r�flexion, que certains de tes objets d�rivent des classes de sprites est tr�s bizarre. Que la balle contiennent un sprite pour la repr�senter OK, qu'elle soit un sprite, c'est plus �trange.

Salut,

Citation:

---

Envoy� par Luc Hermitte

PS: avec r�flexion, que certains de tes objets d�rivent des classes de sprites est tr�s bizarre. Que la balle contiennent un sprite pour la repr�senter OK, qu'elle soit un sprite, c'est plus �trange.

---

Et meme le fait que la balle contienne un sprite, c'est tr�s largement discutable, car la notion de sprite est une notion qui intervient dans un type de vue bien particulier, alors que la notion de balle en elle-m�me repr�sente une donn�e purement m�tier : c'est "quelque chose" qui se trouve, � un instant T � un endroit donn�, mais qui se d�place dans n'importe quel sens et qui rebondit lorsqu'elle touche un obstacle.

Maiis tout ce que l'on doit savoir sur elle, en d�finitive, c'est sa position � un instant T ;)

Quant � la notion de collision en elle-m�me, ce serait sans doute plut�t du ressort d'un controleur quelconque, qui se fout pas mal de savoir quelle forme peuvent prendre la balle ou les briques, mais qui doit juste pouvoir d�terminer, quelle brique la balle touche, � un instant T, pour pouvoir mettre les donn�es sur les briques � jour ;)

Citation:

---

Code:

---

Collision getCollision() const;

---

---

Cette solution semble en effet bien plus logique... Mais je me disais que c'�tait peu �tre plus rapide et moins lourd de passer par des r�ferences

-Pour cette histoire de sprite je comprend effectivement que faire h�rit� la classe de Sprite ne soit pas tr�s correct... Il vaudrait mieux la mettre comme attribut de la classe tout simplement.

Citation:

---

Et meme le fait que la balle contienne un sprite, c'est tr�s largement discutable

---

Mais comment je peux lui appliquer mon Sprite donc? Il faudrait le cr�er dans le main? :?

Dans l'absolu tu aurais une classe Balle qui contient tous les �l�ments de la balle (position, etc), et une BalleRendu qui se chargerait d'afficher la Balle.
En pratique tu peux embarquer le sprite dans Balle, ca facilitera les choses et tu changes rarement la m�thode de rendu lors d'un projet. Tu peux aussi avoir un moteur de rendu qui propose une classe Sprite abstraite qui permet de changer le rendu sans toucher au Sprite dans Balle.

Je comprend et dans ce cas la il faudrait que la classe RenduBalle ai comme attribut une Balle pour pouvoir determiner sa position etc?

Par exemple. Il peut aussi s'agir d'une seule fonction libre qui prend une Balle ou un tableau de Balle pour les afficher.

D'accord merci beaucoup pour toutes ces r�ponses et pour votre aide !