42 (VII): so_long, el primer juego

Después de contar instrucciones con push_swap, so_long fue la recompensa: el primer proyecto donde el resultado se ve. Un juego 2D con minilibX, la librería gráfica de 42: una ventana, sprites, un personaje que se mueve con el teclado, coleccionables que recoger y una salida. Parece una excusa para jugar mientras trabajas, y un poco lo es, pero bajo la superficie hay más sistema de lo que parece.

Dónde estaba el trabajo de verdad

El juego en sí es la parte sencilla. El grueso era todo lo que hay alrededor: leer un mapa en formato .ber, validarlo (rectangular, cerrado por muros, con exactamente un jugador, una salida y al menos un coleccionable) y comprobar que sea jugable, es decir, que exista camino real hasta todos los coleccionables y la salida. Para eso usé un flood fill: recorre el mapa desde la posición inicial y marca lo alcanzable; si algo queda fuera, el mapa no sirve. Después venían los eventos de teclado, el contador de movimientos, los sprites direccionales — el jugador mira hacia donde camina — y cerrarlo todo limpio: ESC, la cruz de la ventana o fin de partida, sin ningún leak.

Cómo lo monté

Separé el código en módulos pequeños: carga del mapa, validación, jugabilidad, renderizado, movimientos, sprites, ventana y gestión de memoria. La norma de 42 (funciones de máximo veinticinco líneas) ayuda más de lo que parece en un proyecto gráfico: te obliga a hacer piezas que se pueden probar por separado. De hecho, en el repositorio, 42_so_long, hay una carpeta de mapas con una decena de variantes de error pensadas para poner a prueba la validación: mapas abiertos, con dos jugadores, sin salida, con coleccionables inalcanzables. Probar el validador con mapas rotos me dio más confianza que jugar al juego en sí.

Un detalle práctico: minilibX no es una librería moderna. Trabajé con la variante de OpenGL para macOS y dejé preparadas la de Linux y una alternativa, para que el código se pueda compilar en otras máquinas. Hay poca documentación, y buena parte del primer día se fue en descubrir cómo se carga un sprite y cómo funciona el bucle de eventos a base de pruebas.

Qué me llevo

Salí con dos ideas claras. La primera: en cualquier programa gráfico, el renderizado es la parte fácil; la robustez — validación de entrada, memoria, salidas limpias — es donde está el trabajo. La segunda: programar por eventos cambia la manera de pensar. Ya no escribo un programa que va de arriba abajo, sino un bucle que reacciona; me sirvió después más de lo que esperaba. Y sí: jugué. Recoger todas las monedas y salir por la puerta es más satisfactorio cuando la ventana es cosa tuya.