TP : Mario Sokoban

A propos du Sokoban

"Sokoban" est un terme japonais qui signifie "Magasinier".
Il s'agit d'un casse-tête inventé dans les années 80 par Hiroyuki Imabayashi. Le jeu a remporté un concours de programmation à l'époque.

Le but du jeu

Il est simple à comprendre : vous dirigez un personnage dans un labyrinthe. Il doit pousser des caisses pour les amener à des endroits précis. Le joueur ne peut pas déplacer 2 caisses à la fois.

Si le principe se comprend vite et bien, cela ne veut pas dire pour autant que le jeu est toujours facile. Il est en effet possible de réaliser des casse-têtes vraiment... prise de tête

Pourquoi avoir choisi ce jeu ?

Parce que c'est un jeu populaire, que je trouve intéressant et qu'on peut réaliser rien qu'avec ce qu'on a appris dans les cours de ce site.
Alors bien sûr, ça demande de l'organisation. La difficulté n'est pas vraiment dans le codage mais dans l'organisation. Il va en effet falloir découper notre programme en plusieurs fichiers .c intelligement, essayer de trouver les bonnes fonctions à créer etc.

C'est aussi pour cette raison que j'ai décidé cette fois de ne pas construire le TP comme les précédents : je ne vais pas vous donner des indices et puis une correction à la fin. Au contraire : je vais vous montrer comment je réalise tout le projet de A à Z.



Pas de problème ! Allez-y lancez-vous, c'est même très bien !
Il vous faudra certainement un peu de temps : personnellement ça m'a pris une bonne petite journée, et encore c'est parce que j'ai un peu l'habitude de programmer et que j'évite certains pièges courants. Ca ne m'a pas empêché de me prendre la tête à 2 ou 3 reprises quand même

Sachez qu'un tel jeu peut être codé de nombreuses façons différentes. Je vais vous montrer ma façon de faire : ce n'est pas la meilleure, mais ce n'est pas la plus mauvaise non plus
Le TP se terminera par une série de suggestions d'améliorations, et je vous proposerai de télécharger le code source complet bien entendu.

Encore une fois : je vous conseille d'essayer de vous y lancer par vous-mêmes. Passez-y 2 ou 3 jours et faites de votre mieux. Il est important que vous pratiquiez.

Le cahier des charges

Le cahier des charges, c'est un document dans lequel on écrit tout ce que le programme doit savoir faire.
En l'occurence, que veut-on que notre jeu soit capable de faire ? C'est le moment de se décider !

Voici ce que je propose :

• Le joueur doit pouvoir se déplacer dans un labyrinthe et pousser des caisses.
• Il ne peut pas pousser 2 caisses à la fois.
• Une partie est considérée comme gagnée lorsque toutes les caisses sont sur des objectifs
• Les niveaux de jeu seront enregistrés dans un fichier (par exemple "niveaux.lvl").
• Un éditeur sera intégré au programme pour que n'importe qui puisse créer ses propres niveaux (bah oui tant qu'on y est hein )

Voilà ça fait déjà pas mal je crois
Il y a des choses que notre programme ne saura pas faire, ça aussi il faut le dire :

• Notre programme ne pourra gérer qu'un seul niveau à la fois. Si vous voulez coder une "aventure" avec une suite de niveaux, vous n'aurez qu'à le faire vous-mêmes à la fin de ce tp
• Il n'y aura pas de gestion du temps écoulé (on sait pas faire ça encore) ni du score.

En fait, avec tout ce qu'on veut faire déjà (notamment l'éditeur de niveaux), y'en a pour un petit moment.

Récupérer les sprites du jeu

