Apprenez à programmer en C !
Last updated on Thursday, September 25, 2014
  • 4 semaines
  • Moyen

Free online content available in this course.

Paperback available in this course

eBook available in this course.

Certificate of achievement available at the end this course

Got it!

TP : Mario Sokoban

La bibliothèque SDL fournit, comme vous l'avez vu, un grand nombre de fonctions prêtes à l'emploi. Il est facile de s'y perdre les premiers temps, surtout si on ne pratique pas.

Ce premier TP de la section SDL est justement là pour vous faire découvrir un cas pratique et surtout vous inviter à manipuler. Cette fois, vous l'aurez compris je crois, notre programme ne sera pas une console mais bel et bien une fenêtre !

Quel va être le sujet de ce TP ? Il va s'agir d'un jeu de Sokoban !
Peut-être que ce nom ne vous dit rien, mais le jeu est pourtant un grand classique des casse-têtes. Il consiste à pousser des caisses pour les amener à des points précis dans un labyrinthe.

Cahier des charges du Sokoban

À 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 à cette é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 deux 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 !

La fig. suivante vous donne un aperçu du jeu que nous allons réaliser.

Le jeu Mario Sokoban que nous allons réaliser
Pourquoi avoir choisi ce jeu ?

Parce que c'est un jeu populaire, qu'il fait un bon sujet de programmation et qu'on peut le réaliser avec les connaissances que l'on a acquises.
Alors bien sûr, ça demande de l'organisation. La difficulté n'est pas vraiment dans le code lui-même mais dans l'organisation. Il va en effet falloir découper notre programme en plusieurs fichiers .c intelligemment et essayer de créer les bonnes fonctions.

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 suivis d'une correction à la fin. Au contraire, je vais vous montrer comment je réalise tout le projet de A à Z.

