Discussion :

[kump_]

Bonjour à tous

Après avoir appris à programmer en C/C++, j'ai décidé de me mettre à la programmation de jeux vidéo. Le snake étant un jeu que j'aime bien je me suis mis à la tache.

Le jeu est programmé avec la bibliothèque SFML et possède des graphismes horribles (j'ai toujours été nul en dessin ).

J'ai terminer la "base" du jeu, et j'aimerai bien implémenter plein d'autre fonctionnalitées ( plusieurs niveaux voir même une mini aventure, des objets bonus, des évènements qui perturberons le joueurs etc...).

Ceci étant je ne suis pas fou, je sais que avant d'arriver à intégrer tout cela il faut déja que mon code de base soit solide et bien organiser.

J'aimerai donc que vous puissiez me donner votre avis sur mon code pour que je puisse l'ammeliorer.

Comme il n'y a pas assez de place pour heberger les dll, voici un lien vers les dll SFML necessaire (windows/system/graphics) : http://www.sfml-dev.org/download-fr.php


Et voici les sources, le fichier projet codeblocks et l'executable (windows):
snake.zip

Un petit screenshoot au passage :

[img=http://img150.imageshack.us/img150/8800/screenah1.th.png]

Merci d'avance à ceux qui auront le courage de lire mon code

[nouknouk]

salut,

avant toute chose: bravo de na pas être tombé dans l'écueil du 'je débute le C++ et je commence un projet trop complexe pour moi (genre MMORPG)' On ne le répétera jamais assez: mieux vaut accumuler les petits projets comme ceux-ci pour se faire la main plutôt que vouloir s'attaquer à "l'Evrest du logiciel" qu'on ne finira jamais car on n'a pas (bien) estimé la charge de travail au départ.

Pour le reste, à savoir ton code:

- excellent point: tu as d'emblée essayé de séparer la 'logique' du jeu de son 'moteur d'affichage'

- un peu trop de 'switch' à mon goût. Ce genre de syntaxe doit rester l'exception. Privilégier d'autres solutions.

- un code commenté, c'est parfait. Si ça te tente, tu peux t'essayer à une syntaxe de commentaire 'standard', genre JavaDoc (et utiliser Doxygen pour générer la doc technique).

- quelques petites maladresses mineures dans la logique de nommage de fonctions (par exemple des fonction nommées 'get' qui ne retournent rien mais font un 'set'). Le programme ne marchera évidemment pas mieux avec un nom plus explicite ou quelques réarrangements de code, mais dans un code source il me semble tout aussi important d'avoir un code clair et qu'on peut lire en diagonale pour savoir immédiatement ce qu'il fait. Il n'est pas rare que son propre code soit devenu difficile à relire quelques mois après un 'break' si on n'est pas minutieux sur ce point (d'où également l'importance des commentaires d'ailleurs).

- un nommage en français C'est un détail, mais si tu comptes un jour travailler dans l'informatique et/ou travailer en équipe et/ou partager tes projets, tu peux commencer doucement à te mettre à l'Anglais (en plus ça raccourcit le nom des fonctions/variables )

Bon, les quelques points ci-dessus n'ont vraiment rien de bien méchant. Il me semble que tu as là une bonne base, fonce !

[Djakisback]

Salut,
personnellement j'aurais vu ta classe Graphique plus générique, à savoir dissocier ce qui est dessin de ce qui est Niveau et/ou déplacements (une classe Niveau serait pas mal dont tu stockes une instance dans Moteur). Les méthodes afficherBoule(), afficherSnake(), ... me semblent trop spécifiques (tu vas devoir créer une nouvelle méthode à chaque fois que tu vas ajouter un type de sprite), a priori t'aurais besoin d'une seule méthode afficheSprites(). Je pense que Graphique n'a pas besoin de savoir s'il stocke des mur ou des boules, juste un std::vector<CSprite> sprites ou un vector<CSprite>* sprites qui pointe sur un vector de sprites de la classe Niveau et ce n'est pas à lui non plus de déplacer les sprites ni de charger un niveau.

[Mat.M]

Le jeu est programmé avec la bibliothèque SFML et possède des graphismes horribles (j'ai toujours été nul en dessin ).

Mais non ils ne sont pas si mal que ça ces graphismes, je n'aurais pas mieux fait pour débuter.
Le mieux c'est de se concentrer sur l'essentiel et de faire des jeux fonctionnels.
Ne pas se casser trop la tête à vouloir trop structurer, avec des classes objets partout.

[kump_]

bravo de na pas être tombé dans l'écueil du 'je débute le C++ et je commence un projet trop complexe pour moi (genre MMORPG)'

Merci, mais de toute façon je prefere snake au MMO

un peu trop de 'switch' à mon goût. Ce genre de syntaxe doit rester l'exception. Privilégier d'autres solutions.

Les if/else if/else sont préférable ou encore une autre solution ?

un code commenté, c'est parfait. Si ça te tente, tu peux t'essayer à une syntaxe de commentaire 'standard', genre JavaDoc (et utiliser Doxygen pour générer la doc technique).

Heu, créer une documentation ce n'est pas plutôt que pour les codes qui vont être réutiliser par d'autre application ? Je ne voit pas trop en quoi ça servira pour mon programme Par contre utiliser une syntaxe de commentaire 'standart' ça je veut bien essayer, JavaDoc est simple et reconnus ?

quelques petites maladresses mineures dans la logique de nommage de fonctions (par exemple des fonction nommées 'get' qui ne retournent rien mais font un 'set').

Fonctions renommées.

un nommage en français. C'est un détail, mais si tu comptes un jour travailler dans l'informatique et/ou travailer en équipe et/ou partager tes projets, tu peux commencer doucement à te mettre à l'Anglais (en plus ça raccourcit le nom des fonctions/variables )

Ca par contre je ne suis pas trop d'accord. Autant je pense qu'il faille savoir un minimum d'anglais technique pour pouvoir programmer, autant je pense qu'on peut favoriser sa langue dans son programme. J'aime le français, et je ne pense pas que ce snake va développer une communauté de dévelloppeur pour m'aider à le créer. Alors il vaut mieu que je puisse mis retrouver encore plus rapidement.

En revanche si j'avais voulu crée un code réutilisable par d'autre personne je l'aurai mis en anglais.

Il me semble que tu as là une bonne base, fonce !

Mon code est donc suffisament solide pour que je puisse créer autour de lui des "modules" qui se grefferont à cette base (par exemple un module menu, module aventure, module évenement etc...) ?

En tout cas merci beaucoup d'avoir pris le temps de lire mes sources !

Salut,
personnellement j'aurais vu ta classe Graphique plus générique, à savoir dissocier ce qui est dessin de ce qui est Niveau et/ou déplacements (une classe Niveau serait pas mal dont tu stockes une instance dans Moteur).

Je ne comprend pas trop l'interet d'une classe niveau, quelle serait ces méthodes par exemple ? Dissocier la classe Graphique des déplacements ok, tu pense qu'il est préférable de donner mes sprites à ma classe moteur qui donnera les nouvelles coordonnées du sprites ?

Les méthodes afficherBoule(), afficherSnake(), ... me semblent trop spécifiques (tu vas devoir créer une nouvelle méthode à chaque fois que tu vas ajouter un type de sprite), a priori t'aurais besoin d'une seule méthode afficheSprites().

Je pense que Graphique n'a pas besoin de savoir s'il stocke des mur ou des boules, juste un std::vector<CSprite> sprites

D'accord, mai dans ce cas, si tout mes sprites sont dans le vector<CSprite> comment faire pour donner les coordonnées de chaque sprite ? Comment les dissocier si ils sont tous dans le même vector ?

ou un vector<CSprite>* sprites qui pointe sur un vector de sprites de la classe Niveau et ce n'est pas à lui non plus de déplacer les sprites ni de charger un niveau.

Arf, là je n'ai pas trop compris désolé

Merci à toi aussi pour avoir lu mes sources !

Mais non ils ne sont pas si mal que ça ces graphismes, je n'aurais pas mieux fait pour débuter.

Mouai c'est de la récupération de sprite et du paint donc bon...

Le mieux c'est de se concentrer sur l'essentiel et de faire des jeux fonctionnels.

Je suis bien d'accord

Ne pas se casser trop la tête à vouloir trop structurer, avec des classes objets partout.

Heu, ne vaut il pas mieu faire quelque chose de structurer pour être sur qu'on puisse l'ammeliorer ?

En tout cas merci à tous pour vos conseils et pour avoir pris le temps de m'aider !

[bachir006]

j'ai survolé ton code source, et j'ai quelques remarques

• evite de mettre la boucle principale dans le main
• pour limiter le framerate, utilise plutot la fonction setFrameLimit(FPS);
• Pour gerer les venements, utilise les inputs
• les classes ne sont pas assez generiques pour etre reutilisés, mais je crois que ce n'etaitpas ton but
• en c++ on prefere les constantes au define
• tu as trop de switch long, et des fonctions enormes, faut restructurer un peu( je parle surtout de la fonction: void Moteur::deplacerSnake() et void Moteur::directionSnake(int direction) )
• faut eviter les nombres magiques:

• Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  if(temps >0.2)/*Utilisation du temps pour que le jeu tourne a la même vitesse sur tout les ordis*/

  et si un jour tu veux changer 0.2 en 0.1? utilise une constantes, ça sera plus flexible
• si je vais a droite et je clique surgauche, je perd, ce qui ne fait partie des regles du serpent

voila e esperant t'avoir aider

[kump_]

Tout d'abord merci d'avoir regardé mes sources

evite de mettre la boucle principale dans le main

Ha ? Pourquoi ça ? Et sinon ou la mettre alors ?

# pour limiter le framerate, utilise plutot la fonction setFrameLimit(FPS);

Je ne connaissais pas cette fonction merci ! Un bon fps est de l'ordre de combien environ ?

Pour gerer les venements, utilise les inputs

J'utilise déja la classe sf::Event, en quoi utilisé les inputs m'aiderais ?

les classes ne sont pas assez generiques pour etre reutilisés, mais je crois que ce n'etaitpas ton but

Il est vrai que ce n'est pas vraiment mon but, mais j'aimerai tout de même les rendre les plus génériques possibles, comment faire ?

en c++ on prefere les constantes au define

Je vais surement paraitre idiot mais bon, qu'est ce que les constantes ? Des variables globales ?

tu as trop de switch long, et des fonctions enormes, faut restructurer un peu( je parle surtout de la fonction: void Moteur::deplacerSnake() et void Moteur::directionSnake(int direction) )

Hum, il vaudrait mieu que je fasse appel a une fonction pour chaque "case" ?
Par exemple quelque chose comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
switch(variable)
{
    case 1:
       fonction();
       break;
 
    case 2:
       fonction();
       break;
}

faut eviter les nombres magiques:

Je suis bien d'accord, mais je suis confronté a un problème tout bête, lorsque je voulais faire un define pour attribuer une valeur, il n'acceptait pas les nombres décimaux.

si je vais a droite et je clique surgauche, je perd, ce qui ne fait partie des regles du serpent

Ha ? Je ne savais pas qu'on ne pouvait pas perdre comme ça.

[Mat.M]

j'ai survolé ton code source, et j'ai quelques remarques

evite de mettre la boucle principale dans le main
Pour gerer les venements, utilise les inputs

Je suis d'accord mais je trouve que c'est pinailler pour pas grand chose.
J'ai regardé le code source il est correct libre à Kump de l'améliorer mais une fois que tout tourne de manière satisfaisante..
Je lui conseille d'aller à l'essentiel de rendre le jeu parfaitement fonctionnel quitte à améliorer le code après parce qu'il risque de perdre son temps inutilement dans la conception de classes inutiles.
Il programme un jeu de Snake pas le moteur de Crysis.
donc un petit jeu comme ça y'a pas besoin de faire compliqué..

tu as trop de switch long, et des fonctions enormes, faut restructurer un eu( je parle surtout de la fonction: void Moteur::deplacerSnake() et void Moteur::directionSnake(int direction) )

Oui mais pour le moment on ne peut pas trop faire autrement et tu ne proposes pas de solution pour rendre le code simple..
il ya des solutions plus complexes ( machine à état ?) mais Kump risque de se compliquer les choses et de se perdre dans des techniques avancées complexes.
Je lui conseille de faire simple au départ au risque d'avoir un code pas terrible sinon il risque de perdre son temps et de se mélanger avec des choses compliquées.

Les améliorations à apporter c'est d'abord dans la finalité du jeu ( graphismes , gameplay, IA..)

[bachir006]

Creer des fonction, vous connaissez? aprceque la, ce 'est pas la logueur des swichs qui derange en fait, mais surtout le copier-coller

[Mat.M]

Creer des fonction, vous connaissez? aprceque la, ce 'est pas la logueur des swichs qui derange en fait, mais surtout le copier-coller

Oui tu as raison; ceci dit cette discussion m'a été bénéfique parce que ça a fait tilt dans ma tête concernant le concept de Machine à états

[Djakisback]

Mat.M, justement s'il ne structure pas mieux son code et veut gérer plusieurs niveaux il va commencer à galérer grave. Tu peux pas commencer à coder les niveaux "à la main" (genre avec des méthodes afficheBoule()) puis revenir plus tard sur le système de gestion pour en faire totalement autre chose ^^ autant être le plus générique possible.

L'intérêt d'une classe Niveau c'est que tu peux encapsuler toutes les données non partagées d'un niveau et ainsi mieux gérer la libération des ressources par exemple lors de la destruction d'un niveau. Dans le cas d'un snake c'est peut-être pas vraiment utile effectivement car tous tes niveaux vont contenir les mêmes types de sprites donc la majeure partie des données va être partagée.

D'accord, mai dans ce cas, si tout mes sprites sont dans le vector<CSprite> comment faire pour donner les coordonnées de chaque sprite ? Comment les dissocier si ils sont tous dans le même vector ?

Justement c'est le prix de réutilisabilité tu devras avoir un pointeur sur ceux qui t'intéressent quelque part ailleurs, dans Moteur par exemple si c'est lui qui gère les mouvements. Si tu veux rendre ta classe Graphique plus générique et réutilisable tu dois ne lui faire faire que des trucs de dessins et ne pas stocker des informations relatives aux niveaux directement dedans. Avec une classe Niveau tu peux avoir un truc du style au final :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Niveau* niveauCourant = new Niveau("niveau1.txt"); // récupère les infos du niveau depuis un fichier et crée les sprites 
graphique->setSprites(niveauCourant->getSprites());

Puis dans le main loop :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
if(niveauCourant->isCleared()) {
niveauCourant->free(); // libère les ressources
niveauCourant->load("niveau" + niveauCourant->getNumero() + ".txt")
graphique->setSprites(niveauCourant->getSprites());
}
 
moteur->updatePositions();
graphique->draw();

Ce qui t'évite de définir :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 sf::Sprite snake;
        sf::Sprite partie_snake[((LARGEUR)-1)*((HAUTEUR)-1)];
        sf::Sprite mur[((LARGEUR)-1)*((HAUTEUR)-1)];
        sf::Sprite boule;

Directement dans Graphique, d'ailleurs je ne vois pas comment tu pourrais gérer plusieurs niveaux avec cette méthode.

* si je vais a droite et je clique surgauche, je perd, ce qui ne fait partie des regles du serpent

Si, je crois bien que ça fait partie des règles originales ^^

[kump_]

Creer des fonction, vous connaissez? aprceque la, ce 'est pas la logueur des swichs qui derange en fait, mais surtout le copier-coller

Le problème c'est que si je crée une fonction elle ne peut pas être générique. Par exemple ma méthode qui attribue des positions au snake ce comporte différemment suivant la direction qu'on lui donne.

Mat.M, justement s'il ne structure pas mieux son code et veut gérer plusieurs niveaux il va commencer à galérer grave.

C'est vrai que j'aimerai bien gérer plusieurs niveaux donc oui il faut que j'ammeliore mon code.

Tu peux pas commencer à coder les niveaux "à la main" (genre avec des méthodes afficheBoule()) puis revenir plus tard sur le système de gestion pour en faire totalement autre chose ^^ autant être le plus générique possible.

Là je ne comprend pas trop, en quoi est ce mauvais de faire des fonctions comme afficherBoule() ou afficherObjet() etc... ? Je pourrai faire en sorte que suivant le niveau on active telle ou telle fonction et hop pas besoin d'adapter ce que j'affiche par niveau. Il me suffira simplement de dire ce que je veut qu'on affiche.

L'intérêt d'une classe Niveau c'est que tu peux encapsuler toutes les données non partagées d'un niveau et ainsi mieux gérer la libération des ressources par exemple lors de la destruction d'un niveau.

J'y ai réflechis cette nuit et oui une classe Niveau serait interessante en effet. Je vois bien une classe Jeu, gérant la classe Moteur et la classe Niveau qui ferait la liaison entre les deux.

Dans le cas d'un snake c'est peut-être pas vraiment utile effectivement car tous tes niveaux vont contenir les mêmes types de sprites donc la majeure partie des données va être partagée.

En fait, je comptait différencier mes niveaux plus tard donc si ce sera utile

....

Directement dans Graphique, d'ailleurs je ne vois pas comment tu pourrais gérer plusieurs niveaux avec cette méthode.

Merci pour les exemples de codes qui m'on donner plein d'idées
En revanche ce que je voulais dire, c'est que si tout mes sprites sont concentrés dans un vector, comment leur attribuer leurs coordonnées ? Car mes sprites snake et partie_snake ont besoin de changer leurs coordonnées, et si je veut plus tard integrer d'autre sprites qui auront besoin de se déplacer indépendament comment faire pour les distinguer dans ma classe vector ? Il faudrait les trier ?

Si, je crois bien que ça fait partie des règles originales ^^

Haha ! Je préfere ça, c'est beaucoups plus drole.

[bachir006]

Le problème c'est que si je crée une fonction elle ne peut pas être générique. Par exemple ma méthode qui attribue des positions au snake ce comporte différemment suivant la direction qu'on lui donne.

j'aurai pensé a une fonction qui prends la position actuel du snake, et la case ou il aimerait aller

[kump_]

Oui d'accord mais à quel sprite l'appliquer ? Vu qu'ils sont tous dans un vector, comment vais je savoir quel sprite est snake et quel autre est mur ?

[bachir006]

ça sent les problmes de conceptionn ce sot des problemes auxquels fallait penser avant d'entamer le projet

[kump_]

ça sent les problmes de conceptionn ce sot des problemes auxquels fallait penser avant d'entamer le projet

Il faut dire que ce n'est pas mon idée mais celle de Djakisback donc je n'allais pas y penser avant

Et puis justement, je sais que j'ai du faire plein d'erreur de conception. C'est pour ça que je demande votre aide

Sinon, j'ai une autre question : je compte implémenter des évenements pour des niveaux (par exemple au bout de Xseconde un mur apparait à telles coordonnées) quel serait le meilleur moyen de stocker ses évenement en fichier ?

J'ai penser au XML mais je n'y connais rien, quel bibliothèque utilise t'on ? Une simple et bien documentée serait parfaite

[bachir006]

pour le XML, je n'ai entendu que du bien de TinyXML(mais jamais testé :d ) : http://www.grinninglizard.com/tinyxml/

[Djakisback]

En revanche ce que je voulais dire, c'est que si tout mes sprites sont concentrés dans un vector, comment leur attribuer leurs coordonnées ? Car mes sprites snake et partie_snake ont besoin de changer leurs coordonnées, et si je veut plus tard integrer d'autre sprites qui auront besoin de se déplacer indépendament comment faire pour les distinguer dans ma classe vector ? Il faudrait les trier ?

Le moteur graphique contient un vecteur de sprites qu'il parcourt et dessine, peu importe ce qu'il y a dedans, il a juste besoin d'accéder à des méthodes de base, comme getX() etc. Et ailleurs tu gardes un pointeur sur les sprites qui t'intéressent pour les déplacements ou autre.

[Mat.M]

Sinon, j'ai une autre question : je compte implémenter des évenements pour des niveaux (par exemple au bout de Xseconde un mur apparait à telles coordonnées) quel serait le meilleur moyen de stocker ses évenement en fichier ?

un moteur de langage script genre LUA est plus souple que XML....
Mais tu devrais te faire un éditeur de niveau, pas besoin forcèment de connecter ça à toute une usine à gaz pour gérer cela..

Un mur qui apparait au bout de x secondes c'est simplement mémoriser dans le membre d'une classe un delta de temps ..
pas besoin d'appeler XML pour cela tu vas te compliquer les choses je trouve inutilement...

[kump_]

pour le XML, je n'ai entendu que du bien de TinyXML(mais jamais testé :d ) :

Merci beaucoup J'ai lu la doc et leurs exemple et j'ai tout compris directement (premiere fois que je lisais une doc en anglais et que j'ai réussi a apprendre a l'utiliser ) .

Le moteur graphique contient un vecteur de sprites qu'il parcourt et dessine, peu importe ce qu'il y a dedans, il a juste besoin d'accéder à des méthodes de base, comme getX() etc. Et ailleurs tu gardes un pointeur sur les sprites qui t'intéressent pour les déplacements ou autre.

D'accord, je comprend mieu.

un moteur de langage script genre LUA est plus souple que XML...

J'ai un peu entendu parler de LUA mais je ne sais pas du tout ce que c'est (d'ailleur qu'est ce qu'un langage de script ?). Est ce long a maitriser ? Est ce vraiment utile ?

Mais tu devrais te faire un éditeur de niveau, pas besoin forcèment de connecter ça à toute une usine à gaz pour gérer cela..

Un mur qui apparait au bout de x secondes c'est simplement mémoriser dans le membre d'une classe un delta de temps ..
pas besoin d'appeler XML pour cela tu vas te compliquer les choses je trouve inutilement...

Ce n'était qu'un exemple Et puis bon, je compte crée un ou plusieurs évenements différents suivant mes niveaux.

J'avais pensé a un fichier de ce type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
<Niveau1>
   <Map>111010100110101010</Map>
   <Evenement>
      <Blabla></Blabla>
   </Evenement>
</Niveau1>
<Niveau2>
....

(Ne me blamez pas si j'ai mal mis en forme ce fichier "XML" mais je ne commence à apprendre )

Donc ce fichier pourrait me servir a stocker chaque évenement pour chaque niveau de façon assez pratique je trouve.

Et puis, lorsque je ferait un éditeur de niveau (vais bien galerer pour ça d'ailleur ) je n'aurait plus qu'a stocker ça dans le fichier xml.

Ce n'est vraiment pas bon ?