A word list became a book. Then it became a game.

A list of words is not a puzzle book yet. It needs a grid, a set of placements, a page someone can read, an answer they can check, and enough variety to make the next page worth turning.

BOOP stands for Book Of Organized Puzzles. It began as a Python command-line generator for word-search books. The first web version put a React form in front of that generator. It could produce a PDF, but a successful download was not the whole product.

Before there was a Play button

The original program groups words by topic, filters them by length and samples sets for the requested puzzles. Placement attempts build grids; the rendering path produces puzzle and solution SVGs, then assembles covers, topic sections and answer pages into a book.

The placement routine builds on Christian Hill’s SciPython word-search article. That credit belongs in the story because the interesting work in a product is often connecting an existing algorithm to all the decisions around it.

Random generation has real failure cases. A word pool can be too small, or a requested set can fail to fit. The web backend returns an explicit placement error rather than quietly delivering a book with missing puzzles. It also gives each generation request its own temporary directory so two books do not mix intermediate files.

The rebuild was about finishing

The June 2026 Finish-Up-A-Thon gave me a reason to revisit what already existed. In my published development notes, I described the difference between the generator working and the application feeling finished: feedback, accessibility, a coherent visual identity and a mobile experience all needed attention.

The paper-inspired design now belongs to the product. It fits the thing being made, rather than treating book generation as another generic upload form. People can choose built-in or custom words and artwork, configure book settings, inspect examples and see progress while generation runs.

The README records a useful, specific cleanup result: one generated Wordo sample PDF went from 26.8 MB to under 0.5 MB. That is a documented example, not a promise about the size of every possible book.

Then the browser became the puzzle

The biggest change was allowing someone to play without first generating a document. Play brings its own requirements: mouse and touch selection, keyboard controls, difficulty choices, a timer, hints and progress that survives a refresh.

A printable puzzle does not need to remember where a person dragged their finger. A browser game does. The current play flow includes six modes, including a circular Bonus variant, and local progress so the interaction can continue after leaving the page.

Create and Play share the idea of arranging words, but they are different products from the user’s perspective. One ends with an artifact to print or share. The other keeps the interaction on the screen.

Keep the earlier version in the story

The original CLI is archived, while BOOP-web contains the later development. A pre-Finish-Up tag preserves the earlier web state, giving the visual and interaction changes a real point of comparison.

The frontend and Python generation backend are deployed separately. An available homepage alone is not evidence that every book-generation path is healthy; the repository remains the place for current backend setup and deployment information.

What I like about BOOP is the change in the question. At first it was “can this generate a puzzle?” Later it became “would someone enjoy spending time with it?” The algorithm still matters. So does everything that happens before and after it.