← Retour aux projets

so_long

GitHub

so_long est mon premier projet graphique du cursus 42 : un petit jeu 2D en C construit avec la MiniLibX. L’objectif est de manipuler des textures/sprites, d’ouvrir une fenêtre, de gérer des événements clavier/souris, et de développer un gameplay simple mais complet.

L’objectif est double :

  • Apprendre les bases d’un moteur 2D “tile-based” : rendu, boucle d’événements, collisions.
  • Écrire un programme robuste grâce à une validation stricte des cartes .ber (format, règles, chemin jouable).

Principe

Le programme prend une carte .ber en argument et lance une partie :

  1. Parser la map et vérifier qu’elle respecte les règles (rectangulaire, murs, éléments obligatoires, etc.).
  2. Charger les textures et afficher la carte en vue 2D.
  3. Déplacer le joueur avec W/A/S/D (et/ou flèches selon ton implémentation).
  4. Empêcher le passage à travers les murs.
  5. Compter chaque mouvement et l’afficher (au minimum dans le shell).
  6. La partie est gagnée quand tous les collectibles C sont récupérés et que le joueur atteint la sortie E.

Points importants

  • Map validation :

  • caractères autorisés : 0 (vide), 1 (mur), C (collectible), E (exit), P (player)

  • exactement 1 P, exactement 1 E, au moins 1 C
  • map rectangulaire et fermée par des murs
  • existence d’un chemin valide (collectibles + sortie accessibles)

  • Gestion des événements :

  • ESC et la croix de la fenêtre ferment proprement le programme

  • Rendu : utilisation des images MiniLibX (tiles/sprites) + refresh propre.

Contraintes respectées

  • Langage : C
  • Lib graphique : MiniLibX
  • I/O & erreurs : open/close/read/write, perror/strerror, exit
  • Mémoire : malloc/free (zéro leak)
  • Build : Makefile standard (pas de relink)
  • Libft autorisée (si intégrée)

Ce que ça m’a apporté

so_long m’a appris à relier plusieurs briques “systèmes” dans un projet concret : parsing d’un format de fichier, validation stricte, gestion mémoire, rendu graphique, et boucle d’événements. C’est aussi un bon exercice d’architecture : séparer lecture/validation, état du jeu, rendu, et inputs pour garder un code lisible et évolutif.

Bonus

  • Ennemis/patrouilles : le joueur peut perdre au contact.
  • Animations de sprites.
  • Compteur de mouvements affiché directement dans la fenêtre.

Objectif

Collecter tous les C de la carte puis atteindre la sortie E.

Contrôles

  • Déplacements : W, A, S, D (et/ou flèches si tu l’as ajouté)
  • Quitter : ESC ou fermeture de la fenêtre (croix)

Map .ber

Caractères autorisés :

  • 0 : case vide
  • 1 : mur
  • C : collectible
  • E : sortie
  • P : position de départ

Contraintes :

  • 1 P, 1 E, au moins 1 C
  • carte rectangulaire
  • carte fermée par des murs
  • existence d’un chemin valide (jouable)

En cas d’erreur : quitter proprement avec Error\n + message explicite.

Découpage conseillé

  • Parsing : lecture du fichier .ber, création d’une grille char**

  • Validation :

  • forme rectangulaire

  • bordures en 1
  • comptage des éléments (P/E/C)
  • caractères invalides
  • validité du chemin (flood fill / BFS)
  • Game state : position joueur, nb collectibles restants, compteur de moves
  • Render : draw tile map + overlay joueur (sprites)
  • Input : hooks MiniLibX (key press / close window)

Vérification du chemin (idée)

  • Dupliquer la map en mémoire
  • Lancer un flood fill depuis P
  • Marquer tout ce qui est atteignable

  • Vérifier :

  • tous les C atteignables

  • E atteignable

Gestion propre des ressources

  • Libérer : map, textures/images MLX, window/display
  • Gérer les erreurs tôt (fail fast) avec cleanup