ATTENTION : Cette page peut être modifiée à tout instant, pensez à la consulter régulièrement
Dernière modification : 04/01/16

Description

L'objectif est de proposer une implémentation en C du célèbre jeu Candy Crush Saga. Ce jeu consiste à éliminer des bonbons d’une grille de jeu en combinant de 3 à 5 bonbons de même catégorie afin de gagner des points. La combinaison est soit verticale, soit horizontale, soit en "T" (en utilisant 5 bonbons), soit en "L" (en utilisant 5 bonbons).

Lorsqu'une combinaison est réalisée, les bonbons correspondants sont effacés de la grille de jeu. La grille de jeu est toujours remplie de bonbons. Pour ce faire toute case vide est remplacée par le contenu de la case au-dessus d’elle, cette dernière devenant vide (à son tour, elle sera remplacée). Les cases vides de la ligne la plus haute de la grille sont remplacées par des bonbons insérés aléatoirement.

Les combinaisons sont obtenues en échangeant de place des paires de bonbons voisins (verticalement ou horizontalement). Seuls les échanges créant une combinaison sont autorisés. S'il n'y a plus de combinaisons valides, la grille est regénérée avec le même ensemble de bonbons mais disposé aléatoirement. Le joueur possède un nombre limité et fixé à l'avance d'échanges autorisés et un score à atteindre pour gagner le niveau correspondant. Les combinaisons de plus de 3 bonbons permettent, en plus de créer des cases vides, de créer un bonbon sépcial dans l’une des cases vidées.

Une combinaison de 4 bonbons sur une ligne ou une colonne génère un bonbon rayé verticalement ou horozontalement. L'utilisation d'un bonbon rayé dans une combinaison efface la ligne ou la colonne entière (en suivant le sens des rayures).

Une combinaison de 5 bonbons en "T" ou "L" génère un bonbon explosif. L'utilisation d'un bonbon explosif dans une combinaison provoque une explosion supprimant les bonbons environnant (le carré 3x3 entourant le bonbon explosif).

Une combinaison de 5 bonbons en ligne ou colonne génère un bonbon multi-couleur. L'utilisation d'un bonbon multi-couleur dans une combinaison (même de taille 2) éliminera tous les bonbons de ce type de la grille de jeu.

Conseils techniques et pratiques

  • Interdiction d'utiliser des variables globales (variables déclarées en dehors d'une fonction).
  • Pour vérifier qu'il n'y a pas de fuite mémoire, ou pour trouver rapidement d'où vient une "segmentation fault", vous avez respectivement les outils valgrind et gdb. Un petit lien pour comprendre l'interet. Vous trouverez de nombreux tutoriels sur leur utilisation grâce à google, bing ou yahoo. Vos projets seront systèmatiquement soumis à valgrind par moi même pour vérifier qu'il n'y a pas de fuites mémoire.
  • Testez votre projet dans les conditions d'évaluation avant de l'envoyer : creez un répertoire temporaire, placez-y une copie de l'archive, décompressez la, suivez les étapes décrites dans votre user.pdf. Vérifiez que tout se passe bien. Testez sur une machine de l'école. Si vous rencontrez un problème (code qui "marche" sur votre pc mais pas à l'école), avertissez moi avant la soutenance (suffisament tot pour que je puisse trouver une solution). Les projets seront évalués sous Linux.

Bibliothèque SDL

Vous trouverez ici un petit bout de code qui montre comment utiliser la librairie sdl (seule librairie autorisée). Ce bout de code et le fichier de sprites associé n'ont pour seul but que de vous donner un exemple. Il ne sagit pas du tout de quelquechose à intégrer à votre projet, ni du fichier de sprite à utiliser pour votre jeu (je vous laisse être créatif ou je vous laisse taper "sprites" dans google image, mais attention aux licences d'utilisation des images).
  • La compilation se fait à l'aide de la commande suivante
    gcc -Wall -pedantic -ansi crush.c `sdl-config --cflags --libs`
    
    (le paquet libsdl-dev doit être installé sur votre distribution). À l'ESIEE, elle est installée dans les salles 5004, 5006, 5008, 5101 et 5103.
  • Ici le fichier de sprites (sprite.bmp) contient 6 photos, toutes de la même taille (75x75) plus les sprites à utiliser pour entourer deux cases verticales ou horyzontales. Le programme affiche lui 9 "cases" de 75x75, il choisit aléatoirement une des 6 images pour chaque case. Le programme répond aux touches clavier : les fleches déplacent la selection et la touche espace change son orientation (verticale/horyzontale).
  • Pour l'affichage de texte, vous devrez vous inspirer de l'exemple et utiliser des sprites (cad une image contenant des représentations graphiques de vos lettres).
  • Ce code n'est pas à copier, il est la pour illustrer le fonctionnement de la bibliothèque. C'est un très mauvais code (pas de constante, tout dans le main etc... c'est presque un exemple de ce qu'il ne faut pas faire en fait).

