how is it decided that the solution is a valid labyrinth? I mean, is it the number of offshoots that the right path has? is it something to do with the ratio of 1s to 0s?
–
Kae VerensMar 25 '12 at 21:16

2

When you say "The labyrinth must be created randomly", what limitations should we infer? I presume, for example, that you don't intend to allow, as a literal reading of the rules currently does, a program which chooses between two hard-coded outputs at random.
–
Peter TaylorMar 25 '12 at 21:41

C++ C, about 1000670643395297 248 chars

How it works: The program uses Brownian Motion to generate solutions. The start point is set. Then, a random point is selected and repeatedly moved randomly until it touches one and only one point on the start branch. The point is then set, and if it also touches the end point, the program exits and the matrix displayed. Since no point can join two branches, there is only one path through the labyrinth. The program uses the rand function, and a command line integer argument as the seed, so with a sufficient rand function it should be possible to eventually generate all valid labyrinths (this algorithm will not create unconnected areas however, so it won't generate all possible labyrinths).

Brownian motion was dropped since it turned out to be unneeded and it's removal simplifies the code significantly. I do think it made nicer labyrinths though. Likewise, the seed argument was dropped, since requiring a stateless random number generator makes more sense to me than a 128-bit seed.

It is possible for the program to get stuck in an infinite loop, since it is possible for situations where any point added to the branches would create multiple paths. This is fixable, but I think that it is rare enough to not be a concern for code golf.

Somehow, a simple path, with no forks or decision nodes, doesn't seem to qualify as a true labyrinth. Try adding some blind alleys.
–
David CarraherApr 8 '12 at 15:25

@David Carraher The algorithm does generate dead ends and branching paths as shown in the sample. Not allowing a new point to connect two already existing branches simply prevents multiple solutions or cycles in the labyrinth.
–
Sir_LagsalotApr 9 '12 at 14:35

JavaScript, 874816788686682668 637 characters

this one works by starting from point [0,0,0] and randomly adding attaching one more 0 next to an 0 wherever allowed (allowed==the new 0 is not next to any other 0s except the originator) until there are no more possible additions.

if any new 0 is next to the exit point (x*y*z == 48) then we open up the exit.

Originally, I produced a path from {1,1,1} to {5,5,5} but because there were no possible wrong turns to be made, I introduced forks or "decision points" (vertices of degree >2) where one would need to decide which way to go. The result is a true maze or labyrinth.

The "blind alleys" were far more challenging to solve than finding a simple, direct path. The most challenging thing was to eliminate cycles within the path while allowing cycles off the solution path.

The following two lines of code are only used for rendering the drawn graphs, so the code does not count, as it is not employed in the solution.

The picture below shows the labyrinth or maze that corresponds to the solution ({{"ooxoo",...}} displayed above:

Here is the same labyrinth inserted in a 5x5x5 GridGraph. The numbered vertices are nodes on the shortest path out of the labyrinth. Note the forks or decision points at 34, 64, and 114.
I'll include the code used for rendering the graph even though it is not part of the solution:

Original solution (432 char, Produced a path but not a true maze or labyrinth)

Imagine a 5x5x5 large solid cube made up of distinct unit cubes. The following begins without unit cubes at {1,1,1} and {5,5,5}, since we know they must be part of the solution. Then it removes random cubes until there is an unimpeded path from {1,1,1} to {5,5,5}.

The "labyrinth" is the shortest path (if more than one is possible) given the unit cubes that have been removed.

Nice update, I like that your updated solution allows cycles on non-solution paths, it makes for a more confusing labyrinth.
–
Sir_LagsalotApr 9 '12 at 14:46

Thanks. I would still like to have the solution path itself be more likely to veer away from the final node from time to time. This is presently discouraged (but not fully prevented) by FindShortestPath.
–
David CarraherApr 9 '12 at 15:58

I'm not too familiar with matlab, but could you do something like FindShortestPath, add a bias against each node in the shortest path, and then run FindShortestPath again taking into account the bias so that it will avoid nodes in the shortest solution? This could be done iteratively too. I'd be interested in seeing what type of path that would produce.
–
Sir_LagsalotApr 9 '12 at 17:13