In 1994 I wrote a game. I was learning Java — not JavaScript, Java — and the AWT toolkit was the only way to put graphics on screen. Applets ran in browsers. This was before CSS existed.
The game was a marble puzzle called Cojones. You move colored marbles around a grid, trying to line up three or more of the same color before the board fills up. It's similar to Color Lines or Lines 98 if you've played those. Simple rules, surprisingly deep strategy.

What Made It Matter
I didn't know how to program when I started. I knew loops and if-statements. That's it. Building this game taught me things that textbooks hadn't:
Adjacency. How do you know which squares a marble can reach? You can't just check if the destination is empty — you need a path of empty squares connecting them. I didn't know the word "BFS" but I reinvented it, badly, tracing paths through the grid cell by cell.
Legal moves. When you select a marble, which cells should light up as valid targets? This is pathfinding from a single source to all reachable cells. I remember the moment it clicked — flood fill from the selected cell, stop at walls and other marbles, mark everything you touch.
Pattern matching. After every move, scan the board for three-or-more-in-a-row. Horizontal and vertical. This sounds trivial but I remember struggling with the edge cases — runs that touch the border, overlapping horizontal and vertical matches on the same marble.
Game state. The turn cycle: move marble, check for matches, remove matches, spawn new marbles, check for matches again (spawned marbles can create lines too), check for game over. Getting this sequence right, with each step depending on the last, was my first encounter with state machines.
Windowed UI. Drawing to a canvas. Click handlers. Coordinates. The gap between "the user clicked at pixel (247, 183)" and "the user clicked on grid cell (3, 4)." Coordinate transformation. Hit testing.
These are the building blocks of every program I've written since. I just didn't know it at the time. I was a kid making marbles move around a grid.
Thirty Years Later
Last week I described the game to Claude and asked it to rebuild it. One prompt. The entire game — grid rendering, marble placement, BFS pathfinding, match detection, animations, scoring, game over — came back as a single HTML file. Vanilla JavaScript and SVG. No build step, no dependencies.
It took me weeks of late nights in 1994. It took one prompt in 2026.
I don't say this to diminish the original effort. The weeks I spent in 1994 were the most important weeks of my programming education. The BFS I reinvented badly was more valuable than any BFS I've copy-pasted since, because I didn't know what I was inventing. I was just trying to figure out why my marble couldn't get to that square.
But the fact that a conversational prompt can now produce what took weeks of focused effort — that's worth sitting with. The knowledge I built over those weeks is still mine. The struggle was the education. The game was just the proof.
The Game
Select a marble, then click an empty cell to move it. The marble slides along empty cells (it can't jump over other marbles). Line up three or more of the same color — horizontally or vertically — to clear them and score points. Three new marbles spawn every turn. The board is 7×7 by default, adjustable up to 12×12. Game ends when the board fills up.
The source is a single HTML file — no server, no framework. Open it in any browser.