42 (VII): so_long, the first game

After counting instructions with push_swap (the previous project, 42 (VI): push_swap, sorting with one hand tied), so_long was the reward: the first project where you can actually see the result. A 2D game with minilibX, 42's graphics library: a window, sprites (the images for the character and the objects), a character that moves with the keyboard, collectibles to pick up, and an exit. It looks like an excuse to play while you work, and it partly is, but under the surface there's more system than it seems.

Where the real work was

The game itself is the easy part. The bulk was everything around it: reading a map in .ber format, validating it (rectangular, enclosed by walls, with exactly one player, one exit, and at least one collectible) and checking that it's playable, meaning that there's a real path to all the collectibles and the exit. For this I used a flood fill (an algorithm that traverses the map from the starting position and marks what is reachable): if any remain outside it, the map isn't valid. Then came the keyboard events (the program sleeps and reacts when you press a key), the move counter, the directional sprites — the player faces the direction they're walking — and wrapping everything up cleanly: ESC, the window close button, or end of game, without any leak (memory the program allocates and never returns).

How I built it

I split the code into small modules: map loading, validation, gameplay, rendering, movement, sprites, window, and memory management. The 42 norm (functions of at most twenty-five lines) helps more than it seems in a graphics project: it forces you to build pieces that can be tested independently. In fact, in the repository, 42_so_long, there's a folder of maps with about ten error variants designed to put the validation to the test: open maps, with two players, without an exit, with unreachable collectibles. Testing the validator with broken maps gave me more confidence than playing the game itself.

A practical detail: minilibX isn't a modern library. I worked with the OpenGL variant for macOS and prepared the Linux one and an alternative, so the code can be compiled on other machines. There's little documentation, and a good part of the first day went into discovering how a sprite is loaded and how the event loop works through trial and error.

What I take away

I came away with two clear ideas. The first: in any graphical program, rendering is the easy part; the robustness — input validation, memory, clean exits — is where the work is. The second: event-driven programming changes the way you think. You no longer write a program that runs top to bottom, but a loop that reacts; I confirmed this in the next project, 42 (VIII): philosophers, threads at the table, where it served me more than I expected. And yes: I played it. Collecting all the coins and getting to the exit is more satisfying when the window is your own doing.