This shows how far you can get when you take something apparently simple, and run with it! - even if you sometimes end up running in circles.

Particulary interesting are the various alternative definitions of complexity.

For this one:"take the average of these look-ahead lengths (L) and count the number of branch points (N). The maze score will be L^N." Why L^N? and not L*N, for instance. Even more plausibly, one could look at Max(L) (it doesn't matter how often one has to look for dead-ends - but their lengths seems crucial). Similarly, rather than the absolute number of loop(-traps), the longest one should matter most. There may be simple ways to integrate these two, and the simplest may just be Max(L, MaxLoopLength).

Psychologically, if the solver's working memory is the limiting criterion for finding a solution for a maze, we can expect that above lengths of 7, humans (not endowed with pencils or Mathematica or the like) start having problems. Then again, perhaps we should also take into account the number of nodes in the sub-tree that need to be evaluated before proceeding...

Also worth mentioning--

Zsombor and I have talked to Stephen Wolfram about compounding an edited volume "Multicomputational approach to Games and Puzzles". The first two or three chapters would probably be reprints of blog posts by Stephen Wolfram:

• Multicomputation: A fourth paradigm
• Multicomputation with numbers
• Multicomputational games and puzzles

The basic idea, per SW, is that each subsequent chapter could deal with a different game or different class of games. Then the entire book can aim to have a diversity of content, something for everyone. But there are so many games, we probably won't get everyone's favorite, Sorry!

Actually, we are also really looking for next steps to take in the Multicomputational paradigm, so the solution to a particular maze or set of mazes (as usual) is worth slightly less than a new function that could possibly be entered into System functionality. For example, here's a stack exchange question, which (despite some of the strongly-stated followup comments) doesn't seem to be getting a clear answer. Did anyone with a long-winded theoretical response even bother to write down something like a transfer matrix as an answer? Isn't it just $(13/142, 112/213, 163/426)$? Is there some more natural way to compute these numbers in Wolfram Language?

Here's how I did the calculation (this time showing some code):

After more testing, and before the book is done, this DirectedGraphTransferMatrix (discovered and refined specifically for this post) will need to go to WFR. Then the issue of not showing code in the book can be simply avoided by linking to the WFR page.

Finally, since the book is about games, we should make more of an effort to make sure the content isn't just about multicomputation. For example, based on calculations such as seen above, "mergial graphs" (like branchial graphs, but extracted from the ReverseGraph) could possibly be relevant. However, in the games context, questions of relevance need to be answered by finding how strategy can possibly be influenced by the claimed-important concept. Zsombor and hopefully Ed Pegg will be helping with content editing, since both of them are knowledgeable experts and great enthusiasts.

The proposed book could end up being a lot of fun, but it depends on what good submissions we get. Soon we will configure a means to submit proposals and / or rough drafts, then we will be off to the races!