The Programming of Patrick's Parabox - Patrick Traynor (ThinkyCon 2025)

Patrick Traynor presents a lightning talk at ThinkyCon 2025 about interesting programming aspects behind the development of Patrick's Parabox.

• Parabox is a Sokoban game where boxes can contain other boxes. • Boxes can be pushed into and out of each other, nesting them in any configuration. • Some boxes can contain themselves directly, allowing repeated entering and exiting while keeping the same Sokoban logic.

• Instead of one two-dimensional array, there is one 2D array for every box in the game. • This forms a 2D array of pointers to 2D arrays. • Spots at edges link up to each other, and recursive levels use the same structure, with a box referring to itself.

The talk sets up the question of how to actually render a scene built on this nested data structure.

Everything is rendered in screen coordinates, anchored to a single reference rectangle representing the current view.

• A function called draw block draws a specific block and all its children within a given rectangle. • When a child contains other blocks, draw block is called again recursively on a smaller rectangle. • Recursion stops once blocks reach a size of one or two pixels.

• To render larger objects outside the current view, the square is conceptually moved out to the parent level, then the parent's parent, going out three levels total. • This produces a rectangle much bigger than the screen; most of it doesn't appear on screen, but it recurses back down correctly to the starting square.

As long as every block is positioned relative to its parent, with only one absolute coordinate (the anchor square), the rendering works out correctly.

Pushing a self-containing block into another box produces a shrinking animation, and the edges of the screen show a matching squishing effect on the outside world.

• The same draw block algorithm is used, keeping everything relative to the anchor point. • Instead of drawing the blue block at its real position, it is shifted down and scaled (shrunk or grown) before calling draw block again. • The same shifting and growing offsets apply when going out to the three parent levels.

Depth sorting is required to ensure the shrinking block is always drawn on top of other blocks like the red ones.

A quote from fellow Sokoban developer Marcos Donatini: "relative coordinates equals absolute bliss."

The crisp-looking large objects outside the screen are not vector graphics but large PNGs sized just big enough to avoid visible blurriness.

A chat question from Don asked why the algorithm goes out three parent levels instead of one.

• Going out only one parent would miss certain elements, like a player token two layers out. • Going out two layers would cover that case. • Three is not a magic number — it's simply enough levels to cover most common situations in the game.

Pseudocode of the explained rendering algorithm was shown for viewers to review.

Some levels have a block containing multiple copies of itself; the existing draw block algorithm handles this without issue.

Initially, a player object appeared instantly at all copies before shrinking down, which looked bad.

• A scissor mode (common in graphics APIs) was used to clamp children into the square. • A special case was added to avoid scaling the big rectangle down to center; instead a positional-only approach was used that still gets clamped.

The fix produced a natural-looking effect while preserving the recursive visual response to player input, after many bugs during development.

Some blocks contain themselves horizontally flipped: exiting from the left results in appearing on the right, and vice versa.

This is straightforward to implement by swapping the logical exit positions.

• The draw block function gains a true/false parameter for whether to draw a block and its children flipped. • Implementing this correctly required code snippets throughout the codebase multiplying by -1 and flipping flags.

This was unexpectedly hard to program; a planned 90° rotation feature was dropped because horizontal flipping alone was difficult enough.

Another mechanic allows the player itself to contain other blocks.

The player was refactored to be the same object as a block, distinguished only by a boolean flag for whether it is the player.

Both Sokoban logic and rendering logic worked with this approach with relative ease, in contrast to the difficulty of the horizontal flip feature.

This mechanic was implemented very early in development.

Patrick demonstrates the level editor tools he built, noting they are not strictly programming but are related.

• Create new blocks and edit their children. • Place blocks inside other blocks and take them back out. • A referential block is represented simply by the letter R, acting like a pointer.

• A hotkey reloads the game and plays the level for quick iteration. • Horizontal and vertical flip keys flip an object and all its children. • A hotkey jumps to view the level in the hub, and levels can be reordered quickly.

A hotkey increases or decreases the size of blocks, aiding rapid iteration on puzzle difficulty and design.

Patrick thanks the audience for making it through the talk and shares his contact information.

A chat question from Scrupulous asked whether anyone else helped with the code.

• The porting studio Plastic Fern handled the console ports of the game, including the Switch version. • There were some performance optimizations for the port, but no huge changes; Patrick notes he is not an optimization expert.

Patrick confirms the code for the base game was entirely his own work.