Jim Weirich <jim / weirichhouse.org> writes:

> I would suggest that your current test is too complicated.  I would
> start off with the goal of writing a maze solver that can solve really
> trivial mazes.  For example, my first four tests would probably have it
> solve the following four one step mazes:
>
>    ####    ###   ####   ###
>    #se#    #s#   #es#   #e#
>    ####    #e#   ####   #s#
>            ###          ###
>
> Then I would add tests to make sure it could solve multi-step mazes:
>
>    ########
>    #s----e#
>    ########
>
> Then I would make sure it could solve mazes with corners.
>
>    ######
>    #s---#
>    ####-#
>       #-#
>       #e#
>       ###
>
> Then finally I would make sure it can solve mazes that involve possible
> back tracking:
>
>    #####   #####
>    #e--#   #---#
>    ###-#   ###-#
>    #s--#   #s--#
>    ###-#   ###-#
>    #---#   #e--#
>    #####   #####
>
> At this point, I would suspect I have a fully general maze solver
> (although by the time I actually reach this point, I may have discovered
> other potential problems that may need further testing).  I might be
> ready to throw your test maze at the problem and see if it works.

I would at least add an maze with a loop, like:

  ########
  ####---#
  #s---#-#
  ####---#
  ####-###
  ####--e#
  ########

> The key is little steps that build upon the previous code base.  Write a
> test, write a little code.  Write a new test, write more code.  Repeat
> until the problem is solved.
>
> Sounds easy, and it is with practice.  But it does take some experience
> to get it down.
>
> Good luck.
>
> --
> -- Jim Weirich
--
Christian Neukirchen  <chneukirchen / gmail.com>  http://chneukirchen.org