I canâ(TM)t see any reference to the size of the table but I sounds a bit to me like something you could do buy drawing some examples on paper, build the solution table from that and then make some test code to try out many iterations.
But it is a great example of the tricks you had to use one the old machines. I can imagine it is an lost art these days with everything make used game engines.

"intrigued the researchers for how early programmers solved the problem of drawing a solvable maze that is drawn procedurally."

These days most younger coders seem to be intrigued about how to write code that doesn't require a dozen different frameworks, half of system memory and 99% CPU just to write Hello World.

Someone wrote Chess in 1K (yes ONE K) for the ZX81 back in the 80s. Granted it wasn't a complete version but it played a basic game.

For a dungeon type game. I forget many of the specifics, but we all used to play an online dungeon game called Milieu. The code for it was considered a big deal and everyone seemed to want to code up a similar game.

Supposedly a big pain was creating dungeon maps with variation but without having to generate the map and store it for each level, but have each new dungeon game have a unique map.

This guy Don Sidoroff came up with some kind of semi-random map generator that could take some kind of seed value and generate the same map for a level based on the seed. The seeds for each level were saved with the game, and the seeds for a particular game were more randomly (or less pseudo-randomly) generated, so that the odds of any game having a level identical to some other game were basically non-existent over any normal level of play.

It's probably considered a not interesting problem in today's computing environment, but it seemed like a big deal then to have a procedurally generated map that could easily be generated on the fly without having to dedicate a lot of memory to holding the map.

Real Programmers write in FORTRAN. Maybe they do now, in this decadent era of Lite beer, hand calculators, and ``user-friendly'' software but back in the Good Old Days, when the term ``software'' sounded funny and Real Computers were made out of drums and vacuum tubes, Real Programmers wrote in machine code. Not FORTRAN. Not RATFOR. Not, even, assembly language. Machine Code. Raw, unadorned, inscrutable hexadecimal numbers. Directly.

https://www.cs.utah.edu/~elb/f... [utah.edu]

Obligatory post.

The game has you run "down" through a maze that scrolls upward, the maze is symmetrical consisting of rows of 16 blocks that can be either wall or free (and walls to both sides). The algorithm is tasked to provide the next bottom row consisting of 8 bits of information (mirrored to make 16).
For each block in the (left half of) new row the decision to make it free or wall is based on the two blocks left of it and the three blocks directly and diagonally above. These 5 bits point to the lookup table which decides if the block is free, wall, or decided by a random generator (for the first and last bock there are slight modifications introducing additional randomness).

The algorithm did not work perfectly, in the game "wall breakers" could be collected to open dead ends.

Two accounts (gained from interviews) about the origin of the maze algorithm are given:

Paul Allen Newell:
"Duncan and I went out for a beer and ended up coming up with this “problem” of wondering whether one could generate an endless maze that always had a solution’ and that ‘We worked out the algorithm and [...] I spent a weekend coding something up."

Steve Sidley (the programmer tasked with writing the game based on the algorithm):
"The basic maze generating routine had been partially written by a stoner who had left. I contacted him to try and understand what the maze generating algorithm did. He told me it came upon him when he was drunk and whacked out of his brain, he coded it up in assembly overnight before he passed out, but now could not for the life of him remember how the algorithm worked."