Version imprimable
Salut tout le monde !
Je viens vers vous en quête d'idées :P
Voilà, je suis en train de faire un Mario Sokoban grâce à SFML.
J'arrive à faire ma map, à l'afficher, bref, l'affichage fonctionne.
Par contre, là où je sèche, c'est comment faire pour déplacer mon Mario... :cry:
C'est pour ça que je post. :roll: Pour savoir comment vous vous feriez ceci..
En pièces jointes, je vous mets les codes si jamais vous en avez besoin.
P.S : j'utilise la technique du Tile Mapping
Ben.... ton mario est représenté visuellement par un sprite...
...donc il suffit de faire changer la position du sprite dans le temps pour obtenir un mouvement.
Si ça ne réponds pas clairement à ta question c'est parceque ta question est extrêmement vague.
Sauf si tu précises exactement ce que tu n'arrives pas a faire.
Je suis de toute façon obligé de la bouger.
Mais, le problème est que c'est dans ma classe Map que je fais l'affichage de la Map.
Dans ma class Mario, j'ai 4 méthode (descends, monte, gauche, droite).
Si je modifie la position du sprite dans une des ces méthodes, il faut ensuite que je mette un sprite de case vide où il y a avait avant le sprite du mon mario.
Et aussi que je récupère la position de x ou y du sprite mario avec GetPosition().x et GetPosition().y mais ces 2 fonctions me renvoient rien...
L'idée de comment le faire bouger, je l'ai. C'est plutôt dans comment le programmer (pas le code, mais l'organisation) que je sèche. :aie:
Désolé si je suis un peu confus ou vague mais c'est pas facile d'expliquer.... :aie::aie:
Bonjour,
Tout d'abord, en principe, lorsque l'on veut faire bien les choses, les définitions des classes vont se trouver dans des .hpp et le code des classes dans les .cpp
Enfin peut être que vous avez fait comme ça pour nous envoyer le code, mais je ne comprends pas pourquoi ... O_o
Après dans la technique, je pense qu'il faut que la classe Mario contienne la position du Mario. Celle ci sera changer à chaque appel de 'monte()' 'descend()' est autre ...
Pour l'affichage, vous faites comme vous voulez, dans la classe Mario ( ce qui me semble pas mal ) ou dans la classe Map, ce qui me semblerai un peu plus étrange, mais pas tant que ça.
En espérant que cela vous ai aidé.
Salut,
Autant le dire tout de suite, je n'ai pas regardé le code, mais...
J'ai l'impression que tu en demande trop à tes classe Mario et Map.
Ta classe Map ne doit faire qu'une chose : gérer l'ensemble des tuiles qui correspondent au niveau en cours.
La gestion des tuiles comprend:
La classe Mario, de son coté, ne doit aussi faire qu'une chose: gérer les différents états du personnage (position, orientation, niveau de vie, ...)
- Le maintien en mémoire des tuiles du niveau (qui seront, idéalement, chargée par une autre classe "Loader", par exemple)
- La possibilité de récupérer une "surface" de tuiles sur base d'une position (le coin supérieur gauche ou le centre de l'affichage, par exemple)
- déterminer, sur base des tuiles contigües à une position donnée si un déplacement donné est autorisé
Tu remarquera qu'il n'est absolument pas question dans ce que j'ai cité de quelconques fonctions d'affichage, et c'est normal:
La "Sacro Sainte" règle de la délégation des tâches dit que chaque classe ne doit chaque fois avoir qu'une seule responsabilité, mais qu'elle doit l'assumer correctement ;)
Il doit donc y avoir une troisième classe (du moins, pour celles que j'explique :D): une classe "Affichage" qui ne s'occupera que de... gérer l'affichage (éventuellement les différentes trames à afficher).
Elle se basera sur, d'une part, une position "de base" sur ton niveau permettant de demander les tuiles à afficher (sans doute fournie par la classe "partie", qui n'a rien à voir avec la classe Map, on est bien d'accord), et, d'autre part, sur la position du Mario, et s'occupera "d'incruster" mario sur la partie du niveau à afficher à la bonne position et dans l'orientation qui correspond à son déplacement (pour qu'on n'ait pas l'impression que mario "marche à reculons" :D)
Au final, on pourrait dire qu'il te faudra au minimum les classes suivantes:
Il faudra sans doute d'autres classes afin d'assurer certains services particuliers (entre autres, une hiérarchies d'états et une hiérarchies d'orientation), mais bon, je ne vais pas non plus me lancer dans l'étude complète et approfondie ici :D
- LevelLoader : s'occupe de charger le niveau courent (tuiles et disposition)
- Map : j'en ai déjà parlé
- Mario : j'en ai déjà parlé
- Game : s'occupe de gérer l'instance de Map et l'instance de Mario. Fait appel à LevelLoader lorsqu'il s'agit de passer au niveau suivant.
- Drawer : récupère les instances de Map et de Mario + informations utiles depuis l'instance de Game pour... afficher ce qui correspond à "l'instant présent"