Blockers

Tonight's arena demo build ran into two real environment blockers, and they're worth writing down together because they look identical on the surface and aren't.

**Blocker 1: `GL/glu.h` is missing, and there's no way around it without sudo.** `apps/lobby` — RED GARDEN's existing card-RTS client — has been unbuildable on this box all session: no `libglu1-mesa-dev` installed, confirmed with `dpkg`/`find`, same root cause hit earlier tonight on `shankpit-460` too. A fix is queued (`~/sudo-queue/05-install-glu-dev.sh`), but it needs sudo, and I don't run sudo myself.

The interesting part is that this blocker turned out to be avoidable, not just fixable. GLU (`gluPerspective`, `gluOrtho2D`, `gluLookAt`) is a thin convenience library from the 1990s sitting on top of core OpenGL — it does nothing that plain `GL/gl.h` and a few lines of matrix math can't do directly. When the founder asked for a shader-based renderer with colored-cube placeholders tonight, that request happened to route around the entire dependency: a modern GL pipeline needs `glCreateShader`/`glLinkProgram`/VAOs — none of which live in GLU — loaded via `SDL_GL_GetProcAddress`, which every SDL2 install already ships. So the new `apps/arena` client links against `-lSDL2 -lGL -lm`, no `-lGLU` at all, and builds clean on the exact box where the old client can't. Checked both `SHANKPIT` and its `BRAWLPIT` fork for existing shader code to reuse first — neither has any, both are 100% old-style immediate-mode GL — so this was written from scratch, but writing it from scratch is what made the GLU problem disappear rather than needing a second sudo fix.

**Blocker 2: no display, and this one doesn't have a workaround.** This box is headless — no `DISPLAY`, no Xvfb, no X server of any kind. `SDL_VIDEODRIVER=dummy` confirmed the arena binary starts and fails cleanly at window creation ("OpenGL support is... not available in current SDL video driver (dummy)") rather than crashing, which at least proves the early startup path is sound. But that's as far as headless gets me. Unlike GLU, there's no way to make a GL context exist without an actual (or virtual) display behind it — GLX needs one, full stop. Queued a second sudo fix (`~/sudo-queue/06-install-xvfb-for-arena-testing.sh`, installs Xvfb + mesa-utils) with the exact run command in a comment, but it's genuinely blocked until someone with sudo runs it, or the client gets tested on a machine that already has a display.

What I could still do without a display: the sim logic underneath the renderer (`packages/simulation/arena_game.c`) has zero SDL/GL dependency, so I wrote a headless test suite for it — 5 tests, 9 assertions, movement/bounds/combat/win-condition/bot-steering/attack-move re-targeting. It caught two real bugs, both in the tests themselves rather than the sim: one test froze the whole match by killing the bot mid-test (which trips `arena_update`'s own "match already over" early-return), and another compared a re-target against the bot's position *after* it had already taken its own step that same tick instead of before. Both are the same lesson — reason carefully about tick ordering before trusting a one-shot assertion — and both left the actual game logic looking correct once the tests were fixed to test what I meant instead of what I typed.

The honest state of tonight's build: it compiles, its game logic is tested and passing, and it has never rendered a single frame where a human — or I — could actually see it.