Conditions de rendu

Rendu

  • le projet doit être envoyé par mail, depuis une adresse ESIEE, au plus tard le to be defined... en avril
  • le sujet du mail doit commencer par [E3FRCRUSH LOGIN1 LOGIN2] où LOGIN1 et LOGIN2 sont a remplacer par les login ESIEE des deux membres du binome
  • le mail contient une unique pièce jointe, "login1_login2.tgz"
    • Pour creer une archive : tar czf archive.tgz REPERTOIRE (toujours archiver un repertoire et non une liste de fichiers)
    • Pour décrompresser une archive : tar xzf archive.tgz
  • Un seul trinome et/ou monome au plus sera accepté (aux délégués de me communiquer l(es) heureux élu(s) au plus tard début janvier)
  • Le projet sera évalué en partie au cours d'une soutenance. Les conditions spécifiques de cette soutenance vous seront commniquées ultérieurement, mais les deux membres d'un même binômes n'auront pas automatiquement la même note.

Contenu

L'archive, une fois décompressée, génèrera un unique dossier login1_login2/ contenant :
  • un sous dossier bin
  • un sous dossier src
  • un sous dossier doc

Le dossier doc devra contenir deux fichiers : user_manual.pdf dev_manual.pdf

user_manual.pdf decrit comment installer le programme à partir de l'archive, comment le lancer, les fonctionnalités du programme, les bugs... Bref, tout ce qu'un utilisateur du programme doit savoir.

dev_manual.pdf decrit comment est écrit le programme : les choix algorithmiques, le design du code, comment rajouter des fonctionnalités, des pistes pour corriger les bugs... Il doit permettre à un développeur de comprendre votre code et de le modifier. Il ne devra surtout pas contenir de code, même des petits bouts. Il peut éventuellement faire référence à un fichier source présent dans le répertoire src/. Ce document est très très important. Il est aussi important, voir plus, que le code lui même pour la notation.

Contenu des dossiers
  • Le dossier login1_login2/ devra contenir un fichier Makefile.
  • La commande make devra compiler les fichiers sources du répertoire src et placer (tous) les fichiers produits dans le répertoire bin (aucun fichier ne doit venir polluer le répertoire src)
  • "make clean" effacera les fichiers binaires, "make force" recompilera toutes les cibles.
  • La commande de compilation devra utiliser les options de gcc vues en cours : -ansi -pedantic -Wall, plus d'autres spécifiques à l'usage de la librarie sdl
  • Les projets qui ne compilent pas (error) ne sont pas corrigés.
  • Un point en moins par avertissements (warning).
  • "make e3frcrush" devra produire un executable "e3frcrush" (dans bin)
  • L'exécutable e3frcrush devra afficher son mode d'emploi s'il est appelé avec le paramètre --help. Le comportement du programme doit être le suivant:
    e3frcrush [--sprite file.bmp]
    
    l'argument optionnal --sprite permet de charger une version alternative du fichier de sprites. Les options seront gérées avec getopt_long().

Il est interdit d'utiliser du code externe et tout code commun à plusieurs projets vaudra zéro pour tous les projets concernés.