Bonjour,

J'ai commencé à apprendre le C++ il y a un mois (j'avais déjà des bases en C et dans d'autres langages).
J'ai développé mon premier jeu, "OXO", qui est un simple Morpion. Le but était simplement d'apprendre le C++ et à utiliser la librairie SFML.

Ayant tout appris sur internet (OpenClassrooms, forums...), je n'ai aucune idée de la qualité de mon code.

C'est pourquoi je m'en remets à vous. Y a-t-il des erreurs de débutant que j'ai commises ? Des optimisations sont-elles possibles ?

Merci pour votre temps passé et vos éventuels conseils !


Code source ici : github.com/BizohxDev/OXO
Télécharger le jeu compilé (Windows) : ICI

Bonjour, je viens de voir ton post. J'espère ne pas répondre trop tard.

Bravo pour ton projet ! Je trouve ton code propre, très clair dans l'ensemble. Je n'ai pas tout lu, donc beaucoup de choses m'échappent certainement. Juste quatre remarques sur ce que j'ai pu lire:

Ta classe de base screen te sert à implémenter différents états du jeu (menus, crédits, game...) c'est une bonne idée, mais elle n'est peut-être pas suffisante. Dans chaque screen, la fonction run() est très longue (ici par exemple) , et encore heureusement il s'agit de scènes simples. Il faudrait trouver un moyen de séparer davantage les choses, ou alors les boucles d'évènement vont devenir gargantuesques et très difficiles à gérer.
Une solution envisageable : Implémenter une classe "component" (ou "behavior" peut-être ?) qui représenterait un petit élément de la scène. Du coup, screen pourrait avoir un membre std::vector<std::unique_ptr<component>>. Un component pourrait comporter 3 méthodes virtuelles, une pour recevoir les évènements, une pour la mise à jour en fonction du temps, une autre pour dessiner à l'écran... le screen ferait tourner une petite boucle qui appellerait toutes les fonctions redéfinies dans les classes des components.
On peut certainement faire beaucoup mieux, mais c'est une approche simple et rapide à mettre en place pour avoir un code plus modulaire.

Je suis étonné par le std::vector<Screen*> dans le main, ce n'est pas grave car les pointeurs n'ont pas l'ownership ici, mais il vaudrait mieux utiliser std::unique_ptr.

Autre chose. J'étais un peu surpris de trouver les sons, images... dans le dossier src, peut-être faudrait-il nommer ce dossier "assets" ou "medias" et mettre les sources dans src ? Pareil pour le dossier "view" pourquoi ne pas le nommer "screen" si on suit ta logique ?

Dernier point, la fonction randomInt, si elle doit être appelée souvent, va à chaque fois instancier std::random_device et std::mt19937. C'est un peu lourd. Peut-être ces éléments devraient-ils être statiques ?

-
Edité par Umbre37 21 avril 2024 à 6:32:19