Mètodes
42 (VII): so_long, el primer joc
Un joc 2D amb minilibX: sprites, events de teclat i el bucle de renderitzat. La part més divertida fins ara.
Després de comptar instruccions amb push_swap, so_long va ser la recompensa: el primer projecte on el resultat es veu. Un joc 2D amb minilibX, la llibreria gràfica de 42: una finestra, sprites, un personatge que es mou amb el teclat, col·leccionables que recollir i una sortida. Sembla una excusa per jugar mentre treballes, i una mica ho és, però sota la superfície hi ha més sistema del que sembla.
On era la feina de veritat
El joc en si és la part senzilla. El gruix era tot el que hi ha al voltant: llegir un mapa en format .ber, validar-lo (rectangular, tancat per parets, amb exactament un jugador, una sortida i com a mínim un col·leccionable) i comprovar que sigui jugable, és a dir, que existeixi camí real fins a tots els col·leccionables i la sortida. Per això vaig fer servir un flood fill: recorre el mapa des de la posició inicial i marca el que és assolible; si en queda per fora, el mapa no serveix. Després venien els events de teclat, el comptador de moviments, els sprites direccionals — el jugador mira cap on camina — i tancar-ho tot net: ESC, la creu de la finestra o final de partida, sense cap leak.
Com el vaig muntar
Vaig separar el codi en mòduls petits: càrrega del mapa, validació, jugabilitat, renderitzat, moviments, sprites, finestra i gestió de memòria. La norma de 42 (funcions de màxim vint-i-cinc línies) ajuda més del que sembla en un projecte gràfic: et força a fer peces que es poden provar per separat. De fet, al repositori, 42_so_long, hi ha una carpeta de mapes amb una desena de variants d’error pensades per posar a prova la validació: mapes oberts, amb dos jugadors, sense sortida, amb col·leccionables inassolibles. Provar el validador amb mapes trencats em va donar més confiança que jugar el joc mateix.
Un detall pràctic: minilibX no és una llibreria moderna. Vaig treballar amb la variant d’OpenGL per a macOS i vaig deixar preparades la de Linux i una d’alternativa, perquè el codi es pugui compilar en altres màquines. Documentació n’hi ha poca, i bona part del primer dia va anar a descobrir com es carrega un sprite i com funciona el bucle d’events a base de proves.
Què m’enduc
Vaig sortir amb dues idees clares. La primera: en qualsevol programa gràfic, el renderitzat és la part fàcil; la robustesa — validació d’entrada, memòria, sortides netes — és on hi ha la feina. La segona: programar per events canvia la manera de pensar. Ja no escric un programa que va de dalt a baix, sinó un bucle que reacciona; em va servir després més del que esperava. I sí: hi vaig jugar. Recollir totes les monedes i sortir és més satisfactori quan la finestra és cosa teva.