Bonjour,
Ah ! Amusant, votre dossier 'src', contient les ressources (images, sons...). G�n�ralement, le dossier 'src', contient, les sources 
. Les m�dias, �a va dans un dossier "res" ou "resources".
Chose que l'on peut am�liorer : mettre en ligne le fichier du projet/Makefile, ou encore mieux, un fichier d'un g�n�rateur de projets (CMakeLists.txt d'un CMake ou autre).
Dans le main:
std::vector<Screen*> screens;
Pourquoi des pointeurs bruts ? Ou m�me, pourquoi ds pointeurs. Je pense que l'on peut les �viter.
Dans le dossier view, j'aurais fait un sous dossier screens, du coup.
ScreenHomepage::ScreenHomepage() = default;
Lorsque l'on utilise le default, on le d�clare ainsi, dans le .h, directement.
Chaqu'un de vos Screen impl�mentent le chargement des ressources et une boucle principale. Il y a plusieurs solutions possibles, mais :
- le chargement des ressources pourrait �tre dans une fonction d�di�e (pour un peu r�duire la taille de run()), mais aussi, car on aimerait peut �tre faire un chargement d'une bonne partie (voire toute) les ressources du jeu, au d�marrage de celui-ci.
- on aimerait n'avoir qu'une seule boucle principale (dans le main()), qui va ex�cuter le code qu'il faut de l'�cran. D'ailleurs, c'est pas mal expliqu� ici : https://alexandre-laurent.developpez...boucle-de-jeu/
Ceci dit, j'aime bien l'id�e d'avoir fait des Screen et une machine � �tats.
1
2
| const int Size_textNamePlayer(2);
sf::Text textNamePlayer[Size_textNamePlayer]; |
Je verrais bien des std::array et des for(auto var : array) (je crois que cela s'appelle range-for 
).
1
2
3
| // Event queue processing
while (app.pollEvent(event)){
switch(event.type){ |
C'est un design que je n'aime pas . Note : c'est un avis personnel. Je pr�f�re r�cup�rer les �v�nement au besoin, et non pas d�pil� les �v�nements re�us moi m�me. Notamment, je peux bloquer votre application en d�pla�ant la fen�tre (le d�placement provoque souvent un envoi d'�v�nement de d�placement de fen�tre pour chaque pixel. Bref, �a spam � mort. Pareil lorsque l'on fait bouger la souris.
Vous avez un mod�le MVP (d'apr�s le nom des dossiers). Ce n'est pas un design que l'on fait pour les jeux vid�o .
Cette variable dans le main:
const int Size_playersNames(2);
doit avoir la m�me valeur que les variables dans les screens, non ? Dans un tel cas, on a souvent un fichier de nombre magique, appel� globals.h . Cela peut se faire aussi s'impl�menter en variable constante statique de classe. Bref, avoir un endroit o� la valeur est d�finie et tout le monde se r�f�re � cette valeur.
Ah ! vous avez un fichier GlobalConstants. Bah, c'est la m�me id�e. Vous pouvez ajouter des namespace pour faire un peu d'ordre dans ce fichier, notamment, pour regroupper tout ce qui concerne l'UI. Et comme c'est de l'UI, faire un fichier d�di� peut �tre une bonne id�e, � placer dans le dossier view.
Aussi, vous avez un petit effet comique, c'est que votre fonction run, accepte deux variables, d�fini � l'ext�rieur (dans le main). Elles le sont, car vous en avez besoin dans plusieurs �crans. Je pense que j'aurai opt� pour une classe pour contenir ces informations.
Dans MRandom, je ne sais plus si cela � un coup de recr�er � chaque fois votre device/mt/distribution. La classe devrait �tre en mesure de conserver tout cela, afin d'�viter de recr�er � chaque g�n�ration d'un nombre.
1
2
3
| /** * * * * * * **
* GETTER *
** * * * * * * **/ |
Inutile.
Cette information, je l'ai juste en lisant le nom de la fonction (ici getText). Pas besoin d'alourdir le fichier. D'ailleurs, pour le MFile::getText(), l'impl�mentation aurait simplement pu �tre dans le fichier .h
Pareil pour le setText. Les fonctions d'une ligne, on peut se permettre de les mettre dans le .h directement. Pareil pour les constructeur vide.
La taille de la grille est aussi en nombre magique (3). En r�alit�, ce n'est pas tr�s grave, car on peut se dire simplement, la taille ne changera jamais. C'est vrai et il n'y a pas trop de mal � �a et je pense qu'il faut se donner certaines limites quant � la modularit� que l'on veut atteindre. Toutefois, je crois qu'il aurait �t� plus simple d'avoir une classe d�di�e � la grille, et peut �tre avoir impl�ment� un tableau plat. D'autant plus que gr�ce � la m�thode getCell(), la diff�rence serait minime pour le reste du code. Et avec une m�thode getCell, vous pouvez ajouter des gardes fous pour rep�rer les erreurs de programmation au plus t�t (des assertions, notamment).
Pourquoi un tableau plat:
- beaucoup plus facile � parcourir (notamment pour voir si toutes les cases ont �t� jou�es) ;
- le getCell permet d'avoir une interface propre (utilisation d'un syst�me de coordonn�es ligne/colonnes), peu importe la structure contenant les donn�es derri�re ;
- permet la taille que l'on veut ;
- permet une utilisation des fonctionnalit�s standard (algorithm)
- les tableaux 2D, bof bof (et encore, le votre est d'une taille fixe, sans allocation dynamique)
Ce code :
1
2
3
4
| do {
row = randomInt(0, 2);
column = randomInt(0, 2);
} while (m_grid[row][column] != ' '); |
En cas de malchance interplan�taire, cela fait freeze votre programme . On aurait pu simplement scanner les cases libres, piocher dans l'une d'entre elle et hop, on a une case al�atoire.
La grille est compos� de char. Vous auriez tr�s bien pu utiliser un enum, rendant le code plus clair.
Chaque �cran charge certaine m�me ressources (les polices) 
Chaque �cran affiche une liste de Drawable, pourtant, chaque �cran poss�de un code du style :
1
2
3
4
5
6
7
8
|
app.clear();
app.draw(bgSprite);
app.draw(title);
app.draw(subtitle);
app.draw(creditsText);
app.draw(buttonBack);
app.display(); |
Un �cran pourrait tr�s bien juste renvoyer/remplir une liste de choses � afficher, tout simplement. Et un code commun ferait le clear/draw/display.
Un Screen va renvoyer l'index d'un autre screen. Cela aurait pu �tre un enum et l'autre probl�me, c'est que c'est d�pendant de l'ordre d'insertion des Screen fait dans le main.
Voil�. Il y a peut �tre d'autres choses � dire, mais il faut retenir les points suivants :
- vous avez fait un jeu qui fonctionne. C'est d�j� un tr�s grand succ�s pour vous m�me et vous pouvez en �tre fier ;
- les retours que j'ai fait, viennent de l'exp�rience. Il est normal que son premier jeu soit cod� comme vous l'avez fait (je pense que le mien �tait m�me pire ). C'est en programmant que l'on devient programmeur (et que l'on acquiert l'exp�rience). Si cela vous tente, faites une branche et tentez de modifier le code suivant mes retours. Si cela ne vous tente pas, faites un autre projet et tentez quelques solutions que j'ai propos�.
- j'ai remarqu� notamment que le code �tait plus proche du C, que du C++. Essayez d'utiliser quelques fonctionnalit�s de base, notamment : algorithm, std::array/std::vector, les ranged for et m�me std::optional (pour le selectedPage, par exemple).
Encore une fois, f�licitations.
Premier jeu en C++ et SFML
R�pondre avec citation
Partager