Dans la plupart des jeux 2D (que ce soit des jeux de plateforme ou de casse-tête comme ici), on appelle les images qui composent le jeu des sprites.
Dans notre cas, j'ai décidé qu'on créerait un Sokoban mettant en scène Mario (d'où le nom "Mario Sokoban"). Comme Mario est un personnage populaire dans le monde de la 2D, on n'aura pas trop de mal à trouver des sprites de Mario.

Il faudra aussi trouver des sprites pour les murs de briques, les caisses, les objectifs etc.

Si vous faites une recherche sur Google de "sprites", vous trouverez de nombreuses réponses. En effet, il y a pas mal de sites qui proposent de télécharger des sprites de jeux 2D auxquels vous avez sûrement joué par le passé

Personnellement, je me suis servi sur : http://www.panelmonkey.org/
Vous en trouverez aussi sur : http://www.videogamesprites.net/
... et bien entendu Google vous en donnera d'autres

Voici les sprites que j'ai récupérés. J'ai fait un peu de retouches sur certains pour qu'ils soient à la bonne dimension :

Sprite	Description
	Un mur
	Une caisse
	Une caisse placée sur un objectif. J'ai juste légèrement "rougi" la caisse sous Photoshop.
	Un objectif (où l'on doit mettre une caisse).
	Le joueur (Mario) orienté vers le bas
	Mario vers la droite
	Mario vers la gauche
	Mario vers le haut

Voilà, avec ça on a tout ce qu'il faut
Comme vous le voyez, les images ont parfois eu besoin de légères retouches. Ce ne sont pas des retouches difficiles à faire (même moi qui suis un gros nul sous Photoshop je m'en suis sorti, alors pourquoi pas vous )



Ah, et j'ai aussi fait une petite image qui pourra servir de menu d'accueil au lancement du programme :



Cette image se trouve dans le pack d'images que je vous ai fait télécharger plus haut.

Important : vous noterez que ces images sont dans différents formats. Il y a des GIF, des PNG et des JPEG. Nous allons donc avoir besoin de la librairie SDL_Image.
Pensez à configurer votre projet pour qu'il gère la SDL et SDL_Image. Si vous avez oublié comment faire, revoyez les chapitres précédents.

Si vous ne configurez pas votre projet correctement, on vous dira que les fonctions que vous utilisez (comme IMG_Load) n'existent pas !

A chaque fois qu'on commence un projet assez important, il est nécessaire de bien s'organiser dès le départ.
En général, je commence par me créer un fichier de constantes constantes.h ainsi qu'un fichier main.c qui contiendra la fonction main (et uniquement la fonction main). Ce n'est pas une règle : c'est juste ma façon de fonctionner. Chacun a sa propre façon de faire.

Les différents fichiers du projet

Je propose de créer dès à présent tous les fichiers du projet (même s'ils restent vides au départ).
Voici les fichiers que je crée :

• constantes.h : les définitions de constantes globales à tout le programme
• main.c : le fichier qui contient la fonction main (fonction principale du programme).
• jeu.c : fonctions gérant une partie de Sokoban
• jeu.h : prototypes des fonctions de jeu.c
• editeur.c : fonctions gérant l'éditeur de niveaux
• editeur.h : prototypes.
• fichiers.c : fonctions gérant la lecture et l'écriture de fichiers de niveaux (niveaux.lvl par exemple).
• fichiers.h : prototypes.

Allons-y donc, on va commencer par créer le fichier des constantes.

Les constantes : constantes.h

Voici le contenu de mon fichier de constantes :

Code : C

Vous noterez plusieurs choses :

• Le fichier commence par un commentaire d'en-tête. Je recommande de mettre ce type de commentaire au début de chacun de vos fichiers (que ce soient des .h ou des .c). Généralement, un commentaire d'en-tête contient :
  • Le nom du fichier (constantes.h)
  • L'auteur (mateo21)
  • Le rôle du fichier (à quoi servent les fonctions à l'intérieur)
  • Je ne l'ai pas fait là, mais on met aussi généralement la date de création et la date de dernière modification. Ca permet de s'y retrouver, surtout dans les gros projets à plusieurs.
• Le fichier est protégé contre les inclusions infinies. Il utilise la technique que l'on a apprise à la fin du chapitre sur le préprocesseur dans la partie II. Ici cette protection ne sert à rien, mais j'ai pris l'habitude de faire ça pour chacun de mes fichiers .h sans exception.
• Enfin, le coeur du fichier. Vous avez une série de defines. J'indique la taille d'un petit bloc en pixels (tous mes sprites sont des carrés de 34px). J'indique que ma fenêtre comportera 12 x 12 blocs de largeur. Je calcule comme ça les dimensions de la fenêtre par une simple multiplication des constantes. Ce que je fais là n'est pas obligatoire, mais ça un énorme avantage : si plus tard je veux changer la taille du jeu, je n'aurai qu'à éditer ce fichier (et à recompiler) et tout mon code source s'adaptera en conséquence.
• Enfin, j'ai défini d'autres constantes via des énumérations anonymes. C'est légèrement différent de ce qu'on a appris dans le chapitre sur les types de variables personnalisés. Ici, je ne crée pas un type personnalisé, je définis juste des constantes.
  
  
  Mais alors c'est exactement comme des defines non ?
  
  
  Oui, à une différence près : c'est l'ordinateur qui attribue automatiquement un nombre à chacune des valeurs (en commençant par 0). Ainsi, on a HAUT = 0, BAS = 1, GAUCHE = 2 etc. Cela permettra de rendre notre code source beaucoup plus clair par la suite, vous verrez !

En résumé, j'utilise :

• Des defines lorsque je veux attribuer une valeur précise à une constante (par exemple "34 pixels").
• Des énumérations lorsque la valeur attribuée à une constante ne m'importe pas. Ici, je m'en fous que HAUT vale 0 (ça pourrait aussi bien valoir 150 ça ne changerait rien), tout ce qui compte pour moi c'est que cette constante ait une valeur différente de BAS, GAUCHE et DROITE

Inclure les définitions de constantes

Le principe, c'est que ce fichier de constantes sera inclus dans chacun de mes fichiers .c.
Ainsi, partout dans mon code je pourrai utiliser les constantes que je viens de définir.

Il faudra donc taper la ligne suivante au début de chacun des fichiers .c :

Code : C

Le main : main.c

La fonction main est extrêmement simple, je peux même me permettre de vous la donner d'un coup comme ça. En effet, elle n'est pas plus difficile que ce qu'on a appris dans les chapitres précédents, donc si vous avez suivi récemment ça ne vous posera aucun problème de compréhension :

Code : C

La fonction main se charge d'effectuer les initialisations de la SDL, de donner un titre à la fenêtre ainsi qu'une icône. A la fin de la fonction, SDL_Quit() est appelé pour arrêter la SDL proprement.

La fonction affiche un menu. Le menu est chargé en utilisant la fonction IMG_Load de SDL_Image :

Code : C

La boucle des évènements

La boucle infinie gère les évènements suivants :

• SDL_QUIT : si on demande à fermer le programme (clic sur la croix en haut à droite de la fenêtre), alors on passe le booléen continuer à 0, et la boucle s'arrêtera. Bref, classique.
• Appui sur la touche Echap : arrêt du programme (comme SDL_QUIT)
• Appui sur la touche 1 du pavé numérique : lancement du jeu (appel de la fonction jouer)
• Appui sur la touche 2 du pavé numérique : lancement de l'éditeur (appel de la fonction editeur)

Comme vous le voyez, c'est vraiment très simple. Si on appuie sur 1, le jeu est lancé. Une fois que le jeu est terminé, la fonction jouer s'arrête et on retourne dans le main dans lequel on refait un tour de boucle. Le main boucle à l'infini tant qu'on ne demande pas à arrêter le jeu.

Grâce à cette petite organisation très simple, on peut donc gérer le menu dans le main, et laisser des fonctions spéciales (comme jouer, ou editeur) gérer les différentes parties du programme.

Attaquons maintenant le gros du sujet : la fonction jouer !
Cette fonction est la plus importante du programme, aussi soyez attentifs car c'est vraiment là qu'il faut comprendre. Vous verrez après que créer l'éditeur de niveaux n'est pas si compliqué en fait

Les paramètres envoyés à la fonction

La fonction jouer a besoin d'un paramètre : la surface ecran. En effet, la fenêtre a été ouverte dans le main, et pour que la fonction jouer puisse dessiner dedans il faut qu'elle récupère le pointeur sur ecran !

Si vous regardez le main à nouveau, vous voyez qu'on appelle jouer en lui envoyant ecran :

Code : C

Le prototype de la fonction, que vous pouvez mettre dans jeu.h, est donc le suivant :

Code : C

Les déclarations de variables

Cette fonction va avoir besoin de nombreuses variables.
Je n'ai pas pensé à toutes les variables dont j'ai eu besoin du premier coup. Il y en a donc certaines que j'ai rajoutées par la suite.

Variables de type défini par la SDL

Voici pour commencer toutes les variables de types définis par la SDL dont j'ai besoin :

Code : C

J'ai créé un tableau de SDL_Surface appelé mario. C'est un tableau de 4 cases qui stockera Mario dans chacune des directions (un vers le bas, un autre vers la gauche, vers le haut et vers la droite).

Il y a ensuite plusieurs surfaces correspondant à chacun des sprites que je vous ai faits télécharger plus haut : mur, caisse, caisseOK (une caisse sur un objectif) et objectif.


C'est un pointeur vers une surface. Il pointe sur la surface correspondant au Mario orienté dans la direction actuelle. C'est donc marioActuel qu'on blittera à l'écran. Si vous regardez tout en bas de la fonction jouer, vous verrez justement :

Code : C

On ne blitte donc pas un élément du tableau mario, mais le pointeur marioActuel.
Ainsi, en blittant marioActuel, on blitte soit le mario vers le bas, soit vers le haut etc. Le pointeur marioActuel pointe vers une des cases du tableau mario.

Quoi d'autre à part ça ?
Une variable position de type SDL_Rect dont on se servira pour définir la position des éléments à blitter (on s'en servira pour tous les sprites, c'est pas la peine de créer un SDL_Rect pour chaque surface !).

positionJoueur est en revanche un peu différent : il indique à quelle case sur la carte se trouve se trouve actuellement le joueur.

Enfin, la variable event traitera les évènements, là il n'y a rien de particulièrement nouveau.

Variables plus "classiques"

J'ai aussi besoin de me créer des variables un peu plus classiques de type int (entier).

Code : C

continuer et objectifsRestants sont des booléens.
i et j sont des petites variables qui vont me permettre de parcourir le tableau.



Le tableau carte défini juste en-dessous !
C'est là que les choses deviennent vraiment intéressantes. J'ai en effet créé un tableau à 2 dimensions. Je ne vous ai pas parlé de ce type de tableaux auparavant (pas eu l'occasion d'en parler), mais c'est justement le moment idéal pour vous apprendre ce que c'est. Ce n'est pas bien compliqué vous allez voir.

Regardez la définition de plus près :

Code : C

En fait, il s'agit d'un tableau d'int (entiers) qui a la particularité d'avoir 2 paires de crochets [ ].
Si vous vous souvenez bien de constantes.h, vous savez que NB_BLOCS_LARGEUR et NB_BLOCS_HAUTEUR sont des constantes qui valent toutes les deux 12.

Ce tableau sera donc à la compilation créé comme ceci :

Code : C



Ca veut dire que pour chaque "case" de carte, il y a 12 sous-cases.
Il y aura donc les variables suivantes :

Code : Autre

C'est donc un tableau de 12 * 12 = 144 cases !
Chacune des ces cases représente une case de la carte.

Voici comment on peut représenter la carte, vous allez comprendre en voyant ça :



(Enfin vous avez intérêt à comprendre parce que j'ai passé un bon moment à tracer toutes les lignes une à une sous Paint là )

Ainsi, la case en haut à gauche est stockée dans carte[0][0].
La case en haut à droite est stockée dans carte[0][11].
La case en bas à droite (la toute dernière) est stockée dans carte[11][11].

Selon la valeur de la case (qui est un nombre entier), on sait si la case contient un mur, une caisse, un objectif etc...). C'est justement là que va servir notre énumération de tout à l'heure !

Code : C

Si la case vaut VIDE (0) on sait que cette partie de l'écran devra rester blanche. Si elle vaut MUR (1), on sait qu'il faudra blitter une image de mur etc...

Initialisations

Chargement des surfaces

Maintenant qu'on a passé en revue toutes les variables de la fonction jouer, on peut commencer à faire quelques initialisations :

Code : C

Rien de sorcier là-dedans, on charge tout grâce à IMG_Load.
Le petit truc intéressant, c'est le chargement de mario. On charge en effet Mario dans chacune des directions dans le tableau "mario" en utilisant les constantes HAUT, BAS, GAUCHE, DROITE. Le fait d'utiliser les constantes rend ici comme vous le voyez le code plus clair. On aurait très bien pu écrire mario[0], mais c'est quand même plus lisible d'avoir mario[HAUT] par exemple !

Orientation initiale du Mario (marioActuel)

On initialise ensuite marioActuel pour qu'il ait une direction au départ :

Code : C

J'ai trouvé plus logique de commencer la partie avec un Mario qui regarde vers le bas (c'est-à-dire vers nous). Si vous voulez, vous pouvez changer cette ligne et mettre :

Code : C

Vous verrez que Mario sera alors orienté vers la droite au début du jeu

Chargement de la carte

Maintenant, il va falloir remplir notre tableau à 2 dimensions carte. Pour l'instant, ce tableau ne contient que des 0.
Il faut lire le niveau qui est stocké dans le fichier niveaux.lvl.

Code : C

J'ai choisi de faire gérer le chargement (et l'enregistrement) de niveaux par des fonctions situées dans fichiers.c
Ici, on appelle donc la fonction chargerNiveau. On l'étudiera plus en détail plus loin (elle n'est pas très compliquée de toute manière). Tout ce qui nous intéresse ici c'est de savoir que notre niveau a été chargé dans le tableau carte.



On teste donc le résultat du chargement dans un if.
Si le résultat est négatif (d'où le point d'exclamation qui sert à exprimer la négation), on arrête tout : on appelle exit.
Sinon, c'est que tout va bien et on peut continuer.

Recherche de la position de départ de Mario

Il faut maintenant initialiser la variable positionJoueur.
Cette variable, de type SDL_Rect, est un peu particulière. On ne s'en sert pas pour stocker des coordonnées en pixels. On s'en sert pour stocker des coordonnées en "cases" sur la carte. Ainsi, si on a :

positionJoueur.x == 11
positionJoueur.y == 11

... c'est que le joueur se trouve dans la toute dernière case en bas à droite de la carte
Reportez-vous au schéma de la carte qu'on a vu plus haut pour bien voir à quoi ça correspond si vous avez (déjà) oublié

Bref, on doit parcourir notre tableau carte à 2 dimensions à l'aide d'une double boucle. On utilise la petite variable i pour parcourir le tableau verticalement, et la variable j pour le parcourir horizontalement :

Code : C

A chaque case, on teste si elle contient MARIO (c'est-à-dire le départ du joueur sur la carte). Si c'est le cas, on stocke les coordonnées actuelles (situées dans i et j) dans la variable positionJoueur.
On efface aussi la case en la mettant à VIDE pour qu'elle soit considérée comme une case vide par la suite.

Activation de la répétition des touches

Dernière chose, très simple : on active la répétition des touches pour qu'on puisse se déplacer sur la carte en laissant une touche enfoncée.

Code : C

La boucle principale

Pfiou !
Nos initialisations sont faites, on peut maintenant attaquer la boucle principale.

C'est une boucle classique qui fonctionne sur le même schéma que celles qu'on a vues jusqu'ici. Elle est juste un peu plus grosse et un peu plus complète (faut c'qui faut )

Regardons de plus près le switch qui teste l'évènement :

Code : C

Si on fait Echap, le jeu s'arrêtera et on retournera au menu principal.

Comme vous le voyez, il n'y a pas 36 évènements différents à gérer : on teste juste si le joueur appuie sur haut, bas, gauche ou droite sur son clavier.
Selon la touche enfoncée, on change la direction de mario. C'est là qu'intervient marioActuel ! Si on appuie vers le haut, alors :

Code : C

Si on appuie vers le bas, alors :

Code : C

marioActuel pointe donc sur la surface représentant Mario dans la position actuelle. C'est ainsi qu'en blittant marioActuel tout à l'heure, on sera sûrs de blitter Mario dans la bonne direction

Maintenant, chose très importante : on appelle une fonction deplacerJoueur. Cette fonction va déplacer le joueur sur la carte s'il a le droit de le faire.

• Par exemple, on ne peut pas faire monter Mario d'un cran vers le haut s'il se trouve déjà tout en haut de la carte.
• On ne peut pas non plus le faire monter s'il y a un mur au-dessus de lui.
• On ne peut pas le faire monter s'il y a 2 caisses au-dessus de lui.
• Par contre, on peut le faire monter s'il y a juste une caisse au-dessus de lui.
• Mais attention, on ne peut pas le faire monter s'il y a une caisse au-dessus de lui et que le caisse se trouve au bord de la carte !

C'est ce qu'on appelle la gestion des collisions. Si ça peut vous rassurer, ici c'est une gestion des collisions extrêmement simple vu que le joueur se déplace par "cases" et dans seulement 4 directions possibles à la fois.



Quoi, vous croyiez tout de même pas qu'un jeu se codait en claquant des doigts hein ?
Dans un jeu 2D où on peut se déplacer dans toutes les directions pixel par pixel, c'est donc une gestion des collisions bien plus complexe (tout ça ne serait-ce que pour faire un RPG 2D !).

Mais il y a pire : la 3D. Je n'ai jamais expérimenté la gestion des collisions dans un jeu 3D, mais d'après ce que j'ai entendu dire, c'est la bête noire des programmeurs
Heureusement, il existe des librairies de gestion des collisions en 3D qui font le gros du travail à notre place.


Bon je divague là.
Revenons à la fonction deplacerJoueur. On lui envoie 3 paramètres :

• La carte (pour qu'il puisse la lire mais aussi la modifier si on déplace une caisse par exemple)
• La position du joueur (là aussi la fonction devra lire et éventuellement modifier la position du joueur)
• La direction dans laquelle on demande à aller. On utilise là encore les constantes HAUT, BAS, GAUCHE, DROITE pour plus de lisibilité.

Nous étudierons la fonction deplacerJoueur plus loin. J'aurais très bien pu mettre tous les tests dans le switch, mais ça serait devenu énorme et illisible. C'est là que découper son programme en fonctions prend tout son intérêt.

Blittons, blittons, la queue du cochon

Notre switch est terminé, à ce stade la carte a changé (ou pas), et le joueur a changé de position et de direction (ou pas ).
Quoi qu'il en soit, c'est l'heure du blit !

On commence par effacer l'écran en lui mettant une couleur de fond blanche :

Code : C

Et maintenant, on parcourt tout notre tableau à 2 dimensions carte pour savoir quel élément blitter à quel endroit sur l'écran.
On effectue une double boucle comme on l'a vu plus tôt pour parcourir toutes les 144 cases du tableau :

Code : C

Pour chacune des cases, on prépare la variable position (de type SDL_Rect) pour placer l'élément actuel à la bonne position sur l'écran.
Le calcul est très simple :

Code : C

Il suffit de multiplier i par TAILLE_BLOC pour avoir position.x.
Ainsi, si on se trouve à la 3ème case, c'est que i vaut 2 (n'oubliez pas que i commence à 0 !). On fait donc le calcul 2 * 34 = 68. On blittera donc l'image 68 pixels vers la droite sur ecran.
On fait la même chose pour les ordonnées y.

Ensuite, on fait un switch sur la case de la carte qu'on est en train d'analyser.
Là encore, avoir fait des constantes est vraiment pratique et ça rend les choses plus lisibles
On teste donc si la case vaut MUR, dans ce cas on blitte un mur. De même pour les caisses et les objectifs.

Test de victoire

Vous remarquerez qu'avant la double boucle on initialise le booléen objectifsRestants à 0.
Ce booléen sera mis à 1 dès qu'on aura détecté un objectif sur la carte. S'il ne reste plus d'objectifs, c'est que toutes les caisses sont sur des objectifs (il n'y a plus que des CAISSE_OK).

Il suffit de tester si le booléen vaut FAUX (= il ne reste plus d'objectifs).
Dans ce cas, on met la variable continuer à 0 pour arrêter la partie :

Code : C

Le joueur

Le joueur, on le blitte juste après. Justement, venons-y :

Code : C

On calcule sa position (en pixels cette fois) en faisant une simple multiplication entre positionJoueur et TAILLE_BLOC. On blitte ensuite le joueur à la position indiquée.

Flip !

Bon ben on a tout fait je crois, on peut afficher le nouvel écran au joueur

Code : C

Fin de la fonction : déchargements

Après la boucle principale, on doit faire quelques FreeSurface pour libérer la mémoire des sprites qu'on a chargés.
On désactive aussi la répétition des touches en envoyant les valeurs 0 à la fonction SDL_EnableKeyRepeat :

Code : C

La fonction deplacerJoueur

La fonction deplacerJoueur se trouve elle aussi dans jeu.c.
C'est une fonction... très chiante à écrire

C'est peut-être là la principale difficulté du codage du jeu de Sokoban.

Rappel : la fonction deplacerJoueur vérifie si on a le droit de déplacer le joueur dans la direction demandée. Elle met à jour la position du joueur (positionJoueur) et aussi la carte si une caisse a été déplacée.

Voici le prototype de la fonction :

Code : C

Ce prototype est un peu particulier. Vous voyez que j'envoie le tableau carte, et que je précise la taille de la deuxième dimension (NB_BLOCS_HAUTEUR).
Pourquoi cela ?

C'est un problème qui m'a pas mal embêté pendant longtemps et je ne comprenais pas pourquoi. La réponse est un peu compliquée pour que je la développe au milieu de ce cours. Grosso modo, le C ne devine pas qu'il s'agit d'un tableau à 2 dimensions, et il faut au moins donner la taille de la seconde dimension pour que ça fonctionne.
Donc, lorsque vous envoyez un tableau à 2 dimensions à une fonction, vous devez indiquer la taille de la seconde dimension dans le prototype. C'est comme ça, c'est obligatoire.

Autre chose : vous noterez que positionJoueur s'appelle en fait "pos" dans cette fonction. J'ai choisi de raccourcir le nom parce que c'est plus court à écrire, et vu qu'on va avoir besoin de l'écrire de nombreuses fois autant pas se fatiguer


Bon on commence par tester la direction dans laquelle on veut aller via un grand :

Code : C

Et c'est parti pour des tests de folie !

On peut commencer à faire tous les tests, en essayant tant qu'à faire de n'oublier aucun cas
Voici comment je procède : je teste toutes les possibilités de collision cas par cas, et dès que je détecte une collision (qui fait que le joueur ne peut pas bouger), je fais un break; pour sortir du switch et donc empêcher le déplacement.

Voici par exemple toutes les possibilités de collision qui existent pour un joueur qui veut se déplacer vers le haut :

• Le joueur est déjà tout en haut de la carte
• Il y a un mur au-dessus du joueur
• Il y a 2 caisses au-dessus du joueur (et il ne peut pas déplacer 2 caisses à la fois, rappelez-vous).

Si tous ces tests sont ok, alors je me permet de déplacer le joueur.

Je vais vous montrer les tests pour un déplacement vers le haut. Pour les autres sens, il suffira d'adapter un petit peu le code.


Code : C

On commence par vérifier si le joueur est déjà tout en haut de l'écran. En effet, si on essayait d'appeler carte[5][-1] par exemple, ce serait le plantage de programme assuré !
On commence donc par vérifier qu'on ne va pas "déborder" de l'écran.

Ensuite :

Code : C

Là encore c'est simple. On vérifie s'il n'y a pas un mur au-dessus du joueur. Si tel est le cas, on arrête (break).

Ensuite (attention ça devient hardcore) :

Code : C

Ce méga test de bourrin peut se traduire comme ceci :
SI au-dessus du joueur il y a une caisse (ou une caisse_ok, c'est-à-dire une caisse bien placée)
ET SI au-dessus de cette caisse il y a : soit le vide (on déborde du niveau car on est tout en haut), soit une autre caisse, soit une caisse_ok) :
ALORS on ne peut pas se déplacer : break.

Si on arrive jusque-là, on a le droit de déplacer le joueur !
On appelle d'abord une fonction qui va déplacer une caisse si nécessaire :

Code : C

Le déplacement de caisse : deplacerCaisse

J'ai choisi de gérer le déplacement de caisse dans une autre fonction car c'est le même code pour les 4 directions. On doit juste s'être assuré avant qu'on a le droit de se déplacer (ce qu'on vient de faire).
On envoie à la fonction 2 paramètres : le contenu de la case dans laquelle on veut aller, et le contenu de la case d'après.

Code : C

Cette fonction met à jour la carte car elle prend des pointeurs sur les cases concernées en paramètre.
Je vous laisse la lire, c'est assez simple à comprendre. Il ne faut pas oublier que si on déplace une CAISSE_OK, il faut remplacer la case où elle se trouvait par un OBJECTIF. Sinon, si c'est une simple CAISSE, alors on remplace la case en question par du VIDE.

Déplacer le joueur

On retourne dans la fonction deplacerJoueur.
Cette fois c'est la bonne, on peut déplacer le joueur.

Comment on fait ?
C'est supra-simple

Code : C

Il suffit de diminuer l'ordonnée y (car le joueur veut monter).

Résumé

En guise de résumé, voici tous les tests pour le cas HAUT :

Code : C

Je vous laisse le soin de faire du copier-coller pour les autres cas (attention, il faudra adapter le code, ce n'est pas exactement pareil à chaque fois !).


Et voilà, on vient de finir de coder le jeu
Enfin presque, il nous reste à coder la fonction de chargement (et de sauvegarde) de niveau.
On verra ensuite comment créer l'éditeur (rassurez-vous, ça ira bien plus vite )

fichiers.c contient 2 fonctions :

• chargerNiveau
• sauvegarderNiveau

Commençons par le chargement de niveau

chargerNiveau

Cette fonction prend un paramètre : la carte. Là encore, il faut préciser la taille de la seconde dimension car il s'agit d'un tableau à 2 dimensions.
La fonction renvoie un booléen : vrai si le chargement a réussi, faux si c'est un échec.

Le prototype est donc :

Code : C

Voyons le début de la fonction :

Code : C

On crée un tableau de char pour stocker le résultat du chargement du niveau temporairement.
On ouvre le fichier en lecture seule ("r"). On arrête la fonction en renvoyant 0 (faux) si l'ouverture a échoué. Classique.

Le fichier niveaux.lvl contient une ligne qui est une suite de nombres. Chaque nombre représente une case du niveau. Par exemple :

111110011111111114000001111100011001033101011011000002001211100101000011111100011211111111111001111130000001111111111111111111111111111111111111

On va donc lire cette ligne avec un fgets :

Code : C

On va analyser le contenu de ligneFichier. On sait que les 12 premiers caractères représentent la première ligne, les 12 suivants la seconde ligne etc.

Code : C

Par un simple petit calcul, on prend le caractère qui nous intéresse dans ligneFichier et on analyse sa valeur.



Bref, le switch fait la conversion '0' => 0, '1' => 1 etc... Et place tout dans le tableau carte (qui s'appelle niveau dans la fonction d'ailleurs, mais ça ne change rien )

Une fois que c'est fait, on peut fermer le fichier et renvoyer 1 pour dire que tout s'est bien passé :

Code : C

Résumé de la fonction chargerFichier

Code : C

Ca reste assez simple, le seul piège à éviter c'était de bien penser à convertir la valeur ASCII '0' en un nombre 0 (et de même pour 1, 2, 3, 4...).

sauvegarderNiveau

Cette fonction est là encore simple :

Code : C

J'utilise fprintf pour "traduire" les nombres du tableau niveau en caractères ASCII.
C'était là encore la seule difficulté, il ne faut pas écrire 0 mais '0'

L'éditeur de niveau est plus facile à créer qu'on ne pourrait l'imaginer.
En plus c'est une fonctionnalité qui va considérablement allonger la durée de vie de notre jeu, alors pourquoi s'en priver

Voilà comment l'éditeur va fonctionner :

• On utilise la souris pour placer les blocs qu'on veut sur l'écran.
• Un clic droit efface le bloc sur lequel se trouve la souris.
• Un clic gauche place un objet. Cet objet est mémorisé : par défaut, on pose des murs avec le clic gauche. On peut changer l'objet en cours en appuyant sur les touches du pavé numérique :
  
  • 1 : mur
  • 2 : caisse
  • 3 : objectif
  • 4 : départ du joueur Mario
• En appuyant sur S, le niveau sera sauvegardé.
• On peut revenir au menu principal en appuyant sur Echap.

Initialisations

Globalement, la fonction ressemble à celle du jeu. J'ai d'ailleurs commencé à la créer en faisant un simple copier-coller de la fonction de jeu, puis en enlevant ce qui ne servait plus et en ajoutant de nouvelles fonctionnalités.

Le début y ressemble pas mal déjà :

Code : C