Et si je veux m'entraîner tout seul ?

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 (cela ne m'a pas empêché de me prendre la tête à plusieurs reprises quand même ;) ).

Sachez qu'un tel jeu peut être réalisé 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 deux ou trois jours et faites de votre mieux. Il est important que vous pratiquiez.

Le cahier des charges

Le cahier des charges 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 deux 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 (ce n'est pas indispensable mais ça ajoutera du piment !).

Voilà qui nous donnera bien assez de travail.

À noter qu'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 ne sait pas encore faire ça) ni du score.

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

Récupérer les sprites du jeu

Dans la plupart des jeux 2D, que ce soient des jeux de plate-forme 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 pour « sprites », vous trouverez de nombreuses réponses. En effet, il y a beaucoup de sites qui proposent de télécharger des sprites de jeux 2D auxquels vous avez sûrement joué par le passé.

Voici les sprites que nous allons utiliser :

Sprite

Description

Image utilisateurImage utilisateurImage utilisateur

Un mur

Image utilisateurImage utilisateurImage utilisateur

Une caisse

Image utilisateurImage utilisateurImage utilisateur

Une caisse placée sur un objectif.

Image utilisateurImage utilisateurImage utilisateur

Un objectif (où l'on doit mettre une caisse).

Image utilisateurImage utilisateurImage utilisateur

Le joueur (Mario) orienté vers le bas

Image utilisateurImage utilisateurImage utilisateur

Mario vers la droite

Image utilisateurImage utilisateurImage utilisateur

Mario vers la gauche

Image utilisateurImage utilisateurImage utilisateur

Mario vers le haut

Le plus simple pour vous sera de télécharger un pack que j'ai préparé contenant toutes ces images.

Télécharger toutes les images

J'ai aussi créé une petite image qui pourra servir de menu d'accueil au lancement du programme (fig. suivante), vous la trouverez dans le pack que vous venez normalement de télécharger.

L'écran d'accueil du programme

Vous noterez que les images sont dans différents formats. Il y a des GIF, des PNG et des JPEG. Nous allons donc avoir besoin de la bibliothèque 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 !

Le main et les constantes

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 celle-là). Ce n'est pas une règle : c'est juste ma façon de fonctionner. Chacun a sa propre manière 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 donc 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 des fonctions de editeur.c ;

  • fichiers.c : fonctions gérant la lecture et l'écriture de fichiers de niveaux (comme niveaux.lvl par exemple) ;

  • fichiers.h : prototypes des fonctions de fichiers.c.

On va commencer par créer le fichier des constantes.

Les constantes : constantes.h

Voici le contenu de mon fichier de constantes :

/*
constantes.h
------------

Par mateo21, pour Le Site du Zéro (www.siteduzero.com)

Rôle : définit des constantes pour tout le programme (taille de la fenêtre...)
*/

#ifndef DEF_CONSTANTES
#define DEF_CONSTANTES

    #define TAILLE_BLOC         34 // Taille d'un bloc (carré) en pixels
    #define NB_BLOCS_LARGEUR    12
    #define NB_BLOCS_HAUTEUR    12
    #define LARGEUR_FENETRE     TAILLE_BLOC * NB_BLOCS_LARGEUR
    #define HAUTEUR_FENETRE     TAILLE_BLOC * NB_BLOCS_HAUTEUR

    enum {HAUT, BAS, GAUCHE, DROITE};
    enum {VIDE, MUR, CAISSE, OBJECTIF, MARIO, CAISSE_OK};

#endif

Vous noterez plusieurs points intéressants dans ce petit fichier.

  • 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 ;

    • l'auteur ;

    • le rôle du fichier (ce à quoi servent les fonctions qu'il contient) ;

    • je ne l'ai pas fait là, mais généralement, on met aussi la date de création et la date de dernière modification. Ça 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. Ici cette protection ne sert pas vraiment, mais j'ai pris l'habitude de faire ça pour chacun de mes fichiers .h sans exception.

  • Enfin, le cœur du fichier. Vous avez une série de define. J'indique la taille d'un petit bloc en pixels (tous mes sprites sont des carrés de 34 px). 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. Cela ressemble aux define à 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 define 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 me moque bien de savoir que HAUT vaut 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 sera d'inclure ce fichier de constantes 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 :

#include "constantes.h"

Le main : main.c

La fonction main principale est extrêmement simple. Elle a pour rôle d'afficher l'écran d'accueil du jeu et de rediriger vers la bonne section.

/*
main.c
------

Par mateo21, pour Le Site du Zéro (www.siteduzero.com)

Rôle : menu du jeu. Permet de choisir entre l'éditeur et le jeu lui-même.
*/

#include <stdlib.h>
#include <stdio.h>
#include <SDL/SDL.h>
#include <SDL/SDL_image.h>

#include "constantes.h"
#include "jeu.h"
#include "editeur.h"

int main(int argc, char *argv[])
{
    SDL_Surface *ecran = NULL, *menu = NULL;
    SDL_Rect positionMenu;
    SDL_Event event;

    int continuer = 1;

    SDL_Init(SDL_INIT_VIDEO);

    SDL_WM_SetIcon(IMG_Load("caisse.jpg"), NULL); // L'icône doit être chargée avant SDL_SetVideoMode
    ecran = SDL_SetVideoMode(LARGEUR_FENETRE, HAUTEUR_FENETRE, 32, SDL_HWSURFACE | SDL_DOUBLEBUF);
    SDL_WM_SetCaption("Mario Sokoban", NULL);

    menu = IMG_Load("menu.jpg");
    positionMenu.x = 0;
    positionMenu.y = 0;

    while (continuer)
    {
        SDL_WaitEvent(&event);
        switch(event.type)
        {
            case SDL_QUIT:
                continuer = 0;
                break;
            case SDL_KEYDOWN:
                switch(event.key.keysym.sym)
                {
                    case SDLK_ESCAPE: // Veut arrêter le jeu
                        continuer = 0;
                        break;
                    case SDLK_KP1: // Demande à jouer
                        jouer(ecran);
                        break;
                    case SDLK_KP2: // Demande l'éditeur de niveaux
                        editeur(ecran);
                        break;
                }
                break;
        }

        // Effacement de l'écran
        SDL_FillRect(ecran, NULL, SDL_MapRGB(ecran->format, 0, 0, 0));
        SDL_BlitSurface(menu, NULL, ecran, &positionMenu);
        SDL_Flip(ecran);
    }

    SDL_FreeSurface(menu);
    SDL_Quit();

    return EXIT_SUCCESS;
}

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

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

menu = IMG_Load("menu.jpg");
La boucle des événements

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

  • arrêt du programme (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.

Le jeu

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é que ça en a l'air.

Les paramètres envoyés à la fonction

La fonction jouera 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 y dessiner, 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 :

jouer(ecran);

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

void jouer(SDL_Surface* ecran);

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 ajoutées par la suite.

Variables de types définis par la SDL

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

SDL_Surface *mario[4] = {NULL}; // 4 surfaces pour 4 directions de mario
SDL_Surface *mur = NULL, *caisse = NULL, *caisseOK = NULL, *objectif = NULL, *marioActuel = NULL;
SDL_Rect position, positionJoueur;
SDL_Event event;

J'ai créé un tableau de SDL_Surface appelé mario. C'est un tableau de quatre 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 fait télécharger plus haut : mur, caisse, caisseOK (une caisse sur un objectif) et objectif.

À quoi sert marioActuel ?

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

SDL_BlitSurface(marioActuel, NULL, ecran, &position);

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 celui 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, inutile de créer un SDL_Rect pour chaque surface !). positionJoueur est en revanche un peu différente : elle indique à quelle case sur la carte se trouve actuellement le joueur. Enfin, la variable event traitera les événements.

Variables plus « classiques »

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

int continuer = 1, objectifsRestants = 0, i = 0, j = 0;
int carte[NB_BLOCS_LARGEUR][NB_BLOCS_HAUTEUR] = {0};

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

C'est là que les choses deviennent vraiment intéressantes. J'ai en effet créé un tableau à deux dimensions. Je ne vous ai pas parlé de ce type de tableaux auparavant, 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 :

int carte[NB_BLOCS_LARGEUR][NB_BLOCS_HAUTEUR] = {0};

En fait, il s'agit d'un tableau d'int (entiers) qui a la particularité d'avoir deux paires de crochets [ ].
Si vous vous souvenez bien de constantes.h, 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 :

int carte[12][12] = {0};

Mais qu'est-ce que ça veut dire ?

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

carte[0][0]
carte[0][1]
carte[0][2]
carte[0][3]
carte[0][4]
carte[0][5]
carte[0][6]
carte[0][7]
carte[0][8]
carte[0][9]
carte[0][10]
carte[0][11]
carte[1][0]
carte[1][1]
carte[1][2]
carte[1][3]
carte[1][4]
carte[1][5]
carte[1][6]
carte[1][7]
carte[1][8]
carte[1][9]
carte[1][10]
...
carte[11][2]
carte[11][3]
carte[11][4]
carte[11][5]
carte[11][6]
carte[11][7]
carte[11][8]
carte[11][9]
carte[11][10]
carte[11][11]

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

La fig. suivante vous donne une idée de la façon dont la carte est représentée.

Découpage de la carte

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 !

enum {VIDE, MUR, CAISSE, OBJECTIF, MARIO, CAISSE_OK};

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 :

// Chargement des sprites (décors, personnage...)
mur = IMG_Load("mur.jpg");
caisse = IMG_Load("caisse.jpg");
caisseOK = IMG_Load("caisse_ok.jpg");
objectif = IMG_Load("objectif.png");
mario[BAS] = IMG_Load("mario_bas.gif");
mario[GAUCHE] = IMG_Load("mario_gauche.gif");
mario[HAUT] = IMG_Load("mario_haut.gif");
mario[DROITE] = IMG_Load("mario_droite.gif");

Rien de sorcier là-dedans : on charge tout grâce à IMG_Load.
S'il y a une petite particularité, 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 :

marioActuel = mario[BAS]; // Mario sera dirigé vers le bas au départ

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 :

marioActuel = mario[DROITE];

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 à deux 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.

// Chargement du niveau
if (!chargerNiveau(carte))
    exit(EXIT_FAILURE); // On arrête le jeu si on n'a pas pu charger le niveau

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étails 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 une condition. 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.

Nous possédons maintenant un tableau carte qui décrit le contenu de chaque case : MUR, VIDE, CAISSE

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 de la fig. suivante pour bien voir à quoi ça correspond si vous avez (déjà) oublié.

On doit parcourir notre tableau carte à deux 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 :

// Recherche de la position de Mario au départ
for (i = 0 ; i < NB_BLOCS_LARGEUR ; i++)
{
    for (j = 0 ; j < NB_BLOCS_HAUTEUR ; j++)
    {
        if (carte[i][j] == MARIO) // Si Mario se trouve à cette position
        {
            positionJoueur.x = i;
            positionJoueur.y = j;
            carte[i][j] = VIDE;
        }
    }
}

À 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.

// Activation de la répétition des touches
SDL_EnableKeyRepeat(100, 100);

La boucle principale

Pfiou ! Nos initialisations sont faites, on peut maintenant s'occuper de 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 comme on dit !).

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

switch(event.type)
{
    case SDL_QUIT:
        continuer = 0;
        break;
    case SDL_KEYDOWN:
        switch(event.key.keysym.sym)
        {
            case SDLK_ESCAPE:
                continuer = 0;
                break;
            case SDLK_UP:
                marioActuel = mario[HAUT];
                deplacerJoueur(carte, &positionJoueur, HAUT);
                break;
            case SDLK_DOWN:
                marioActuel = mario[BAS];
                deplacerJoueur(carte, &positionJoueur, BAS);
                break;
            case SDLK_RIGHT:
                marioActuel = mario[DROITE];
                deplacerJoueur(carte, &positionJoueur, DROITE);
                break;
            case SDLK_LEFT:
                marioActuel = mario[GAUCHE];
                deplacerJoueur(carte, &positionJoueur, GAUCHE);
                break;
        }
        break;
}

Si on appuie sur la touche 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 les touches « haut », « bas », « gauche » ou « droite » de 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 :

marioActuel = mario[HAUT];

Si on appuie vers le bas, alors :

marioActuel = mario[BAS];

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 certain 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 deux 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 la caisse se trouve au bord de la carte !

Oh la la, c'est quoi ce bazar ?

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 quatre directions possibles à la fois. Dans un jeu 2D où on peut se déplacer dans toutes les directions pixel par pixel, la gestion des collisions est bien plus complexe.

Mais il y a pire : la 3D. La gestion des collisions dans un jeu 3D est vraiment la bête noire des programmeurs. Heureusement, il existe des bibliothèques de gestion des collisions en 3D qui font le gros du travail à notre place.

Revenons à la fonction deplacerJoueur et concentrons-nous. On lui envoie trois paramètres :

  • la carte : pour qu'elle 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 celui-ci 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 du programme, la carte et le joueur ont probablement changé. Quoi qu'il en soit, c'est l'heure du blit !

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

// Effacement de l'écran
SDL_FillRect(ecran, NULL, SDL_MapRGB(ecran->format, 255, 255, 255));

Et maintenant, on parcourt tout notre tableau à deux 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 :

// Placement des objets à l'écran
objectifsRestants = 0;

for (i = 0 ; i < NB_BLOCS_LARGEUR ; i++)
{
    for (j = 0 ; j < NB_BLOCS_HAUTEUR ; j++)
    {
        position.x = i * TAILLE_BLOC;
        position.y = j * TAILLE_BLOC;

        switch(carte[i][j])
        {
            case MUR:
                SDL_BlitSurface(mur, NULL, ecran, &position);
                break;
            case CAISSE:
                SDL_BlitSurface(caisse, NULL, ecran, &position);
                break;
            case CAISSE_OK:
                SDL_BlitSurface(caisseOK, NULL, ecran, &position);
                break;
            case OBJECTIF:
                SDL_BlitSurface(objectif, NULL, ecran, &position);
                objectifsRestants = 1;
                break;
        }
    }
}

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 :

position.x = i * TAILLE_BLOC;
position.y = j * TAILLE_BLOC;

Il suffit de multiplier i par TAILLE_BLOC pour avoir position.x.
Ainsi, si on se trouve à la troisiè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 défini des constantes est vraiment pratique et 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 », c'est-à-dire s'il ne reste plus d'objectifs.
Dans ce cas, on met la variable continuer à 0 pour arrêter la partie :

// Si on n'a trouvé aucun objectif sur la carte, c'est qu'on a gagné
if (!objectifsRestants)
    continuer = 0;
Le joueur

Il nous reste à blitter le joueur :

// On place le joueur à la bonne position
position.x = positionJoueur.x * TAILLE_BLOC;
position.y = positionJoueur.y * TAILLE_BLOC;
SDL_BlitSurface(marioActuel, NULL, ecran, &position);

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 !

On a tout fait, il ne nous reste plus qu'à afficher l'écran au joueur :

SDL_Flip(ecran);

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 :

// Désactivation de la répétition des touches (remise à 0)
SDL_EnableKeyRepeat(0, 0);

// Libération des surfaces chargées
SDL_FreeSurface(mur);
SDL_FreeSurface(caisse);
SDL_FreeSurface(caisseOK);
SDL_FreeSurface(objectif);
for (i = 0 ; i < 4 ; i++)
    SDL_FreeSurface(mario[i]);

La fonction deplacerJoueur

La fonction deplacerJoueur se trouve elle aussi dans jeu.c.
C'est une fonction… assez délicate à écrire. C'est peut-être la principale difficulté que l'on rencontre lorsqu'on code un 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 :

void deplacerJoueur(int carte[][NB_BLOCS_HAUTEUR], SDL_Rect *pos, int direction);

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 ?

La réponse est un peu compliquée pour que je la développe au milieu de ce cours. Pour faire simple, le C ne devine pas qu'il s'agit d'un tableau à deux dimensions et il faut au moins donner la taille de la seconde dimension pour que ça fonctionne.
Donc, lorsque vous envoyez un tableau à deux 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 ne pas se fatiguer.

Commençons par tester la direction dans laquelle on veut aller via un grand switch :

switch(direction)
{
    case HAUT:
    /* etc. */
Et c'est parti pour des tests de folie !

Il faut maintenant écrire tous les tests de tous les cas possibles, en essayant de ne pas en oublier un seul.

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 deux caisses au-dessus du joueur (et il ne peut pas déplacer deux caisses à la fois, rappelez-vous) ;

  • il y a une caisse puis le bord de la carte.

Si tous ces tests sont ok, alors je me permets 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.

if (pos->y - 1 < 0) // Si le joueur dépasse l'écran, on arrête
    break;

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 du programme assuré !
On commence donc par vérifier qu'on ne va pas « déborder » de l'écran.

Ensuite :

if (carte[pos->x][pos->y - 1] == MUR) // S'il y a un mur, on arrête
    break;

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 les yeux) :

// Si on veut pousser une caisse, il faut vérifier qu'il n'y a pas de mur derrière (ou une autre caisse, ou la limite du monde)
if ((carte[pos->x][pos->y - 1] == CAISSE || carte[pos->x][pos->y - 1] == CAISSE_OK) &&
    (pos->y - 2 < 0 || carte[pos->x][pos->y - 2] == MUR ||
    carte[pos->x][pos->y - 2] == CAISSE || carte[pos->x][pos->y - 2] == CAISSE_OK))
    break;

Ce gros test 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 à passer ce test, on a le droit de déplacer le joueur. Ouf !
On appelle d'abord une fonction qui va déplacer une caisse si nécessaire :

// Si on arrive là, c'est qu'on peut déplacer le joueur !
// On vérifie d'abord s'il y a une caisse à déplacer
deplacerCaisse(&carte[pos->x][pos->y - 1], &carte[pos->x][pos->y - 2]);
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 quatre 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 deux paramètres : le contenu de la case dans laquelle on veut aller et le contenu de la case d'après.

void deplacerCaisse(int *premiereCase, int *secondeCase)
{
    if (*premiereCase == CAISSE || *premiereCase == CAISSE_OK)
    {
        if (*secondeCase == OBJECTIF)
            *secondeCase = CAISSE_OK;
        else
            *secondeCase = CAISSE;

        if (*premiereCase == CAISSE_OK)
            *premiereCase = OBJECTIF;
        else
            *premiereCase = VIDE;
    }
}

Cette fonction met à jour la carte car elle prend en paramètres des pointeurs sur les cases concernées.
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 fait-on ? C'est très très simple :

pos->y--; // On peut enfin faire monter le joueur (oufff !)

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 :

switch(direction)
{
    case HAUT:
        if (pos->y - 1 < 0) // Si le joueur dépasse l'écran, on arrête
            break;
        if (carte[pos->x][pos->y - 1] == MUR) // S'il y a un mur, on arrête
            break;
        // Si on veut pousser une caisse, il faut vérifier qu'il n'y a pas de mur derrière (ou une autre caisse, ou la limite du monde)
        if ((carte[pos->x][pos->y - 1] == CAISSE || carte[pos->x][pos->y - 1] == CAISSE_OK) &&
            (pos->y - 2 < 0 || carte[pos->x][pos->y - 2] == MUR ||
            carte[pos->x][pos->y - 2] == CAISSE || carte[pos->x][pos->y - 2] == CAISSE_OK))
            break;
        
        // Si on arrive là, c'est qu'on peut déplacer le joueur !
        // On vérifie d'abord s'il y a une caisse à déplacer
        deplacerCaisse(&carte[pos->x][pos->y - 1], &carte[pos->x][pos->y - 2]);
        
        pos->y--; // On peut enfin faire monter le joueur (oufff !)
        break;

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 à voir la fonction de chargement (et de sauvegarde) de niveaux.
On verra ensuite comment créer l'éditeur. Rassurez-vous, ça ira bien plus vite !

Chargement et enregistrement de niveaux

Le fichier fichiers.c contient deux 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 à deux dimensions.
La fonction renvoie un booléen : « vrai » si le chargement a réussi, « faux » si c'est un échec.

Le prototype est donc :

int chargerNiveau(int niveau[][NB_BLOCS_HAUTEUR]);

Voyons le début de la fonction :

FILE* fichier = NULL;
char ligneFichier[NB_BLOCS_LARGEUR * NB_BLOCS_HAUTEUR + 1] = {0};
int i = 0, j = 0;

fichier = fopen("niveaux.lvl", "r");
if (fichier == NULL)
    return 0;

On crée un tableau de char pour stocker temporairement le résultat du chargement du niveau.
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 :

11111001111111111400000111110001100103310101101100000200121110 [...]

On va donc lire cette ligne avec un fgets :

fgets(ligneFichier, NB_BLOCS_LARGEUR * NB_BLOCS_HAUTEUR + 1, fichier);

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.

for (i = 0 ; i < NB_BLOCS_LARGEUR ; i++)
{
    for (j = 0 ; j < NB_BLOCS_HAUTEUR ; j++)
    {
        switch (ligneFichier[(i * NB_BLOCS_LARGEUR) + j])
        {
            case '0':
                niveau[j][i] = 0;
                break;
            case '1':
                niveau[j][i] = 1;
                break;
            case '2':
                niveau[j][i] = 2;
                break;
            case '3':
                niveau[j][i] = 3;
                break;
            case '4':
                niveau[j][i] = 4;
                break;
        }
    }
}

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

Le switch fait la conversion '0' => 0, '1' => 1, etc. Il place tout dans le tableau carte. La carte s'appelle niveau dans cette 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é :

fclose(fichier);
return 1;

Finalement, le chargement du niveau dans le fichier n'était pas bien compliqué. 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 :

int sauvegarderNiveau(int niveau[][NB_BLOCS_HAUTEUR])
{
    FILE* fichier = NULL;
    int i = 0, j = 0;

    fichier = fopen("niveaux.lvl", "w");
    if (fichier == NULL)
        return 0;

    for (i = 0 ; i < NB_BLOCS_LARGEUR ; i++)
    {
        for (j = 0 ; j < NB_BLOCS_HAUTEUR ; j++)
        {
            fprintf(fichier, "%d", niveau[j][i]);
        }
    }

    fclose(fichier);
    return 1;
}

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

L'éditeur de niveaux

L'éditeur de niveaux 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.

Édition d'un niveau avec l'éditeur

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 déjà pas mal :

void editeur(SDL_Surface* ecran)
{
    SDL_Surface *mur = NULL, *caisse = NULL, *objectif = NULL, *mario = NULL;
    SDL_Rect position;
    SDL_Event event;
    
    int continuer = 1, clicGaucheEnCours = 0, clicDroitEnCours = 0;
    int objetActuel = MUR, i = 0, j = 0;
    int carte[NB_BLOCS_LARGEUR][NB_BLOCS_HAUTEUR] = {0};
    
    // Chargement des objets et du niveau
    mur = IMG_Load("mur.jpg");
    caisse = IMG_Load("caisse.jpg");
    objectif = IMG_Load("objectif.png");
    mario = IMG_Load("mario_bas.gif");
    
    if (!chargerNiveau(carte))
        exit(EXIT_FAILURE);

Là, vous avez les définitions de variables et les initialisations.
Vous remarquerez que je ne charge qu'un Mario (celui dirigé vers le bas). En effet, on ne va pas diriger Mario au clavier là, on a juste besoin d'un sprite représentant la position de départ de Mario.

La variable objetActuel retient l'objet actuellement sélectionné par l'utilisateur. Par défaut, c'est un MUR. Le clic gauche créera donc un mur au départ, mais cela pourra être changé par l'utilisateur en appuyant sur 1, 2, 3 ou 4.

Les booléens clicGaucheEnCourset clicDroitEnCours, comme leurs noms l'indiquent, permettent de mémoriser si un clic est en cours (si le bouton de la souris est enfoncé). Je vous expliquerai le principe un peu plus loin. Cela nous permettra de poser des objets à l'écran en laissant le bouton de la souris enfoncé. Sinon on est obligé de cliquer frénétiquement avec la souris pour placer plusieurs fois le même objet à différents endroits, ce qui est un peu fatigant.

Enfin, la carte actuellement sauvegardée dans niveaux.lvl est chargée. Ce sera notre point de départ.

La gestion des événements

Cette fois, on va devoir gérer un nombre important d'événements différents. Allons-y, un par un.

SDL_QUIT
case SDL_QUIT:
    continuer = 0;
    break;

Si on clique sur la croix, la boucle s'arrête et on revient au menu principal.
Notez que ce n'est pas ce qu'il y a de plus ergonomique pour l'utilisateur : celui-ci s'attend plutôt à ce que le programme s'arrête quand on clique sur la croix, or ce n'est pas ce qu'il se passe ici car on ne fait que revenir au menu. Il faudrait peut-être trouver un moyen d'arrêter le programme en renvoyant une valeur spéciale à la fonction main par exemple. Je vous laisse réfléchir à une solution.

SDL_MOUSEBUTTONDOWN
case SDL_MOUSEBUTTONDOWN:
    if (event.button.button == SDL_BUTTON_LEFT)
    {
        // On met l'objet actuellement choisi (mur, caisse...) à l'endroit du clic
        carte[event.button.x / TAILLE_BLOC][event.button.y / TAILLE_BLOC] = objetActuel;
        clicGaucheEnCours = 1; // On retient qu'un bouton est enfoncé
    }
    else if (event.button.button == SDL_BUTTON_RIGHT) // Clic droit pour effacer
    {
        carte[event.button.x / TAILLE_BLOC][event.button.y /TAILLE_BLOC] = VIDE;
        clicDroitEnCours = 1;
    }
    break;

On commence par tester le bouton qui est enfoncé (on vérifie si c'est le clic gauche ou le clic droit) :

  • si c'est un clic gauche, on place l'objetActuel sur la carte à la position de la souris ;

  • si c'est un clic droit, on efface ce qu'il y a à cet endroit sur la carte (on met VIDE comme je vous avais dit).

Comment sait-on sur quelle « case » de la carte on se trouve ?

On le retrouve grâce à un petit calcul. Il suffit de prendre les coordonnées de la souris (event.button.x par exemple) et de diviser cette valeur par la taille d'un bloc (TAILLE_BLOC).
C'est une division de nombres entiers. Comme en C une division de nombres entiers donne un nombre entier, on est sûr d'avoir une valeur qui corresponde à une des cases de la carte.

Par exemple, si je suis au 75e pixel sur la carte (sur l'axe des abscisses x), je divise ce nombre par TAILLE_BLOC qui vaut ici 34.

75 / 34 = 2

N'oubliez pas que le reste est ignoré. On ne garde que la partie entière de la division en C car il s'agit d'une divison de nombres entiers.
On sait donc qu'on se trouve sur la case n° 2 (c'est-à-dire la troisième case, car un tableau commence à 0, souvenez-vous).

Autre exemple : si je suis au 10e pixel (c'est-à-dire très proche du bord), ça va donner le calcul suivant :

10 / 34 = 0

On est donc à la case n° 0 !

C'est comme ça qu'un simple petit calcul nous permet de savoir sur quelle case de la carte on se situe.

carte[event.button.x / TAILLE_BLOC][event.button.y / TAILLE_BLOC] = objetActuel;

Autre chose très importante : on met un booléen clicGaucheEnCours (ou clicDroit selon le cas) à 1. Cela nous permettra de savoir lors d'un événement MOUSEMOTION si un bouton de la souris est enfoncé pendant le déplacement.

SDL_MOUSEBUTTONUP
case SDL_MOUSEBUTTONUP: // On désactive le booléen qui disait qu'un bouton était enfoncé
    if (event.button.button == SDL_BUTTON_LEFT)
        clicGaucheEnCours = 0;
    else if (event.button.button == SDL_BUTTON_RIGHT)
        clicDroitEnCours = 0;
    break;

L'événement MOUSEBUTTONUP sert simplement à remettre le booléen à 0. On sait que le clic est terminé et donc qu'il n'y a plus de « clic en cours ».

SDL_MOUSEMOTION
case SDL_MOUSEMOTION:
    if (clicGaucheEnCours) // Si on déplace la souris et que le bouton gauche de la souris est enfoncé
    {
        carte[event.motion.x / TAILLE_BLOC][event.motion.y / TAILLE_BLOC] = objetActuel;
    }
    else if (clicDroitEnCours) // Pareil pour le bouton droit de la souris
    {
        carte[event.motion.x / TAILLE_BLOC][event.motion.y / TAILLE_BLOC] = VIDE;
    }
    break;

C'est là que nos booléens prennent toute leur importance. On vérifie quand on bouge la souris si un clic est en cours. Si tel est le cas, on place sur la carte un objet (ou du vide si c'est un clic droit).
Cela nous permet donc de placer d'affilée plusieurs objets du même type sans avoir à cliquer plusieurs fois. On a juste à déplacer la souris en maintenant son bouton enfoncé !

En clair : à chaque fois qu'on bouge la souris (ne serait-ce que d'un pixel), on vérifie si un des booléens est activé. Si tel est le cas, alors on pose un objet sur la carte. Sinon, on ne fait rien.

Résumé : je résume la technique, car vous vous en servirez certainement dans d'autres programmes.
Cette technique permet de savoir si un bouton de la souris est enfoncé lorsqu'on la déplace. On peut s'en servir pour coder un glisser-déplacer.

  1. Lors d'un MOUSEBUTTONDOWN: on met un booléen clicEnCours à 1.

  2. Lors d'un MOUSEMOTION: on teste si le booléen clicEnCours vaut « vrai ». S'il vaut « vrai », on sait qu'on est en train de faire une sorte de glisser-déplacer avec la souris.

  3. Lors d'un MOUSEBUTTONUP: on remet le booléen clicEnCours à 0, car le clic est terminé (relâchement du bouton de la souris).

SDL_KEYDOWN

Les touches du clavier permettent de charger et de sauvegarder le niveau ainsi que de changer l'objet actuellement sélectionné pour le clic gauche de la souris.

case SDL_KEYDOWN:
    switch(event.key.keysym.sym)
    {
        case SDLK_ESCAPE:
            continuer = 0;
            break;
        case SDLK_s:
            sauvegarderNiveau(carte);
            break;
        case SDLK_c:
            chargerNiveau(carte);
            break;
        case SDLK_KP1:
            objetActuel = MUR;
            break;
        case SDLK_KP2:
            objetActuel = CAISSE;
            break;
        case SDLK_KP3:
            objetActuel = OBJECTIF;
            break;
        case SDLK_KP4:
            objetActuel = MARIO;
            break;
    }
    break;

Ce code est très simple. On change l'objet actuel si on appuie sur une des touches numériques, on enregistre le niveau si on appuie sur S, ou on charge le dernier niveau enregistré si on appuie sur C.

Blit time !

Voilà : on a passé en revue tous les événements.
Maintenant, on n'a plus qu'à blitter chacun des éléments de la carte à l'aide d'une double boucle. C'est à peu de choses près le même code que celui de la fonction de jeu. Je vous le redonne, mais pas la peine de vous le réexpliquer ici.

// Effacement de l'écran
SDL_FillRect(ecran, NULL, SDL_MapRGB(ecran->format, 255, 255, 255));

// Placement des objets à l'écran
for (i = 0 ; i < NB_BLOCS_LARGEUR ; i++)
{
    for (j = 0 ; j < NB_BLOCS_HAUTEUR ; j++)
    {
        position.x = i * TAILLE_BLOC;
        position.y = j * TAILLE_BLOC;

        switch(carte[i][j])
        {
            case MUR:
                SDL_BlitSurface(mur, NULL, ecran, &position);
                break;
            case CAISSE:
                SDL_BlitSurface(caisse, NULL, ecran, &position);
                break;
            case OBJECTIF:
                SDL_BlitSurface(objectif, NULL, ecran, &position);
                break;
            case MARIO:
                SDL_BlitSurface(mario, NULL, ecran, &position);
                break;
        }
    }
}

// Mise à jour de l'écran
SDL_Flip(ecran);

Il ne faut pas oublier après la boucle principale de faire les SDL_FreeSurface qui s'imposent :

SDL_FreeSurface(mur);
SDL_FreeSurface(caisse);
SDL_FreeSurface(objectif);
SDL_FreeSurface(mario);

Avec ça, le ménage est fait. :-)

Résumé et améliorations

Bien, on a fait le tour. L'heure est au résumé.

Alors résumons !

Et quel meilleur résumé pourrait-on imaginer que le code source complet du programme avec les commentaires ?

Pour éviter de vous proposer des dizaines de pages de code qui répètent tout ce qu'on vient de voir, je vous propose plutôt de télécharger le code source complet du programme ainsi que l'exécutable (compilé pour Windows).

Télécharger le programme + les sources (436 Ko)

Ce fichier .zip contient :

  • l'exécutable pour Windows (si vous êtes sous un autre OS, il suffira de recompiler) ;

  • les DLL de la SDL et de SDL_Image ;

  • toutes les images dont a besoin le programme (je vous les ai fait télécharger plus tôt dans le pack « sprites ») ;

  • les sources complètes du programme ;

  • le fichier .cbp de projet Code::Blocks. Si vous voulez ouvrir le projet sous un autre IDE, créez un nouveau projet de type SDL (configurez-le correctement pour la SDL) et ajoutez-y manuellement tous les fichiers .c et .h. Ce n'est pas bien compliqué, vous verrez.

Vous noterez que le projet contient, en plus des .c et des .h, un fichier ressources.rc.
C'est un fichier qui peut être ajouté au projet (uniquement sous Windows) et qui permet d'intégrer des fichiers dans l'exécutable. Ici, je me sers du fichier de ressources pour intégrer une icône dans l'exécutable. Cela aura pour effet de donner une icône à l'exécutable, visible dans l'explorateur Windows (fig. suivante).

Intégration d'une icône à l'exécutable

Avouez que c'est quand même plus sympa que d'avoir l'icône par défaut de Windows pour les exécutables !
Vous trouverez plus d'informations sur cette technique sur le cours Créer une icône pour son programme.

Améliorez !

Ce programme n'est pas parfait, loin de là !
Vous voulez des idées pour l'améliorer ?

  • Il manque un mode d'emploi. Affichez un écran d'explications juste avant le lancement d'une partie et avant le lancement de l'éditeur. Indiquez en particulier les touches à utiliser.

  • Dans l'éditeur de niveaux, on ne sait pas quel est l'objet actuellement sélectionné. Ce qui serait bien, c'est que l'objet actuellement sélectionné suive le curseur de la souris. Comme ça, l'utilisateur verrait ce qu'il s'apprête à mettre sur la carte. C'est facile à faire : on a déjà fait un Zozor qui suit le curseur de la souris dans le chapitre précédent !

  • Dans l'éditeur de niveaux, on apprécierait de pouvoir choisir une CAISSE_OK (une caisse bien placée sur un objectif dès le départ). En effet, je me suis rendu compte par la suite qu'il y a de nombreux niveaux qui commencent avec des caisses bien placées dès le départ (ça ne veut pas dire que le niveau est plus facile, loin de là).

  • Dans l'éditeur toujours, il faudrait empêcher que l'on puisse placer plus d'un départ de joueur sur une même carte !

  • Lorsqu'on réussit un niveau, on retourne immédiatement au menu. C'est un peu brut. Que diriez-vous d'afficher un message « Bravo » au centre de l'écran quand on gagne ?

  • Enfin, il serait bien que le programme puisse gérer plus d'un niveau à la fois. Il faudrait que l'on puisse créer une véritable petite aventure d'une vingtaine de niveaux par exemple. C'est un petit peu plus compliqué à coder mais faisable. Il faudra adapter le jeu et l'éditeur de niveaux en conséquence. Je vous suggère de mettre un niveau par ligne dans niveaux.lvl.

Comme promis, pour vous prouver que c'est faisable… je l'ai fait !
Je ne vous donne pas le code source, en revanche (je crois que je vous en ai déjà assez donné jusqu'ici !), mais je vous donne le programme complet compilé pour Windows et Linux.

Le programme comporte une aventure de 20 niveaux (de très très facile à… super difficile).
Pour réaliser certains de ces niveaux, je me suis basé sur le site d'un passionné de Sokoban (sokoban.online.fr).

Voici le Mario Sokoban amélioré pour Windows et Linux :

Téléchargez l'installation du Mario Sokoban amélioré (665 Ko)
Ou bien : Téléchargez la version compilée pour linux au format .tar.gz (64 Ko)

Le programme d'installation a été créé à l'aide d'Inno Setup. Pour plus d'informations, voir le cours Créer une installation.

Example of certificate of achievement
Example of certificate of achievement